839の日記

趣味の話を書くブログです。

Certified Kubernetes Administrator(CKA)を取得した(19/06 v1.14)

f:id:husq:20190617201800p:plain
Certified Kubernetes Administrator

CKAを受けたので受験ログをまとめておく
今後受ける人の参考になれば

バックグラウンド

  • インフラ専任ではないがk8s(GKE)はそこそこ触っている
    • GKE contextとhelmが多め
  • k8s/GCPを真面目にデビューしてから4ヶ月ぐらい
    • 試験のためには結構勉強はした(15hぐらい?)

勉強概要

  • vagrant上でのk8s環境構築、実施
    • cka-practice/ckad-practiceの実施環境
    • k8s.ioのkubeadmページを見ながらvagrantクラスタ構築
    • cloud managed k8sでの学習は微妙にcloud contextが入るので個人的にはvagrant推奨
  • k8s the hardwayを2周
    • 後述するが1周で十分
  • linux academyのk8sコース受講
    • これは受けなくても良かったかも

結果

1問解けなかった問題があり、それが8%分あった

結果としては84/100%、ボーダーは74%だった
解けなかったと思った問題はなかったが92%から8%分何かとちっているらしい
結果は試験終了から大体31時間ほどで来た

Verify a Linux Foundation Certified Professional | Linux Foundation Training
のサイトから結果を確認できる(CKA-1900-002255-0100/Tanaka)

試験のルールとか概要

すべて受験時のもの
受ける際にExpert Certification - Cloud Native Computing Foundationを確認されたし
pdfなので保存した後にgoogle翻訳でファイルアップロードを使って読むと楽

  • k8sのバージョンはv1.14系
  • 閲覧してよいドキュメントは以下の3点
  • 試験問題は日本語が選択可(ちゃんと意味がわかる日本語だった)
  • 試験会場は貸し会議室を利用*1
  • chromeにextensionを入れてデスクトップ共有される
  • カメラでモニタリングされる
    • 試験会場を確認される際にも利用される
  • 試験開始15分前からポータルで試験準備ページに飛べる
    • 15分前から試験官立ち会い(リモートだけど)のもと作業を進めたほうがいい*2

当日の流れ

閲覧可なドキュメントは上記の述べた3種類だが、ほぼk8s.io/docsしか見ていない*3

試験ページは15分前から解放されると認識していたが5分前に開いたら思ったより時間がかかった
結果的に開始が15分遅れて、貸し会議室の時間が大丈夫かヒヤヒヤした(後ろにマージン30分持たせておいたのでセーフだった)
机を移す際は4つの角が全部映るぐらいカメラを引いてほしいと言われたがちゃんと映ってるか確認しながらmacのインカメで映すのが微妙に大変だった

試験前の準備は試験官と英語のチャットで行うが、英語力が低すぎて*4手間取ったのもある…
試験問題自体はちゃんと読める日本語だったので本当に助かった

試験が終わるとアンケートページが出てくるので答えて全部終わり
結果は3日以内にメールとポータル上で確認できるとのこと

試験中は1度だけ試験官に顔がちゃんと映っていないと注意された
多分ちょこちょこ映ってなかったと思うがある程度はスルーしてるのかもしれない
口元を隠すと注意されるというのは見ていたのでそのへんの仕草は意図的にしないとように心がけていた

試験の所感

3時間枠だが、1時間半ほどで1問を除いて解き終わった
1問は圧倒的に難しいやつだったので意図的に飛ばし、それらを除いて一旦見直しで30分ちょっと
ラスト1時間はその問題に取り組んでいたが、難しそうなので10分前に諦めて試験終了(部屋の時間も少し不安だったし)

圧倒的に難しい1問は他の92%達成率の方もブログで触れていたのでこれかぁ〜という気持ちになった
オンプレクラスタの知見がかなりある人じゃないと解けなさそうとは感じた

事前にやったことがないような問題もあったが、k8s.io/docsを見ればなんとかなるな〜という感じの問題だった

やった内容に深く関係するリンク

vagrant環境で勉強した内容

k8s構築で試した構成は以下の感じ

  • cni
    • calico
    • flannel
    • loopback*6
  • container runtime
    • docker
    • crio(試したけど動かなかったので実質やってない)
    • containerd
    • gVisor*7

のあたりの構成で構築した
candidate handbooksに

The Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) exams are released on Ubuntu 16.

と記載されているのでboxはubuntu/xenial64を使った

構築関係で試したのは以下のあたり

  • kubeadmを使ってflannel構成で構築した後、同じVMでcalicoに構成変更する
  • kubeadmを使ったupgrade(master/worker)*8
    • workerをアップデートするための手法(kubeadm drainなど)
  • container runtimeをnodeによって切り替えてみる
    • node単位でdocker使ったりcontainerd使ったり
  • masterでもpodを動かすようにする
    • taintを外すだけ
  • hpaがちゃんと動作するか確かめる
    • metrics-serverを入れる必要があるが、現時点(19/06)では軽微な修正が必要

自分が受けた時点ではv1.14系でどういうクラスタを使うかも明示されていた
masterが複数構成になっているクラスタはなかったのでそういった理由でsingle master clusterの構築で色々試した

勉強環境の準備

基本的にいつも使っているようなdotfiles環境はないのでplainな環境でやるように心がけていた

先述の通りvagrant環境を構築したので一応公開しておく
GitHub - 8398a7/cka-practice: The vagrant environment used when practicing CKA.

