😺

Kubernetesの単体障害テストどうしようか悩んだ話

2024/02/26に公開

Kubernetesの単体障害

Kubernetesの単体障害テストケースを書くことがあるのですが、Kubernetesを理解できていない方もおり、物理サーバーの障害のノリで言われることもしばしば。
定石をカスタムして選んでもらえれば、お互いハッピー（~~責任を押し付けられる~~）なので自分なりのパターンをまとめてみる。

OKE環境前提で考えていますが、VMWareやほかのクラウドにも応用は効くと思います。
単体障害と一口に言っても、考え方が色々あると思うので、入り口の参考程度に。

kubectl delete pods <pod> --grace-period=0 --force

メリット：自動で復旧する。
デメリット：複数Podになると面倒（複数Podが落ちる場合は単体障害とは呼ばない気はするが）

kubectl scale deployment --replicas=0 <deployment>

メリット：同じコマンドで復旧できるので、復旧が楽。
デメリット：Podの正常終了を障害と呼ぶのか？

外部からリクエストを大量に投げてPodをハングさせる。
※requestリソースが設定されていないとノードが落ちるので注意

メリット：障害として考えられるトリガー。
デメリット：そもそもリクエストを受け付けるPodしかできない。負荷をかける準備が面倒。

おそらく、厳しい。
Pod単位までしか無理。

つまり電源を切ってしまう。一番確実。

メリット：楽。クラウドならインスタンスを再作成ですぐに復旧。
デメリット：特に思いつかない。

つまりネットワークの疎通をできなくしてしまう。

メリット：NW障害として考えられるシナリオ。
デメリット：NW周りの設計把握が必要。事故りそう。

外部からリクエストを大量に投げてPodをハングさせる。
もしくは、高負荷なPodをデプロイする。
※requestリソースの設定は意図的にノードが壊れるようにする。

メリット：（リソース設計が甘いと）障害として考えられるトリガー。
デメリット：テスト手順や復旧手順を間違えると被害が広がる。

kubeletをプロセスkillする。

書いておいてなんだが、思いつき。
今度機会が合ったらやってみます。