はじめに

KCNA-JP（Kubernetes and Cloud Native Associate 日本語版）に合格しました。
正答率75%で合格判定です。
受験1回目は71%で不合格、二日後の再受験では87%で合格しました。

この記事では、KCNA-JP対策として学習した内容をもとに試験で問われやすいKubernetes / Cloud Native用語を整理してみます。

受験した私本人の苦手傾向に基づいた分野を中心としているため、網羅的ではないことをご了承ください。また、本記事は自身の受験体験と学習メモをもとに整理したものです。正確性には注意していますが、試験範囲や仕様は変わる可能性があるため、最終確認は公式ドキュメントをご参照ください。Let's go!

どんな人が読んだら嬉しいか

KCNA-JPをこれから受ける人
Kubernetesの用語が多すぎて混乱している人
CKAの前にKCNAで基礎を固めたい人
とりあえず記事1つで知識を頭に入れたい人
最後の総仕上げで知識の復習をしたい人

KCNA-JPの出題傾向と対策

KCNA-JPは細かいコマンド暗記よりも、次のようなコンポーネントの違い・目的を理解することを中心に進めていくことが重要だと感じました。

Pod / Deployment / ReplicaSet / StatefulSet / DaemonSet の違い
Service / Ingress / Gateway API の違い
Liveness / Readiness / Startup Probe の違い
ConfigMap / Secret の違い
Role / ClusterRole / RoleBinding / ClusterRoleBinding の違い
RuntimeClass / CRI / OCI / runc の違い
NetworkPolicy / Service Mesh / Envoy の違い
Monitoring / Observability / Metrics / Logs / Traces の違い
GitOps / CI/CD の違い

KCNA-JPでは四択問題が出題されます。このコンポーネントは何をするものか？目的は何か？なぜ他のコンポーネントでは充足しないか？という観点での知識整理が重要です。

ですので、なんとなく点で覚え始めたあとは少しずつ知識が線や面になるように理解を広げていく。言い換えると、1つの新出単語に遭遇したらその周辺の語彙も覚えていくようにすると合格への近道になります。

繰り返しになりますが、KCNA-JPは初学者向けの試験なので知識を深める必要性はあまり高くなく、広げていくことが重要だと感じます。

KCNA-JPの試験範囲

公式の試験範囲は以下の通りです。

領域	配点
Kubernetes Fundamentals	44%
Container Orchestration	28%
Cloud Native Application Delivery	16%
Cloud Native Architecture	12%

Kubernetesの技術が中心に問われますが、「例：CNCFのフルネームは？」など、技術そのもの以外にもコミュニティ系の理解を問う問題も出てきます。
試験対策としてはまずKubernetesの基本リソースに関する知識を押さえ、その後にCloud Native周辺用語を広げるのが効率的です。

重要用語まとめ

1. Kubernetes基本構成

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
コンテナを管理・自動化・オーケストレーションするものは？	Kubernetes	コンテナ運用を自動化する基盤。宣言的設定、自動復旧が核。
Kubernetesの実行基盤は？	Cluster	Control PlaneとNodeの集合。実行基盤そのもの。
クラスタの状態を管理するものは？	Control Plane	クラスタ管理の中枢でAPI受付、状態管理、配置制御を担う。
Podが配置される先は？	Node	Podを動かすマシン。物理/仮想どちらでもよい。
Kubernetes APIの入口は？	kube‑apiserver	Kubernetes APIの入口。kubectlなどが接続する。
クラスタ状態を保存するものは？	etcd	クラスタ状態を保存するキーバリューストア。
Podの配置先を決めるものは？	kube‑scheduler	Podの配置先を決める。Requestsや制約を考慮する。
各ワーカーノードで動くエージェントは？	kubelet	Node上に起動しPodの実行・監視を担当する。
Serviceの通信ルールを扱うものは？	kube‑proxy	Service通信の転送を担当。CNIとは役割が違う。

