Kubernetes（AKS）をやさしく学ぶ旅 その7
少し間が開きましたが・・・・。
その6 では Pod の少し詳細な部分に触れ、ReplicaSet をこれからハンズオンする、というところで完了しました。
今までに構築してきた環境をベースに ReplicaSet のハンズオンを行います。
ハンズオン Start！
まずは、ReplicaSet を「5」で指定（replicas: 5）したマニフェストファイルを準備して ReplicaSet を作成します。
xxx > kubectl create -f ReplicaSet/replicaset.yaml replicaset.apps/photoview-rs created
その後、Pod 情報を確認してみると・・・・。
xxx > kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS photoview-rs-2mhpk 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-ghn9h 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-hpps2 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-m4fnl 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-sz5vb 1/1 Running 0 8m26s app=photoview,env=prod
この上で詳細情報（describe）を確認してみると・・・・。
xxx > kubectl describe rs photoview-rs （略） Replicas: 5 current / 5 desired （略）
正常に5つの ReplicaSet が作成されているようです！ちなみに、マニフェストファイルの「replicas: n」を変更すればそれに応じた ReplicaSet になります。ここで一度、ReplicaSet は削除してしまいますので、Pod もまとめて削除されます。
xxx > kubectl delete -f ReplicaSet/replicaset.yaml replicaset.apps "photoview-rs" deleted xxx > kubectl get pod NAME READY STATUS RESTARTS AGE photoview-rs-2mhpk 0/1 Terminating 0 15m photoview-rs-m4fnl 0/1 Terminating 0 15m xxx > kubectl get pod No resources found. ＊一度目の確認時にはまだ残っていたようです
クラスター内の制御はどう行っているの？
ReplicaSet のハンズオンを行ってみましたが、実際クラスター内で Pod を指定した数だけ起動するのはどのように行っているのでしょうか？これを制御しているのが「コントローラー」です。クラスターにおいて Pod が設定した数値になっているかを確認しそうでない場合は自動で修復を試みます。ちなみに、ReplicaSet は指定された数の Pod を起動するリソースではなく指定された数の Pod を起動した状態を維持するリソースです。（ここも本来はハンズオンがあるのですが割愛）
Pod に障害があった場合はどのような挙動になるの？
実際に ReplicaSet で Pod に障害が発生した場合はどうなるのでしょうか？挙動を確認してみます。
xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 2m25s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-8vchz 1/1 Running 0 77s 10.244.1.6 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 77s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 77s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 77s 10.244.2.5 aks-nodepool1-11226562-1
ここで、意図的にPod「
xxx > kubectl delete pod nginx-replicaset-8vchz pod "nginx-replicaset-8vchz" deleted xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 4m59s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-9k9q9 1/1 Running 0 17s 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 3m51s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 3m51s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 3m51s 10.244.2.5 aks-nodepool1-11226562-1
すると、「nginx-replicaset-8vchz」は消え「nginx-replicaset-9k9q9」が作成されます。ちなみに、IPアドレスも変わっております。終了した Pod に関しては再起動ではなく別途作成されることに注意しましょう。また、Kubernetes ではコンテナーアプリケーションを運用する際にステートフルなアプリケーションの場合、Pod の状態を保証できないため、その際は StatefulSet を利用する必要があります。（ステートフル＝クライアントのセッションを保持するもの）
Node に障害があった場合はどうなるのか？
Pod ではなく Node の障害の場合はどうなるのでしょうか？クラスターを構成するマシンが落ちた想定で進めてみます。
xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 Ready agent 62m v1.15.4 aks-nodepool1-11226562-1 Ready agent 60m v1.15.4 aks-nodepool1-11226562-2 Ready agent 61m v1.15.4 xxx > az vm stop --name aks-nodepool1-11226562-0 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 64m v1.15.4 aks-nodepool1-11226562-1 Ready agent 62m v1.15.4 aks-nodepool1-11226562-2 Ready agent 64m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES （略） nginx-replicaset-lgmjf 1/1 Terminating 0 19m 10.244.0.8 aks-nodepool1-11226562-0（略）
タイムラグがありますが、「STATUS」列は「Terminating」になります。試しに「-0」だけでなく「-2」も落としてみました。
xxx > az vm stop --name aks-nodepool1-11226562-2 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 68m v1.15.4 aks-nodepool1-11226562-1 Ready agent 66m v1.15.4 aks-nodepool1-11226562-2 NotReady agent 68m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 26m 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-5vffm 1/1 Running 0 18s 10.244.2.12 aks-nodepool1-11226562-1 nginx-replicaset-9k9q9 1/1 Terminating 0 21m 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-fv8np 1/1 Running 0 5m43s 10.244.2.8 aks-nodepool1-11226562-1 nginx-replicaset-jzthk 1/1 Terminating 0 25m 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Terminating 0 25m 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 25m 10.244.2.5 aks-nodepool1-11226562-1 nginx-replicaset-s57gt 1/1 Running 0 18s 10.244.2.14 aks-nodepool1-11226562-1 ＊途中、「-0」をカバーして「STATUS」列が「ContainerCreating」のものも表示されました。
結果として、全てが「-1」に寄る形になっております。（負荷かかりそうですね。。）
ちなみに、「-0」と「-2」を Start として戻しても Pod が立ち上げた2台に配置されるわけではありませんでした。
ひとまず、ここで Pod は削除します。
負荷に応じて Pod の数を変える（ハンズオンなし）
Kubernetes はスケーラビリティが高いというところがメリットですが、2種類のスケーラビリティのキーワードを学びます。
・スケールアウト（水平スケール）
➡簡易的な説明として「台数を増やすこと」
・スケールアップ（垂直スケール）
➡簡易的な説明として「リソースを増強すること」
Pod で考える水平スケールとしては前述でマニフェストファイルを書き換えましたが、コマンドの発行でも可能です。「kubectl scale --replicas=n ～～」でOKです。
ちなみに、Kubernetes は、CPU使用率やそれ以外の各種メトリックを使用して、Pod の数をスケールすることが可能です。機能としては Horizontal Pod Autoscaler です。
ちなみに、当機能は ReplicaSet だけでなくその他の Deployment や StatefulSet 等にも利用が可能です。マニフェストに記述して実現します。
とまぁ、ハンズオン含め長くなってしまいましたが、前回の その6 と今回の その7 にてPod の詳細と ReplicaSet の動き等は完了とします！
