k8sメリット/デメリット

◽️k8sのメリット

①ローリングアップデートによる無停止運用が可能 ->ただし、podがレプリケートしていること前提。

②容易なスケーリング

③リソースの修正 ->ローリングアプデート前提になりますが無停止でできるのが利点

④オートヒーリング機能 ->pod(コンテナ)が停止ても復旧できる機能

⑤スケジューリング機能   ->各nodeのリソース状況などに応じて、podの割り当てを行える

◽️k8sのデメリット(障害事例)

過去の障害事例を見るとnode故障関連が多いようです。
①nodeの障害   ->nodeがNotReadyになった場合、再作成を行う必要がある。(基本的に、複数のnodeが稼働前提になるので、運用状問題ないと思われる。)　　　
参考：https://unicorn.limited/jp/item/808

②node障害後のpodの移動 ->1つのpodのみで、node故障が発生して、他のnodeに移動しない現象ありMaster側で、各nodeにpodの再割り当て（スケジューリング）をするところ正確にできてない現象。


解決案：deschedulerというのスケジューリングの偏りを検知して、再スケジュールしてくれる機能
参照：http://bbrfkr.hatenablog.jp/entry/2019/04/12/153509

③バージョンアップにあるk8sの不具合発生など   ->過去に不具合の事例が出ているようですが検証後導入するか　　事前に悪評があれば様子見で対処できるか思います。

④クラスタが丸ごと故障した場合   ->node及びpodが使用不可※ただし、外ずけにしたディスクについては生きているので、保存データの担保できると思う。

⑤ヒューマンエラー(Spotifyでの事例)例：クラスタ及びnodeの削除参考：https://www.itmedia.co.jp/news/articles/1907/08/news074.html

退避：バックアップ/ディザスターリカバリーのテストなどを行う。
上記を含め、コード化による作業が全般になるのでヒューマンエラー比率が上がるのは確か。

対策①：クラスタ障害時に、非k8sのインスタンスへの切り替えを検討。対策②：リージョン間でクラスタリングを作成して、冗長化を行う。 

メモ：①本番・ステージング・開発で環境を分ける。②nodeについては、本番用node/ステージング＆開発node(内部で、NameSpaceで区切る)