プロンプトとコンテキスト
ある運用プラットフォームがデバッグのためにKubernetesノードのsystemdログを必要としていますが、ノードのファイルシステムをテナントに公開してはなりません。Kubernetes v1.36における安定版NodeLogQueryの境界、アクセス制御、クエリパラメータ、ページネーション、レート制限、およびノードが到達不能な場合や結果が大きすぎる場合の対処法について説明してください。
面接官が評価するポイント
- NodeLogQueryを、ノードファイルの直接読み取り、コンテナログ、および集中ログシステムと明確に区別できているか。
enableSystemLogQuery、Kubeletの認証・認可、およびテナント分離について説明できるか。- 時間範囲、重大度、出力サイズ、デッドライン、および同時実行数制限を考慮しているか。
- 観測可能で、監査可能であり、ロールバック可能な運用ワークフローを提示できているか。
確認すべき明確化のための質問
- 対象はノードサービス、カーネルログ、それともPodのstdout/stderrですか？それぞれエントリポイントが異なります。
- 呼び出し元はクラスタ管理者、オンコールSRE、それともテナントのセルフサービスプラットフォームですか？
- ノード間をまたぐクエリ、長期間のクエリ、またはライブフォロー（追従）クエリは必要ですか？これらはノードの負荷に影響します。
- 履歴検索用に利用可能なログ収集システムはすでに存在しますか？
30秒の回答フレームワーク
まず境界を設定します。NodeLogQueryは制御されたKubeletのノードログ機能であり、任意のファイルアクセスではありません。次にフローを提示します。呼び出し元を認証・認可し、ノードとクエリのスコープを検証し、Kubeletにノードログインターフェースを呼び出させ、制限された結果を返します。最後にガードレールで締めくくります。enableSystemLogQueryを有効にし、時間、行数、バイト数、同時実行数、デッドラインを制限します。履歴検索は集中ログに送り、異常なリクエストに対して監査とアラートを実施します。
ステップバイステップの詳細解説
1. ログソースと機能の境界を定義する
NodeLogQueryはsystemdやカーネルログなどのノードシステムログを対象とします。Podのstdout/stderrはコンテナログまたは集中コレクターを使用する必要があります。クエリインターフェースは任意のファイルシステムパスの受け入れ、認証情報ディレクトリの読み取り、またはKubelet認可のバイパスを許可してはなりません。テナントはフィルタリングされたノードイベントや集約データを受け取るにとどめ、未加工のノードログは制御されたSREロールに限定されるべきです。
2. テナントの認証、認可、および分離を行う
KubeletのHTTPSエンドポイントは、リクエスト属性を評価する前にクライアントを認証します。API Serverまたは運用プロキシは、許可されたノードログ機能のみにルールが限定された専用のIDを使用します。テナントがnodes/proxyまたは同等の広範なアクセス権を受け取ることはありません。また、プラットフォームはテナントとノードのバインディングを検証し、ノード名やラベルの変更によって他のテナントのノードに到達できないようにします。
3. クエリを制限しリソースを保護する
短いデフォルトウィンドウとともに、明示的なノード、サービスユニット、時間範囲、および重大度の指定を必須とします。最大期間、返却バイト数、行数、同時実行数、およびテナントごとのレートを設定します。制限に達した場合は、再開可能なページトークンまたは明確なエラーを返します。ストリーミングは許容されますが、切断、デッドライン、または上限到達時にはKubeletおよびプロキシのリソースを解放する必要があります。
4. オブザーバビリティの確保、障害処理、およびロールバック
呼び出し元のID、ノード、パラメータの概要、開始・終了時刻、返却バイト数、切り捨て理由、および認可結果を記録します。ログ本文を監査ストリームにコピーしてはいけません。ノードが到達不能な場合はフェイルファストし、集中ログの参照を推奨します。Kubeletが過負荷になった場合はサーキットブレーカーを作動させてアラートを発報します。NodeLogQueryはv1.36で安定版となりデフォルトで有効ですが、enableSystemLogQueryは運用の設定項目として残ります。カナリアノードに展開し、無効化できるパスを確保しておきます。
模範解答
私ならNodeLogQueryをファイルブラウザではなく、制御されたノード診断インターフェースとして位置づけます。まずシステムログ、コンテナログ、および集約された履歴検索を分離します。呼び出し元はKubeletを介して認証・認可され、承認されたノードとログタイプのみをクエリできます。テナントには広範なnodes/proxyアクセス権を付与せず、プラットフォーム側でテナントとノードのバインディングを検証します。
すべてのクエリには、短いデフォルトウィンドウとともにノード、サービスユニット、時間範囲、重大度を含めます。バイト数、行数、同時実行数、レート、デッドラインの制限を強制し、結果をストリーミングまたはページネーションして切り捨てを報告します。監査にはID、ノード、パラメータの概要、所要時間、サイズ、判定結果のみを記録し、本文は絶対に含めません。到達不能なノードや過負荷のKubeletはフェイルファストし、サーキットブレーカーを作動させてユーザーを集中ログへと誘導します。NodeLogQueryはv1.36で安定版となりデフォルトで有効ですが、enableSystemLogQueryをカナリア展開し、ロールバック手段を保持します。
よくある間違い
- NodeLogQueryをノードファイルへの任意のアクセスと見なしてしまうこと。
- テナントに
nodes/proxyを付与し、ノードとテナントの分離を無視すること。 - 無制限の時間範囲、出力サイズ、または同時実行数を許可してしまうこと。
- ログ本文を監査ストリームに書き込み、機密データの二次漏洩を引き起こすこと。
- 到達不能なノードへの再試行を無制限に行い、コントロールプレーンやKubeletの負荷を増大させること。
フォローアップの質問と回答
フォローアップ 1: すべての履歴クエリをNodeLogQuery経由で送信しないのはなぜですか？
ノードエンドポイントはニアリアルタイムの診断に適しています。長時間の読み取りによってKubeletのリソースを消費することなく、履歴検索、インデックス作成、テナント分離、および保持期間の管理は集中ログ収集システムが処理すべきです。
フォローアップ 2: クエリがテナントの境界を越えられないことをどのように証明しますか？
すべてのリクエストについてID、ノード、リソース、判定結果を記録します。許可されたノードは成功し、他のテナントのノードは拒否されることを証明する結合テスト（シンセティックテスト）を実施し、プロキシが任意のパスやノードパラメータを拒否することを検証します。
フォローアップ 3: ログに認証情報が含まれている場合はどうしますか？
レスポンス時における推測に基づく不可逆なマスキングに頼るべきではありません。クエリのスコープ、ロール、保持期間を縮小し、収集時に構造化されたマスキングを実施します。高リスクなフィールドが発見された場合は、影響を受けるアクセス権を取り消し、認証情報をローテーションします。