Kubernetes CKA 認定試験実践問題集（55問 + 実技シミュレーション10問）

CKA試験概要

CKA（Certified Kubernetes Administrator）は、CNCF（Cloud Native Computing Foundation）が提供する実技重視のKubernetes管理者認定試験です。

項目	内容
試験時間	120分
問題数	17問（実技形式）
合格基準	66%以上
試験形式	オンライン、監督付き
有効期間	3年
Kubernetesバージョン	最新安定版

ドメイン別出題比率

ドメイン	比率
Cluster Architecture, Installation & Configuration	25%
Workloads & Scheduling	15%
Services & Networking	20%
Storage	10%
Troubleshooting	30%

kubectlコマンドチートシート

# クラスター情報
kubectl cluster-info
kubectl get nodes -o wide
kubectl describe node NODE_NAME

# Pod管理
kubectl run nginx --image=nginx --restart=Never
kubectl get pods -A -o wide
kubectl describe pod POD_NAME
kubectl logs POD_NAME -c CONTAINER_NAME
kubectl exec -it POD_NAME -- /bin/sh

# Deployment管理
kubectl create deployment myapp --image=nginx --replicas=3
kubectl scale deployment myapp --replicas=5
kubectl rollout status deployment myapp
kubectl rollout undo deployment myapp

# サービス公開
kubectl expose deployment myapp --port=80 --type=ClusterIP
kubectl expose deployment myapp --port=80 --type=NodePort

# RBAC
kubectl create serviceaccount mysa
kubectl create clusterrole myrole --verb=get,list,watch --resource=pods
kubectl create clusterrolebinding mybinding --clusterrole=myrole --serviceaccount=default:mysa

# etcdバックアップ/リストア
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# ノード管理
kubectl cordon NODE_NAME
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
kubectl uncordon NODE_NAME

# jsonpath使用例（中括弧はクォートで囲む）
kubectl get pod mypod -o jsonpath='{.spec.nodeName}'
kubectl get nodes -o jsonpath='{.items[*].metadata.name}'

選択問題（Q1 〜 Q55）

ドメイン1: Cluster Architecture, Installation & Configuration

Q1. kubeadm initでKubernetesクラスターを初期化するとき、デフォルトのPodネットワークCIDRは？

A) 10.0.0.0/8 B) 192.168.0.0/16 C) 明示的な指定が必要（デフォルト値なし） D) 172.16.0.0/12

答え: C

解説: kubeadm initはデフォルトのPodネットワークCIDRを自動設定しません。--pod-network-cidrフラグで明示的に指定する必要があります。CNIプラグインによって異なり、Calicoは通常192.168.0.0/16、Flannelは10.244.0.0/16を使用します。

Q2. etcdスナップショットをリストアするための正しいetcdctlコマンドは？

A) etcdctl snapshot load B) etcdctl snapshot restore C) etcdctl backup restore D) etcdctl cluster restore

答え: B

解説: ETCDCTL_API=3 etcdctl snapshot restoreコマンドでetcdスナップショットをリストアします。--data-dirオプションでリストア先を指定し、etcdサービスを再起動する必要があります。

Q3. ClusterRoleとRoleの違いとして正しいものは？

A) ClusterRoleは1つの名前空間にのみ適用される B) Roleはクラスター全体のリソースにアクセスできる C) ClusterRoleはクラスタースコープのリソースとすべての名前空間に適用できる D) ClusterRoleとRoleは機能的に同一である

答え: C

解説: ClusterRoleはクラスタースコープのリソース（nodes、persistentvolumesなど）とすべての名前空間の名前空間スコープのリソースへのアクセス権を付与できます。Roleは特定の名前空間内でのみ有効です。

Q4. RoleBindingとClusterRoleBindingの違いは？

A) RoleBindingはClusterRoleを参照できない B) ClusterRoleBindingは特定の名前空間にのみ適用される C) RoleBindingは特定の名前空間内で権限を付与し、ClusterRoleBindingはクラスター全体に権限を付与する D) 両者は同じスコープに適用される

答え: C

解説: RoleBindingは特定の名前空間内のリソースへの権限を付与します。ClusterRoleBindingはクラスター全体にわたって権限を付与します。RoleBindingがClusterRoleを参照する場合、ClusterRoleの権限はその名前空間のみに適用されます。

Q5. kubeadmでクラスターをアップグレードするときの正しい手順は？

A) コントロールプレーン → ワーカーノード → etcd B) etcd → コントロールプレーン → ワーカーノード C) ワーカーノード → コントロールプレーン → etcd D) kubeadm upgrade plan → kubeadm upgrade apply → kubelet/kubectlのアップグレード

答え: D

解説: 正しい手順: 1) kubeadm upgrade planで利用可能なバージョンを確認、2) kubeadm upgrade apply vX.Y.Zでコントロールプレーンをアップグレード、3) kubeletとkubectlをアップグレード、4) 各ワーカーノードでkubeadm upgrade nodeを実行、5) ワーカーノードのkubeletをアップグレード。

