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