CKA(Certified Kubernetes Administrator)受験記

更新とご注意

CKAの試験様式が2022/6/25に変更になったようです。
筆者はそれ以前に受験していますので、下記リンクも併せてご参照のうえ試験に臨んでいただければと思います。

TLDR;

2022/06/19にCKAを受験し、合格しました。
受験にあたっての気をつけたこと、何を勉強したか、試験をスムーズに進めるためのTIPS、ヤマを張った箇所などなどを備忘録として記載します。

また、余談が多く含まれます。
忙しい人は下記に個人的なポイントをまとめておきますので、読み飛ばしていただければと思います。
試験に向けてのTIPS
試験環境の設定
記憶を頼りに、ヤマをはる

Disclaimer

あくまでいち個人のCKA受験記、平たく言うと感想です。この記事を読んだからといって、CKAの合格を保証するものではありません。
他にも受験した方の記事は数多くありますので、色々とご参考にされた上で適切な学習コンテンツを選んでいただき、受験に臨んでいただければと思います。

動機と前提

• かつてk8sをベースにしたR&D的なお仕事をしていたので、API Objectを作ったりはある程度理解している（と思いたい）
• 現職でもk8sは日常的に使ってはいる。
• 会社からの補助があったため、無料で受験ができた。通常は$375。Training込みのBundleだと$575。円安の昨今だと個人で手を出すのはちょっと躊躇するかも・・・
• 試験の形式として、自分でAPI Objectを作る、手を動かす形式の試験なので座学が苦手な私でも楽しめるかなと思った。
• あと、持っているとなんかカッコ良いかなって・・・

学習コンテンツ

私は会社からの補助の範囲で、なるべく無料で済ませようとしました。

• LFS258
  • 上記でも少し触れましたが、CKAを主催するLinux Fundationでは、Trainingと受験資格がセットになったBundleを提供しているようです。会社からの補助でこちらも提供していただいたので、メインの学習コンテンツとして利用しました。
  • 1日1-2章くらいで進めて1-1.5週間かかったような。
• KILLERCODA
  • CKAの試験環境を模したサイトです。サインインが必要ですが、無料で使えるので演習環境としても重宝しました。
  • 左ペインに問題が、右ペインにコンソールが表示され、Webブラウザ上で問題を解いていきます。
  • CKA向けには約10問、CKAD, CKSも入れると40問ほどあるようです。出題範囲のうち、自分が苦手なものを選んで演習していました。

演習環境

CKAは設問に従ってObjectを作ったり設定を投入したりと、自ら手を動かす試験です。
そのため、Kubernetes環境が必要になります。私は下記の２つの環境を利用しました。

• GCP
  • LF258を進めるためにGCP, AWS, Local VMのどれかを演習環境として選択する必要があったのですが、私はGCPの無料トライアル期間を利用し、VM上に環境を構築しました。
• KILLERCODA PLAYGROUND
  • 正直、これが死ぬほど便利でした。
  • Cluster Upgrade, Delete and Join Node等、オペミスしたらクラスタ再構築しないといけない操作を繰り返しやりたくなります。
  • 自前の環境は壊してしまったら環境構築をせねばならず面倒ですよね。KILLERCODAを使うと気軽に壊していいクラスタが１クリックで手に入るのはありがたかったです。
  • ただし、Ephemeralな環境ですので、設定やファイル、オブジェクトを残して置けるわけではありません。一定時間が過ぎると消えてしまいますので重要なリソースはバックアップを取るようにしましょう。

雑多に感想

• 楽しかった。
  • コマンドオプションを丸暗記、重箱の隅をつつくような出題は私の時はなかった。
  • 手を動かすのが好きな人は楽しんで勉強・受験ができるのではないでしょうか。
• ただし、無勉では受かるのは難しいと思います。
  • CKAは一度の申し込みで、2回まで受験が可能です。
  • 社内でX月までに受けなさい、的な期限が設けられていたのですが、業務多忙で勉強時間を作れず一度無勉で受けました。結果50点代後半。合格ラインは66点。
  • Kubernetes 公式Referenceなど一部のドキュメントは参照できるのですが、これらは上から流せばそのまま動くような完璧な手順になっているわけではありません。
  • 出題範囲にあるものは自分で動かし、目的を達成できているか動作確認の仕方まで確立しておくと試験中の安心感が違うかなと感じました。
  • 私は2回目の受験で合格しました。
• 楽しかったけど、本当に必要だったか？は疑問。
  • もちろん、体系立てて勉強はできますし、得られるものはあります。
  • ただ、開発・オペレーションをする時は必ず仕様は確認するし、自作したオブジェクトが期待通りか試験はするし、、、日常的に使う機会がある人はわざわざとる必要ないんじゃないかな〜〜〜〜〜って思ってしまった。。。
  • CKAD, CKSは時間と気持ちに凄まじく余裕ができたらトライするかな・・・