Q6. Kubernetes APIサーバー証明書のデフォルトの場所は？

A) /etc/ssl/kubernetes/ B) /var/lib/kubernetes/ C) /etc/kubernetes/pki/ D) /home/kubernetes/certs/

答え: C

解説: kubeadmで作成されたクラスターでは、証明書はデフォルトで/etc/kubernetes/pki/ディレクトリに保存されます。apiserver.crt、apiserver.key、ca.crt、ca.keyなどがこのディレクトリにあります。

Q7. kubectl config use-contextコマンドの役割は？

A) 新しいkubeconfigファイルを作成する B) 現在のアクティブなコンテキストを変更する C) クラスターに新しいユーザーを追加する D) 名前空間を変更する

答え: B

解説: kubectl config use-context CONTEXT_NAMEはkubeconfigファイルの現在のアクティブコンテキストを切り替えます。CKA試験では各問題ごとに異なるコンテキストに切り替える必要があるため、非常に重要なコマンドです。

Q8. ノードにtaintを追加する正しいコマンドは？

A) kubectl label node NODE_NAME key=value:NoSchedule B) kubectl taint node NODE_NAME key=value:NoSchedule C) kubectl annotate node NODE_NAME key=value:NoSchedule D) kubectl mark node NODE_NAME key=value:NoSchedule

答え: B

解説: kubectl taint nodes NODE_NAME key=value:effectでtaintを追加します。effectはNoSchedule、PreferNoSchedule、NoExecuteのいずれかです。削除するには末尾に-を付けます: kubectl taint nodes NODE_NAME key=value:NoSchedule-

Q9. Static Podを作成する正しい方法は？

A) kubectl create podコマンドを使用する B) kubeletが監視するディレクトリ（デフォルト: /etc/kubernetes/manifests/）にYAMLファイルを配置する C) kube-apiserverに直接APIコールを行う D) etcdに直接データを書き込む

答え: B

解説: Static Podはkubeletが監視するディレクトリ（デフォルト: /etc/kubernetes/manifests/）にPodマニフェストファイルを配置することで作成されます。kubeletがファイルを検出し、Podを起動します。kube-apiserver、etcd、controller-manager、schedulerなどのコントロールプレーンコンポーネントはこの方式で実行されます。

Q10. kubeadm joinの--tokenと--discovery-token-ca-cert-hashの役割は？

A) クラスター証明書を生成する B) ワーカーノードがコントロールプレーンに安全に参加するための認証情報 C) ネットワークCNIを設定する D) etcdクラスターに参加する

答え: B

解説: --tokenはBootstrap Tokenで、ワーカーノードがコントロールプレーンと通信するための一時的な認証トークンです。--discovery-token-ca-cert-hashはCA証明書のハッシュ値で、中間者攻撃を防ぎます。kubeadm token create --print-join-commandで再生成できます。

ドメイン2: Workloads & Scheduling

Q11. ローリングアップデート中に同時に利用不可能なPodの最大数を設定するフィールドは？

A) maxSurge B) maxUnavailable C) minReadySeconds D) revisionHistoryLimit

答え: B

解説: spec.strategy.rollingUpdate.maxUnavailableはローリングアップデート中に同時に利用不可能なPodの最大数（またはパーセンテージ）を指定します。maxSurgeは同時に追加作成できるPodの最大数を指定します。デフォルト値は両方とも25%です。

Q12. PodのQoSクラスのうち、requestsとlimitsが同じ値に設定されている場合は？

A) BestEffort B) Burstable C) Guaranteed D) Reserved

答え: C

解説: Guaranteed QoSクラスは、PodのすべてのコンテナでCPUとメモリのrequestsとlimitsが設定され、かつ同じ値である場合に割り当てられます。Burstableはrequestsとlimitsが異なる場合、BestEffortはrequests/limitsがまったく設定されていない場合です。

Q13. nodeSelectorとnodeAffinityの違いは？

A) nodeSelectorはより複雑なルールをサポートする B) nodeAffinityはrequired/preferredルールとIn、NotInなど様々な演算子をサポートする C) nodeSelectorはlabelではなくannotationを使用する D) nodeAffinityはdeprecatedになっている

答え: B

解説: nodeAffinityはnodeSelectorよりも表現力があります。requiredDuringSchedulingIgnoredDuringExecution（ハード要件）とpreferredDuringSchedulingIgnoredDuringExecution（ソフト要件）をサポートし、In、NotIn、Exists、DoesNotExist、Gt、Lt演算子を使用できます。

Q14. DaemonSetを使用するのはどのような場合か？

A) 特定数のPodレプリカを常に維持する場合 B) すべての（または一部の）ノードにPodを1つずつ実行する場合 C) 順序がある状態保持アプリケーションを実行する場合 D) バッチ処理を実行する場合

答え: B

