四つの緑色表示が答える別々の問い

一言でいうと

Gitと同じであること、Kubernetesが準備できたこと、ユーザーのリクエストが成功したことは、互いに異なる主張です。

なぜ必要なのか

オンコールのチャンネルに「決済ができません」というメッセージが届きました。デプロイ画面にはSyncedとHealthyが表示され、PodもReadyです。 ここで「インフラは正常なので、ユーザーがもう一度試せばよい」と答えると、確認した範囲より大きな結論を出したことになります。 画面の緑色が間違っていると決めつける必要もありません。その表示が答えている問いと、ユーザーが投げかけている問いが違うことがあるのです。 このラボでは決済システムを接続しません。nginxの業務パスが意図的に500を返す小さなモデルで、 この違いを再現します。実際の障害対応のように見せかけた偽の状態ファイルではなく、個人VMのArgo CDとHTTPサーバーを使います。

どう動くのか

調査するときは、次の4つの問いを順番に切り分けてください。

問い	確認する根拠	これだけでは分からないこと
どの変更をデプロイしようとしたのか	リモートのmainとGitコミットのファイル	コントローラーがそのコミットを見たか
その目標がクラスターに反映されたか	Applicationのsync revisionとSynced	実行中のプロセスが新しい設定を読んだか
リソースが準備の条件を満たしているか	health、observedGeneration、updatedReplicas、Pod Ready	業務パスが正しい本文を返すか
私たちが調べたリクエストが成功するか	リクエストのパス・レスポンスコード・本文・観測時刻	外部ユーザー全体の成功率と長期的な可用性

Argo CDのデフォルトのhealth評価は、リソースの種類ごとのKubernetesの状態を使います。たとえばDeploymentの 現在の世代が観測されたかどうかや、更新されたレプリカを確認することは重要ですが、ショッピングモールの注文の意味までは自動では分かりません。 Syncedも、アプリケーションの意味を評価する機能ではありません。誤った設定をGitに保存したなら、その設定を忠実に デプロイした結果がSyncedになることもあります。したがって、GitOpsの宣言的な管理と、アプリケーションに対する適切な検証は、お互いの代わりにはなりません。 公式のリソースhealthドキュメント

readinessは、このPodにトラフィックを送る準備ができたかを判断するための信号です。ただし、実際に何を検査するのかは、 私たちが書いたprobeとアプリの実装によります。このラボの/healthzは、プロセスが応答するという意味の200だけを返します。 業務パスの/は500を返します。この設計はわざと不完全にしてあり、本番での推奨のprobeではありません。 かといって、外部の決済APIが少し遅いときに、すべてのPodのlivenessが失敗するように変えれば解決するわけでもありません。 readinessによる転送の制御と、livenessによる再起動の判断は、目的が違います。外部依存の障害を再起動で直せるかどうかを 確認しないまま2つの信号をつなげると、復旧の代わりに再起動の負荷を生み出すことがあります。 公式のprobeの概念

現場での姿

最初の落とし穴は、コミットを確認せずに緑の画面だけを見ることです。たった今上げた変更ではなく、以前のコミットのHealthyを 見ているかもしれません。ローカルのHEAD、サーバーのリモートのmain、Applicationのstatus.sync.revisionを一緒に比較してください。 ブランチ名のmainは動く名前であり、コミットSHAはその瞬間の具体的なソースです。pushコマンドが終わったという事実は、 デプロイ完了の証拠ではありません。このラボではrefreshで該当のApplicationの再比較を要求しますが、それも成功の宣言ではないので、 実際のrevisionと状態の収束を待ちます。コントローラー全体の設定や、ほかのApplicationは変更しません。

2つ目の落とし穴は、レスポンスコードだけを残すことです。200であっても、古い本文や別のバージョンの応答かもしれません。 サービスのアドレス、パス、本文、時刻を一緒に残し、デプロイされたPodのUIDと結び付けると、主張がより明確になります。 逆に500は、サーバーがHTTPレスポンスを返したという観測です。DNSの失敗や接続の失敗を、同じ出来事としてひとまとめにしないでください。 このラボの500はnginxの設定で再現しているので、外部APIやDNSの障害を原因として書くと、観測と合いません。

このラボはVMからClusterIPを呼び出します。この経路の成功だけでは、外部のDNS・Ingress・TLS・認証が正常だとは言えません。 最後のレポートには、外部経路の確認が残っているという結論を書きます。短い時間に3回成功したという結果を、 1か月の可用性や実際の決済の成功率に置き換えないことも、エンジニアの検証能力です。

次のラボですること

最初の観測でGit revisionとリソースのアイデンティティを保存し、readinessと業務の応答を別々に読みます。原因は、公開されているnginxの 設定と実際の応答で絞り込みます。そのあとGitで設定を直しますが、設定の修正だけで既存のプロセスまで変わったかどうかは、 別の観測で確認します。数値やUIDをでっち上げて書かず、ヘルパーが残した実際の観測から調べてください。