デプロイは成功したのに、新バージョンが見えない理由

目標

実際のk3sで、宣言の受け入れ・ロールアウトの完了・準備の失敗・手動ロールバック・外部設定の復旧を、それぞれの証拠で区別します。

なぜ重要なのか

デプロイコマンドが終わったという事実だけで、新バージョンがリクエストを処理していると言うことはできません。ローリングアップデートは、既存の正常なレプリカを維持するので、新バージョンが失敗しても、サービスは正常に見えます。そのときlivenessを直したり、すべてのPodを削除したりすると、何が失敗したのかの証拠まで失います。このラボは、正常な比較群と最後の正常なレプリカを残し、指定した準備の失敗だけを注入します。 50分のラボです。必要なら期限が切れる前に延長してください。セッションの終了時に、VMとファイルは回収されます。

用意されている環境とヘルパー

個人用VMのkcna-delivery空間に、web Deploymentの2つのレプリカ、settings ConfigMap、web Service、control Podがあります。アプリのイメージはdigestで固定し、non-root・cap drop ALL・RuntimeDefault・読み取り専用ルート・ServiceAccountトークンの非マウントを使います。 v1・v2・v3は、同じイメージで動作を区別する擬似アプリのバージョンです。新しいイメージをビルドしたり、実際のCI・GitOpsを変更したりする実験ではありません。ノード・正常な比較群・ロールアウトの保護設定を変更したり、本番のkubeconfig・シークレットを持ち込んだりしないでください。受講生のすべてのファイルは、/root/kcna-deliveryの下に置きます。入力JSONは自分で作成し、実際の観測JSONはcaptureで作ります。 python3 /opt/fixtures/kcna_delivery_lab.pyのあとに、act・capture・grade・prepareとステップ番号1–8を付けます。 observeは、現在のAPI・HTTPレスポンスを読みます。gradeは、ファイルとオブジェクトを変更しません。 actは、操作の完了記録を/opt/fixtures/kcna-delivery-action-N.jsonに残します。ファイルのUID・レスポンス・完了の有無を、作り上げて書かないでください。

ステップ

capture 1で/root/kcna-delivery/baseline.jsonを保存してください。v1・blueの正常なPod2つ、Deployment・ReplicaSet・Pod UID、コンテナID・再起動回数、Ready、EndpointSliceとServiceのレスポンスを調べます。control Podは、独立した正常な比較群です。
annotation.jsonに文字列note=reviewedを保存し、act 2・capture 2でmetadata_only.jsonを作成してください。Deploymentオブジェクトのアノテーションだけが変わり、元のReplicaSet・Pod・コンテナ・revisionは維持される必要があります。オブジェクトの変更がそのまま新しいプロセスになるという仮説を反証してください。
config-green.jsonに文字列color=greenを保存し、act 3・capture 3でconfig_only.jsonを作成してください。ConfigMap settingsの値はgreenですが、既存のPodとServiceの実行中のCOLORはblueです。環境変数の消費時点と、APIに保存された値を区別してください。
release-v2.jsonに、文字列release=v2とブール値ready=trueを保存してください。act 4・capture 4でv2_complete.jsonを作成します。新しいReplicaSetとPod2つがv2・greenで応答し、updatedReplicas=2である必要があります。正常なrevision番号を、この観測に残してください。
release-v3.jsonに、文字列release=v3、ブール値ready=false、文字列color=purpleを保存してください。act 5・capture 5でv3_unready.jsonを作成します。v3はRunningですがReadyではなく、直接HTTP 503を返します。既存のv2・green2つは同じUID・コンテナのまま残り、Serviceはこの正常なレプリカに転送する必要があります。
追加の変更なしに、capture 6でdeadline_exceeded.jsonを保存してください。実際のProgressing=False・ProgressDeadlineExceededと、依然としてv3である望ましいテンプレートを確認します。livenessの再起動や自動ロールバックではなく、準備ができない新バージョンの進捗失敗です。この実験の20秒という基準は、本番の推奨値ではありません。
v2_complete.jsonに保存されたDeploymentのdeployment.kubernetes.io/revisionを調べて、rollback.jsonのrevisionに文字列で書いてください。act 7・capture 7でrolled_back.jsonを作成します。実際のrollout undoコマンドの完了記録、保存された元のv2 Pod、増加したrevision、そして依然としてpurpleの外部ConfigMapを比較してください。
restore-green.jsonに文字列color=greenを保存し、act 8・capture 8でconfig_restored.jsonを作成してください。外部設定まで別途復旧し、v2・greenの応答、元の正常なPod・比較群の保存を確認します。Deploymentのロールバックと外部設定の復旧が、別の操作である理由を、前の記録で説明してください。

参考