解説: DaemonSetはクラスターのすべてのノード（またはnodeSelectorで選択されたノード）にPodを1つずつ実行します。ノード監視エージェント、ログコレクター、ネットワークプラグインなどに使用されます。新しいノードが追加されると、そのノードに自動的にPodが作成されます。

Q15. StatefulSetのPod名の形式は？

A) pod-ランダムサフィックス B) statefulset-name-0、statefulset-name-1、... C) statefulset-name-ランダム D) pod-0、pod-1、...

答え: B

解説: StatefulSetのPodは予測可能な名前を持ちます: statefulset名-0、statefulset名-1、... という形式です。この安定した名前はStatefulSetが提供する中核機能の一つで、順序付きデプロイ・スケーリング・削除を可能にします。

Q16. Jobのcompletionsとparallelismフィールドの役割は？

A) completions: 同時実行Pod数、parallelism: 完了すべき総タスク数 B) completions: 完了すべき総タスク数、parallelism: 同時実行Pod数 C) completions: リトライ回数、parallelism: タイムアウト時間 D) 両フィールドともリトライに関する設定

答え: B

解説: completionsはJobが正常に完了すべきPodの総数を指定します。parallelismは同時実行できるPodの数を指定します。例: completions=10、parallelism=3の場合、10個のタスクを3個ずつ並列処理します。

Q17. CronJobでタイムゾーンを設定するには？

A) spec.scheduleフィールドにタイムゾーン情報を含める B) spec.timeZoneフィールドにIANAタイムゾーン名を指定する（Kubernetes 1.27以降） C) クラスター全体の設定でのみ可能 D) CronJobはタイムゾーンをサポートしない

答え: B

解説: Kubernetes 1.27からGA（Generally Available）としてspec.timeZoneフィールドがサポートされています。"America/New_York"や"Asia/Tokyo"などのIANAタイムゾーン名を指定できます。以前のバージョンではUTC基準でスケジュールを設定する必要がありました。

Q18. Pod AffinityとPod Anti-Affinityの違いは？

A) Pod Affinityは特定のノードに、Pod Anti-Affinityは特定のPodと同じノードにスケジューリング B) Pod Affinityは特定のPodと同じ場所に、Pod Anti-Affinityは特定のPodと異なる場所にスケジューリング C) 2つの概念は同一 D) Pod Anti-Affinityはdeprecatedになっている

答え: B

解説: Pod Affinityは特定のラベルを持つPodと同じノード/ゾーンにスケジューリングします（例：キャッシュとアプリを同じノードに配置）。Pod Anti-Affinityは特定のラベルを持つPodと異なるノード/ゾーンにスケジューリングします（例：可用性のためにレプリカを異なるノードに分散）。

Q19. kubectl get pod --field-selector=status.phase=Runningのfield-selectorとは？

A) ラベルベースのフィルタリング B) リソースの特定フィールド値によるフィルタリング C) アノテーションベースのフィルタリング D) 名前空間によるフィルタリング

答え: B

解説: --field-selectorはリソースオブジェクトの特定フィールド値でフィルタリングします。--selector（または-l）がラベルベースなのと異なり、field-selectorはstatus.phase、metadata.name、spec.nodeNameなどの実際のリソースフィールドを基準にします。

Q20. Tolerationを使用する目的は？

A) Podを特定のノードに強制配置する B) Podが特定のtaintを持つノードにスケジューリングされることを許可する C) 特定のノードからPodを削除する D) ノードに新しいtaintを追加する

答え: B

解説: Taintはノードに設定され、特定のPodがスケジューリングされないようにします。TolerationはPodに設定され、特定のtaintを「許容できる」と宣言します。Tolerationがあるからといってそのノードに必ずスケジューリングされるわけではなく、単にスケジューリングが許可されるだけです。

ドメイン3: Services & Networking

Q21. ClusterIPサービスの特徴は？

A) クラスター外部からアクセス可能 B) ノードの特定ポートを通じてアクセス可能 C) クラスター内部からのみアクセス可能な仮想IPを提供する D) ロードバランサーを自動作成する

答え: C

解説: ClusterIPサービスはクラスター内部からのみアクセス可能な仮想IPアドレス（Cluster IP）を割り当てます。外部からはアクセスできず、クラスター内部のサービス間通信に使用されます。デフォルトのサービスタイプです。

Q22. NodePortサービスで許可されるポート範囲は？

A) 1-1024 B) 1024-65535 C) 30000-32767 D) 8000-9000

答え: C

解説: NodePortのデフォルトポート範囲は30000-32767です。kube-apiserverの--service-node-port-rangeフラグで変更できます。指定しない場合、この範囲内でポートが自動的に割り当てられます。

Q23. CoreDNSでのサービスDNS名の形式は？

A) service-name.cluster.local B) service-name.namespace.svc.cluster.local C) namespace.service-name.cluster.local D) service-name.default.kubernetes.local

答え: B