試験に向けてのTIPS

Linux Foundationでは、CKA受験生向けにCandidate Handbookなるものが用意されています。
が、英語なので読み飛ばしてしまっていたり、実際に受けてみると思わぬトラブルがあったりと、私はなかなかバタバタがあったので記録を残しておきます。

• できればVivaldi Browserを使う。BookmarkもVivaldiに登録しておく。また、Vivaldiにカメラとマイクの共有を許可をしておくとスムーズです。

  • Candidate HandbookによるとChromeでも良いようなのですが、いざ試験を開始すると下記のトラブルに見舞われました。
  • MacのPreferenceから共有設定をしておいたにも関わらず、カメラ、デスクトップのシェアができず、試験官からVivaldiをダウンロードするよう指示されました。
  • 私ではないですが、知人はChromeだと課題が動かない問題があったとかなかったとか・・・

• 試験官

  • 試験予定時刻15分前からLinux Foundationのサイトで"Take Exam"のボタンが活性化され、受験に進むことができます。この時、別サイトに飛ばされます。
  • 例えば、試験開始時刻が9:00AM JSTだったとしましょう。我々は8:45 - 9:15の間にチェックインを済ませておく必要があります。
  • ただし、受験に進んだからといってすぐに受けられるわけではありません。試験官がログインするまで待つ必要があります。
  • なので、8:45に"Take Exam"を押したからといって、すぐに受験できるわけではありません。私は、試験官がログインしたのが試験予定時間の10分後だったので、かなり肝を冷やしました。。。結局試験を開始できたのは試験官による説明の後、予約時間の45分後くらいでした。
  • 試験官がログインすると、チャットで説明を受けます。

• 試験官からのオリエンテーションと事前チェック

  • 試験官は英語しかできないので、チャットも英語でのやりとりになります。
  • 英語で名前と写真が確認できる身分証の提示が求められます。パスポート、キャッシュカード等。
  • macOSの場合、FinderとVivaldi以外は落とした上でForce Quit Menuの表示をチェックされます。
  • 机の上はクリーンデスクが求められます。時計も不可。試験のコンソールで残り時間が見れるので、時計は別途用意しなくても良いと思います。
  • 腕時計は付けられません。試験中に３回カメラに向けて両腕を上げるよう指示されます。
  • 飲み物は、透明なグラスに入った透明な液体のみが許可されています。
  • トイレなど、休憩とれます。休憩時間は試験時間にカウントされず、ロスタイム的に伸ばしてもらえます。
  • 受験者、もしくは試験官と試験サイトの接続が切れると、ページ上に"Wait until connection is back"的なメッセージが表示されます。
    • つまり試験官側のネットワークが不安定でも、上記事象にあたります。
    • 試験中に後で振り返りたい設問にはフラグを立てられるのですが、なんと、上記事象が起きたのち復帰してみると、フラグが消えていました。
    • 試験官に「フラグ消えてんだけど？」と問いかけるも「私はフラグのスペシャリストではない」との回答。じゃあお前はなんなんだ・・・・対応には不満が残りました。

• 試験中

  • 私はCKA英語版で申し込んだのですが、言語は日本語・英語を試験のコンソール上で選べました。
  • 最初の方に時間のかかる問題があって後ろの方に簡単な問題が連続していたので、ざっと見てからどこに時間配分をするか考えても良いかもしれません。
  • 問題は、フラグを立てて後で見返すことが可能なので難しかったら一度パスししてできる問題から着手するのが良いかも。
  • 動作確認がしやすいようにしておきましょう。
    • 例えば、設問ごとにディレクトリを作る。作業ログをとっておく。
    • 一度動作確認したつもりでも、後から不安になってOKなはずな問題の確認に時間を使うのは勿体無いですよね。でも心配になってしまうのが人間の心理というもの。
    • なので、できれば動作確認は繰り返し確認できるようにスクリプトにしておくと良いかもしれません。

• 動作確認用スクリプトの例1）
  とあるService Accountに対して、deploymentのcreate/deleteを許可するClusterRoleとのRoleBindingを作成せよ。
  類似問題はKILLERCODAのRBAC ServiceAccount Permissionsにて確認ができます。

#!/bin/bash
# Confirm operation which is allowed as the following service account
kubectl auth can-i create deployment -n ns1 --as=system:serviceaccount:ns1:pipeline
kubectl auth can-i delete deployment -n ns1 --as=system:serviceaccount:ns1:pipeline

# Confirm operation which is not allowed as the following service account.
kubectl auth can-i update deployment -n ns1 --as=system:serviceaccount:ns1:pipeline
kubectl auth can-i update deployment -n default --as=system:serviceaccount:ns1:pipeline

