はじめに
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も）
よかったらこちらの記事ものぞいてみてください。