解説: KubernetesでのサービスのFQDNはservice-name.namespace.svc.cluster.local形式です。同じ名前空間内ではservice-nameだけでもアクセスできます。PodのDNSはpod-ip（ドットをダッシュに変換）.namespace.pod.cluster.local形式です。

Q24. NetworkPolicyを適用するための前提条件は？

A) kube-proxyがIPVSモードである必要がある B) NetworkPolicyをサポートするCNIプラグインが必要 C) クラスターがクラウドプロバイダーで実行されている必要がある D) Ingress Controllerがインストールされている必要がある

答え: B

解説: NetworkPolicyはCNI（Container Network Interface）プラグインがサポートしている必要があります。Calico、Cilium、WeaveNetなどがNetworkPolicyをサポートしています。FlannelはデフォルトでNetworkPolicyをサポートしていません。対応するCNIがなければNetworkPolicyリソースを作成してもトラフィック制御は実際には適用されません。

Q25. Ingressリソースが機能するための前提条件は？

A) NodePortサービスが存在する必要がある B) LoadBalancerサービスが存在する必要がある C) Ingress Controllerがクラスターにデプロイされている必要がある D) kube-proxyが実行中である必要がある

答え: C

解説: Ingressリソース単独ではトラフィックを処理しません。Nginx Ingress Controller、Traefik、HAProxyなどのIngress Controllerがクラスターにデプロイされていて初めてIngressルールが適用されます。

Q26. kube-proxyのデフォルトモードは？

A) userspace B) iptables C) IPVS D) ebpf

答え: B

解説: kube-proxyのデフォルトモードはiptablesです。IPVSモードはより多くのロードバランシングアルゴリズムをサポートし、大規模クラスターでより良いパフォーマンスを提供します。CiliumなどのCNIはkube-proxyなしにeBPFでサービスを処理できます。

Q27. ServiceにexternalTrafficPolicy: Localを設定したときの効果は？

A) 外部トラフィックをブロックする B) トラフィックを受信したノードのPodにのみ転送し、クライアントIPを保持する C) すべてのノードに均等にトラフィックを分散する D) LoadBalancerサービスにのみ適用可能

答え: B

解説: externalTrafficPolicy: Localを設定すると、外部トラフィックはそのPodを実行しているノードにのみ転送されます。元のクライアントIPが保持されるメリットがありますが、Podがないノードでは接続が拒否される可能性があります。デフォルトのClusterはすべてのノードへSNATして転送します。

Q28. CNI（Container Network Interface）プラグインの役割は？

A) コンテナランタイムを管理する B) Pod間のネットワーク接続とIPアドレスの割り当てを担当する C) Kubernetes APIサーバーとの通信を処理する D) ストレージボリュームをマウントする

答え: B

解説: CNIプラグインはPod作成時にネットワークインターフェースを設定し、IPアドレスを割り当て、Pod間通信が可能なようにネットワークルーティングを構成します。Flannel、Calico、Cilium、WeaveNet、Canalが代表的なCNIプラグインです。

Q29. headless service（clusterIP: None）の特徴は？

A) サービスが外部からアクセスできない B) 個別のPod IPをDNSで直接返し、クライアントがPodを直接選択できる C) ロードバランシングなしにランダムにPodに転送する D) StatefulSetでのみ使用可能

答え: B

解説: Headless ServiceはclusterIP: Noneで設定し、仮想IPなしでDNSが直接PodのIPリストを返します。StatefulSetと組み合わせると、各Podに安定したDNS名（pod-0.service.namespace.svc.cluster.local）が提供されます。

Q30. NetworkPolicyのpodSelector: {}（空のセレクター）の意味は？

A) どのPodも選択しない B) その名前空間のすべてのPodを選択する C) すべての名前空間のすべてのPodを選択する D) システムPodのみを選択する

答え: B

解説: NetworkPolicyのpodSelector: {}は空のセレクターで、NetworkPolicyがデプロイされた名前空間のすべてのPodを選択します。すべてのPodにネットワークポリシーを適用したり、デフォルト拒否ポリシーを作成する際に使用します。

ドメイン4: Storage

Q31. PersistentVolumeのReclaim PolicyがRetainのとき、PVCが削除されると？

A) PVも自動的に削除される B) PVのデータが初期化される C) PVC削除後もPVが維持され、管理者が手動で処理する必要がある D) PVが別のPVCに自動的にバインドされる

答え: C

解説: Retainポリシーは、PVCが削除されてもPVを保持します。PVはReleased状態になり、データは保存されます。管理者がPVのclaimRefを手動で削除するか、PV自体を削除する必要があります。Deleteポリシーはバックエンドストレージも削除します。

Q32. PVCのアクセスモードReadWriteMany（RWX）とは？

A) 1つのノードから読み書き可能 B) 複数のノードから同時に読み込みのみ可能 C) 複数のノードから同時に読み書き可能 D) 1つのPodからのみ読み書き可能

答え: C

