k8s 問題集・練習問題クイズ

k8sで、Podの望ましいレプリカ数を維持しローリングアップデートを扱う代表的なリソースはどれですか？

答え： Deployment

DeploymentはReplicaSetを介してPod数を維持し、ローリングアップデートやロールバックを扱う実務で最もよく使うワークロードです。

k8sで、Podへ安定した仮想IPやDNS名を提供して通信先を抽象化するリソースはどれですか？

答え： Service

ServiceはPodの入れ替わりに関係なく、ラベルセレクタに一致するPod群への安定した到達点を提供します。

k8sで、アプリ設定値などの非機密データをPodに渡す用途に適したリソースはどれですか？

答え： ConfigMap

ConfigMapは設定ファイルや環境変数など、機密でない設定データをコンテナに渡すために使います。

k8sで、パスワードやトークンなどの機密情報を扱うリソースはどれですか？

答え： Secret

Secretは機密情報を扱うためのリソースです。実務では外部Secret管理やRBAC、暗号化設定も合わせて考えます。

k8sのlivenessProbeの主な目的はどれですか？

答え： コンテナが生存しているか確認し、異常なら再起動させる

livenessProbeはアプリが固まった場合などにコンテナ再起動を促すためのヘルスチェックです。readinessProbeとは役割が違います。

k8sで、HTTP/HTTPSのホスト名やパスに基づいてServiceへルーティングする入口として使うものはどれですか？

答え： Ingress

IngressはHTTP/HTTPSの外部入口を定義します。実際に動かすにはIngress Controllerが必要です。

k8sで、Podに付与する実行時のIDとしてRBACやクラウド連携に使われるものはどれですか？

答え： ServiceAccount

ServiceAccountはPodがAPIや外部クラウドリソースにアクセスする際のIDとして扱われます。

現在のNamespaceにあるPodの状態を一覧で確認したい。まず使う基本コマンドとして適切なものはどれですか？

答え： kubectl get pods

kubectl get pods は現在のNamespaceのPod一覧とREADY、STATUS、RESTARTSなどを確認する基本コマンドです。障害調査の入口としてよく使います。

特定Podが起動失敗している。イベント、環境変数、ボリューム、Probe設定などの詳細を確認したい。適切なコマンドはどれですか？

答え： kubectl describe pod <pod名>

kubectl describe pod はPodの詳細、コンテナ状態、直近イベントなどを表示します。ImagePullBackOffやProbe失敗などの原因調査に向いています。

アプリコンテナの標準出力ログを確認したい。単一コンテナPodで基本的に使うコマンドはどれですか？

答え： kubectl logs <pod名>

kubectl logs <pod名> はPod内コンテナのログを表示します。複数コンテナPodでは -c <コンテナ名> を指定して対象を明確にします。

Pod内で一時的にシェルを開き、ファイルや環境変数を確認したい。一般的な実行コマンドはどれですか？

答え： kubectl exec -it <pod名> -- sh

kubectl exec はコンテナ内でコマンドを実行します。-it は対話操作向けで、-- の後にコンテナ内で実行するコマンドを指定します。

修正したDeploymentマニフェスト deployment.yaml をクラスタに反映したい。宣言的管理として適切なコマンドはどれですか？

答え： kubectl apply -f deployment.yaml

kubectl apply -f はYAMLなどのマニフェストをクラスタへ宣言的に反映します。差分を継続管理する前提の運用でよく使います。

特定Namespace dev のPod一覧を確認したい。適切なコマンドはどれですか？

答え： kubectl get pods -n dev

Namespaceを指定するには -n または --namespace を使います。--context は接続先クラスタやユーザーなどのkubectl contextを切り替える指定です。

Deployment web のレプリカ数を一時的に3へ変更したい。適切なコマンドはどれですか？

答え： kubectl scale deployment web --replicas=3

kubectl scale はDeploymentやReplicaSetなどのレプリカ数を変更します。GitOps運用では、恒久変更はマニフェスト側にも反映する必要があります。

Deployment api の更新が正常に進んでいるか、ロールアウト状態を確認したい。適切なコマンドはどれですか？

