Kubernetesの単体障害
Kubernetesの単体障害テストケースを書くことがあるのですが、Kubernetesを理解できていない方もおり、物理サーバーの障害のノリで言われることもしばしば。
定石をカスタムして選んでもらえれば、お互いハッピー（責任を押し付けられる）なので自分なりのパターンをまとめてみる。
前提
OKE環境前提で考えていますが、VMWareやほかのクラウドにも応用は効くと思います。
単体障害と一口に言っても、考え方が色々あると思うので、入り口の参考程度に。
Podの単体障害を発生させるには
強制削除
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リソースの設定は意図的にノードが壊れるようにする。
メリット：（リソース設計が甘いと）障害として考えられるトリガー。
デメリット：テスト手順や復旧手順を間違えると被害が広がる。
プロセスkill
kubeletをプロセスkillする。
書いておいてなんだが、思いつき。
今度機会が合ったらやってみます。