解説: ReadWriteMany（RWX）は複数のノードから同時に読み書きができます。NFS、CephFS、Azure Fileなどがサポートしています。ReadWriteOnce（RWO）は1つのノードから読み書き、ReadOnlyMany（ROX）は複数のノードから読み込みのみ可能です。

Q33. StorageClassの主な役割は？

A) 既存のPVを管理する B) 動的PVプロビジョニングのためのストレージ属性を定義する C) Podに直接ストレージを割り当てる D) ネットワークストレージへのアクセスをブロックする

答え: B

解説: StorageClassはPVCが作成されたときに自動的にPVを動的にプロビジョニングする方法を定義します。provisioner（例: kubernetes.io/aws-ebs）、reclaimPolicy、parametersなどを指定します。volumeBindingMode: WaitForFirstConsumerはPodがスケジューリングされるまでPV作成を遅延させます。

Q34. emptyDirボリュームの特徴は？

A) ノードが再起動してもデータが保持される B) Podが削除されるとデータも削除され、Pod内のコンテナ間のデータ共有に使用される C) 複数のPod間でデータを共有できる D) PVCなしで外部ストレージにアクセスする

答え: B

解説: emptyDirはPodがノードに割り当てられたときに作成され、Podが削除されると一緒に削除されます。Pod内の複数のコンテナ間でファイルを共有するのに便利です。デフォルトはノードのディスクを使用しますが、medium: Memoryでtmpfsを使用することもできます。

Q35. ConfigMapをボリュームとしてマウントする利点は？

A) 環境変数として注入するよりも速い B) ファイルとしてマウントされ、ランタイム中のConfigMap変更が自動的に反映される可能性がある C) 暗号化されたデータを保存できる D) 永続ストレージのようにデータが保持される

答え: B

解説: ConfigMapをボリュームとしてマウントすると、ConfigMapの更新時にマウントされたファイルが自動的に更新されます（kubeletのsyncFrequencyに依存）。環境変数として注入されたConfigMapはPodの再起動なしには更新されません。

ドメイン5: Troubleshooting

Q36. PodがCrashLoopBackOff状態のとき、最初に確認すべきことは？

A) kubectl get podでPodの一覧を確認 B) kubectl logsでコンテナのログを確認 C) kubectl deleteでPodを再作成 D) ノードを再起動

答え: B

解説: CrashLoopBackOffはコンテナが繰り返しクラッシュして再起動されている状態です。kubectl logs POD_NAMEでコンテナのstdout/stderrログを確認し、必要に応じてkubectl logs POD_NAME --previousで前回のクラッシュログを確認します。kubectl describe podでイベントも確認します。

Q37. ImagePullBackOffエラーの主な原因と解決方法は？

A) PodのCPU/メモリ不足 B) 誤ったイメージ名/タグ、またはプライベートレジストリの認証情報がない C) NetworkPolicyによるブロック D) PVCバインディングの失敗

答え: B

解説: ImagePullBackOffの主な原因: 1) イメージ名やタグが誤っている、2) イメージが存在しない、3) プライベートレジストリの認証情報（imagePullSecrets）が未設定、4) ネットワーク接続の問題。kubectl describe podのEventsセクションで詳細なエラーメッセージを確認できます。

Q38. ノードがNotReady状態のとき、確認すべき項目は？

A) kube-apiserverのログのみ確認 B) kubeletサービスの状態、ログ、ネットワーク接続、ディスク/メモリ状態 C) etcdの状態のみ確認 D) Podを削除して再作成

答え: B

解説: NotReady診断: 1) systemctl status kubeletでkubeletの状態確認、2) journalctl -u kubelet -fでkubeletログ確認、3) kubectl describe nodeでディスク/メモリ/PID圧迫確認、4) ネットワーク接続確認、5) コンテナランタイム（containerd/docker）の状態確認。

Q39. etcdクラスターの正常性を確認するコマンドは？

A) kubectl get etcd B) etcdctl endpoint health C) systemctl status etcd D) kubectl describe etcd

答え: B

解説: ETCDCTL_API=3 etcdctl endpoint health --endpoints=https://127.0.0.1:2379 --cacert=... --cert=... --key=...でetcdクラスターの状態を確認します。etcdctl endpoint statusで各メンバーの状態とリーダー情報を確認できます。

Q40. 実行中のPodでコマンドを実行する正しい方法は？

A) kubectl exec POD_NAME COMMAND B) kubectl exec -it POD_NAME -- COMMAND C) kubectl run POD_NAME -- COMMAND D) kubectl attach POD_NAME -c COMMAND

答え: B

解説: kubectl exec -it POD_NAME -- /bin/shでPodの対話型シェルを開けます。-iはstdinを開き、-tはTTYを割り当てます。特定のコンテナを指定する場合は-c CONTAINER_NAMEを追加します。単一コマンド実行: kubectl exec POD_NAME -- ls /etc

Q41. Podのリソース使用量を確認するコマンドは？

