SRE 採用向けベスト Kubernetes テスト

標準的な Kubernetes テストが失敗する理由

ほとんどの Kubernetes 評価は、「StatefulSet とは何ですか?」または「テイント（taint）と容認を説明してください。」という質問をします。これらは暗記を測定しており、ノード障害から生き残るクラスターを設計できるか、アプリが振動しているときに検出でき、またはデプロイメントが安定化しない理由をデバッグできるかどうかをテストしていません。

深い Kubernetes 経験を持つ SRE または DevOps エンジニアは、実際の質問は運用の安定性、コスト、および本番環境での問題を圧力下でデバッグすることについてであることを知っています。

ここからは、シグナル価値を持つ Kubernetes 評価がどのようなものであるかを見ていきます。

評価するコアスキル

1. クラスター設計と復旧力

彼らはゾーンの障害から生き残るクラスターを設計できるか?

評価の質問:

「ゾーン障害の中でも稼働し続ける必要がある本番ワークロードを実行しています。現在、単一の AZ に 3 ノードクラスターがあります。何を変更しますか? トレードオフは何ですか?」

良い答え:

• ノードを 3 つの AZ に分散する(最低でも)
• PodDisruptionBudgets を使用してカスケード障害を防ぐ
• ノードアフィニティを使用して、すべてのレプリカが 1 つのゾーンに配置されることを回避する
• ノードのヘルスチェックを構成する
• コストトレードオフ(インフラストラクチャが 3 倍になる)を理解している

弱い答え:

• 「より多くのレプリカを実行してください」(ゾーン障害に対応していない)
• 「アンチアフィニティを使用してください」(ポッドトポロジー分散制約を理解していない)

2. ワークロード構成とデバッグ

彼らは本番環境のワークロードを構成し、失敗したときにデバッグできるか?

評価の質問:

「新しいマイクロサービスをデプロイしました。デプロイメントは 3 つのレプリカが実行されていることを示していますが、2 つだけがトラフィックを処理しています。準備性チェック(readiness check)は成功しています。これはなぜ起こっているのでしょうか?」

良い答え(順序で考慮):

• エンドポイントがサービスセレクターから欠けていないか? (kubectl get endpoints で確認)
• ポッドネットワークポリシーがトラフィックをブロックしていないか?
• ポッドのネットワークインターフェイスが正しく設定されているか?
• ロードバランサーのヘルスチェックが準備性チェックと異なっていないか?

これは Kubernetes の事実ではなく、体系的なデバッグをテストします。

3. ストレージと状態管理

StatefulSet と Deployment を使い分けられるか? ノードローカルと永続ストレージをいつ使い分けるか?

評価の質問:

「Kubernetes で Elasticsearch を実行しています。StatefulSet と Deployment のどちらを使いますか? ストレージについてはどうですか?」

良い答え:

• 安定したアイデンティティと順序付けのために StatefulSet を使用する
• データの永続性のために永続ボリュームを使用する
• ノード全体に分散するためにアンチアフィニティを使用する
• 慎重なアップグレード戦略(ローリング再起動はクォーラム損失を引き起こす可能性がある)

弱い答え:

• 「Deployment を使ってください。シンプルです」
• データの永続性やクォーラムについて言及がない

4. スケーリングとコスト最適化

スケールアップする場合と、ワークロードを最適化する場合を判断できるか?

評価の質問:

「クラスター CPU 利用率が 85% に達しています。コストは月 $10,000 です。2 つの選択肢があります: ノードを追加するか、ポッドのリクエストを最適化するか。最初に何をチェックしますか?」

良い答え:

• ポッドがリソースをオーバーリクエストしていないか確認する(リクエストが高すぎる場合)
• ノイジーネイバー問題(1 つのポッドが予想より大幅に多く使用している)がないか確認する
• ワークロードが自然にピークしないか確認する(トラフィックパターンを変更可能か)
• 実際のリソース制約の場合のみノードを追加する

これは運用判断をテストします。

5. 可視性と本番環境デバッグ

Kubernetes の監視を設計できるか? アプリがぐらついている理由を診断できるか?

評価の質問:

「Kubernetes で実行されているアプリケーションが、30 秒間続く 0.1% のエラー率スパイクを発生させ、その後回復します。これが 1 日に 1 回、ランダムな時間に起こります。どのように調査しますか?」

良い答え(言及する項目):

• ポッド再起動イベント(ノードログと kubelet をチェック)
• リソース枯渇(メモリと CPU をチェック)
• ネットワークタイムアウト(サービスエンドポイントと DNS をチェック)
• アプリケーションレベルの再試行(アプリが一時的なエラーから復旧しているか?)

評価構造

パート 1: テイクホーム設計演習(2 時間)

シナリオ:

「次の制約を備えた SaaS アプリケーション向けに本番 Kubernetes クラスターを設計してください:

• 99.9% アップタイム SLA
• ステートレスフロントエンド、ステートフルバックエンド(データベース)
• 50-500 の同時ユーザー(負荷変動あり)
• 予算制約: 月額最大 $5,000
• 単一ゾーンの障害から生き残る必要がある
• スケーリングは自動である必要がある」

候補者が提供すべきもの:

• ノードアーキテクチャ(ノード数、インスタンスタイプ、ゾーン)
• ワークロード構成(デプロイメント、リソースリクエスト、スケーリングポリシー)
• ストレージ戦略(永続ボリューム、バックアップ)
• 監視とアラート計画
• コスト内訳

これは彼らが大規模にシステムを構築したことがあるかどうかをテストします。

パート 2: 構成レビュー(30 分)

意図的な問題を含む Kubernetes マニフェストを提供してください:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # 問題: HA の場合は 3 である必要があります
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # 問題: セマンティックバージョニングを使用する必要があります
        resources:
          requests:
            cpu: 100m  # 問題: 低すぎる。アプリが CPU スロットルされます
            memory: 64Mi  # 問題: 低すぎる。OOM になります
      # 問題: readiness プローブなし、liveness プローブなし
      # 問題: ノードアフィニティなし。すべて同じノードで実行される可能性
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080
  # 問題: 順序付けのためのヘッドレスサービスなし。StatefulSet で順序付けを使用していません

すべての問題を特定し、修正方法を説明するよう依頼します。強い候補者は 8 個以上の問題を指摘します。弱い候補者は 1-2 個の明らかな問題のみです。

パート 3: トラブルシューティング会話(30 分)

シナリオ:

「新しいサービスを Kubernetes にデプロイしました。トラフィックは到達していますが、レイテンシーが通常の 10 倍です。Prometheus は CPU とメモリの使用状況が正常と表示されています。デバッグ方法を説明してください。」

候補者が尋ねるべき質問:

• サービスエンドポイントは最新ですか? (kubectl get endpoints)
• ポッドがトラフィックを均等に受けているか、1 つのポッドが遅いか?
• ネットワークパスに問題があるか (kube-proxy、CNI)?
• アプリケーションが何かをブロックしているか (外部 API、データベース)?
• デプロイに最適化されていないコード変更が含まれていたか?

これは彼らが体系的に考えるかどうかをテストします。

Kubernetes 評価ルーブリック

テストしないこと

候補者に以下を依頼しないでください:

• Kubernetes Operator をゼロから作成する。(これはシステムプログラミングであり SRE ではありません)
• API バージョンを暗記する。(本番環境ではドキュメントを使用します)
• インタビュー中にゼロからクラスターをセットアップする。(これはオペレーションタスクであり、判断の評価ではありません)

代わりに依頼してください:

• 現実的な制約のためにクラスターを設計する
• デプロイメントが失敗する理由をデバッグする
• オプション間のトレードオフを説明する
• 本番環境用にワークロードを構成する

Kubernetes をまだ使用していないチーム向け

DevOps または SRE を採用していても、Kubernetes をまだ使用していない場合は、Kubernetes の専門知識を必要とせずに、コンテナ化とオーケストレーションの概念をテストしてください。多くのチームは、実際に必要なのはシステム思考であるのに Kubernetes の知識に過度に重みを置いています。

本番環境で Kubernetes を使用しているチームについては、採用前にこの評価構造を使用して運用の深さを評価してください。この評価に合格する候補者は初日から生産性があります。

次: DevOps 評価の結果を解釈する方法を理解してください。