【Kubernetes】ワークロードリソースについて【Deployment編】

前回の記事ではPodの作成をしましたが、実際は直接Podを作成したりすることはなく、ワークロードリソース上で管理することになります。
今回はそのワークロードリソースについて述べたいと思います。

ワークロード(Workloads)とは?

公式サイトを見てみましょう。

ワークロードとは、Kubernetes上で実行中のアプリケーションです。 ワークロードが1つのコンポーネントからなる場合でも、複数のコンポーネントが協調して動作する場合でも、KubernetesではそれらはPodの集合として実行されます。Kubernetesでは、Podはクラスター上で実行中のコンテナの集合として表されます。

公式サイト

つまりKubernetes上にデプロイされたPodの集合体をひとまとめにワークロードと呼ぶようです。そしてそれらを人に代わって管理するのがワークロードリソースなんだとか。

ワークロードリソース -Deployment-

いくつか種類があるようです。
今回の記事ではそのうちの1つであるDeploymentについて紹介します。

何それ美味しいの?

リソース(Podなど)のあるべき状態を定義します。
コンテナに障害が発生してPodが停止したときなど、あるべき状態から乖離した場合、Kubernetesが自動的に復旧(=あるべき状態に戻す)してくれます。(つまり美味しい)

今回も公式サイトに載っているyamlファイルを実装してみます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

上記のyamlについて補足します。
.metadata.nameフィールド(4行目)で設定した「nginx-deployment」と言う名前のDeploymentが定義されます。(この名前のルールが新たにできようなイメージ)
.spec.replicas(8行目)では維持したいPodの数を定義し、ここでは3つのPodを常に動かすことになります。
.spec.selector(9行目)では、このDeploymentで管理するPodを定義します。
ここでは「app」というラベルに「nginx」という値を含むPodをこのDeploymentの管理対象としています。
.spec.selector(12行目)以降はこのDeploymentで作成するPodのテンプレートです。本Deploymentの管理対象となるように、「app」というラベルが「nginx」という値で定義されています。

実装

では早速実装していきます。

kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created

Deploymentの一覧を取得してみます。

kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           48s

今回meta.nameで定義した「nginx-deployment」という名前のDeploymentが存在することが確認できます。

次に、spec.replicasで定義した数だけPodが存在するか確認します。

kubectl get pod       
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86dcfdf4c6-m5vnb   1/1     Running   0          55s
nginx-deployment-86dcfdf4c6-p7726   1/1     Running   0          55s
nginx-deployment-86dcfdf4c6-zbvwz   1/1     Running   0          55s

Podが3つあることが確認できました。

実験-Podをわざと消してみる-

Deploymentはあるべき姿を定義すると述べましたが、ではあるべき姿ではなくなった場合にどのような挙動を取るのか確認してみます。
replicasの数を3としているので、上記で取得したPodのうち一番上のやつをわざと消してみます。

kubectl delete pods nginx-deployment-86dcfdf4c6-m5vnb
pod "nginx-deployment-86dcfdf4c6-m5vnb" deleted

さて、改めてPod一覧を取得してみると

kubectl get pod                                      
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86dcfdf4c6-drwk4   1/1     Running   0          3s
nginx-deployment-86dcfdf4c6-p7726   1/1     Running   0          9m24s
nginx-deployment-86dcfdf4c6-zbvwz   1/1     Running   0          9m24s

Podの数をあるべき姿に戻すために自動的に1つ立ち上がりました。

後片付け

今回作成したリソースを削除します。

kubectl delete -f nginx-deployment.yaml         
deployment.apps "nginx-deployment" deleted

まとめ

PodなどのリソースはDeploymentによって管理され、yamlの中でPodを作成するときのテンプレートや維持すべき数を定義しました。
実際にDeploymentをデプロイ(?)し、あるべき姿から乖離させた時にちゃんと復旧するかの挙動を確認しました。

ご覧いただきありがとうございました。