Certified Kubernetes Application Developer (CKAD) #20 試験のコツと時間管理、よく間違えるパターン
#1 から #19 まで 5 つのドメインをすべて整理しました。この記事は 実技試験に入る直前にもう一度読んでいく圧縮版 です。新しいドメインはなく、2 時間の実技をどう運用するか、そしてシリーズ全体で受験者が最もよく点数を逃す落とし穴だけを集めています。択一式ではなく空のターミナルに直接作り出す試験なので、同じ知識でも運用が合格と不合格を分けます。
2 時間の運用戦略 #
タスク単位の運用 #
CKAD は約 15〜20 個のタスクを 2 時間で解く必要があります。択一式のように設問ごとに時間を均等に分けるのではなく、タスクごとに配点が画面に表示されるので、その配点がそのまま優先順位 になります。
| 段階 | 時間 | 行動 |
|---|---|---|
| 一次解答 | 約 90 分 | 配点が高く簡単なタスクから。詰まったら flag して即次のタスクへ |
| 二次解答 | 約 20 分 | flag したタスクだけ見直す。部分点でも確保 |
| 検算 | 約 10 分 | k get で結果を確認し、context・namespace・ファイル名を再確認 |
時間管理の第一のルール #
1 つのタスクに没頭しないこと です。配点の割に時間がかかると感じたら、ひとまず可能なところまで作っておいて flag して次へ進みます。合格ラインは 66% なので、難しいタスクを 1 つや 2 つ諦めても大丈夫です。配点 4 点の詰まったタスク 1 つを抱え込んで配点 8 点の簡単なタスクを 2 つ逃すのが、最もよくある失敗です。
配点が高く簡単なものから #
タスク一覧を最初から最後まで一度ざっと眺めながら、配点に対する難易度 を頭の中でタグ付けします。generator で 1 行で終わるタスクや慣れたリソースのタスクを先に処理して点数を素早く積み上げ、手間のかかるタスクを後ろに回す運用が、合格ラインを超える道です。
kubectl 速度セットアップの再整理 #
#1 で組んだセットアップを試験開始直後の 1 分以内に終わらせます。タスクごとに数十秒ずつ節約する投資です。
# kubectl を k に
alias k=kubectl
# dry-run + YAML 出力を do に
export do="--dry-run=client -o yaml"
# 即時削除を now に (Pod を素早く消して作り直すとき)
export now="--force --grace-period=0"
# 自動補完 (k まで拡張)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k~/.vimrc には YAML インデント事故を防ぐ設定を入れます。
set expandtab
set tabstop=2
set shiftwidth=2
set numberさらに手に馴染ませておくとよい vim の操作があります。YAML ブロックをまるごとインデントするときは、ビジュアルモード (V) で行を選択してから > で 1 段下げ、. で繰り返します。インデントをもう 1 段細かく見たいときは :set list でタブと空白を目で区別します。
命令型 generator を積極的に活用する #
CKAD でマニフェストを最初から手で書く人は時間を失います。ほとんどのリソースは run・create・expose で骨格を抜き出してから必要なフィールドだけ直すほうが速く、タイプミスも少なくなります。
# Pod の骨格
k run nginx --image=nginx $do > pod.yaml
# Deployment の骨格 (replicas を含む)
k create deploy web --image=nginx --replicas=3 $do > deploy.yaml
# Job / CronJob の骨格
k create job pi --image=perl $do > job.yaml
k create cronjob report --image=busybox --schedule="*/5 * * * *" $do > cj.yaml
# ConfigMap / Secret
k create configmap app-config --from-literal=KEY=value $do > cm.yaml
k create secret generic app-secret --from-literal=PASSWORD=1234 $do > secret.yaml
# Service (Deployment の公開)
k expose deploy web --port=80 --target-port=8080 $do > svc.yamlgenerator で作れないフィールド (probe、securityContext、volume など) は、骨格 YAML を開いてから kubectl explain でパスを確認して埋めます。ブラウザでドキュメントを開くより速い場合が多いです。
k explain pod.spec.containers.livenessProbe
k explain deployment.spec.strategy --recursive公式ドキュメントを素早く活用する #
CKAD は試験中に kubernetes.io/docs とその下層ドキュメントの閲覧が許可されています。だからすべての YAML フィールドを暗記する必要はありません。ただし運用には 2 つの原則があります。
- ブックマークより検索 です。試験環境のブラウザに事前に作っておいたブックマークを移しにくい場合があるので、ドキュメント上部の検索窓に
liveness probe・networkpolicyのようにキーワードを打って例の YAML へ直行する動線を手に馴染ませます。 - ドキュメントの時間も試験時間 です。ドキュメントをあさっている間もタイマーは流れます。よく使うリソースは generator で骨格を即座に作り、ドキュメントは generator で作れない細部フィールドを確認する用途だけに使います。
ドキュメントから YAML スニペットをコピーするときはインデントが付いてくるので、貼り付けた直後に :set paste で自動インデントの干渉を切るのが安全です。
よく間違えるパターン #
実技で点数を逃す定番パターンです。知識不足より運用ミスで失う点数のほうが多いです。
1) context と namespace の未切り替え #
各タスクは指定されたクラスタとネームスペースで解いて初めて採点されます。タスク説明に提示される use-context コマンドを 先に実行 しないと、答えを正しく作っても別のクラスタに作られて 0 点になります。
k config use-context <タスクで指定されたコンテキスト>
k config set-context --current --namespace=<タスクのネームスペース>2) dry-run を使わず手で作成 #
空の画面に YAML を最初からタイプすると遅く、タイプミスが出ます。マニフェストが必要なほぼすべてのタスクは k ... --dry-run=client -o yaml > file.yaml から始めます。
3) YAML インデントとタブ #
タブと空白が混ざったり、インデントが 1 つずれたりすると apply が失敗します。~/.vimrc の expandtab・shiftwidth=2 を開始時に必ず適用します。
4) 要求されたファイル名とパスの不一致 #
「/opt/course/2/pod.yaml に保存せよ」のような指示は、採点がそのパスを見ます。パス・ファイル名を正確に合わせないと、成果物が正しくても点数になりません。
5) タスクを最後まで読まない #
1 つのタスクに複数の条件が付くことが多いです。イメージだけ変えて replicas の調整を漏らしたり、label は付けたのに env の注入を逃したりすると部分点しか得られません。タスク説明のすべての条件を押さえてから始めます。
6) imperative で済むものをわざわざ YAML で #
label 追加・イメージ変更・scale・rollout のようなタスクはコマンド 1 行で終わるのに、YAML を作って編集すると時間の無駄です。
k set image deploy/web nginx=nginx:1.25
k scale deploy/web --replicas=5
k label pod nginx tier=frontend
k rollout undo deploy/web7) 変更後に apply しない #
YAML ファイルを直しておいて apply をしないと、クラスタには反映されません。編集後は k apply -f file.yaml を忘れないようにします。
8) label と selector のタイプミス #
Deployment の selector.matchLabels と Pod テンプレートの labels が違うと作成に失敗し、Service の selector が Pod label とずれるとトラフィックが届きません。generator が合わせてくれた label を勝手に直すときは、片方だけ変えてしまわないよう注意します。
部分点と検算 #
CKAD はタスク単位で採点され、一部のタスクには部分点があります。完璧に解けそうにないタスクも作れるところまで作っておけば点数が入ります。そしてタスクを終えるたびに短く検算します。
# 作ったリソースが実際に立ち上がったか
k get pod,deploy,svc -n <namespace>
# Pod が Running か、再起動がないか
k get pod nginx -o wide
# 適用されたフィールドが意図どおりか
k describe pod nginx | less
k get deploy web -o yaml | grep -A3 strategy検算は 30 秒以内に終わりますが、「やり終えたと思っていたタスクが実は失敗していた」という最もよくある失点を防ぎます。
混同しやすい概念ペア #
タスク中に瞬間的に混同しやすいペアを、1 行の違いに圧縮します。
| ペア | 1 行の違い |
|---|---|
| liveness vs readiness probe | 死んだら再起動 vs 準備できていなければトラフィック遮断 |
| requests vs limits | スケジューリング保証量 vs 使用上限 |
| QoS (Guaranteed/Burstable/BestEffort) | requests=limits vs 一部だけ設定 vs 未設定 |
| ClusterIP vs NodePort | クラスタ内部専用 vs ノードポートで外部公開 |
| env vs volume (ConfigMap/Secret) | env は変更後に再生成が必要 vs volume は自動更新 |
| Job restartPolicy | OnFailure または Never のみ許可 (Always 不可) |
最後の行は定番の罠です。Job と CronJob の Pod テンプレートに restartPolicy: Always を入れると作成が拒否されます。OnFailure または Never を使います。
ドメイン別の受験直前チェックリスト #
各ドメインで手がすぐ出るべき核心コマンドとフィールドです。
ドメイン 1: Application Design and Build (20%) #
- マルチコンテナ Pod:
spec.containersに 2 つ以上、spec.initContainersで init - sidecar は
initContainersにrestartPolicy: Alwaysでも表現 - Job/CronJob:
restartPolicyOnFailure/Never、completions・parallelism・backoffLimit - CronJob
schedule、concurrencyPolicy(Forbid/Allow/Replace)
ドメイン 2: Application Deployment (20%) #
-
k create deploy、k set image、k scale、k rollout status/undo - rolling update:
strategy.rollingUpdate.maxSurge・maxUnavailable - Helm:
helm install・upgrade・rollback・-f values.yaml - Kustomize:
kustomization.yaml、k apply -k
ドメイン 3: Application Observability and Maintenance (15%) #
-
k logs(-f・--previous・-c)、k describeでイベント確認 - probe 3 種:
livenessProbe・readinessProbe・startupProbe(exec/httpGet/tcpSocket) -
k debug、k port-forward、ephemeral container でデバッグ
ドメイン 4: Application Environment, Configuration and Security (25%) #
- ConfigMap/Secret:
envFrom・valueFrom・volume マウント - ServiceAccount の指定、RBAC
Role・RoleBinding - SecurityContext:
runAsUser・fsGroup・readOnlyRootFilesystem・capabilities - requests/limits で QoS が決まる、
LimitRange - Volume:
emptyDir・PVC・projected・ephemeral
ドメイン 5: Services and Networking (20%) #
-
k exposeで Service、typeClusterIP/NodePort/LoadBalancer/ExternalName - Service
selectorと Pod label の一致を確認 - Ingress
rules・paths・backend - NetworkPolicy
podSelector・ingress/egress・policyTypes(デフォルト deny の動作を理解)
オンライン監督の受験直前チェック #
CKAD は PSI のリモートターミナルに接続して作業するオンライン監督試験です。試験開始前に次を確認します。
身分証 #
- 英文表記のある身分証 (パスポート推奨)、名前が登録情報と正確に一致
- 監督官のチャット案内に従って身分証の両面をカメラに提示
受験環境 #
- 机の上のすべての物を片付け、壁面のメモ・ポスターを撤去
- デュアルモニターは 1 台だけ使用し、補助画面を切り離す
- 家族・ルームメイトの出入りを遮断し、静かな単独空間を確保
システム #
- 受験 30 分前に入室してシステムチェックを通過
- バックグラウンドアプリ・通知・VPN を終了し、安定した有線ネットワークを推奨
- 試験開始後にまず
alias k・do・自動補完・.vimrcのセットアップ
まとめ #
この記事で押さえたこと:
- 2 時間の運用。タスクごとの配点が優先順位。配点が高く簡単なものから、詰まったら flag して次へ、没頭は禁物
- 速度セットアップ。
alias k・do・now・自動補完・vim インデントを開始 1 分以内に - generator と explain。骨格は命令型で、細部フィールドは
k explainと検索で - ドキュメント活用。ブックマークより検索、ドキュメントの時間も試験時間
- 定番ミス 8 つ。context/namespace、dry-run の未使用、インデント、ファイル名、タスクの読み残し、不要な YAML、apply の漏れ、label/selector のタイプミス
- 部分点と検算。作れるところまで作って
k getで確認 - 混同しやすい概念ペア、ドメイン別の核心コマンド、オンライン監督のチェック
次へ: フルスケール実技模擬試験 #
最後の記事です。
#21 フルスケール実技模擬試験 (全ドメイン統合シナリオ + 解説) では、実際の試験に近いドメイン分布で統合シナリオを解き、詳しい解説を付けます。試験環境のように時間を計って解いてみて、足りないドメインをもう一度固める最後の段階です。