はじめに

ReplicaSetは設定を変更することによって、レプリカの数を変更することができます。
今回はその動作を確認しました。

方法は二つあります。
1．kubectl scaleコマンドで変更する
2．マニフェストを書き換えて、kubectl applyコマンドで反映する

kubectl scaleコマンドで変更する

初期状態を確認します。

$ kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
sample-pod3-rzmhb   2/2     Running   0          38s   192.168.79.91    k8s-worker01   <none>           <none>
sample-pod3-tjsdm   2/2     Running   0          38s   192.168.69.220   k8s-worker02   <none>           <none>
sample-pod3-zmjkj   2/2     Running   0          38s   192.168.79.83    k8s-worker01   <none>           <none>
$ kubectl get rs -o wide
NAME          DESIRED   CURRENT   READY   AGE   CONTAINERS    IMAGES                      SELECTOR
sample-pod3   3         3         3       47s   nginx,redis   nginx:latest,redis:latest   app=nginx-redis

レプリカを 3 -> 5 にスケールさせます。

$ kubectl scale replicaset --replicas=5 sample-pod3
replicaset.apps/sample-pod3 scaled
$ kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
sample-pod3-bv9x8   2/2     Running   0          68s     192.168.79.87    k8s-worker01   <none>           <none>
sample-pod3-rzmhb   2/2     Running   0          2m42s   192.168.79.91    k8s-worker01   <none>           <none>
sample-pod3-tjsdm   2/2     Running   0          2m42s   192.168.69.220   k8s-worker02   <none>           <none>
sample-pod3-vg2g8   2/2     Running   0          68s     192.168.69.223   k8s-worker02   <none>           <none>
sample-pod3-zmjkj   2/2     Running   0          2m42s   192.168.79.83    k8s-worker01   <none>           <none>
$ kubectl get rs -o wide
NAME          DESIRED   CURRENT   READY   AGE     CONTAINERS    IMAGES                      SELECTOR
sample-pod3   5         5         5       2m37s   nginx,redis   nginx:latest,redis:latest   app=nginx-redis

レプリカが増えました。

Pod削除時の動作

ここで意図的にPodを削除して、セルフヒーリング機能が働くか確認してみます。

$ kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
sample-pod3-bv9x8   2/2     Running   0          68s     192.168.79.87    k8s-worker01   <none>           <none>
sample-pod3-rzmhb   2/2     Running   0          2m42s   192.168.79.91    k8s-worker01   <none>           <none>
sample-pod3-tjsdm   2/2     Running   0          2m42s   192.168.69.220   k8s-worker02   <none>           <none>
sample-pod3-vg2g8   2/2     Running   0          68s     192.168.69.223   k8s-worker02   <none>           <none>
sample-pod3-zmjkj   2/2     Running   0          2m42s   192.168.79.83    k8s-worker01   <none>           <none>
$ kubectl delete pod sample-pod3-rzmhb
pod "sample-pod3-rzmhb" deleted
$ kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
sample-pod3-bv9x8   2/2     Running   0          2m41s   192.168.79.87    k8s-worker01   <none>           <none>
sample-pod3-dgh4k   2/2     Running   0          9s      192.168.69.219   k8s-worker02   <none>           <none>
sample-pod3-tjsdm   2/2     Running   0          4m15s   192.168.69.220   k8s-worker02   <none>           <none>
sample-pod3-vg2g8   2/2     Running   0          2m41s   192.168.69.223   k8s-worker02   <none>           <none>
sample-pod3-zmjkj   2/2     Running   0          4m15s   192.168.79.83    k8s-worker01   <none>           <none>

分かりづらいんですが、二行目の「sample-pod3-rzmhb」を削除すると、「sample-pod3-dgh4k」が新たにデプロイされています。

これによって、kubectl scaleコマンドで設定したレプリカの数が、Masterサーバのマニュアルにも反映されていることが確認できます。

また、kubectl describeコマンドで、Podのデプロイ履歴も確認しておきます。

