大量のコンテナを本番環境で安定運用する仕組みを標準化した。
ただ、欠点としてめちゃくちゃ複雑なので、
- ローカル環境が複雑になる。(docker-composeはあるが)
- 設定が複雑になる。
小さいWebサービスをリリースしたい程度の要望なら不要。
1. 障害時の自動復旧
例えば、
|
1 2 3 4 5 |
Pod A ← 落ちた ↓ Kubernetes「死んでるな」 ↓ Pod A' を自動起動 |
みたいなことをやってくれる。
2. スケールが楽
アクセスが増えたら、
|
1 2 |
通常[Pod][Pod][Pod] アクセス増加[Pod][Pod][Pod][Pod][Pod][Pod][Pod] |
みたいにコンテナ数を増やせる。
しかもCPU使用率などを見て自動スケールもできる。
3. ローリングアップデート
これが今回のカナリアの話ともつながる。
例えば、
|
1 2 3 |
v1.1[Pod][Pod][Pod][Pod] ↓ 少しずつ交換 v1.2[Pod][Pod][Pod][Pod] |
みたいに、全部止めずに新バージョンへ入れ替えることができる。
さらに設定次第では、
|
1 2 |
v1.1 95% v1.2 5% |
みたいな段階的な展開も可能。
4. 「インフラの違い」を吸収した
これがKubernetesの本質的な強さだと思う。
昔は、
AWSならこうする
GCPならこうする
自社サーバーならこうする
みたいに環境ごとの差が大きかった。
Kubernetesでは、
このコンテナを、この数だけ、この条件で動かしたい
という宣言をしておけば、Kubernetes側が面倒を見る。
だから、
「サーバーをどう操作するか」から「どういう状態にしたいか」へ
発想を変えたのがかなり大きい。


この記事へのコメントはありません。