provisionしているshの役割はそれぞれ以下の通り

  • 00: k8s.io/docsの手順によるdocker install
  • 01: k8s.io/docsの手順によるkubelet kubeadm kubectlのinstall
    • version変数を変えれば古いバージョンでの構築も可能
    • 1.13.7から1.14.3への更新とかはこのあたりを調整して試した
  • 02: kubeletの設定
    • /etc/systemd/system/kubelet.service.d/10-kubeadm.conf の引数にvmのprivate ipを付与
  • 03: master nodeのセットアップ
    • kubeadm initの実行を行い、出力されたログを見てworker nodeでkubeadm joinを実行する
  • 04: calicoとkubeconfigのセットアップ
    • privileged: falseを指定してvagrantユーザで実行させるようにしている
    • network policy周りの検証をするならcalicoなのでprovisionする場合はcalicoを選択

master nodeは00-04まで、worker nodeは00-02までを行う
worker nodeは02まで終わったらmaster nodeの03を待った上で手動でkubeadm joinを行っている

最低限使うものだけは空で打てるように覚えた

bashrc

source <(kubectl completion bash) # これはデフォルトのnodeではされているっぽくて不要だった

vimrc

set number
set relativenumber
set expandtab
set smartindent
set tabstop=2
set shiftwidth=2
imap <C-j> <Esc> # 一応定義しているが試験中は諸事情により使ってない

tmux

unbind C-b
set -g prefix C-t # C-bはemacsキーバインドと被ってるので変えている
set -g default-terminal "screen-256color" # 色付け
bind h select-pane -L # 画面の移動はvimキーバインドで移動したい
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

これぐらいあれば個人的にはだいたいストレスなく作業できる(通常環境に比べると剥離は激しいが)
どっちみちpodの中とかで調査する際はdotfilesは使えないわけでちょっとした機能拡張で快適に作業できるようにしておいたほうが良いなとは今回感じた
vim(vscode)もimapを定義しているが最近はEscももっぱらC-[になってしまった

ちなみに試験はブラウザ上のターミナルで行うが、BetterTouchToolsとvimiumが悪さしてimapはちゃんと動かなかった
Esc相当はとりあえずC-cで代用できたが、これができてなかったらyamlの編集に壊滅的ダメージになるところだった…

kubectlの補完は使い方を覚えていると本当に便利なので絶対に習得したほうがいい
deploymentとかで作られたpodの補完もそうだが引数の補完もかなり便利

勉強期間中は結構explainも使っていたが、実際問題見にくいのでdocsで内部検索をしたほうが見やすく出る
docsで案内されていないようなものに関してはexplainを叩いてみるぐらいでもいいかも*9
kubectlコマンド系もhelpが充実しているので大体はdocsを見なくてもわかるようになっているなと感じた

kubectl系で覚えておいたほうが良いのは以下

kubectl run nginx --image=nginx --restart=Never # pod
kubectl run busybox --image=busybox --restart=Never --rm -it -- sh # 一時作業用pod
kubectl run nginx --image=nginx --replicas=2 # deployment, replicasはなくても良い
kubectl run nginx --image=nginx --expose --port=80 # deployment, service
kubectl run busybox --image=busybox --restart=OnFailure -- date # dateコマンドを打って終了するjob
kubectl run busybox --image=busybox --restart=OnFailure --schedule="*/1 * * * *" -- date # dateコマンドを打って終了するcronjob

それぞれ --dry-run -o yaml をつけてyamlを吐き出すこともできるのでkubectl runで指定できないパラメタはつけるといい

kubectl run nginx --image=nginx --restart=Never -o yaml --dry-run > pod.yaml
# vim pod.yamlでvolumes等を編集する

kubectl run はdeprecatedなものがちょこちょこあるので本筋に乗っかるなら kubectl create 系で覚えたほうがいいかもしれない
ただrunに比べて色々指定できるパラメタが少なくてyamlの編集量が増えることと自分の試験期間中は大丈夫ということもあってrun系のコマンドを習得した

勉強中に取り組んだkindのタイプ(ぱっと思い出せる範疇)としては以下

  • Pod
  • Service
  • Deployment
  • DaemonSet
  • Secret
  • hpa
  • PersistentVolume
  • PersistentVolumeClaim
  • Job
  • CronJob
  • NetworkPolicy

pv, pvc周りに関しては素のk8sなのでGKEとかで演習していると試験構成とずれるので注意*10
kubeadmとか使って構築しておいたほうがk8sへの理解も深まるのでvagrantを使った素のk8s学習が良いと感じた

手元のvagrantでcniはflannelとcalicoを試した
flannelはnetwork policyでpodとかにアクセス制限してても効かないのでckad-practiceでnetwork policyの問題を解くときはcalicoでセットアップしている必要がある

README通りにやっても動かなかったものたち

総括

マネージドでk8sを使ってるとあまり理解していないようなことが色々と把握できて有意義な試験だったと思う
トラブルシュートする際に雑にpod作ったり、yaml書いたりして調査するスキルも上がったなぁと感じる

次はCKADでも取ってみようかな

*1:自室だとルールが微妙にグレーっぽくてややこしかったので

*2:自分の場合は要領が悪くて結構時間がかかった

*3:https://kubernetes.ioが正式ドメインだがhttps://k8s.ioでリダイレクトしてくれる

*4:ok, ok?, yes, sorry, thanksぐらいしか発言してない

*5:お世話になったのでPRを投げた

*6:これはkubernetes the hard way中で構築したのでGCP

*7:これもkubernetes the hard way中で構築したのでGCP

*8:細やかな不備があったのでPRを投げたり、issueにコメントしたり

*9:explainにもリンクが載っているケースがあるのでまずexplainでも良い

*10:pvcを作るとpvが割り当てられるとか