実験の実施
今回は、Kubernetes上の動作も確認したいので、いくつかコンソールを開いておきましょう。
1. ノードの状態確認のためのコンソール
下記のコマンドを実行し、ノードの状態をリアルタイムに出力できるようにしておきます。
kubectl get nodes -w
2. Podの状態確認のためのコンソール
別のコンソールにて下記のコマンドを実行し、ノードの状態をリアルタイムに出力できるようにしておきます。
kubectl get pods -o wide -w
3. Webアクセス可否の確認
別のコンソールにて、Webアクセスができるか確認する準備をしておきます。このコンソールはWebブラウザでもOKです。
curl http://20.89.82.247/
4. Chaos Toolkitの実行
さらに別のコンソールで下記のコマンドを実行し、実験を開始します！
chaos --verbose run stop_aksnode.json
実験の結果
Chaos Toolkitのコマンドを実行して少し待つと、curlコマンドを実行した際に応答が帰ってこなくなります。すなわち、Webアクセスができない状態となります。
「1. ノードの状態確認のためのコンソール」からも、ノードが落ちたことが確認できます（少しタイムラグが生じる場合があります）。
> kubectl get nodes -w NAME STATUS ROLES AGE VERSION aks-nodepool1-67032099-vmss000000 Ready agent 14m v1.20.9 （ここでchaos runコマンドを実行） aks-nodepool1-67032099-vmss000001 Ready agent 14m v1.20.9 aks-nodepool1-67032099-vmss000002 Ready agent 14m v1.20.9 aks-nodepool1-67032099-vmss000002 NotReady agent 14m v1.20.9 aks-nodepool1-67032099-vmss000002 NotReady agent 14m v1.20.9
そして実行から約5分後、「2. Podの状態確認のためのコンソール」を確認すると、Podの停止が試みられ、並行して別のノード（aks-nodepool1-67032099-vmss000000）でPodが起動されることが確認できます。
> kubectl get pods -o wide -w NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES azure-vote-back-6c4dd64bdf-7gh9p 1/1 Running 1 11m 10.244.2.5 aks-nodepool1-67032099-vmss000002 <none> <none> azure-vote-front-85b4df594d-fhhzg 1/1 Running 1 11m 10.244.2.7 aks-nodepool1-67032099-vmss000002 <none> <none> azure-vote-back-6c4dd64bdf-7gh9p 1/1 Running 1 12m 10.244.2.5 aks-nodepool1-67032099-vmss000002 <none> <none> azure-vote-front-85b4df594d-fhhzg 1/1 Running 1 12m 10.244.2.7 aks-nodepool1-67032099-vmss000002 <none> <none> （ここでchaos runコマンドを実行） azure-vote-back-6c4dd64bdf-7gh9p 1/1 Terminating 1 17m 10.244.2.5 aks-nodepool1-67032099-vmss000002 <none> <none> azure-vote-front-85b4df594d-fhhzg 1/1 Terminating 1 17m 10.244.2.7 aks-nodepool1-67032099-vmss000002 <none> <none> azure-vote-back-6c4dd64bdf-8f87l 0/1 Pending 0 0s <none> aks-nodepool1-67032099-vmss000000 <none> <none> azure-vote-front-85b4df594d-s9m7s 0/1 Pending 0 0s <none> aks-nodepool1-67032099-vmss000000 <none> <none> azure-vote-back-6c4dd64bdf-8f87l 0/1 ContainerCreating 0 0s <none> aks-nodepool1-67032099-vmss000000 <none> <none> azure-vote-front-85b4df594d-s9m7s 0/1 ContainerCreating 0 0s <none> aks-nodepool1-67032099-vmss000000 <none> <none> azure-vote-back-6c4dd64bdf-8f87l 1/1 Running 0 21s 10.244.1.4 aks-nodepool1-67032099-vmss000000 <none> <none> azure-vote-front-85b4df594d-s9m7s 1/1 Running 0 48s 10.244.1.5 aks-nodepool1-67032099-vmss000000 <none> <none>
Podの起動とほぼ同じタイミングでcurlコマンドにも応答するようになります。
> curl http://20.89.82.247/ StatusCode : 200 StatusDescription : OK ...
この後、Chaos Toolkitにて停止したノードについて、ノードの起動が行われるか待ってみましたが、自動で起動される気配はありませんでした。
結果から
これらの結果から、下記のことが分かりました。
- 1台のノードが停止した場合でも、別のノード上でPodが起動してくることでサービスが復旧する動作を確認できた
- 停止したノードは自動で起動することは無く、AKSとしてはノードの起動数までは監視していないと考えられるため、別途アクションを検討する必要がある
実際にKubernetesクラスターのノードに障害があった際の動きを確認するという目的について、達成できました。
補記：5分でPodが再起動した点について
5分でPodが再起動するというのは遅く感じられたでしょうか？
この動作はKubernetesの動作であり、「KubeletがNode情報を更新しなくなったことを検知し、300秒経ってもノードが復旧せずPodの情報が更新されない場合、Podが強制退去され別のノードにスケジュールされる」という設定が入っているためです。
> kubectl get pod -o yaml azure-vote-back-6c4dd64bdf-8f87l
apiVersion: v1
kind: Pod
...
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
...
詳細については、Kubernetesのドキュメント（TaintとToleration）を参照してください。
時間を短縮することは可能ですが、仕組みを理解したうえで変更することをお勧めします。
次回予告
次回は、Kubernetesそのものへの、Chaos Toolkitによるカオスの挿入方法について紹介します。