A) kubectl get pod --resources B) kubectl top pod C) kubectl describe pod --metrics D) kubectl stats pod

答え: B

解説: kubectl top podでPodのCPUとメモリ使用量を表示します。このコマンドはMetrics Serverがクラスターにインストールされている必要があります。kubectl top nodeでノードのリソース使用量を確認できます。

Q42. PodがPending状態になる主な原因は？

A) コンテナがクラッシュしている B) イメージが見つからない C) スケジューラーが適切なノードを見つけられない、またはPVCがバインドされていない D) ネットワーク接続の問題

答え: C

解説: Podがペンディング状態になる原因: 1) リソース不足（CPU/メモリ）でスケジューリング不可、2) taint/tolerationの不一致、3) nodeSelector/affinityの条件を満たすノードがない、4) PVCがバインドされていない、5) スケジューラーが実行されていない。kubectl describe podのEventsで理由を確認できます。

Q43. kube-apiserverのログを確認する方法は？

A) kubectl logs kube-apiserver -n default B) kubectl logs -n kube-system kube-apiserver-NODENAME C) systemctl logs kube-apiserver D) journalctl -u kubernetes

答え: B

解説: Static Podとして実行されるkube-apiserverのログはkubectl logs -n kube-system kube-apiserver-controlplaneで確認できます（Pod名にはノード名が含まれます）。またはcrictl logs CONTAINER_IDでも確認できます。

Q44. コンテナがOOMKilled状態になる原因と解決策は？

A) CPU制限超過 - limits.cpuを増やす B) メモリ制限超過 - limits.memoryを増やす、またはアプリのメモリ使用を最適化する C) ディスク容量不足 - PVCのサイズを増やす D) ネットワークタイムアウト - リトライ設定を追加する

答え: B

解説: OOMKilled（Out of Memory Killed）はコンテナがlimits.memoryに設定されたメモリ制限を超えたときに発生します。解決策: 1) limits.memoryの値を適切に増やす、2) アプリケーションのメモリリークを確認して修正、3) JVMの場合はヒープサイズ（-Xmx）を調整。

Q45. Kubernetesのイベントを時系列で確認するコマンドは？

A) kubectl get events B) kubectl get events --sort-by=.metadata.creationTimestamp C) kubectl describe events D) kubectl logs events

答え: B

解説: kubectl get events --sort-by=.metadata.creationTimestampでイベントを時系列に並び替えて確認します。特定の名前空間: kubectl get events -n NAMESPACE。リアルタイム確認: kubectl get events --watch。kubectl describe podのEventsセクションでもPod関連イベントを確認できます。

Q46. kubeletの設定ファイルの場所は？

A) /etc/kubernetes/kubelet.conf B) /var/lib/kubelet/config.yaml C) /etc/kubelet/config.yaml D) /usr/local/kubernetes/kubelet.conf

答え: B

解説: kubeletのデフォルト設定ファイルは/var/lib/kubelet/config.yamlで、systemdサービス設定は/etc/systemd/system/kubelet.service.d/10-kubeadm.confまたは/etc/default/kubeletにあります。systemctl status kubeletで実行中の設定を確認できます。

Q47. PersistentVolumeClaimがPending状態になる理由は？

A) Podが実行中でないため B) 要件（storageClass、accessMode、capacity）を満たすPVがないか、動的プロビジョニングに失敗 C) 名前空間の設定が誤っているため D) ノードのディスク容量が不足しているため

答え: B

解説: PVCのPending状態の原因: 1) 要求されたStorageClassが存在しない、2) 要求されたaccessModeをサポートするPVがない、3) 要求された容量を満たすPVがない、4) 動的プロビジョニングの失敗、5) volumeBindingMode: WaitForFirstConsumerでPodスケジューリング待ち。kubectl describe pvcで詳細を確認。

Q48. kubectl get pod -o wideで追加表示される情報は？

A) コンテナのログ B) IPアドレス、ノード名、ゲートウェイ C) リソース使用量 D) 環境変数

答え: B

解説: -o wideオプションは基本出力に加えてIPアドレス、ノード名（NODEカラム）、Nominated Node、Readiness Gatesの情報を表示します。PodがどのノードでどのIPで実行中かを素早く確認するのに便利です。

Q49. kube-schedulerがPodをスケジューリングできないとき発生するイベントメッセージは？

A) Error B) Warning FailedScheduling C) Normal SchedulingFailed D) Critical NoNodeAvailable

答え: B

解説: kube-schedulerがPodをスケジューリングできないとき、Warning FailedSchedulingイベントが生成されます。kubectl describe pod POD_NAMEのEventsセクションで「0/3 nodes are available: 3 Insufficient memory」などの詳細メッセージを確認できます。

Q50. kubectl rollout restart deployment DEPLOY_NAMEの動作は？

A) Deploymentを前バージョンにロールバックする B) ローリング方式ですべてのPodを再起動する C) Deploymentを削除して再作成する D) Podを一時停止する

