Kubernetes の面接で成功するために必要な知識と自信を身につけるための包括的なガイドへようこそ。コンテナオーケストレーションの旅を始めたばかりの方でも、専門知識を深めたい経験豊富なプロフェッショナルの方でも、このドキュメントは Kubernetes の概念を習得するための構造化されたアプローチを提供します。基本的な原則や高度なアーキテクチャの考慮事項から、実践的なトラブルシューティング、シナリオベースのチャレンジ、開発者、管理者、DevOps エンジニア向けの役割固有の質問まで、幅広い質問を綿密にキュレーションしました。理解を深め、問題解決スキルを磨き、あらゆる Kubernetes の面接を自信を持って乗り切る準備をしてください。
回答：
Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。本番環境でアプリケーションを実行する際の複雑さを処理し、高可用性、スケーラビリティ、効率的なリソース利用を保証するために使用されます。
回答：
コンテナは、アプリケーションを実行するために必要なすべてを含む、軽量で実行可能なソフトウェアパッケージです。Pod は Kubernetes における最小のデプロイ可能な単位であり、1 つ以上のコンテナ、ストレージリソース、一意のネットワーク IP、およびコンテナの実行方法を制御するオプションをカプセル化します。Pod 内のすべてのコンテナは同じネットワーク名前空間を共有し、localhost を介して通信できます。
回答：
Node は Kubernetes におけるワーカーマシンであり、VM または物理マシンです。各 Node には、Pod を実行するために必要なコンポーネント（Kubelet (マスターのエージェント)、Kube-proxy (ネットワークプロキシ)、およびコンテナランタイム (例：Docker, containerd)）が含まれています。
回答：
コントロールプレーンは、Kube-API Server (Kubernetes API を公開)、etcd (クラスターデータの整合性が取れた高可用性キーバリューストア)、Kube-Scheduler (新しい Pod を監視し、Node に割り当てる)、および Kube-Controller-Manager (Node、Replication、Endpoint、Service Account コントローラーなどのコントローラープロセスを実行する) で構成されます。
回答：
Deployment は、Pod と ReplicaSet の望ましい状態を管理する高レベルの抽象化です。Pod と ReplicaSet の宣言的な更新を提供し、アプリケーションのレプリカ数を定義したり、更新をロールアウトしたり、以前のバージョンにロールバックしたりする方法を可能にします。
回答：
Kubernetes は各 Pod に一意の IP アドレスを割り当てます。Pod 内のすべてのコンテナはこの IP を共有し、localhost を介して通信できます。異なるノード上の Pod は、ネットワークオーバーレイを実装する CNI (Container Network Interface) プラグインを使用して通信できます。Kube-proxy は、サービス検出とロードバランシングを可能にするために、ノード上のネットワークルールを管理します。
回答：
Service は、Pod のセットで実行されているアプリケーションをネットワークサービスとして公開するための抽象的な方法です。Pod のグループに対して安定した IP アドレスと DNS 名を提供します。一般的なタイプには、ClusterIP (クラスター内部)、NodePort (各ノードの IP の静的ポートでサービスを公開)、および LoadBalancer (クラウドプロバイダーのロードバランサーを使用してサービスを外部に公開) があります。
回答：
ReplicaSet は、指定された数の Pod レプリカが常に実行されていることを保証します。その主な目的は、Pod のセットの安定性と可用性を維持することです。ReplicaSet を直接使用することもできますが、通常はロールアウト更新などの高度な機能のために Deployment によって管理されます。
kubectl とは何であり、その主な機能は何ですか？回答：
kubectl は、Kubernetes クラスターと対話するためのコマンドラインツールです。ユーザーは、Kubernetes クラスターに対してコマンドを実行し、アプリケーションをデプロイし、クラスターリソースを検査および管理し、ログを表示できます。Kubernetes API サーバーと通信します。
etcd の役割は何ですか？回答：
etcd は、Kubernetes がすべてのクラスターデータを格納するために使用する、分散型で整合性が取れた高可用性のキーバリューストアです。これには、構成データ、状態情報、メタデータ、およびクラスターの望ましい状態が含まれます。Kubernetes クラスターの単一の真実の情報源として機能します。
回答：
Kubernetes Operator は、Kubernetes ネイティブアプリケーションをパッケージ化、デプロイ、管理する方法です。Kubernetes API を拡張して、複雑なアプリケーションのインスタンスを作成、設定、管理します。データベース (例：Cassandra, MySQL) のようなステートフルアプリケーションでは、バックアップ、アップグレード、スケーリングなどのタスクを自動化するために Operator を使用します。
回答：
Custom Resource Definition (CRD) を使用すると、Kubernetes API を拡張して、独自のカスタムリソースを Kubernetes で定義できます。これにより、Kubernetes が管理できる構造化データを保存および取得できるようになります。CRD は、Operator の構築やアプリケーション固有のオブジェクトの定義に不可欠です。
回答：
API Server は、クライアント証明書、ベアラートークン、またはサービスアカウントトークンなどのさまざまな方法で認証を処理します。認証後、RBAC (Role-Based Access Control)、Node 認証、または ABAC (Attribute-Based Access Control) などのモジュールを使用して認可が実行されます。RBAC が最も一般的であり、権限を持つロールを定義し、それらをユーザーまたはサービスアカウントにバインドします。
回答：
Deployment は、同一の Pod のセットを管理し、クラスター全体で望ましい数のレプリカが実行されていることを保証します。通常はステートレスアプリケーション向けです。DaemonSet は、すべてのノード（または一部のノード）で Pod のコピーを実行することを保証します。これは、すべてのノードで実行する必要があるログコレクター (例：Fluentd) や監視エージェント (例：Node Exporter) のようなクラスターレベルのサービスに役立ちます。
回答：
Pod Security Policies (PSPs) は、Pod とコンテナにセキュリティ標準を強制するアドミッションコントローラーでした。これにより、クラスター管理者は、特権モード、ホストネットワークアクセス、ボリュームタイプなどのセキュリティに敏感な側面を制御できました。PSPs は、より柔軟で詳細な制御を提供する Pod Security Admission (PSA) および OPA Gatekeeper のようなポリシーエンジンを支持して非推奨になっています。
回答：
コントロールプレーンの高可用性は、API Server、etcd、Controller Manager、および Scheduler の複数のインスタンスを実行することによって実現されます。etcd は通常、クォーラムベースのクラスター (例：3 または 5 ノード) として実行されます。API Server の前にロードバランサーが配置され、トラフィックを分散し、フェイルオーバーを提供します。
回答：
ミューテーティングアドミッションウェブフックは、Kubernetes API Server へのリクエストを永続化する前に変更できる HTTP コールバックです。サイドカーコンテナを注入したり、ラベル/アノテーションを追加したり、フィールドのデフォルト値を設定したりできます。例えば、サービスメッシュ統合のために Pod に istio-proxy サイドカーを自動的に注入できます。
回答：
etcd は、Kubernetes の整合性が取れた高可用性のキーバリューストアとして機能します。すべての Kubernetes オブジェクト (Pod、Deployment、Service など) の構成、状態、メタデータを含む、すべてのクラスターデータを格納します。クラスターの運用に不可欠であり、その可用性はクラスターの正常性に直接影響します。
回答：
Kubernetes Network Policies は、Pod のグループが互いに、および外部エンドポイントとどのように通信できるかを定義する仕様です。これらは、Calico、Cilium、または Weave Net のような NetworkPolicy をサポートするネットワークプラグイン (CNI) によって実装されます。CNI プラグインは、これらのポリシーをファイアウォールルールに変換します。
回答：
Taints はノードに適用され、それらのノードに一致する Tolerations を持つ Pod がない限り、特定の Pod にとって「不適切」であるとマークします。Tolerations は Pod に適用され、それらが Tainted ノードにスケジュールされることを可能にします。このメカニズムは、特定のワークロード (例：GPU ノード) のためにノードを予約したり、正常でないノードから Pod をエビクトしたりするために使用されます。
回答：
まず、イベントとステータスを確認するために kubectl describe pod <pod-name> を使用します。次に、エラーを確認するために kubectl logs <pod-name> を使用してアプリケーションログを確認します。最後に、クラッシュの原因を理解するために、以前のコンテナインスタンスからのログを確認するために kubectl logs <pod-name> -p を調べます。
回答：
Deployment に RollingUpdate 戦略を使用します。これにより、Kubernetes は古い Pod を新しい Pod に徐々に置き換えることができ、常に最小限の数の Pod が利用可能であることを保証します。新しい Pod がトラフィックをルーティングされる前に準備ができていることを確認するには、ヘルスチェック (レディネスプローブ) が不可欠です。
回答：
安定した一意のネットワーク識別子、安定した永続ストレージ、および順序付けられた、正常なデプロイ/スケーリング/削除を必要とするアプリケーションには StatefulSet を使用します。例としては、PostgreSQL のようなデータベースや、各レプリカが独自の永続ボリュームと予測可能なホスト名を持つ必要がある Apache Kafka のような分散システムが挙げられます。
回答：
まず、kubectl top nodes および kubectl top pods を使用して、リソースを大量に消費しているものを特定します。次に、Pod のリソースリクエストと制限を確認し、適切に設定されていることを確認します。軽減策には、アプリケーションのリソース使用量の最適化、クラスターの水平スケーリング、またはリソースリクエスト/制限の調整が含まれます。
回答：
クラスター内または外部トラフィックにアプリケーションを公開するには、LoadBalancer または NodePort タイプ の Kubernetes Service を使用します。安全な HTTP/HTTPS アクセスについては、Ingress コントローラー (例：Nginx Ingress) をデプロイし、TLS ターミネーションを持つ Ingress リソースを定義します。これは、証明書マネージャー (Cert-Manager) と統合して自動証明書プロビジョニングを行うことがよくあります。
回答：
Kubernetes Job オブジェクトを使用します。Job は、指定された数の Pod がタスクを正常に完了することを保証します。定期的なタスクの場合は、CronJob を使用します。CronJob は、定義されたスケジュールで Job オブジェクトを作成します。
回答：
マイクロサービスを、アンチアフィニティルールを使用して異なるノードに分散された複数のレプリカ (例：3 つ以上) を持つ Deployment としてデプロイします。堅牢なレディネスプローブとライブネスプローブを実装します。データ永続化については、分散データベースまたは永続ボリュームを持つ StatefulSet を使用します。最後に、適切なリソースリクエスト/制限と自動スケーリングを確保します。
回答：
機密情報を保存するには Kubernetes Secrets を使用します。これらのシークレットは、Pod にファイルとしてマウントしたり、環境変数として公開したりできます。セキュリティを強化するために、HashiCorp Vault やクラウドプロバイダーの KMS サービスのような外部シークレット管理システムと統合します。
回答：
クラスター内で外部データベースを表すために、ExternalName タイプまたは Endpoints を持つヘッドレス Service の Kubernetes Service を作成します。これにより、Pod は Kubernetes サービス名でデータベースを解決できます。ネットワークポリシーを使用して、データベースの IP およびポートへの出口トラフィックのみを制限し、認証情報は Kubernetes Secrets を介して管理します。
回答：
CPU 使用率またはリクエスト/秒などのカスタムメトリックに基づいてスケーリングするように構成された Deployment の Horizontal Pod Autoscaling (HPA) を実装します。これにより、需要が増加すると自動的に Pod レプリカが増加します。また、基盤となるクラスターに十分なノード容量があることを確認するか、Cluster Autoscaler を実装します。
回答：
まず、リソース不足 (CPU/メモリ)、ノードアフィニティ/テイントの問題、またはバインドされていない永続ボリュームクレームを示すイベントがないか kubectl describe pod <pod-name> を確認します。次に、kubectl describe node <node-name> を使用してノードの条件とリソースの可用性を調べます。
回答：
Deployment に RollingUpdate 戦略を使用します。これにより、古い Pod が新しい Pod に徐々に置き換えられ、継続的な可用性が保証されます。また、新しい Pod がトラフィックをルーティングされる前に正常であることを確認するために、レディネスプローブを定義します。
回答：
まず、サービスの kubectl describe service <service-name> を確認して、その構成とエンドポイントの準備状況を確認します。次に、サービスをバックアップしている Pod の正常性 (kubectl get pods -o wide) を調べ、アプリケーションエラーがないかログを確認します。ネットワークポリシーやファイアウォールルールも要因となる可能性があります。
回答：
Role-Based Access Control (RBAC) を実装します。これには、Role (名前空間内の権限) または ClusterRole (クラスター全体の権限) を定義し、RoleBinding または ClusterRoleBinding を使用してそれらをユーザーまたはサービスアカウントにバインドすることが含まれます。
回答：
NetworkPolicy を使用して、Pod 間の、または Pod と外部エンドポイント間のトラフィックフローを制御します。例えば、データベース Pod を分離して、特定のアプリケーション Pod のみがそれに接続できるようにしたり、開発名前空間からの出口トラフィックを制限したりします。
回答：
Kubernetes Secrets は基本的なエンコーディングを提供しますが、真のセキュリティのためには、HashiCorp Vault、AWS Secrets Manager、または Azure Key Vault のような外部シークレット管理ソリューションと統合します。これらのソリューションは、シークレットを Pod に直接注入したり、CSI ドライバーを使用して動的にマウントしたりすることで、機密データを Git に直接保存することを回避できます。
回答：
Helm チャートは Kubernetes のパッケージマネージャーであり、必要なすべての Kubernetes リソース (Deployment、Service、ConfigMap など) を単一のバージョン管理可能なユニットにバンドルします。CI/CD では、環境全体で一貫性のある再現可能なデプロイメント、簡単なバージョンアップグレード/ロールバック、および構成のパラメータ化を可能にします。
回答：
Argo CD や Flux のようなツールを使用して GitOps アプローチを採用します。コードがマージされテストされた後、CI パイプラインは Docker イメージをビルドし、Kubernetes マニフェスト (例：Git リポジトリ内) のイメージタグを更新します。その後、GitOps オペレーターは Git の変更を検出し、それをクラスターに自動的に適用して、望ましい状態の同期を保証します。
回答：
クラスターについては、ノードのリソース使用率 (CPU、メモリ、ディスク)、API サーバーのレイテンシ、etcd の正常性を監視します。アプリケーションについては、主要なメトリクスには、Pod の CPU/メモリ使用量、リクエストレート、エラーレート、レイテンシ、およびアプリケーション固有のビジネスメトリクスが含まれます。Prometheus と Grafana は、このための一般的なツールです。
回答：
PersistentVolumes (PV) と PersistentVolumeClaims (PVC) を使用します。PVC は PV からストレージを要求し、PV は StorageClass によってプロビジョニングされます。これにより、アプリケーションはインフラストラクチャの具体的な詳細を知ることなくストレージを要求でき、Pod が再スケジュールされてもデータの永続性が保証されます。
回答：
一般的な原因としては、リソース不足 (CPU/メモリ)、ノードのテイント/トレレーション、または永続ボリュームの問題が挙げられます。kubectl describe pod <pod-name> を使用して、スケジューリングの失敗、リソースリクエスト、およびボリュームバインディングのステータスを示すイベントを確認します。
回答：
これは、Pod 内のコンテナが繰り返し起動してクラッシュしていることを示します。まず kubectl logs <pod-name> を使用してアプリケーションのエラーを確認します。ログが役に立たない場合は、kubectl describe pod <pod-name> を使用して OOMKilled イベントやレディネス/ライブネスプローブの失敗を探します。
回答：
kubectl logs で -c フラグを使用してコンテナ名を指定できます。例：kubectl logs <pod-name> -c <container-name>。これにより、特定のサービスからのログを分離できます。
回答：
サービスタイプ (例：NodePort、LoadBalancer) とその外部 IP/ポートを確認します。次に、ファイアウォールルール、セキュリティグループ、およびネットワークポリシーを確認します。最後に、サービスのセレクターが Pod ラベルと正しく一致しているか、および Pod が実行中で正常であるかを確認します。
回答：
kubectl describe networkpolicy <policy-name> を使用して、そのルールを理解します。次に、Pod のラベルと名前空間を確認して、それらがポリシーによってターゲットにされているかどうかを確認します。デバッグ Pod 内の kube-no-trouble や netshoot のようなツールも、接続性のテストに役立ちます。
回答：
kubectl exec -it <pod-name> -- /bin/bash (bash が利用できない場合は /bin/sh) を使用できます。これにより、コンテナのファイルシステムを検査したり、コマンドを実行したり、環境内で直接問題を診断したりできます。
回答：
一般的な原因としては、イメージ名/タグの間違い、プライベートレジストリの認証の問題、またはレジストリへのネットワーク接続の問題が挙げられます。kubectl describe pod <pod-name> を使用してイメージプルエラーを確認し、イメージ名、レジストリ認証情報 (シークレット)、およびネットワークアクセスを確認します。
回答：
これは、リソース競合 (CPU スロットリング)、非効率的なアプリケーションコード、または外部依存関係の問題を示している可能性があります。Pod のリソース使用率メトリクス (CPU/メモリ) を確認し、遅いクエリがないかアプリケーションログを確認し、外部サービスへのネットワークレイテンシを検査します。
回答：
kubectl describe pod <pod-name> を使用してプローブ失敗イベントと使用されている特定のコマンド/パスを確認します。次に、kubectl logs <pod-name> を使用して、アプリケーションがクラッシュしているか、またはプローブのエンドポイントに応答していないかを確認します。コンテナ内でプローブコマンドを直接実行することも役立ちます。
回答：
一般的な理由としては、kubelet が実行されていない、コントロールプレーンとの通信を妨げるネットワークの問題、またはノードリソースの不足が挙げられます。ノードに SSH で接続し、systemctl status kubelet を確認し、kubelet ログ (journalctl -u kubelet) をレビューし、API サーバーへのネットワーク接続を確認します。
回答：
主要なプラクティスには、最小権限の原則に基づいた Role-Based Access Control (RBAC) の実装、Kubernetes およびそのコンポーネントの定期的な更新、コンテナイメージの脆弱性スキャン、Network Policy を使用したネットワークセグメンテーション、および API サーバーアクセスの保護が含まれます。
回答：
最小権限とは、ユーザーやサービスアカウントに、タスクを実行するために必要な最小限の権限のみを付与することを意味します。これにより、アカウントが侵害された場合の影響を最小限に抑え、クラスター内の攻撃対象領域を削減します。
回答：
Network Policy は、Pod が互いに、また外部エンドポイントとどのように通信できるかを定義します。これらは Pod レベルのファイアウォールとして機能し、ネットワークセグメンテーションを可能にし、機密性の高いワークロードを分離して不正な通信を防ぎます。
回答：
イメージスキャンは、デプロイ前にコンテナイメージ内の既知の脆弱性 (CVE) や設定ミスを特定します。これを CI/CD に統合することで、セキュアで準拠したイメージのみがレジストリにプッシュされ、クラスターにデプロイされることが保証され、脆弱なソフトウェアの実行を防ぎます。
回答：
Kubernetes Secrets は基本的なストレージを提供しますが、デフォルトでは base64 でエンコードされており、保存時に暗号化されません。ベストプラクティスとしては、HashiCorp Vault、AWS Secrets Manager、または Azure Key Vault のような外部シークレット管理ソリューションを使用し、多くの場合 CSI ドライバーまたは外部シークレットオペレーターを介して統合し、機密データを暗号化および管理することが推奨されます。
回答：
Pod Security Standards は、Pod のさまざまなレベルの分離 (Privileged、Baseline、Restricted) を定義する組み込みのセキュリティ制御です。これらは、Pod がルートアクセスやホストパスマウントのような過度に寛容な設定で実行されるのを防ぐことで、セキュリティベストプラクティスの実施を支援します。
回答：
権限昇格を防ぐには、Pod Security Standards の強制、イミュータブルコンテナの使用、ホストアクセス制限、厳格な RBAC の実装、およびクラスター構成とユーザーアクティビティの定期的な監査など、いくつかの対策が必要です。ケーパビリティの制限と特権コンテナの禁止は重要です。
回答：
サービスメッシュは、サービス間の暗号化された通信のための mTLS (相互 TLS)、きめ細かなアクセス制御ポリシー、およびトラフィック暗号化などの機能を提供することで、セキュリティを強化します。マイクロサービス間の通信のためのセキュリティ構成とオブザーバビリティを一元化します。
回答：
イミュータブルインフラストラクチャとは、コンポーネント (コンテナイメージやデプロイされたアプリケーションなど) がビルドされデプロイされたら、決して変更されないことを意味します。変更が必要な場合は、新しいイメージをビルドして古いインスタンスを置き換える必要があり、これにより設定ドリフトが削減され、一貫性、信頼性、およびセキュリティが向上します。
回答：
リソースクォータは、名前空間が消費できる CPU、メモリ、その他のリソースの総量を制限し、リソース枯渇を防ぎます。リミットレンジは、名前空間内の Pod のデフォルトおよび最大リソースリクエスト/リミットを定義し、アプリケーションが過剰なリソースを消費しないようにし、クラスターの安定性と公平性を向上させます。
回答：
まず kubectl describe pod <pod-name> を使用してイベントとステータスを確認します。次に、kubectl logs <pod-name> を使用してアプリケーションログを確認します。クラッシュループの場合は、kubectl logs --previous <pod-name> を使用して、最後に終了したコンテナのログを確認します。
回答：
一般的な原因としては、リソース不足 (CPU/メモリ)、ノードのテイント/トレレーション、またはノードセレクター/アフィニティの問題が挙げられます。kubectl describe pod <pod-name> を使用してスケジューリングイベントを確認し、kubectl get events --field-selector involvedObject.kind=Node を使用してノードの状態を確認します。
回答：
Deployment を公開するために、LoadBalancer または NodePort タイプ の Service を作成します。より高度なルーティングや SSL 終端のためには、Ingress リソースを使用します。これには Ingress Controller が必要です。
回答：
Kubernetes Deployment はデフォルトでローリングアップデートを処理し、maxUnavailable および maxSurge の設定に基づいて古い Pod を終了する前に新しい Pod を作成します。主な考慮事項としては、適切なレディネストプローブ、十分なリソース割り当て、および完全なロールアウト前の新しいバージョンのテストが挙げられます。
回答：
ConfigMap は、アプリケーションの環境変数や設定ファイルのような、機密性のない設定データに使用します。Secret は、API キー、データベース認証情報、または TLS 証明書のような機密データに使用し、これらはデフォルトで暗号化されて保存されます。
回答：
Node Selector または Node Affinity を使用します。Node Selector は厳密な一致 (nodeSelector: {gpu: 'true'}) にはよりシンプルです。Node Affinity は requiredDuringSchedulingIgnoredDuringExecution または preferredDuringSchedulingIgnoredDuringExecution ルールでより柔軟性を提供します。
回答：
まず、kubectl describe service <service-name> を使用して、そのセレクターが Pod ラベルと一致しているか確認します。次に、kubectl get endpoints <service-name> を使用して、Pod IP がリストされているか確認します。最後に、Pod が正常であり、レディネストプローブがパスしていることを確認します。
回答：
Kubernetes Job リソースを使用します。Job は 1 つ以上の Pod を作成し、指定された数の Pod が正常に終了することを保証します。スケジュールされたタスクの場合は、CronJob を使用します。
回答：
PersistentVolume (PV) は、管理者がプロビジョニングしたクラスター内のストレージの一部です。PersistentVolumeClaim (PVC) は、ユーザーからのストレージ要求です。PVC は適切な PV にバインドされ、Pod がライフサイクルとは独立して永続的なストレージを利用できるようになります。
回答：
手動では、kubectl scale deployment <deployment-name> --replicas=<number> を使用します。自動では、Horizontal Pod Autoscaler (HPA) を使用します。HPA は、観測された CPU 使用率またはその他のカスタムメトリクスに基づいて、Deployment または ReplicaSet の Pod の数をスケーリングします。
Kubernetes の面接を乗り切ることは、困難ではありますがやりがいのある経験です。このドキュメントでは、一般的な質問と洞察に富んだ回答を包括的に概観し、成功に必要な知識と自信を身につけられるように設計しました。徹底的な準備が最も重要であることを忘れないでください。コアコンセプト、実践的な応用、トラブルシューティングのシナリオを理解することで、パフォーマンスは大幅に向上します。
面接を超えて、Kubernetes との旅は継続的な学習と適応の旅です。この分野は急速に進化しており、好奇心を持ち続け、新しい機能を実験し、コミュニティと関わることで、スキルをシャープで関連性の高いものに保つことができます。チャレンジを受け入れ、成功を祝い、このダイナミックで不可欠なテクノロジーにおける専門知識を構築し続けてください。
