Rollingupdatestrategy について: 犬小屋は、終わらない(IT)

2025年12月31日

Rollingupdatestrategy について

質問

Rollingupdatestrategy について詳細に解説してください。
メリットはなんですか？

解答

RollingUpdateStrategy（ローリングアップデート戦略）は、

Kubernetes において Deployment や DaemonSet などがアプリケーションを段階的に更新するための戦略です。

これは、古いバージョンの Pod を一度にすべて停止せずに、少しずつ新しいバージョンに置き換える方法です。
そのため、サービスを停止せずにデプロイを行えるという大きな特徴があります。

◆ 基本的な考え方

ローリングアップデートでは、

新しいバージョンの Pod を一部立ち上げる
それが正常に稼働していることを確認する
問題なければ古い Pod を順次停止する
という流れを繰り返します。

これにより、システム全体を止めずにアップデートが完了します。

◆ Deployment の例

Deployment マニフェスト内では、以下のように設定します。

strategy:  type: RollingUpdate  rollingUpdate:    maxUnavailable: 1    maxSurge: 1

パラメータ解説

パラメータ	意味
type	戦略の種類。`RollingUpdate` または `Recreate`（全停止→再起動）を指定
maxUnavailable	アップデート中に「利用不可能」になってよい Pod の数または割合（例: `1` や `25%`）
maxSurge	一時的に「通常より多く」作成してよい Pod の数または割合（例: `1` や `25%`）

動作イメージ

たとえば replicas が 4 の場合：

段階	稼働中のPod (新/旧)	状況
初期	旧×4	旧バージョン全稼働
Step 1	新×1 + 旧×4	maxSurge により一時的に5つ稼働
Step 2	新×1 + 旧×3	正常確認後、旧1つ停止
Step 3	新×2 + 旧×2	順次入れ替え継続
最終	新×4	新バージョン全稼働

このように、「古いものを1つ止めて、新しいものを1つ立ち上げる」 を繰り返します。

◆ メリット

ゼロダウンタイムデプロイ
- サービスを止めずにバージョンアップが可能。
- ユーザーへの影響を最小限にできる。
段階的リリースが可能
- もし新バージョンに問題があれば、その時点で停止やロールバックができる。
負荷の平準化
- Pod が一度に再起動しないため、システム全体の負荷が急増しない。
柔軟な制御
- maxUnavailable / maxSurge の調整により、安定性と速度のバランスを取れる。

◆ デメリット・注意点

リソースが一時的に増加する
- maxSurge によって一時的に Pod 数が増えるため、リソースに余裕が必要。
ステートフルなアプリには不向き
- セッションを持つアプリ（例: 状態を内部に持つ DB）は、Pod が入れ替わるとセッション切断などが起きる。
複雑な依存関係のあるシステムでは慎重な設計が必要
- バックエンドやキャッシュなど、他サービスとの整合性を考慮しないと不整合が起きる。

◆ 代替戦略：`Recreate` との比較

戦略	特徴	向いているケース
RollingUpdate	順次入れ替え。サービス継続可能	Webアプリ、APIサーバーなど
Recreate	全停止 → 全再起動	データベース、セッションを持つアプリなど

◆ ローリングアップデートのメリットまとめ

高可用性を維持したまま更新可能
失敗時は即座にロールバック可能
デプロイの自動化が容易
負荷・リスクを分散できる

もしあなたが 高可用性Webサービス や マイクロサービス構成 を運用している場合、
RollingUpdateStrategy は最もバランスの取れた更新方法といえます。
ただし、状態を持つアプリや重い初期化処理を行うアプリでは、
maxUnavailable / maxSurge の値を慎重に設定する必要があります。