• 動作確認用スクリプトの例2）
  namespace1からnamespace2への疎通のみを許可するNetwork Policyを作成せよ。
  類似問題はKILLERCODAのNetworkPolicy Namespace Communicationより確認ができます。

#!/bin/bash
# Confirm pod in namespace-1 can access to the service in namespace-2.
kubectl exec -it <podname> -- /bin/sh -c "curl -m 2 <ip>:<port>"
# Confirm pod in namespace-2 cannot access to the service in namespace-1.
kubectl exec -it <podname> -- /bin/sh -c "curl -m 2 <ip>:<port>"

試験環境の設定

alias

Kubernetes Clusterの操作ですので、kubectlをたくさん打ちます。でも、kubectl毎回打つのめんどくさいですよね。。。ということで、aliasを設定しました。
kとする人も多いようですが、私はOpenShiftのocにならってkcと略すことが多いです。

echo "alias kc=' kubectl'" >> ~/.bashrc
source ~/.bashrc

Context/Namespace Switch

試験中は、複数のクラスタのContext Switch, 複数のNamespaceの変更が求められます。
Context Switchは設問の冒頭にコマンドの記載があるのでいいのですが、Namespaceの変更・確認がめんどくさい。
毎回kubectl config set-context hogehogeを打つのは手間なのと、頻繁に確認できるよう試験が始まったらすぐにシェルを設定しました。
せっかく正解のオブジェクトを作っても、誤ったContext, Namespaceに作ってたら勿体無いですからね。。。

$ cd /usr/local/bin
$ cat chns
#!/bin/bash
NS=$1
kubectl config set-context --current --namespace=$NS
kubectl config get-contexts

$ cat shns
#!/bin/bash
kubectl config get-contexts

記憶を頼りに、ヤマをはる。

上述の通り、一度ダメもとで受験し、落ちました。
その時の出題内容を記憶を頼りに書き出し、次に同様の問題が出たときに必ず解けるよう勉強していました。
個人的にヤマを張って勉強した箇所をシェアします。

• etcd
  • Snapshotの作成、リストアは暗記して何も見ずに実行できるようにしておきました。
• RBAC
  • Service AccountとUser, ClusterRoleとRole、ClusterRoleBindingとRoleBindingどちらを意図した設問になっているかをきちんと読み解くこと。
  • KILLERCODAでの演習。
    • RBAC ServiceAccount Permissions
    • RBAC User Permissions
  • kubectl authでの動作確認を確実に取れるようオプションの書き方を覚える。
    • 特に--as=system:serviceaccount:<namespace>:<serviceaccountname>オプションはリファレンスにもヘルプにもないので、覚えておくと良いと思います。
• ResourceRequest/ResourceLimit
  • リファレンス通りにPodに対して設定を投入できるようBookmarkを作っておく
• Taint/Toleration
  • NoSchedule, NoExecuteの違いを押さえておく。
  • Taint/Tolerationの付与の仕方、削除の仕方を覚えておく。
• Volumes
  • hostPath, NFSを使ったPersistentVolumeの作成方法を覚えておく。リファレンスでよく使うYamlをBookmarkしておく。
    • 動作確認のために、PersistentVolumeClaim, Podも作れるようにしておく。
  • PersistentVolumeClaimを作った際に、PersistentVolumeと紐付けができるとkubectl get pvしたときにSTATUSがAvailable ->BOUNDに変化します。PVCを作ったときは上記コマンドで確認する。
• NetworkPolicy
  • KILLERCODAの演習。類似問題が本番も出ました。
    • NetworkPolicy Namespace Communication
  • 上記に追加し、指定ポート以外の接続をDenyする設定のやり方を学習しておく。
• Service/Ingress
  • 適当なサービスを作成、公開する練習。動作確認目的でも利用しました。
    • kubectl deploy nginx --image=nginx ; kubectl expose deploy nginx --port=9999 --target-port=80
  • KILLERCODAの演習。
    • Ingress Create
  • GCP上のk8s環境にて、適当なサービスを作って、IngressControllerインストールして、Ingressを作成する一連の流れを覚えておく。
  • お気に入りのIngress作成用YamlをBookmarkしておく。私はsimple-fanoutを参考に諸々作り出すことが多かったです。
• ClusterConfiguration
  • Upgradeの手順は暗記するか、リファレンスを参考にできるようにしておくこと。
  • Nodeの数の確認方法。Nodeに付与されたTaint/Tolerationの確認方法。
• Deployment
  • 指定された名前、イメージを使って指定された数Replicaの設定ができること。
  • kubectl editもしくはkubectl scaleでReplicaの数を変更できること。