2. Workload

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
最小のデプロイ単位は？	Pod	Kubernetesで扱う最小の実行単位。1つ以上のコンテナを含む。
Pod内で実際にアプリが動くものは？	Container	アプリと依存関係をまとめた実行単位。Podの中で動く。
Podを更新・スケールするには？	Deployment	Podの更新やスケーリングなどを扱う。
Pod数を維持するものは？	ReplicaSet	指定した数のPodを維持する。通常はDeployment経由で使う。
永続的なIDや順序が必要な場合は？	StatefulSet	ステートフルアプリやDB向け。固定IDや永続ストレージが必要な場合に使う。
全Nodeで同じPodを動かすには？	DaemonSet	各対象NodeにPodを原則1つずつ配置する。監視、ログ収集、CNIなどで使う。
一度だけ実行する処理は？	Job	完了するまで実行するタスク。バッチ処理で使う。
毎日・毎時など定期実行するには？	CronJob	Jobを定期実行するリソース。cron形式でスケジュールする。

3. Network

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
Podを安定して公開するには？	Service	Pod群への安定したアクセス先を提供する。
Serviceのデフォルトtypeは？	ClusterIP	クラスタ内部向けService。外部公開しない内部通信で使う。
NodeのポートでPodを公開するには？	NodePort	各Nodeのポートを使ってServiceを公開する。Node経由で外部アクセスできる。
クラウドのLBでPodを公開するには？	LoadBalancer	パブリッククラウドのロードバランサーで外部公開する。
HTTP/HTTPSを外部公開するには？	Ingress	HTTP/HTTPSをHostやPathで制御する。Ingress Controllerが必要。
より高度なL4/L7トラフィック制御は？	Gateway API	Ingressより新しいルーティングAPI。L4/L7やロール分離に対応する。
Serviceを名前で解決する仕組みは？	CoreDNS	Service名を名前解決する仕組み。PodからServiceへ名前でアクセスできる。
Podネットワークを実現するプラグインは？	CNI	Podネットワークを実装する仕様。Calico、Cilium、Flannelなどがある。
Pod間通信を制御するものは？	NetworkPolicy	Pod間や外部との通信を制御する。インとアウトはIngress/Egressと呼ぶ。

参考：Service / Ingress / Gateway APIの覚え方

やりたいこと	選ぶもの
Pod群に安定した入口を作る	Service
HTTP/HTTPSをHostやPathで振り分ける	Ingress
より高度なL4/L7ルーティングやロール分離を扱う	Gateway API

Gateway APIはIngressの上位互換のように語られることがありますが、試験では「Ingressと同じもの」というよりも「より高度で、拡張性が高く、マルチトラフィックに対応する」と理解するとよいです。

4. Probe

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
異常なコンテナを再起動したい	Liveness Probe	コンテナが生きているか確認する。失敗すると再起動される。
準備できるまでトラフィックを流したくない	Readiness Probe	リクエストを受けられる状態か確認する。失敗するとService対象から外れる。
起動に時間がかかるアプリを扱いたい	Startup Probe	起動完了を確認する。完了まで他のProbeを抑制する。

ざっくり注意点

起動完了のみを確認したいならStartup Probeです。
生きているかはLiveness Probe、通信を流してよいかはReadiness Probeです。

5. 設定・機密情報

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
設定値を外出しするには？	ConfigMap	機密ではない設定値を保持する。環境変数やVolumeとして使える。
機密情報を扱うには？	Secret	パスワードやトークンを保持する。base64は暗号化ではない。

6. Storage

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
Podにストレージを渡すには？	Volume	Podにマウントするストレージ。emptyDir、configMap、secretなどがある。
永続ストレージの実体は？	PersistentVolume / PV	クラスタ上の永続ストレージ実体。Podとは独立したライフサイクルを持つ。
ストレージを要求するものは？	PersistentVolumeClaim / PVC	ユーザーからのストレージ要求。PodはPVCを通じてPVを使う。
動的にPVを作るには？	StorageClass	動的プロビジョニング用のクラス。ストレージ種別を抽象化する。
PVC削除後にデータを残したい場合は？	Reclaim Policy	PVC削除後のPVの扱いを決める。RetainやDeleteがある。

