Certified Kubernetes Administrator (CKA) #26 試験のコツと時間管理、よく間違えるパターン

#1 から #25 まで 5 つのドメインをすべて整理しました。この記事は 実技試験に入る直前にもう一度読んでいく圧縮版 です。新しいドメインはなく、2 時間の実技をどう運用するかと、シリーズ全体で運用者が最も頻繁に点数を取りこぼす罠だけを集めました。選択式ではなく実際のクラスターを空のターミナルで直し、作り出す試験なので、同じ知識でも運用が合格と不合格を分けます。

2 時間の運用戦略 #

作業単位の運用 #

CKA は約 15〜20 個の作業を 2 時間以内に解く必要があります。選択式のように問題ごとに均等に時間を分けるのではなく、作業ごとに配点が画面に表示されるので、その配点がそのまま優先順位 になります。CKAD と違い、CKA には etcd 復旧やクラスターアップグレードのように 1 つの作業で 10 分を超える高配点問題と、generator 1 行で終わる低配点問題が同じリストに混ざっています。

時間管理の第一のルール #

1 つの作業に没頭しません。 配点の割に時間がかかると感じたら、まず可能なところまで作っておいて flag して次へ進みます。合格ラインは 66% なので、難しい 1 つか 2 つの作業を諦めても構いません。配点 4 点の詰まる作業 1 つを抱え込んで、配点 8 点の手に馴染んだ作業 2 つを逃すのが最もよくある失敗です。

トラブルシューティングを優先順位として見る #

CKA は Troubleshooting が 30% で最も大きなドメインです。トラブルシューティングの作業は配点が高く、原因さえ見つければ修正自体は 1 行で終わるケースが多いです。ただし原因追跡が長引くと時間を丸ごと食うので、5 分以内に原因の糸口がつかめなければ flag して次へ進む基準線 を決めておく運用が安全です。逆に etcd 復旧のように手順が決まっている高配点の作業は、手に馴染ませておけば時間あたりの点数が最も大きくなります。

配点が高く手に馴染んだものから #

作業リストを最初から最後まで一度ざっと見て、配点に対する難易度 を頭の中でタグ付けします。RBAC 作成、PV/PVC の作成、Service の公開のように手順が決まっている作業を先に処理して点数を素早く積み、原因追跡が必要なトラブルシューティングや手間のかかるアップグレードを中間に配置する運用が合格ラインを超える道です。

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

CKA は static Pod マニフェストや kubeadm 設定ファイルの特定フィールドだけを素早く変える作業が多いです。yq が入っていれば手編集より安全で速いです。

# 特定フィールドの読み取り
yq '.spec.containers[0].command' /etc/kubernetes/manifests/kube-apiserver.yaml

# フィールドの修正 (in-place)
yq -i '.spec.replicas = 3' deploy.yaml

さらに手に馴染ませておくとよい vim の操作があります。YAML ブロックを丸ごとインデントするときは、ビジュアルモード (V) で行を選択してから > で 1 段下げ、. で繰り返します。static Pod マニフェストを編集するときは 1 文字でもずれると kubelet が Pod を上げ直せないので、:set list でタブとスペースを目で見分けます。

context 切り替えを真っ先に行う #

CKA が CKAD と最も大きく違う運用ポイントです。CKA は クラスターが複数 あり、各作業は指定されたクラスターで解かないと採点されません。作業説明の一番上に提示される use-context コマンドを 先に実行 しないと、答えを正しく作っても別のクラスターに作られて 0 点になります。

# 作業ごとに真っ先に実行
k config use-context <作業で指定されたコンテキスト>

# いまどのクラスターか確認
k config current-context

ノードの中に入る作業も同様です。static Pod の修正、kubelet の再起動、etcd スナップショットのような作業は、指定されたノードに SSH で入ってから 解く必要があります。control plane ノードで行うべき作業をワーカーノードで行うと点数がありません。

# 作業で提示されるホスト名で接続
ssh node01

# 作業が終わったら必ず抜けて元の環境へ
exit

SSH でノードに入ったまま次の作業を解き始める間違いがよくあります。ノード作業が終わったら exit で抜ける ことを 1 つの動作として束ねておく習慣が誤答を防ぎます。

公式ドキュメントを素早く活用する #

CKA は試験中に kubernetes.io/docs とその配下のドキュメント閲覧が許可されます。そのためすべての YAML フィールドや長いコマンドを暗記する必要はありません。ただし運用に 2 つの原則があります。

• 検索で例にすぐ飛ぶ。 ドキュメント上部の検索ボックスに etcd backup・kubeadm upgrade・rbac のようなキーワードを打って、例のコマンドと YAML にすぐ飛ぶ動線を手に馴染ませます。etcdctl の証明書フラグや kubeadm upgrade の手順のように長くて覚えにくいコマンドは、ドキュメントからコピーする方が安全です。
• ドキュメントの時間も試験時間。 ドキュメントを探っている間もタイマーは進みます。よく使うリソースは generator で骨組みを即座に作り、ドキュメントは手順が長い作業や覚えにくいフラグを確認する用途に使います。

