リクエストは保存されたのに、なぜアプリは準備できないのか

一言でいうと

セルフサービスAPIは、インストールコマンドを隠すボタンではなく、ユーザーのリクエストを実際のリソースの状態に継続的に結びつける契約です。リクエストの受理、同期、準備完了は、それぞれ別の問いへの答えです。

なぜ必要なのか

開発者が「テスト用のアプリを1つください」と頼むたびに、プラットフォームチームがDeploymentとServiceを手で作っていると、引き渡しの過程で漏れが生じます。あるアプリにはServiceがなく、あるアプリはレプリカ数だけが違います。これを解決しようとしてテンプレートを共有しても、コピーしたあとの変更と削除は、再びそれぞれの責任になります。セルフサービスは、繰り返されるリクエストを簡単なAPIにし、その後ろのリソースをコントローラーが継続的に管理するようにするアプローチです。

しかし、APIが簡単になったからといって、運用の責任がなくなるわけではありません。HTTPリクエストが成功したという理由でユーザーに「アプリの準備ができました」と伝えたのに、コンテナイメージはまだダウンロード中ということもありえます。APIサーバーは宣言を保存し、コントローラーはその宣言を処理していて、アプリは自分の準備手順を実行します。3つの作業の担当が違うため、完了する時点も違います。

どう動くのか

今回のラボのAppは、replicasとchannelの2つの入力だけを受け取ります。XRDは、このAPIの名前・範囲・入力形式を定義します。replicasは1から3までで、channelはstableまたはpreviewです。これは人に見せるヘルプだけではありません。上限を超えるリクエストはAPIサーバーが拒否しなければならず、拒否されたオブジェクトは保存されてはいけません。開発者のアカウントは、自分のネームスペースでAppを扱えますが、配下のDeploymentを直接作成する権限は与えられません。

Compositionは、Appをどんな実際のリソースで構成するかを決めます。今回は、関数がDeploymentとServiceを作り、リクエストの名前をリソース名・セレクターに結びつけます。リクエストのレプリカ数はDeploymentへ、channelはコンテナの環境変数へ渡されます。Serviceがほかのアプリのラベルを選択していると、HTTPが成功しても、自分のリクエストの準備ができた証拠にはなりません。そのため、名前だけでなく、所有UIDとPodの所有の系譜を突き合わせます。

観測	確認できた事実	まだ確認できていない事実
App作成の成功	APIがリクエストを受けて保存した	コンテナが起動したか
Synced=True	コントローラーがリクエストを処理した状態	準備条件と実際のアプリが正常か
Ready=True	構成で定義した準備条件を満たした	その条件が業務の成功を十分に表しているか
該当PodのHTTPレスポンス	実際のコードが期待したchannelで応答した	次の変更や削除も正常に処理されるか

Readyの意味は、準備条件をどう書いたかによって決まります。Deploymentは通常Available条件を提供しますが、ラボの誤ったCompositionはReady条件を探します。コンテナとHTTPは正常なのに、探している条件がないため、上位のAppは準備ができていないと報告します。このとき、準備の検査をなくせば、表示だけを緑にすることはできます。しかし、次には実際には準備ができていないアプリまで成功と表示する可能性があり、問題を解決したことにはなりません。

現場での姿

入力の有効性と権限も別です。replicas=4を自分のチームに作るリクエストは、スキーマに違反します。逆に、有効なreplicas=1でも、別のチームに作るリクエストは、権限に違反します。2つの失敗をどちらも「リクエストエラー」とひとまとめにすると、ユーザーは、値を変えるべきなのか、対象のチームを直すべきなのか、わかりません。プラットフォームエンジニアは、実際のレスポンスと保存されたかどうかを確認し、原因を切り分けて説明する必要があります。

チームの境界のテストでは、管理者ではなく、制限されたServiceAccountでリクエストします。管理者の成功を見て、ユーザーも使えると判断すると、権限の欠落を見逃します。逆に、権限の参照が失敗したときに、結果を自動的にnoに置き換えると、テストツールが壊れていることを、分離の成功と勘違いします。観測の失敗は、別に残す必要があります。

次の読み物で確認すること

作成したあとの変更と削除でも、同じ原則が必要です。次の読み物では、観測世代・所有UID・finalizerをつなげ、続くラボで、実際のAppのリクエストファイルと該当PodのHTTPを突き合わせます。宣言ファイルだけを提出せず、現在のリソースと所有関係を記録する理由を、先に整理してください。