7. Security

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
誰に何を許可するか？	RBAC	役割ベースのアクセス制御。Kubernetes APIへの操作権限を管理する。
特定Namespace内の権限は？	Role	Namespace内に限った権限定義。podsのget/list/watchなどを定義する。
クラスタ全体の権限は？	ClusterRole	クラスタ全体、または複数Namespace向けの権限定義。
権限を付与するには？	RoleBinding	RoleやClusterRoleをユーザーやServiceAccountに結びつける。
クラスタ全体に権限付与するには？	ClusterRoleBinding	ClusterRoleをクラスタ全体に結びつける。強い権限の与えすぎに注意する。
PodにAPI操作用のIDを与えるには？	ServiceAccount	PodやアプリがAPI Serverへのアクセスで使う。
Podのセキュリティ制限レベルは？	Pod Security Standards / PSS	Podのセキュリティ基準。privileged、baseline、restrictedを覚える。
PSSを強制する仕組みは？	Pod Security Admission / PSA	PSSをAdmission Controllerで適用する仕組み。Namespaceラベルで制御する。

privileged / baseline / restricted の覚え方

レベル	意味
privileged	ほぼ制限なし
baseline	一般的な特権昇格を防ぐ標準的な制限
restricted	より厳格なセキュリティ制限

KCNA-JPでは、細かいYAMLよりも、この3段階の意味や制限の強さを問われる傾向にあります。

8. Runtime / Container

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
コンテナを実行するものは？	Container Runtime	コンテナを実行するソフトウェア。containerdやCRI-Oが代表例。
kubeletとRuntimeの接続仕様は？	CRI	kubeletとContainer Runtimeを接続するインターフェース。
コンテナ標準は？	OCI	コンテナの標準仕様。OCI ImageやOCI Runtimeと関係する。
OCI準拠の低レベルRuntimeは？	runc	OCI Runtime仕様に基づく低レベルRuntime。コンテナプロセスを起動する。
コンテナRuntime構成を選ぶには？	RuntimeClass	PodごとにRuntime構成を選ぶ機能。runtimeClassNameで指定する。
より分離されたRuntimeの例は？	gVisor	サンドボックス型Runtimeの一例。セキュリティ分離を強める。

9. Observability / Monitoring

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
しきい値監視は？	Monitoring	既知の指標を監視すること。CPU、メモリ、エラー率などを見る。
可観測性とは？	Observability	外部出力からシステム内部を理解できる性質。Metrics、Logs、Tracesなどを用いる。
数値指標は？	Metrics	数値化された時系列データ。CPU使用率やリクエスト数など。
実行履歴やメッセージは？	Logs	イベントや処理内容の記録。障害調査で使う。
リクエストの流れを追うには？	Traces	リクエストが複数サービスを通る流れを追跡する情報。
Traceを構成する単位は？	Span	Trace内の1つの処理単位。分散トレーシングの基本単位。
メトリクス監視ツールは？	Prometheus	メトリクス収集・監視の代表的OSS。PromQLやAlerting Ruleと関係する。
通知の管理は？	Alertmanager	Prometheusのアラート通知を管理する。通知、抑制、集約を担当する。
一定時間続いたらアラートにするには？	for	Alerting Ruleの指定。条件が一定時間続いたら発火させる。