答え： kubectl rollout status deployment/api

kubectl rollout status deployment/api はDeploymentのロールアウト進行状況を確認します。更新が止まっている場合の初期確認に便利です。

不要になったNamespace sandbox を削除したい。含まれるリソースもまとめて削除される点に注意しながら実行するコマンドはどれですか？

答え： kubectl delete namespace sandbox

kubectl delete namespace sandbox はNamespaceを削除します。Namespace内の多くのリソースも削除対象になるため、対象環境を確認してから実行します。

操作前に、kubectlが現在どのクラスタ・ユーザー・Namespaceを向いているか確認したい。適切なコマンドはどれですか？

答え： kubectl config current-context と kubectl config view --minify

kubectl config current-context は現在のcontext名を表示します。kubectl config view --minify は現在contextに絞ったcluster、user、namespaceなどの設定確認に使えます。

Podの配置判断に必要なCPU量をSchedulerへ伝え、同時にコンテナが使えるCPUの上限も設定したい。指定する組合せはどれですか？

答え： requestsとlimits

requestsはスケジューリング時に必要量として使われ、limitsはコンテナが利用できるリソース上限を定めます。

アプリの起動は完了したが、依存DBへの接続が切れて一時的にリクエストを処理できない。Podを再起動せずServiceの転送先から外したい。使うProbeはどれですか？

答え： readinessProbe

readinessProbeが失敗するとPodは準備未完了となり、通常はServiceの転送対象から外れますが、コンテナは再起動されません。

DeploymentのPod数をCPU使用率に応じて自動的に増減させたい。代表的に利用するリソースはどれですか？

答え： HorizontalPodAutoscaler

HorizontalPodAutoscalerはCPU使用率などのメトリクスを基に、対象ワークロードのレプリカ数を調整します。

Nodeメンテナンスのdrain中も、WebアプリのPodを最低2個は利用可能に保ちたい。設定するものはどれですか？

答え： PodDisruptionBudgetのminAvailable

PodDisruptionBudgetはdrainなどの自発的な中断で同時に利用不能にできるPod数を制約します。障害による停止そのものは防ぎません。

あるNamespaceで、明示的に許可した通信以外はPodへの受信を拒否する方針にしたい。基本となる方法はどれですか？

答え： default-denyのNetworkPolicyを作り、必要な通信を別Policyで許可する

NetworkPolicy対応CNIを前提に、Podを選択する受信default-denyを設定し、必要な送信元やポートだけを追加Policyで許可します。

Kubernetesアプリを複数のマニフェストとしてまとめ、値を差し替えながら再利用可能に配布したい。Helmで中心になる単位はどれですか？

答え： Chart

Helm ChartはKubernetesリソースのテンプレートや既定値をまとめたパッケージです。環境差分はvaluesで調整し、同じChartを複数環境へ展開できます。

同じHelm Chartをdevとprodに展開するが、prodだけレプリカ数やイメージタグを変えたい。一般的に編集・指定するものはどれですか？

答え： values.yaml または追加のvaluesファイル

HelmではChart内のテンプレートに値を埋め込みます。環境別の差分はvalues.yaml、別valuesファイル、--setなどで指定します。

リポジトリにあるChartを初めてクラスタへ展開し、Helmのリリースとして管理したい。基本コマンドはどれですか？

答え： helm install

helm installは指定したChartからリソースを作成し、名前付きのリリースとして履歴管理します。repo updateはローカルのChart索引更新だけです。

既存のHelmリリースを新しいChartバージョンやvaluesで更新したい。使うコマンドはどれですか？

答え： helm upgrade

helm upgradeは既存リリースを指定したChartと値で更新します。必要に応じて--installを付けると未作成時にインストールもできます。

HelmのテンプレートがどのKubernetesマニフェストに展開されるか、クラスタへ適用せず事前確認したい。適切なのはどれですか？

答え： helm template

helm templateはChartをローカルでレンダリングし、生成されるYAMLを表示します。CIでの確認やレビューにも使えます。

