はじめに
本記事は、以下の内容の続きになります。
今回は、k8s自体の特長のひとつである 「セルフヒーリング（自己回復）」 の動作を確認してみたいと思います。
障害が発生してノードがダウンした場合に、どのように振る舞うかの検証を行います。
セルフヒーリング時の動作
セルフヒーリングが実行される状況を、順を追って確認していきます。
ここでは、3ノードでクラスタを構築しています。
正常時の状況
まず、障害発生前の状況です。
AWSコンソールで、k8sクラスタに登録されているノード（EC2インスタンス）の状況、
および、Kubernetes のダッシュボードの状況を確認します。
インスタンスIDと、ノード名が一致しないので、分かりにくいかもしれませんが、以下のノードが対応するモノになっています。
AWSコンソールで、2番目に表示されている 「i-04c1b56fb1ab8bc7a」
↓ ↑
Kubernetes ダッシュボードで、3番目に表示されている 「ip-192-168-85-79.us-west-2.compute.internal」
障害の発生
次に、障害を発生させるために、AWSコンソールから、ECインスタンスを強制的に停止させます。
少し待つと、Kubernetes ダッシュボードで、先程のノードのアイコンが、「？」マークに変わりました。
ノードからのヘルチェックの応答がなくなり、状態が不明（Unknown）となっています。
セルフ・ヒーリングの開始
そのまま、何もしないで、待ってみます。
すると、新しく 「ip-192-168-79-73.us-west-2.compute.internal」 のノードが自動的に追加されました！
ただし、まだノードが起動している最中なので、状態は 「False」 になっています。
AWSコンソールから、EC2インスタンスの状況も確認してみると、
停止したインスタンスは 「stopped」 の状態になり、新しく 「i-0da3402ec83997a51」 のインスタンスが追加されています。
セルフ・ヒーリング後
さらに、何もしないで、もう少し待ってみます。
すると、先程自動で追加された 「ip-192-168-79-73.us-west-2.compute.internal」 のノードが正常な状態になりました。
今回の場合は、およそ2分程度で、新しいノードに変わって動作する状態になりました！
障害が発生したノードで稼働していたコンテナも、新しく登録されたノードに、自動的にデプロイされたようです。
ちなみに、強制的に停止し、状態不明となった 「ip-192-168-85-79.us-west-2.compute.internal」 のノードは、しばらくすると、Kubernetes ダッシュボード上からも無くなっていました。
まとめ
今回、セルフヒーリングの動作を確認してみましたが、障害が発生した後、
特に何をしなくても、自動でノードが追加され、元々の3ノード構成となって稼働していました。
このように、楽に回復性を向上させることができるのがk8sのメリットのひとつであり、ノードも自動で追加されるのがクラウド上でk8sを動作させるメリットだと思います。
実際の運用では、完全にノードが停止せずに、ゾンビ状態やコンテナプロセスがダウンする等のことも考えられますが、
その辺りはどのように検知＋セルフヒーリングできるのか、別途調べたいと思います。