10. Cloud Native Application Delivery (CI/CD)

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
コード変更後にテストする流れは？	CI	継続的インテグレーション。ビルドやテストを自動化する。
デプロイ自動化は？	CD	継続的デリバリー/デプロイ。リリースを自動化する考え方。
Gitを信頼できる情報源にする運用は？	GitOps	Gitに望ましい状態を置き、実環境と継続的に同期する運用。
GitOpsツールは？	Argo CD	Gitに書いた望ましい状態と、Kubernetes上の実際の状態を比較・同期する。
GitOpsの代表例は？	Flux	Argo CDに並ぶGitOpsツールの一つ。
2環境を切り替える方式は？	Blue-Green Deployment	新旧2環境を切り替えるデプロイ方式。ロールバックしやすい。
少しずつ新バージョンに流す方式は？	Canary Deployment	一部ユーザーから段階的に新バージョンへ流す方式。

11. Service Mesh

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
マイクロサービス間通信を制御するには？	Service Mesh	サービス間通信を管理する仕組み。通信制御、可観測性、セキュリティを追加する。
Service Mesh製品は？	Istio	Service Meshの代表的実装。トラフィック制御、mTLS、可観測性に関係する。
Service Meshの例は？	Linkerd	軽量なService Mesh実装。Istioと並ぶ代表例。
EnvoyはControl PlaneかData Planeか？	Envoy	Service Meshで使われるプロキシ。実際の通信を処理するData Plane側。

Service Meshの構成

Service Meshは大きく分けると、以下の2層です。

層	役割
Control Plane	設定やポリシーを管理する
Data Plane	実際の通信を処理する

Envoyは実際の通信を処理するため、Data Plane側です。

12. 拡張

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
独自リソースを定義するには？	CRD	Kubernetes APIに独自リソースを追加する仕組み。Operatorと関係が深い。
CRDで作られるものは？	Custom Resource	CRDによって追加された独自リソース。Kubernetes APIとして扱える。
運用知識を自動化する仕組みは？	Operator	アプリ運用の知識をControllerとして実装したもの。CRDと一緒に使われる。

13. kubectlコマンドでよく問われるもの

試験での問われ方	回答として覚える用語・コンポーネント名	かんたんな解説
状態確認	kubectl get	リソース一覧を見るコマンド。状態をざっくり確認する。
スケジューリング失敗、Probe失敗などの調査	kubectl describe	リソース詳細やEventを見るコマンド。原因調査で使う。
アプリログ確認	kubectl logs	Podやコンテナのログを見るコマンド。
リアルタイムログ確認	kubectl logs -f	ログをリアルタイムに追う。-fはfollowの意味。
複数コンテナPodのログ確認	kubectl logs -c	対象コンテナを指定してログを見る。サイドカー構成で重要。
Pod内での疎通確認や名前解決確認	kubectl exec	Pod内でコマンドを実行する。nslookupなどの確認で使う。
リソース使用量確認	kubectl top	CPU/メモリ使用量を見る。Metrics Serverが必要。
Deploymentの更新履歴確認	kubectl rollout history	Deploymentのリビジョン履歴を見る。
Deploymentのロールバック	kubectl rollout undo	Deploymentをロールバックする。更新失敗時に使う。
環境変数の設定	kubectl set env	Deploymentなどに環境変数を設定する。

DNS関連の問題について

「Podが名前解決できないからDNSに発生している問題を確認したい」という文脈では、kubectl execでPod内に入ってnslookupで名前解決を確認する、という流れが正しいと思われます。

KCNA-JPでよくある問題パターン

最も目的に沿うKubernetesリソースを選ばせる

例：

ステートレスアプリをスケール、更新したい → Deployment
各Nodeに1つずつPodを置きたい → DaemonSet
Podを外部公開したい → Service / Ingress / Gateway APIを状況に応じて選ばせる
機密情報を扱いたい → Secret
非機密の設定を渡したい → ConfigMap

似た言葉を混ぜてくる（これがややこしいが、得点源にできると合格が近づく）

例：

ServiceとIngress
IngressとGateway API
LivenessとReadiness
ConfigMapとSecret
RoleとClusterRole
ServiceAccountとUser
NetworkPolicyとService Mesh
MonitoringとObservability
TraceとSpan
CRIとRuntimeClass