Helmリリースの更新に失敗した場合、直前の正常なリビジョンへ戻したい。使うコマンドはどれですか？

答え： helm rollback

helm rollbackはリリース履歴の指定リビジョンへ戻します。対象リビジョンを判断するにはhelm historyで履歴を確認します。

Helm Chart内で、APIバージョンやアプリバージョンなどChart自体のメタデータを記述するファイルはどれですか？

答え： Chart.yaml

Chart.yamlはChart名、バージョン、appVersionなどChartのメタデータを持ちます。values.yamlはテンプレートへ渡す既定値を持ちます。

Helmリリースを削除し、Chartから作成されたKubernetesリソースも通常は削除したい。使うコマンドはどれですか？

答え： helm uninstall

helm uninstallは指定リリースをアンインストールし、通常はそのリリースが管理していたKubernetesリソースを削除します。

一時的にNodeへ新しいPodを配置させず、既存Podはすぐには退避しないようにしたい。使うkubectl操作はどれですか？

答え： kubectl cordon

cordonはNodeをSchedulingDisabledにし、新しいPodの配置対象から外します。既存Podを退避させるにはdrainを使います。

DeploymentのPodを設定変更なしで順番に作り直し、アプリを再起動させたい。代表的なコマンドはどれですか？

答え： kubectl rollout restart deployment/<name>

kubectl rollout restartはPodテンプレートに再起動用の変更を加え、Deploymentのローリング更新としてPodを作り直します。

Deploymentの新バージョン展開が途中で止まっていないか確認したい。進行状況の確認に使う代表的なコマンドはどれですか？

答え： kubectl rollout status deployment/<name>

rollout statusはDeploymentなどのロールアウト完了や進行状況を確認します。失敗時はdescribeやlogsで原因を追います。

NamespaceごとにCPUやメモリの合計使用量を制限し、チーム単位の使いすぎを防ぎたい。使うリソースはどれですか？

答え： ResourceQuota

ResourceQuotaはNamespace内で作成できるリソース数やCPU・メモリ要求量などの合計に上限を設定します。

PodがKubernetes APIへアクセスするときの権限を、アプリごとに最小化したい。まず紐づけるべきKubernetesリソースはどれですか？

答え： ServiceAccount

PodにはServiceAccountを紐づけられます。実際の許可はRole/ClusterRoleとRoleBinding/ClusterRoleBindingで最小権限にします。

Namespace内のユーザーにPod一覧の参照だけを許可し、クラスタ全体の権限は与えたくない。使う組合せとして適切なのはどれですか？

答え： Role と RoleBinding

Namespace内だけの権限にはRoleを定義し、そのNamespaceでRoleBindingします。ClusterRoleBindingはクラスタ全体に広がるため過剰になりやすいです。

Podをrootユーザーで動かさない、特権コンテナを禁止するなど、Podのセキュリティ条件をNamespace単位で強めたい。代表的な仕組みはどれですか？

答え： Pod Security Admission

Pod Security AdmissionはNamespaceラベルでPod Security Standardsのレベルを適用し、Pod作成時にセキュリティ条件を検査できます。

アプリが永続ディスクを要求し、実際のストレージ実体とは疎結合にしたい。Pod側で参照する要求リソースはどれですか？

答え： PersistentVolumeClaim

PodはPVCを参照して必要な容量やアクセスモードを要求します。PVは実体、StorageClassは動的プロビジョニングの種類を表します。

クラウド環境でPVC作成時にストレージを自動作成し、SSDやHDDなどの種類を選ばせたい。主に使うリソースはどれですか？

答え： StorageClass

StorageClassは動的プロビジョニングで使うプロビジョナやパラメータを定義します。PVCから参照することでストレージを自動作成できます。

PodがPendingのまま起動しない。スケジューリング失敗やPVC未束縛などの理由をまず確認するコマンドはどれですか？

答え： kubectl describe pod <pod>

Pendingではコンテナがまだ動いていないことが多く、describeでEventsを確認するとスケジューリング失敗、リソース不足、PVC未束縛などを追えます。

PodがCrashLoopBackOffになっている。直前に終了したコンテナのログを確認したい。適切なオプションはどれですか？