課題のnote=reviewedのような表現は、フィールドと値の説明です。ファイルは、形式の例のように正しいJSONで作成してください。 true・falseは、引用符のないブール値です。revisionは文字列で、必ず正常なv2の観測から読み取ります。 captureは、実際の条件が収束するのを待ちます。6回のServiceのレスポンスは学習用の標本であり、長期間の可用性の保証ではありません。完了した観測・入力は保存してください。prepareは、ない前のステップだけを埋め、現在のステップの答えや既存の誤答を上書きしません。途中で記録が途切れたとしても、自動初期化はしません。特に、ロールバックの完了記録が失われた状態で、現在v2だからという理由で、過去の成功を再構成しません。その場合は、必要なファイルを保管したうえで、新しいラボを始めてください。同じVMで、すべての履歴を初期化するコマンドは提供しません。採点は60秒、ステップの準備は90秒のバジェットです。正常な起動や準備失敗の期限待ちは、captureで行います。記録のハッシュは、偶発的なファイルの変更を検知するものであり、VMのrootに対するリモート証明やセキュリティの保証ではありません。公式の根拠: Deployment・ConfigMap

正常なバージョンの宣言と実行の証拠

capture 1で/root/kcna-delivery/baseline.jsonを保存してください。v1・blueの正常なPod2つ、Deployment・ReplicaSet・Pod UID、コンテナID・再起動回数、Ready、EndpointSliceとServiceのレスポンスを調べます。control Podは、独立した正常な比較群です。

名前だけでなく、UIDとコンテナIDも一緒に残してください。

オブジェクトのアノテーションはロールアウトではない

annotation.jsonに文字列note=reviewedを保存し、act 2・capture 2でmetadata_only.jsonを作成してください。Deploymentオブジェクトのアノテーションだけが変わり、元のReplicaSet・Pod・コンテナ・revisionは維持される必要があります。オブジェクトの変更がそのまま新しいプロセスになるという仮説を反証してください。

変更の位置がmetadataなのか、spec.templateなのかを区別してください。

設定の変更と実行中の環境変数

config-green.jsonに文字列color=greenを保存し、act 3・capture 3でconfig_only.jsonを作成してください。ConfigMap settingsの値はgreenですが、既存のPodとServiceの実行中のCOLORはblueです。環境変数の消費時点と、APIに保存された値を区別してください。

ConfigMapの保存値と、既存のプロセスの環境変数は、同じ瞬間には変わりません。

新しいテンプレートが実際にデプロイされた証拠

release-v2.jsonに、文字列release=v2とブール値ready=trueを保存してください。act 4・capture 4でv2_complete.jsonを作成します。新しいReplicaSetとPod2つがv2・greenで応答し、updatedReplicas=2である必要があります。正常なrevision番号を、この観測に残してください。

availableReplicasは、古いバージョンのこともあります。updatedReplicasと応答のバージョンをあわせて見てください。

新バージョンは生きているが、準備ができていない

release-v3.jsonに、文字列release=v3、ブール値ready=false、文字列color=purpleを保存してください。act 5・capture 5でv3_unready.jsonを作成します。v3はRunningですがReadyではなく、直接HTTP 503を返します。既存のv2・green2つは同じUID・コンテナのまま残り、Serviceはこの正常なレプリカに転送する必要があります。

Running・Ready・HTTPレスポンス・Serviceへの転送は、それぞれ別の観測です。

進捗期限の超過は自動ロールバックではない

追加の変更なしに、capture 6でdeadline_exceeded.jsonを保存してください。実際のProgressing=False・ProgressDeadlineExceededと、依然としてv3である望ましいテンプレートを確認します。livenessの再起動や自動ロールバックではなく、準備ができない新バージョンの進捗失敗です。この実験の20秒という基準は、本番の推奨値ではありません。

Progressing条件のstatusとreason、望ましいテンプレートがそのままかを確認してください。

調査したrevisionで手動ロールバックする

v2_complete.jsonに保存されたDeploymentのdeployment.kubernetes.io/revisionを調べて、rollback.jsonのrevisionに文字列で書いてください。act 7・capture 7でrolled_back.jsonを作成します。実際のrollout undoコマンドの完了記録、保存された元のv2 Pod、増加したrevision、そして依然としてpurpleの外部ConfigMapを比較してください。

revisionの数字を暗記しないでください。rollbackは、外部のConfigMapを元に戻しません。

外部設定まで別途復旧する

restore-green.jsonに文字列color=greenを保存し、act 8・capture 8でconfig_restored.jsonを作成してください。外部設定まで別途復旧し、v2・greenの応答、元の正常なPod・比較群の保存を確認します。Deploymentのロールバックと外部設定の復旧が、別の操作である理由を、前の記録で説明してください。

正常な応答だけを見ず、次のPodが読む設定も確認してください。