各コンポーネントの役割や目的を理解することが合格への早道です。

実務っぽい文脈で問う

例：

アプリが起動に時間がかかる
Podがスケジュールされない
Pod間通信を制御したい
ログを確認したい
DNS解決を確認したい
Gitを起点にデプロイしたい
マイクロサービス間通信を可視化・制御したい

試験中に手でコマンドを入力することはありませんが、「この課題にはあの機能だよね、あのコマンドやオプションを使うよね」が選択肢を見て思い浮かぶレベル程度まで理解しておくとよいです。

日本語が不自然でも、公式用語に戻す

模擬問題では、日本語がやや不自然なことがあります。
試験中にいったん英語に戻すこともできますので、日<->英を何度か繰り返して問題の問うている真意を拾いましょう。
私の体感だと以下のような言葉が試験問題に入っている場合は、矢印の右に記載している機能を聞かれているんだなと理解しています。

例：

「起動完了のみを確認」 → Startup Probe
「サービス間通信の制御」 → Service Mesh
「Pod間通信の制御」 → NetworkPolicy
「コンテナRuntime構成の選択」 → RuntimeClass
「通知を送るまで一定時間待つ」 → Prometheus Alerting Ruleのfor

個人的に重要だと思った覚え方

Podはアプリケーションの実行単位、Deploymentはアップデートなどの一括管理

Podは最小単位ですが、直接Podを管理するよりDeploymentで管理する方向での設問が多い印象です。（実運用でもきっとそうかも）

やりたいこと	実現する機能
最小の実行単位	Pod
ステートレスアプリを運用する	Deployment
Pod数を維持する	ReplicaSet
各Nodeに配置する	DaemonSet
固定ID・永続性を持たせる	StatefulSet

通信系は何をしたいかで判別する

やりたいこと	実現する機能
Pod群へ安定して到達したい	Service
HTTP/HTTPSで外部公開したい	Ingress
高度なL4/L7制御をしたい	Gateway API
Pod間通信を許可/拒否したい	NetworkPolicy
サービス間通信に可観測性やmTLSを入れたい	Service Mesh

Service Meshが出てきたらIstioは...、Envoyは...というように繋げて覚えていくのが吉です。

まとめ

KCNA-JP対策では、用語の丸暗記よりも以下の観点で整理するのが有効でした。

その用語は何をするものか
なぜKubernetes / Cloud Nativeで重要なのか
似た用語と何が違うのか
試験ではどんな文脈で問われるのか（これは一度受けてみるのをおすすめ。再試験は一度まで無料なので）

重点的に抑えると良いポイントを改めてまとめました。

Pod / Deployment / ReplicaSet / StatefulSet / DaemonSet
Service / Ingress / Gateway API
NetworkPolicy / Service Mesh / Envoy
Liveness / Readiness / Startup Probe
ConfigMap / Secret
PV / PVC / StorageClass
RBAC / ServiceAccount
RuntimeClass / CRI / OCI / runc
GitOps / Argo CD / Flux
Prometheus / Alertmanager / Metrics / Logs / Traces
CRD / Operator
kubectl logs / describe / exec / rollout

今回はKCNA-JP合格に向けて知識整理する目的で記事を書きました。実務ベースとなると、別の試験であるCKAの方でより多く問われそうです。

さて、KCNA-JPは入門資格ですが、範囲はかなり広かった印象です。
Udemyで販売されている模擬問題集を実践しながら、間違えた問題に含まれる語彙を一つずつ理解し、その周辺機能まで拾って覚えていくことで合格に至ったように思います。

深い知識よりもクラウドネイティブの全体像とKubernetesの基本用語の切り分けができれば、十分に合格を狙える試験だと感じました。
およその学習時間は15時間~20時間程度でした。

私個人ではECS、EKSを少し触ったことがありローカルでpodmanを起動して遊んでいる程度の経験値です。（あ、NKPも）
よかったらこちらの記事ものぞいてみてください。

参考リンク