変更と削除まで責任を持つセルフサービスAPI

一言でいうと

良いセルフサービスは、作成したあとも、リクエストと実際の状態の差を収束させ、削除のリクエストと実際の回収の完了を区別し、ほかのチームのリソースを保全します。

なぜ必要なのか

プラットフォームのデモでは、アプリが一度作成されると拍手がもらえます。運用では、その後のほうが長く続きます。レプリカ数を増やし、新しい設定を反映し、使っていない環境を消します。ユーザーは「変更しました」という応答を見ますが、一部のPodは以前の設定で応答することがあります。削除のリクエストは成功したのに、コストが発生するリソースが残ることもあります。作成だけを自動化して残りを人に任せると、運用の負担は別の名前で戻ってきます。

開発者が、配下のDeploymentを直接直した状況も考えてみましょう。Appのリクエストは2レプリカなのに、Deploymentを3レプリカに変えたら、何が原本でしょうか。このラボでは、Appが原本です。コントローラーは差を観測して、配下のリソースをまた2レプリカに戻します。元に戻ること自体はバグではなく、宣言した契約の結果です。続けたい変更は、原本のリクエストに対して行う必要があります。

どう動くのか

変更の検証は、以前と同じUIDのリクエストかどうかから始まります。Kubernetesの名前は再利用できます。parcelを削除して同じ名前で新しく作ると、URLと名前は同じに見えても、UIDは違います。以前のアプリの成功の記録を、新しいアプリの証拠として使ってはいけない理由です。配下のDeploymentのUIDも一緒に結びつければ、リソースを削除して作り直した回避策を区別できます。

次は世代です。Deploymentのmetadata.generationは望む設定の変更を表し、status.observedGenerationはコントローラーが観測した世代を表します。以前の世代でReadyだった状態が、新しい宣言の直後にも、しばらく見えることがあります。そのため、観測した世代が現在の世代か、新しいレプリカと利用可能なレプリカの数が目標と同じか、終了中の以前のPodが残っていないか、現在のPodが実際にpreviewの応答を返しているかを、合わせて確認します。

実験で配下のリソースを3レプリカに変えたあと、最終結果が2レプリカであることだけを提出すると、本当に差を作ったのかがわかりません。最初から2レプリカだったとしても、同じ結果になるからです。今回のラボの実験ヘルパーは、APIが保存した3レプリカの状態のパッチのレスポンスを保管します。その世代より後の世代で2レプリカに戻ったかを確認して、変化の前後をつなげます。状態1つと、出来事の流れは、別の種類の証拠です。

削除にも段階があります。削除のリクエストを受けたAPIサーバーは、deletionTimestampを付けることがあります。finalizerが残っていれば、オブジェクトはすぐには消えません。この印は、該当のコントローラーに、整理の手順を終える機会を与えるための仕組みです。障害対応中にfinalizerをすべて消すと、目の前のオブジェクトはなくなるかもしれませんが、所有者が責任を持つべき外部リソースが残るおそれがあります。

ラボでは、教育用の保留の印を1つ入れて、削除中の状態を観察します。この印は、上位のリクエストがなくなるのを遅らせるだけで、配下のすべてのリソースが生きていることを保証しません。コントローラーが配下のリソースを先に回収することもあるため、毎回実際の状態を見る必要があります。解除するときは、該当の印1つだけを取り除き、UIDとresourceVersionを突き合わせて、その間に起きた変更を上書きしません。

現場での姿

「参照結果がない」にも、2つの意味があります。一覧APIが正常に応答して対象がなかった場合と、認証・通信の問題で一覧を得られなかった場合です。後者を空の一覧に置き換えると、削除の検査が障害を成功として報告します。ラボは、App・Deployment・ReplicaSet・Service・Podのそれぞれの一覧の参照が成功し、対象がないときだけ、不在を認めます。

範囲も確認する必要があります。team-aを整理しながらteam-bまで削除すれば、自分のアプリは確実に消えます。しかし、それは成功した整理ではありません。ほかのチームのsentinelのUIDと実際のレスポンスがそのままかを突き合わせて、必要なリソースだけを回収したかを確認します。このラボは、個人VM内のチームの権限分離を扱うもので、ネームスペースだけですべてのネットワーク・リソースの分離が完成したとは主張しません。

次のラボですること

同じリクエストをpreview・2レプリカに変更し、配下のリソースの手動の変更が原本に戻ることを観測します。続いて、削除中の状態と実際の回収を分けて記録し、ほかのチームが保全されたかを確認します。最後に、観測の失敗と矛盾をunknownとして残す、小さな診断ツールを書きます。ない情報から成功を推定しない習慣が目標です。