お題とスコープ
あなたは数百の Kubernetes クラスターを運用しています。v1.36 では、コアコンポーネントが /statusz を公開し、デフォルトで人間が読めるテキストを返し、明示的なコンテンツネゴシエーションによって構造化 API を返します。収集、権限、バージョン互換性、アラート、および障害分離を設計してください。一部のクラスターはまだ古いリリースを実行しており、コントロールプレーンのエンドポイントをパブリックに公開することはできません。
面接官が見ているポイント
面接官は、多数のクラスターに対する認証、レート制限、バージョンのパース、および縮退運転を設計しながら、ヘルスプローブ、コンポーネントの状態、およびビジネス SLO を分離できるかをテストしています。優れた回答では、機密フィールド、アラートストーム、コレクターの障害、および到達不能なコントロールプレーンを適切に処理します。
最初に明確にすべき質問
- liveness、依存関係の状態、またはバージョニングされた診断フィールドのどれが必要ですか？
- コレクターは各クラスター内で実行されますか、それとも中央プレーンからデータをプルしますか？
- どのロールが statusz の読み取りを許可され、レスポンスによって内部トポロジーやバージョンが公開される可能性はありますか？
- 検出は秒単位が求められますか、それとも分単位のキャパシティとトレンドで十分ですか？
30秒の回答
「私なら statusz をビジネスヘルスシグナルではなく、診断シグナルとして扱います。クラスター内コレクターが最小権限でプライベートネットワーク経由でエンドポイントにアクセスし、利用可能な場合は構造化出力を要求し、人間の診断用にテキストを保持します。古いクラスターには互換プローブを使用します。中央プラットフォームは、レート制限、キャッシング、アラートの重複排除を行いながら、クラスター、コンポーネント、バージョンごとに集約します。到達不能なコントロールプレーンは収集パスの障害であり、自動的に内部コンポーネントの障害とみなすわけではありません。」
ステップバイステップの解決策
1. シグナルとバージョン規約を定義する
コンポーネントの識別子、バージョン、レスポンス形式、チェック項目、およびタイムスタンプを記録します。未知のフィールドに依存せずにそれらを保持しながら、バージョンごとに構造化フィールドをパースします。表示およびエビデンス用にはテキストを使用します。statusz は /livez、/readyz、およびビジネスメトリクスとは分離しておきます。
2. 収集トポロジーを設計する
各クラスター内で軽量なコレクターを実行し、ローカルネットワーク経由で API サーバー、スケジューラー、コントローラーマネージャーにアクセスします。中央は墨消し（マスキング）された状態イベントを受信して集約し、パブリックなコントロールプレーンエンドポイントを回避します。コレクターにはキュー、バックオフ、ローカルキャッシュを持たせます。
3. 認証と認可を適用する
最小限のリソーススコープを持つ読み取り専用のコレクター ID を作成し、コンポーネントエンドポイントとネットワークパスを制限します。読み取り担当者、頻度、レスポンスサイズを監査します。管理者の認証情報を再利用してはいけません。必要に応じて、テナントおよび運用ロールごとにバージョンやトポロジーのフィールドをフィルタリングします。
4. 負荷と障害を制御する
コンポーネントごとの並行性、タイムアウト、キャッシュ期間、最大レスポンスサイズを設定します。コントロールプレーンがビジー状態または到達不能な場合は、リトライでインシデントを増幅させるのではなく、バックオフします。コンポーネントが報告した障害、HTTP 障害、ネットワーク到達不能、およびコレクターのバックログを個別にモデル化します。
5. 集約とアラート
イベントフィンガープリントを使用して重複排除を行い、クラスター、コンポーネント、バージョン、障害タイプごとに時系列を構築します。複数のコンポーネントの障害や特定バージョンへの集中など、継続的な期間と影響範囲を条件とします。単一のタイムアウトは低優先度の診断シグナルとします。
6. カナリアリリースとロールバック
まずは少数の v1.36 クラスターで構造化収集を有効にします。拡大する前に、API 負荷、フィールドの安定性、アラートの精度、収集レイテンシを比較します。フィールドや負荷にリグレッションが発生した場合は、新しいパーサーを無効化し、互換プローブに戻し、生レスポンスと監査ログを保持します。
模範解答
私なら statusz を liveness プローブやビジネス SLO と並ぶコントロールプレーンの診断レイヤーとして位置付けます。各クラスターはプライベートネットワーク経由で最小権限の読み取り専用コレクターを実行し、中央は墨消しされた状態を受信して集約します。古いリリースには互換プローブを使用します。構造化レスポンスはバージョンごとにパースし、未知のフィールドを許容し、オペレーター用にテキストを保持します。並行性、タイムアウト、キャッシュ、レスポンスサイズを制限し、コンポーネント障害、ネットワーク障害、コレクターのバックログを分離します。フィンガープリントと時間枠によってアラートを重複排除します。少数の v1.36 クラスターでカナリア検証を行い、必要に応じて新しいパーサーのみを無効化します。
よくある間違い
- statusz をビジネス SLO として扱う → ユーザー体験が誤認される → ビジネスメトリクスとレイヤーを分ける。
- パブリックエンドポイントに対して中央からクエリを実行する → アタックサーフェスが拡大する → クラスター内で収集し、状態を中央に送信する。
- 管理者認証情報を再利用する → 読み取り権限が過剰になる → 最小限の読み取り専用 ID を作成する。
- 未知のフィールドでパイプライン全体を失敗させる → アップグレード時に収集が中断される → バージョンごとに寛容にパースする。
- すべてのタイムアウトでアラートを送信する → アラートストームが発生する → パスの障害とコンポーネントの障害を分離し、重複排除する。
フォローアップの質問と回答
なぜテキストレスポンスを保持するのですか？
構造化フィールドは機械による集約用であり、テキストはオペレーターが迅速にインシデントのエビデンスを読んだり保存したりするのに役立ちます。これらは単一のエンドポイントから取得されますが、果たす目的が異なります。
コントロールプレーンに到達できない場合の誤検知をどのように防ぎますか？
ネットワーク到達不能、認証失敗、コレクターのバックログ、コンポーネントが報告した障害を個別にモデル化します。コンポーネントの障害のエスカレーションは、十分なエビデンスがある場合にのみ行います。
古いクラスターはどのようにサポートしますか？
まずエンドポイントとバージョンをプローブし、構造化パース、テキストパース、または互換プローブを選択します。すべてのクラスターがベータインターフェースをサポートしていると仮定せず、ケイパビリティマトリクスを維持します。
収集によって API サーバーの速度が低下するのをどのように防ぎますか？
頻度と並行性を制限し、キャッシュとバックオフを使用し、レスポンスサイズに上限を設け、API サーバーの負荷が上昇した際には自動的に収集頻度を下げます。