答え: B

解説: kubectl rollout restart deploymentはDeploymentのPodをローリング方式で再起動します。イメージや設定変更なしにConfigMapやSecretの更新を適用したり、Podを更新したりするときに便利です。kubectl rollout statusで進捗を監視できます。

Q51. ServiceAccountをPodに紐付ける方法は？

A) kubectl attach B) spec.serviceAccountNameフィールドにServiceAccount名を指定 C) kubectl link D) PodのラベルにserviceAccount=NAMEを追加

答え: B

解説: PodまたはDeploymentのspec.serviceAccountNameフィールドにServiceAccount名を指定します。指定しない場合、その名前空間のdefault ServiceAccountが自動的にマウントされます。ServiceAccountトークンは/var/run/secrets/kubernetes.io/serviceaccount/にマウントされます。

Q52. ネットワークデバッグのために一時的なPodを作成する方法は？

A) kubectl debug node B) kubectl run tmp --image=busybox --rm -it -- /bin/sh C) kubectl create pod debug D) kubectl network debug

答え: B

解説: kubectl run tmp --image=busybox --rm -it -- /bin/shで一時的なデバッグPodを作成します。--rmは終了後に自動削除、-itは対話型TTYを意味します。nicolaka/netshootイメージは様々なネットワークデバッグツールを含んでいて便利です。

Q53. kubeconfigファイルのcluster、user、contextの関係は？

A) clusterとuserは独立していてcontextとは無関係 B) contextはclusterとuser（+namespace）を組み合わせて、どのクラスターにどの認証情報でアクセスするかを定義する C) userがclusterを含む D) clusterがuserとcontextを含む

答え: B

解説: kubeconfigファイルは3つのセクションで構成されます: clusters（サーバーアドレスとCA情報）、users（認証情報）、contexts（cluster + user + namespaceの組み合わせ）。contextは特定のクラスターに特定の認証情報でアクセスする方法を定義します。kubectl config use-contextでアクティブなcontextを変更します。

Q54. Pod内の環境変数を確認する方法は？

A) kubectl get pod -o env B) kubectl exec POD_NAME -- env C) kubectl describe pod --env D) kubectl get configmap

答え: B

解説: kubectl exec POD_NAME -- envで実行中のコンテナの環境変数を確認します。kubectl exec POD_NAME -- printenv VARIABLE_NAMEで特定の環境変数の値を確認することもできます。kubectl describe podでも環境変数のリストを確認できます。

Q55. 次のうち、Kubernetesクラスターのコントロールプレーンコンポーネントでないものは？

A) kube-apiserver B) kube-scheduler C) kubelet D) kube-controller-manager

答え: C

解説: kubeletは各ノード（コントロールプレーンおよびワーカーノード）で実行されるノードエージェントであり、コントロールプレーンコンポーネントではありません。コントロールプレーンコンポーネント: kube-apiserver（APIサーバー）、etcd（状態ストア）、kube-scheduler（Podスケジューリング）、kube-controller-manager（コントローラー管理）。ノードコンポーネント: kubelet、kube-proxy、コンテナランタイム。

実技シミュレーション（P1 〜 P10）

P1. etcdバックアップとリストア

シナリオ: コントロールプレーンノードでetcdスナップショットを/opt/etcd-backup.dbに保存し、リストアしなさい。

# etcdバックアップ
ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# スナップショット確認
ETCDCTL_API=3 etcdctl snapshot status /opt/etcd-backup.db --write-out=table

# 新しいデータディレクトリへリストア
ETCDCTL_API=3 etcdctl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-restore

# /etc/kubernetes/manifests/etcd.yaml を編集して
# --data-dirを/var/lib/etcd-restoreに変更
# hostPathも同様に変更

P2. RBAC設定

シナリオ: dev名前空間のdeveloper ServiceAccountがpodsとdeploymentsをget、list、watch、create、update、deleteできるようにRBACを設定しなさい。

kubectl create namespace dev
kubectl create serviceaccount developer -n dev

kubectl create role developer-role \
  --verb=get,list,watch,create,update,delete \
  --resource=pods,deployments \
  -n dev

kubectl create rolebinding developer-binding \
  --role=developer-role \
  --serviceaccount=dev:developer \
  -n dev

# 検証
kubectl auth can-i get pods --as=system:serviceaccount:dev:developer -n dev
kubectl auth can-i delete deployments --as=system:serviceaccount:dev:developer -n dev
kubectl auth can-i get nodes --as=system:serviceaccount:dev:developer -n dev  # no確認

P3. マルチコンテナPodのログ確認

シナリオ: app名前空間にnginxとbusyboxコンテナで構成されたPodを作成し、busyboxコンテナのログを確認しなさい。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: multi-container
  namespace: app
spec:
  containers:
  - name: nginx
    image: nginx:latest
  - name: busybox
    image: busybox:latest
    command: ['sh', '-c', 'while true; do echo "Hello from busybox"; sleep 5; done']
