インフラ作業支援ラボInfra Support Lab ← ガイド一覧← 戻る
トップ > ガイド > Deploymentの更新と切り戻し
実務ガイド｜更新日：2026年10月26日

Kubernetes Deploymentの更新・切り戻し｜kubectl rolloutの確認手順

KubernetesのDeploymentを更新するとき、変更前のrevision・Podの稼働状況・切り戻し可能性を確認する運用ガイドです。rolloutコマンドの確認操作と変更操作を分けて扱います。

この記事の目的

Deploymentのrevision、更新状態、undoの範囲、GitOps管理との整合、サービス正常性の確認。

最初にやること

kubectl config current-contextとkubectl rollout history deployment/APP -n appで対象と履歴を確認します。

注意：rollout undoは設定を以前のrevisionへ戻す変更操作であり、データベース・外部サービスの状態は元に戻りません。app・APP・POD_NAME・CONTAINER_NAMEは例です。context・namespace・権限を実環境で確認してください。
Kubernetes

Kubernetes・kubectl基本操作

対象と原因を絞り、変更前後の確認手順へ進みます。

記事を読む →Kubernetes

CrashLoopBackOffの原因

対象と原因を絞り、変更前後の確認手順へ進みます。

記事を読む →Kubernetes

ImagePullBackOffの原因

対象と原因を絞り、変更前後の確認手順へ進みます。

記事を読む →

1. 変更前に記録する情報

kubectl config current-context kubectl get deployment APP -n app -o wide kubectl describe deployment APP -n app kubectl rollout history deployment/APP -n app kubectl get pods -n app -o wide

APPは実際のDeployment名に置き換えます。historyは保持されているReplicaSetのrevision履歴を表示します。保持数にはrevisionHistoryLimit等の制限があり、過去のすべてに戻れるわけではありません。

2. status・history・restart・undoの違い

コマンド区分意味
rollout status参照・監視ロールアウトの進捗を監視
rollout history参照revision履歴を参照
rollout restart状態変更対象Podの再作成を促す
rollout undo状態変更以前のrevisionに戻す
# 参照：最新ロールアウトの進捗を確認（監視を継続） kubectl rollout status deployment/APP -n app --timeout=120s # 参照：履歴 kubectl rollout history deployment/APP -n app

status --timeoutは監視の時間を制限するもので、デプロイ操作自体をキャンセルするものではありません。revisionが途中で変わる環境では最新rolloutの監視対象も変わるため、必要ならrevision固定を検討します。

3. 設定変更前の確認

イメージ変更やマニフェスト適用の前に、GitOps/CIの管理元、Namespace、replicas、PDB、readiness・liveness probe、RollingUpdateパラメータとサービス停止影響を確認します。

# 自分に許可される操作の確認 kubectl auth can-i patch deployment/APP -n app # 状態の参照 kubectl get deployment APP -n app -o yaml
注意：kubectl applyやrollout restartは承認済みの変更時だけ実行します。apply --dry-run=serverはAPI側の検証に有用ですが、webhookなど外部の副作用がゼロとまでは保証しません。

4. 切り戻し前に確認すること

# 参照：履歴の有無 kubectl rollout history deployment/APP -n app # 変更承認後にのみ実施する操作例 kubectl rollout undo deployment/APP -n app

undoはDeploymentのPodテンプレートの旧revisionへの復帰であり、PVCのデータ、DBマイグレーション、ConfigMap・Secretの外部変更まで巻き戻すものではありません。GitOps管理下ではコントローラーが再適用する場合があるため、宣言的な変更元も合わせて修正します。

危険：バックアップ未取得のまま本番でundo・restartを行わないでください。Undo可能なリビジョンがない場合もあります。

5. ロールアウト結果別の判断・復旧

表示例はいずれも想定例であり実測ではありません。 変更前に、対象Deploymentの管理元（GitOps/CI等）、現在のイメージ参照、変更元の版、過去の安定したrevisionとデータ互換性を記録します。

結果・想定表示判断と次に取る行動
successfully rolled outDeployment更新は進行上完了。replicasのAvailable、Pod Ready、アプリ応答と利用者側の通信を別途確認する
ProgressDeadlineExceeded進捗期限超過。kubectl describe deployment APP -n app、新PodのEvents・ログ・Ready失敗原因を調べる。自動的なロールバックは保証されない
--timeout=120sがタイムアウト監視コマンドの期限切れと、実際のDeployment停止を混同しない。Pod/Deploymentの状態を再取得してから判断する
履歴がない・戻せるrevisionがないundoを実行しない。構成管理元の以前のマニフェストを確認し、データ互換性を含む別の復旧計画を立てる
undo後も異常・GitOpsで再び変更される変更元へ修正を反映し、Podテンプレート以外のConfigMap・Secret・DB変更が残っていないか確認する
# 参照のみ：revisionの詳細と失敗原因の材料 kubectl rollout history deployment/APP -n app kubectl describe deployment APP -n app kubectl get replicasets -n app kubectl get pods -n app -o wide

切り戻しの実行条件：影響対象と旧revisionを特定し、旧イメージが取得可能で、スキーマ等が互換であり、管理元の承認を得た場合のみkubectl rollout undoを検討します。rollbackはPodテンプレートを対象とし、DB・PVC・別オブジェクトは戻しません。切り戻し後は新規Podと依存サービスを含む業務動作を検証し、未回復ならログ・Events・管理元の変更履歴を保全して担当者へ連絡してください。Kubernetes公式 — Deployment更新とロールバック。

6. 更新・切り戻し後の正常性判定

kubectl get deployment APP -n app -o wide kubectl rollout status deployment/APP -n app --timeout=120s kubectl get pods -n app -o wide kubectl get events -n app --sort-by=.metadata.creationTimestamp

PodのReady、DeploymentのAvailable、ログ、アプリヘルス、利用者からの実通信まで確認して完了とします。Readyなのに業務不具合があればアプリ側ログ・依存先を確認します。

7. ロールアウトで失敗した場合

現象切り分け先
新PodがCrashLoopBackOff前回ログと終了理由を調べる
ImagePullBackOffレジストリ・タグ・認証を調べる
新PodのReadyが上がらないprobe、Service、アプリ依存先、readiness条件を確認
変更したはずなのに戻るGitOps・CIの同期と宣言的構成を確認

関連する確認手順：ConfigMap・Secretを更新する前の確認。

関連する確認手順：Serviceが正しいPodを向いているか確認。

公式・一次資料

関連手順を確認する

参照操作・変更操作・削除操作を区別し、作業前後に対象と正常性を記録します。

関連ガイドへ