答え： kubectl logs <pod> --previous

--previousを付けると、再起動前の終了済みコンテナインスタンスのログを取得できます。CrashLoopBackOffの原因調査で有効です。

クラスタ外からHTTPでアプリへアクセスさせ、ホスト名やパスごとに複数Serviceへ振り分けたい。主に定義するリソースはどれですか？

答え： Ingress

IngressはHTTP/HTTPSの入口ルールを定義し、ホスト名やパスに応じてServiceへルーティングします。実際の処理にはIngress Controllerが必要です。

Podが何度も再起動し、直前の終了理由がOOMKilledになっている。最初に見直す内容として最も適切なものはどれですか？

答え： 実際のメモリ使用量とmemory request/limitを確認し、アプリまたは制限値を調整する

OOMKilledはコンテナが利用可能なメモリを超えたことを示します。メトリクス、使用傾向、request/limit、メモリリークを確認し、根拠を持って調整します。

新しいPodがImagePullBackOffになった。まず確認する組合せとして最も適切なものはどれですか？

答え： PodのEvents、イメージ名・タグ、レジストリ認証用imagePullSecrets

ImagePullBackOffではdescribeでEventsを確認し、存在しないタグ、レジストリ到達性、認証Secretの設定などを切り分けます。

Deploymentの新バージョンでエラー率が急増したため、直前の正常なリビジョンへすぐ戻したい。適切なコマンドはどれですか？

答え： kubectl rollout undo deployment/<name>

rollout undoはDeploymentを以前のリビジョンへ戻します。実行後はrollout statusとアプリ指標で復旧を確認します。

起動に数分かかるアプリで、起動処理中にlivenessProbeが失敗して再起動を繰り返している。適切な改善はどれですか？

答え： startupProbeを設定し、成功するまでliveness/readinessの開始を待たせる

startupProbeは遅い初期化の完了を判定し、成功前のliveness/readiness実行を抑えます。起動後は通常の健全性確認を継続できます。

3つのAvailability Zoneにまたがるクラスタで、同じアプリのPodが1ゾーンへ偏るのを抑えたい。適切な設定はどれですか？

答え： topologySpreadConstraintsをzoneラベルに対して設定する

topologySpreadConstraintsはzoneなどのトポロジードメイン間で、条件に一致するPodの偏りを制御します。

ServiceのClusterIPへ接続できるが応答先がなく、EndpointSliceにエンドポイントが表示されない。最初に確認すべきものはどれですか？

答え： Serviceのselectorが対象Podのlabelsと一致しているか

selectorとPod labelが一致しないとServiceはバックエンドを選択できず、対応するEndpointSliceにPod IPが登録されません。

Podからapi.backend.svc.cluster.localの名前解決だけが失敗している。切り分けとして適切なものはどれですか？

答え： Pod内からnslookup等を実行し、Service名・NamespaceとCoreDNSの状態を確認する

クラスタDNSの問題は、呼び出し元Podでの名前解決結果、FQDNのService名とNamespace、CoreDNS Pod・ログ・Serviceを順に確認します。

稼働中アプリのPVC容量を増やしたい。事前条件として主に確認すべきものはどれですか？

答え： StorageClassがボリューム拡張を許可し、CSIドライバ等が拡張をサポートしていること

PVC拡張にはStorageClassのallowVolumeExpansionと、ストレージドライバ・基盤側の対応が必要です。ファイルシステム拡張の条件も確認します。

各レプリカに安定した名前と個別の永続ボリュームが必要なデータストアを運用したい。適切なworkloadはどれですか？

答え： StatefulSet

StatefulSetはPodへ安定した序数付きIDを与え、volumeClaimTemplatesで各レプリカ専用のPVCを管理できます。

一般的なLinuxコンテナで不要なシステムコールを既定プロファイルで制限したい。securityContextで指定するものはどれですか？

答え： seccompProfile.type: RuntimeDefault

RuntimeDefaultはコンテナランタイムの既定seccompプロファイルを使用してシステムコールを制限します。ワークロード互換性を検証して適用します。