ドキュメントから YAML スニペットをコピーするときはインデントが付いてくるので、貼り付けた直後に :set paste で自動インデントの干渉を切る方が安全です。

よく間違えるパターン #

運用者の実技で点数を取りこぼす定番パターンです。知識不足より運用ミスで失う点数の方が多いです。

1) context と namespace の未切り替え #

各作業は指定されたクラスターとネームスペースで解かないと採点されません。作業説明に提示される use-context コマンドを先に実行しないと、答えを正しく作っても別のクラスターに作られて 0 点になります。CKA はクラスターが複数あるので、この間違いが特に頻発します。

k config use-context <作業で指定されたコンテキスト>
k config set-context --current --namespace=<作業のネームスペース>

2) etcd 証明書フラグの抜け #

etcdctl コマンドは ETCDCTL_API=3 と --cacert・--cert・--key の 3 つの証明書フラグがすべて揃っていないと動作しません。1 つでも抜けると認証エラーでスナップショットを取ったり復旧したりできません。証明書のパスは /etc/kubernetes/manifests/etcd.yaml の --cert-file・--key-file・--trusted-ca-file で確認します。

ETCDCTL_API=3 etcdctl snapshot save /opt/snap.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

3) drain オプションの抜け #

ノードを空けるとき --ignore-daemonsets を抜くと DaemonSet Pod のせいでコマンドが止まり、--delete-emptydir-data を抜くと emptyDir を使う Pod でブロックされます。アップグレードやノード整備の作業でこの 2 つのオプションの抜けが定番です。

k drain node01 --ignore-daemonsets --delete-emptydir-data
# 作業が終わったら再びスケジュール可能に
k uncordon node01

4) static Pod マニフェストの場所の混同 #

control plane コンポーネント (apiserver・etcd・scheduler・controller-manager) は /etc/kubernetes/manifests/ の static Pod として上がっています。このディレクトリは control plane ノードにあるので、ワーカーノードで探すと見えません。kubelet 設定の staticPodPath がまさにこのディレクトリを指しています。ファイルをディレクトリの外へ移すと kubelet が該当 Pod を下ろし、戻すと上げます。

# control plane ノードで
ls /etc/kubernetes/manifests/
# kubelet がどのパスを見るか
grep staticPodPath /var/lib/kubelet/config.yaml

5) アップグレード順序の混同 #

クラスターアップグレードは順序が決まっています。control plane が先、ワーカーが後 で、control plane の中でも kubeadm アップグレードの後に kubelet・kubectl の順です。ノードは 1 台ずつ drain → アップグレード → uncordon の順で進めます。

# 1) control plane ノード: kubeadm が先
kubeadm upgrade plan
kubeadm upgrade apply v1.xx.y
# 2) 同じノードを drain した後 kubelet/kubectl をアップグレード、再起動
k drain <cp-node> --ignore-daemonsets
# (apt/yum で kubelet kubectl をアップグレード)
systemctl daemon-reload && systemctl restart kubelet
k uncordon <cp-node>
# 3) ワーカーノードは kubeadm upgrade node の後に同じ手順

6) 部分点を取り損ねる #

完璧に解けない作業も、作れるところまで作っておけば点数が入ります。トラブルシューティングで原因を最後まで直せなかったとしても、診断した内容を反映して可能な修正を適用しておけば部分点が拾えることがあります。空のまま置くのが最ももったいないです。

7) 作業を最後まで読まない #

1 つの作業に複数の条件が付くケースが多いです。スナップショットを取れという指示に保存パスまで指定されていたり、RBAC 作業で特定 namespace に限定という条件が付いたりする具合です。条件を 1 つ落とすと部分点しかもらえません。作業説明のすべての条件を押さえてから始めます。

8) 変更後の適用・再起動の抜け #

YAML ファイルだけ直して apply をしなかったり、static Pod マニフェストを直した後に kubelet が反映する時間を待たなかったりすると、クラスターに反映されません。設定ファイルを変えた後は k apply -f または systemctl restart kubelet まで 1 つの動作として束ねます。

部分点と検算 #

CKA は作業単位で採点され、一部の作業には部分点があります。そして作業を終えるたびに短く検算します。運用者の作業は「作った」ではなく「実際に上がって動いているか」まで確認する必要があります。

# 作ったリソースが実際に上がったか
k get pod,deploy,svc -n <namespace>

# ノード作業の後にノードが Ready に戻ったか
k get nodes

# control plane コンポーネントが上がり直したか
k get pods -n kube-system

# スナップショットファイルが実際にできたか
ls -l /opt/snap.db

検算は 30 秒以内で終わりますが、「全部やったと思った作業が実は失敗していた」という最もよくある失点を防ぎます。特に static Pod を直した後は kubelet が新しい Pod を上げるのに数秒かかるので、k get pods -n kube-system をもう一度確認します。