$ kubectl describe rs sample-pod3
Name:         sample-pod3
・・・
Events:
  Type    Reason            Age    From                   Message
  ----    ------            ----   ----                   -------
  Normal  SuccessfulCreate  4m47s  replicaset-controller  Created pod: sample-pod3-rzmhb　<-- 最初のデプロイ
  Normal  SuccessfulCreate  4m47s  replicaset-controller  Created pod: sample-pod3-tjsdm　<-- 最初のデプロイ
  Normal  SuccessfulCreate  4m47s  replicaset-controller  Created pod: sample-pod3-zmjkj　<-- 最初のデプロイ
  Normal  SuccessfulCreate  3m13s  replicaset-controller  Created pod: sample-pod3-vg2g8　<-- kubectl scaleでの追加
  Normal  SuccessfulCreate  3m13s  replicaset-controller  Created pod: sample-pod3-bv9x8　<-- kubectl scaleでの追加
  Normal  SuccessfulCreate  41s    replicaset-controller  Created pod: sample-pod3-dgh4k　<-- セルフヒーリング機能による追加

ReplicaSetの削除

kubectl scaleコマンドでスケールさせると、当然yamlファイルは更新していません。
kubectl scaleコマンドでスケールさせた後に、変更していないyamlファイルで削除できるのか確認してみました。

sampleReplicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sample-pod3
spec:
  replicas: 3  <-- レプリカの数は「3」
  selector:
    matchLabels:
      app: nginx-redis
  template:
    metadata:
      labels:
        app: nginx-redis
    spec:
      containers:
        - name: nginx
          image: nginx:latest
        - name: redis
          image: redis:latest

$ kubectl get rs -o wide
NAME          DESIRED   CURRENT   READY   AGE     CONTAINERS    IMAGES                      SELECTOR
sample-pod3   5         5         5       4m35s   nginx,redis   nginx:latest,redis:latest   app=nginx-redis

yamlファイルのレプリカ数は「3」、実際のレプリカ数は「5」です。

削除してみます。

$ kubectl delete -f sampleReplicaSet.yaml
replicaset.apps "sample-pod3" deleted
$ kubectl get pod
NAME                READY   STATUS        RESTARTS   AGE
sample-pod3-bv9x8   0/2     Terminating   0          17m
sample-pod3-dgh4k   0/2     Terminating   0          14m
sample-pod3-tjsdm   0/2     Terminating   0          18m
sample-pod3-vg2g8   0/2     Terminating   0          17m
sample-pod3-zmjkj   0/2     Terminating   0          18m
$ kubectl get rs
No resources found in default namespace.

削除されました。

マニフェストを書き換えて、kubectl applyコマンドで反映する

初期状態を確認します。

$ kubectl get pod
NAME                READY   STATUS    RESTARTS   AGE
sample-pod3-67b24   2/2     Running   0          35s
sample-pod3-fk967   2/2     Running   0          35s
sample-pod3-ssn7z   2/2     Running   0          35s

yamlファイルのreplicasの値を変更して、applyします。

$ kubectl apply -f sampleReplicaSet.yaml
replicaset.apps/sample-pod3 configured
$ kubectl get rs
NAME          DESIRED   CURRENT   READY   AGE
sample-pod3   5         5         5       97s
$ kubectl get pod
NAME                READY   STATUS    RESTARTS   AGE
sample-pod3-67b24   2/2     Running   0          99s
sample-pod3-fk967   2/2     Running   0          99s
sample-pod3-mp6cs   2/2     Running   0          15s
sample-pod3-ssn7z   2/2     Running   0          99s
sample-pod3-w559b   2/2     Running   0          15s

これだけです。

まとめ

ReplicaSetのスケーリングの動作を確認できました。
kubectl scaleコマンドでのスケーリングは、今までのインフラ運用（一度設定したらあまり変えない）に慣れている方だと馴染みやすいかもしれません。（私もそうです）
しかし、Kubernetesで実現するマイクロアーキテクチャは、頻繁に環境を変更します。そのため、手作業で変更するのはあまり現実的ではなく、実際には、コードをGitリポジトリで管理しておいて、変更がコミットされたら自動で適用するCI/CDのパイプラインを構築することが多いです。
そのため、検証などでCI/CDのパイプラインを作るまでもない環境でも、マニフェストを書き換えてapplyする方法に慣れておいた方がよいでしょう。