1. はじめに
Kubernetes において、Pod のデプロイ戦略として、ローリングアップデート が用意されています。
ローリングアップデートは、よく知られたデプロイ戦略です。
ただし、ローリングアップデートの実施前に確認しておかないと、想定していない障害や不具合が発生することがあります。
この記事では、ローリングアップデート実施前の確認事項をまとめています。
2. ローリングアップデートとは
ローリングアップデートとは、システム全体停止を行わず、順次 Pod (コンテナ) を新しいバージョンの Pod へと段階的に入れ替えていくデプロイ手法です。
2.1. メリット
- ダウンタイムが生じない
- 常に一定数の Pod が存在しているため、サービス停止せず更新を行うことができます。
- リスク分散
- 一度に全ての Pod を入れ替えないため、新しいバージョンに問題があった場合でも、影響範囲が少なくてすみます。S
2.2. 注意点
ローリングアップデートの注意点として、古い Pod と 新しい Pod が一時的に存在する時間が生まれてしまうことです。
この時、ユーザーによって、アクセスする Pod が異なる場合があります。
こういった挙動で不具合が生じる可能性があるシステムで利用する場合は、注意が必要です。
3. 最初に確認したい全体観点
- レプリカ数の確認
- maxUnavailable / maxSurge
- Readiness / Liveness Probe
4. レプリカ数の確認
ローリングアップデートを行う事前確認として、レプリカの数を kubectl get deployment コマンド で確認を行うのが良いです。
- レプリカ数が 1 の場合
- maxUnavailable を 0 と設定したとしても Pod の切替時に処理落ちが発生する可能性があるため、レプリカ数 は、2 以上あることが望ましいで
5. maxUnavailable / maxSurge の設定
Kubernetes では、設定変更することで ローリングアップデート時の挙動を変更することが可能です。
主に注目したい設定は、 maxUnavailable 、 maxSurge です。
これらの設定値を確認しておかないと、 Pod のアップデート時にシステム障害やレイテンシが遅くなる可能性があります。
5.1. maxUnavailable
maxUnavailable は、ローリングアップデート時における Pod の最低稼働数を保証する機能です。
.spec.strategy.rollingUpdate.maxUnavailableはオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。
公式ドキュメント参照： https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/#max-unavailable
以下、例を示します。
Pod が 10 台 稼働、かつ、maxUnavailable が 30% と設定されている環境があるとします。
その場合、ローリングアップデートを実行すると、即座に 古い Pod の 3 台が削除され、新しいPod がスケールアウトします。この間、Kubernetes は、Pod 数が 7 台未満にならないことを保証します。
5.1.1. 注意事項
注意事項は、maxUnavailable を 30% 設定した場合、理想とするPod 数の 70% に減少するため、Pod が過負荷状態になる可能性があります。
本番環境で実施する場合は、maxUnavailable の値を 0 に設定しておくことで、「常に理想とする Pod 数（100%）を維持したまま」 アップデートを行うことが可能です。
5.2. maxSurge
maxSurge は更新中に、理想の数（Desire）を超えて一時的に追加できるPodの最大数を付与すための機能です。
.spec.strategy.rollingUpdate.maxSurgeはオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。
公式ドキュメント： https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/#max-surge
maxSurge を設定すると、ローリングアップデート中に通常設定されている理想の数以上の Pod を稼働させることができます。
5.2.1 設定のメリット
- 過負荷の防止： 稼働するPod 数を保ったままアップデートを行うことが可能なため、Pod １つあたりの負荷増やさずに実施できます。
- ダウンタイムの回避： 新しい Pod が正常に起動したことを確認してから古い Pod を削除するため、リクエストの取りこぼしが少なくてす見ます。
5.2.2. 動作フロー
- Pod の先行作成
- maxSurge で指定された数のPod を作成します。
- Ready 待ち
- 新しく作成された Pod のステータスが Ready になるまで現状維持します。
- Pod の入れ替え
- 新しいPod が Ready になってから順次 Pod の入れ替えを行います。
5.2.3. 注意事項
maxSurge は、非常に便利な機能ですが、注意点があります。
maxSurge を利用する場合、一時的に「理想の数 ＋ maxSurge 数」の Pod が並行稼働します。
そのため、以下のリソースに余裕があることを確認してください。
- ノードのリソース確認する
- CPU や メモリの空きを確認する。
- IP アドレスの空きを確認する
- Pod が一時的に増えるため、サブネットに IP の空きがあるか
6. Readiness Probe / Liveness Probe が適切か
6.1.1. Readiness Probe とは
Readiness Probe は、ヘルスチェック機能で Pod の状態が Ready であるか判定を行う機能です
ヘルスチェックの結果、Pod の状態が READY でなければ、Service から Pod を切り離しトラフィックが Pod にトラフィックが振り分けられないようにします。
6.1.2. 確認事項
- initialDelaySeconds の最適化
- アプリの起動が完了する前にチェックが始まると、不要な「Not Ready」状態が続き、ローリングアップデートの進行を遅らせます。
- 対策: 起動時間を実測し、適切な待機時間を設定します。
- 「Ready」の定義（設計）
- 単にプロセスが動いているだけでなく、**「業務が継続できるか」**を基準にします。
- 例： DB 接続が確立されている、必要なキャッシュの読み込みが完了している等。
6.2.1. Liveness Probe とは
Liveness Probe は、Pod が 「健康に動き続けているか」 を確認する機能です。
チェックに失敗し続けると、Kubernetes はその Pod を 「修復不能」とみなして強制再起動 します。
6.2.2. パラメータ設定の注意点（重要）
liveness Probe の設定値は以下に注意すると良いです。
| パラメーター | 設定例 | 注意点 |
|---|---|---|
| timeoutSeconds | 1 〜 10 | 「1回の応答」を待つ時間です。1秒だとネットワークの微細な揺らぎで失敗しやすいため、システムの特性に合わせて調整します。 |
| failureThreshold | 3 以上推奨 | **「何回連続で失敗したらアウトか」です。※ 0 は設定不可（最小値は 1）**です。通常、一時的なエラーを許容するために 3 程度を設定します。 |
8. おわりに
本記事では、Kubernetes のローリングアップデートを安全に行うための確認事項についてまとめました。
ローリングアップデートは非常に強力な機能ですが、デフォルト設定のままでは、予期せぬ負荷上昇や Pod の再起動ループを引き起こす可能性があります。
特に以下の 3 点は、デプロイの成否を分ける重要なポイントです。
- リソースの余力: maxSurge を活用する際は、ノードの CPU/メモリだけでなく IP アドレスの枯渇にも注意を払うこと。
- Probe の適切な設定: Liveness と Readiness の役割を明確に分け、アプリケーションの起動実態に合わせたしきい値を設定すること。
- ガードレールの設置: 本記事では詳しく触れませんでしたが、ノードのメンテナンスなど「外的な要因」による Pod の消失を防ぐためには、PodDisruptionBudget (PDB) の併用も検討してください。
インフラ側の設定（Kubernetes）とアプリケーション側の挙動をセットで最適化することで、ユーザーに影響を与えない「止まらないシステム」を実現できます。