紛らわしい概念のペア #

作業中に瞬間的に混同しやすいペアを、一行の違いに圧縮します。

taint/toleration と affinity は方向が逆です。taint はノード側から Pod を拒否し toleration がその拒否に耐えさせるのに対し、nodeAffinity は Pod 側から特定のノードを好むか強制します。両方を一緒に使うことで「このノードにはこの Pod だけ」のような専用配置が完成します。

ドメイン別の受験直前チェックリスト #

各ドメインで手がすぐ出るべき核心のコマンドと手順です。

ドメイン 1: Cluster Architecture, Installation and Configuration (25%) #

• kubeadm: kubeadm init・join、kubeadm token create --print-join-command
• アップグレード: kubeadm upgrade plan/apply、control plane が先・ワーカーが後
• etcd: etcdctl snapshot save/restore に証明書フラグ 3 つ
• RBAC: Role/ClusterRole・RoleBinding/ClusterRoleBinding、k auth can-i
• 証明書・kubeconfig: kubeadm certs renew、/etc/kubernetes/pki のパス

ドメイン 2: Workloads and Scheduling (15%) #

• k create deploy、k set image、k scale、k rollout status/undo
• scheduling: nodeSelector・nodeAffinity・taint/toleration
• requests/limits で QoS が決まる、LimitRange・ResourceQuota
• ConfigMap/Secret: envFrom・valueFrom・volume マウント

ドメイン 3: Services and Networking (20%) #

• k expose で Service、type ClusterIP/NodePort/LoadBalancer/ExternalName
• Service selector と Pod label の一致を確認
• Ingress rules・paths・backend、IngressClass
• CoreDNS の動作確認、NetworkPolicy podSelector・policyTypes (デフォルト deny を理解)

ドメイン 4: Storage (10%) #

• PV/PVC 静的プロビジョニング、accessModes・capacity の一致
• StorageClass と動的プロビジョニング、reclaimPolicy (Delete/Retain)
• PVC を Pod に volumeMounts・volumes で接続
• volume expansion (allowVolumeExpansion)

ドメイン 5: Troubleshooting (30%) #

• Pod: k describe・k logs (--previous)、Pending/CrashLoop/ImagePull/OOM のパターン
• ノード: systemctl status kubelet・journalctl -u kubelet、NotReady・pressure
• control plane: /etc/kubernetes/manifests/ の static Pod、crictl ps でコンテナ確認
• ネットワーキング・DNS: k get ep で endpoint 確認、CoreDNS Pod・Service
• 証明書: openssl x509 -noout -dates で期限確認、kubeadm certs renew

オンライン監督受験の直前点検 #

CKA は PSI のリモートターミナルに接続して作業するオンライン監督試験です。試験開始前に次を確認します。

身分証 #

• 英文表記のある身分証 (パスポート推奨)、名前が登録情報と正確に一致
• 監督官のチャット案内に従って身分証の両面をカメラに提示

受験環境 #

• 机の上のすべての物を片付け、壁面のメモ・ポスターを撤去
• デュアルモニターは 1 台だけ使用、補助画面を切り離す
• 家族・ルームメイトの出入りを遮断、静かな単独空間を確保

システム #

• 受験 30 分前に入室してシステム点検を通過
• バックグラウンドアプリ・通知・VPN を終了、安定した有線ネットワークを推奨
• 試験開始後に真っ先に alias k・do・自動補完・.vimrc をセットアップ、最初の作業の前に context を確認

まとめ #

この記事で押さえたこと:

• 2 時間の運用。 作業ごとの配点が優先順位。配点が高く手に馴染んだものから、詰まったら flag して次へ、没頭は禁止
• トラブルシューティングの優先順位。 30% のドメインなので点数は大きいが、原因追跡が長引くなら基準線で切って次へ
• 速度セットアップ。 alias k・do・now・自動補完・vim インデント・yq を開始 1 分以内に
• context が最優先。 CKA はクラスターが複数。作業ごとに use-context を先に、ノード作業の後は exit
• ドキュメント活用。 検索で etcdctl・kubeadm のような長いコマンドにすぐ、ドキュメントの時間も試験時間
• 定番のミス。 context/namespace、etcd 証明書フラグ、drain オプション、static Pod の場所、アップグレード順序、部分点、作業の読み残し、適用・再起動の抜け
• 部分点と検算。 作れるところまで作って k get nodes・k get pods -n kube-system で確認
• 紛らわしい概念のペア、5 つのドメイン別の核心手順、オンライン監督の点検

次へ: フルスケール実技模擬試験 #

最後の記事です。

#27 フルスケール実技模擬試験 (全ドメイン統合シナリオ + 解説) では、実際の試験に近いドメイン分布で統合シナリオを解き、詳細な解説を付けます。試験環境のように時間を計って解いてみて、トラブルシューティングやクラスターアーキテクチャのような比重の大きいドメインをもう一度固める最後の段階です。