EOF

kubectl logs multi-container -c busybox -n app
kubectl logs multi-container -c busybox -n app -f
kubectl exec -it multi-container -c nginx -n app -- nginx -v

P4. ノードメンテナンス（drainとuncordon）

シナリオ: worker-node-1をメンテナンスモードにし、完了後に再スケジューリング可能な状態に戻しなさい。

kubectl get nodes
kubectl cordon worker-node-1
kubectl drain worker-node-1 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --force

kubectl get pods -o wide -A | grep worker-node-1

# メンテナンス完了後
kubectl uncordon worker-node-1
kubectl get nodes

P5. PersistentVolumeとPersistentVolumeClaimの作成

シナリオ: 10Gi容量のhostPath PVを作成し、それを使用するPVCとPodを作成しなさい。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/my-pv
EOF

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
EOF

kubectl get pv my-pv
kubectl get pvc my-pvc

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: pvc-pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: /data
      name: storage
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: my-pvc
EOF

P6. NetworkPolicy設定

シナリオ: backend名前空間のPodがfrontendラベルを持つPodからのトラフィックのみポート8080で受け取るようにNetworkPolicyを設定しなさい。

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: backend
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
EOF

kubectl get networkpolicy -n backend
kubectl describe networkpolicy backend-policy -n backend

P7. Deploymentのアップグレードとロールバック

シナリオ: webapp Deploymentをnginx:1.25からnginx:1.26にアップグレードし、問題があればロールバックしなさい。

kubectl create deployment webapp --image=nginx:1.25 --replicas=3
kubectl set image deployment/webapp nginx=nginx:1.26
kubectl rollout status deployment/webapp
kubectl rollout history deployment/webapp
kubectl rollout undo deployment/webapp
kubectl rollout undo deployment/webapp --to-revision=1

# 現在のイメージ確認
kubectl get deployment webapp -o jsonpath='{.spec.template.spec.containers[0].image}'

P8. CronJob作成

シナリオ: 5分ごとに現在時刻を出力するCronJobを作成しなさい。

cat <<EOF | kubectl apply -f -
apiVersion: batch/v1
kind: CronJob
metadata:
  name: print-time
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: time-printer
            image: busybox
            command:
            - /bin/sh
            - -c
            - date; echo "CronJob executed"
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
EOF

kubectl get cronjob print-time
kubectl get jobs

P9. Ingress設定

シナリオ: myapp-service（ポート80）に対するIngressを作成し、myapp.example.comドメインでアクセスできるようにしなさい。

kubectl create deployment myapp --image=nginx --replicas=2
kubectl expose deployment myapp --port=80 --name=myapp-service

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-service
            port:
              number: 80
EOF

kubectl get ingress myapp-ingress
kubectl describe ingress myapp-ingress

P10. 証明書更新とクラスター状態確認

シナリオ: クラスター証明書の有効期限を確認し、更新しなさい。またクラスター全体の状態を点検しなさい。

# 証明書の有効期限確認
kubeadm certs check-expiration

# 全証明書の更新
kubeadm certs renew all

# 個別証明書の更新
kubeadm certs renew apiserver
kubeadm certs renew apiserver-kubelet-client

# opensslで証明書を直接確認
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep -A2 Validity

# クラスターの状態確認
kubectl get pods -n kube-system
kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -A
kubectl get pods -A | grep -v Running | grep -v Completed

# ノードの条件確認
kubectl describe nodes | grep -A5 "Conditions:"

試験のヒント

コンテキスト切り替え: 各問題の開始時に必ずkubectl config use-context CONTEXT_NAMEを確認
命令型コマンドの活用: ほとんどのタスクでYAMLより速い
テンプレート生成: --dry-run=client -o yamlでYAMLを生成して編集
vim設定: :set et ts=2 sw=2 nuでYAML編集環境を最適化
エイリアス設定: alias k=kubectlとexport do="--dry-run=client -o yaml"
ドキュメント活用: kubernetes.io/docsの公式ドキュメントのブックマークが許可されています

CKA試験概要

ドメイン別出題比率

kubectlコマンド チートシート

選択問題（Q1 〜 Q55）

ドメイン1: Cluster Architecture, Installation & Configuration

ドメイン2: Workloads & Scheduling

ドメイン3: Services & Networking

ドメイン4: Storage

ドメイン5: Troubleshooting

実技シミュレーション（P1 〜 P10）

P1. etcdバックアップとリストア

P2. RBAC設定

P3. マルチコンテナPodのログ確認

P4. ノードメンテナンス（drainとuncordon）

P5. PersistentVolumeとPersistentVolumeClaimの作成

P6. NetworkPolicy設定

P7. Deploymentのアップグレードとロールバック

P8. CronJob作成

P9. Ingress設定

P10. 証明書更新とクラスター状態確認

試験のヒント

kubectlコマンドチートシート