Kubernetes資格を武器にプラットフォームエンジニアへ：CKA/CKS活かし方ガイド

目次

数年前、オンプレKubernetesを夜中に復旧しながら「この運用を個人技にしない仕組みが要る」と痛感しました。そこでCKAから取り始め、試験勉強をそのままRunbookとGitOpsに落とした結果、MTTRが半分になり、プラットフォームチームへの異動も決まりました。この記事は、同じようにSRE・プラットフォームエンジニアを目指す人に向けて、Kubernetes系資格を“運用設計力”として証明するための具体策をまとめたものです。

この記事で持ち帰ってほしいこと

  • 「Kubernetes 資格 どれから？」の迷いを解消する選び方と順番。
  • 受験勉強をそのままポートフォリオとRunbookに変換する手順。
  • 90日でクラスタ運用の成果物を作り、面接で語れるネタをそろえる計画。

なぜKubernetes資格が転職で効くのか

クラスタ運用は「再現性」と「安全な変更速度」が評価軸です。CKAやCKSは、手順暗記ではなく設計・トラブルシュートの型を持っているかを問われるため、プラットフォーム採用での信頼度が上がります。実務では以下を示せると強いです。

  • ノード障害時にどの順で確認し、どこで切り戻すかを即答できる。
  • 権限分離（RBAC）とネットワークポリシーをセットで設計している。
  • IaCとGitOpsで構成差分を管理し、変更履歴を追跡できる。

これらを資格学習と連動させると、試験合格＝運用改善を回した証拠になり、書類選考が通りやすくなります。

目的別：どの資格をどの順で取るか

1. CKA（Certified Kubernetes Administrator）

クラスタの構築・アップグレード・トラブルシュートが主題。**「本番を落とさない基盤力」**を示すために最優先で取得。オンコール経験がある人なら、試験範囲を実環境に当てはめてRunbookを作ると評価が跳ねます。

2. CKAD（Certified Kubernetes Application Developer）

アプリ開発側の目線でマニフェストを書く試験。プラットフォーム側でも「開発者に何を渡せばセルフサービス化できるか」を考える土台になるので、サービステンプレートやHelm Chart設計と一緒に進めると相乗効果があります。

3. CKS（Certified Kubernetes Security Specialist）

セキュリティの深掘り。RBAC設計、ネットワークポリシー、イメージ署名、監査ログをまとめて証明できるので、SREやセキュリティチームとの連携役を狙う人に有効。CKAを取った後に挑むと学習効率が良いです。

4. 補助として押さえたいもの

  • Terraform Associate：クラスタ外のネットワーク・ストレージも含めてコード化し、再現性の根拠を作る。
  • GitOpsツールの実践バッジ（Argo CDやFluxの公式ワークショップ）：資格というより実演ですが、GitOps運用の証拠として面接で効きます。

順番の目安：CKA → CKAD（開発寄りの人はCKADを先に）→ CKS。Terraform Associateは並行で進め、IaCをポートフォリオに載せます。

勉強をそのまま実務価値に変えるアウトプット

  1. 最小構成クラスタの再現セット
    • kindやk3dでクラスタを毎回ゼロから立てるシェルスクリプトを用意。CoreDNSやIngressの死活、PodDisruptionBudgetまで含めて再現性を示す。
  2. 障害シナリオ×Runbook
    • "ノード停止" "イメージPull失敗" "etcd容量枯渇" など5パターンを用意し、確認コマンドと復旧手順を1枚のMarkdownにまとめる。実際にkubectl get eventsの出力を貼ると説得力が増します。
  3. GitOpsパイプラインのデモ
    • Argo CD / FluxでNamespaceごとに権限を分け、ローリング更新とHelmリリースの差分をPRコメントに残す仕組みを構築。CIログのスクショを職務経歴書に添付すると面接で話が弾みます。
  4. セキュリティ強化の前後比較
    • CKSの学習と連動し、NetworkPolicy適用前後での到達可否を表にまとめる。Trivyやkube-benchのスキャン結果を添えて「改善前→改善後」を示すと効果的。

90日ロードマップ（週8〜10時間想定）

0〜30日：CKAで基盤力を固める

  • 毎日30分、kubectlのオプションを手打ちする練習を続け、補完頼みの癖を抜く。
  • kind/k3dでクラスタを日替わりで作り、Node障害・証明書期限切れを再現して復旧までのメモを残す。
  • Runbook初版をGitHubに公開し、各手順に「目的」「判定基準」「所要時間」を書く。

31〜60日：CKADとGitOpsで開発目線を足す

  • Deployment／Job／Ingress／Helmのテンプレートを整え、開発者が自分で変更できるガイドを作る。
  • Argo CDかFluxでステージング環境を用意し、PRマージ→デプロイ→ロールバックをワンコマンド化。
  • 週1回、実際に更新を流して差分をスクショし、職務経歴書に「変更の安全性を数値で管理している」ことを書ける状態にする。

61〜90日：CKSで安全性を仕上げる

  • Pod Security Standard/Admissionを適用し、特権コンテナを弾く設定をテスト。拒否ログをRunbookに追記。
  • NetworkPolicyでゼロトラスト風の分離を実装し、到達確認の結果を表形式でまとめる。
  • Trivyやkube-benchを定期スキャンに組み込み、検出→修正→再スキャンのサイクルを1回回す。ここまででCKS本番を受け、結果をポートフォリオに追記。

面接・職務経歴書での見せ方

  • 数値で語る：「ノード障害時の一次切り分け時間を20分→8分」「ローリング更新の失敗率を3%→0.5%」のようにBefore/Afterを書く。
  • コードとRunbookをセットで提出：GitHubリポジトリに/manifestsと/runbooksを並べ、PRテンプレートに「変更意図・リスク・ロールバック方法」を記載。
  • チームへの浸透度を示す：勉強会資料や社内LTスライドを1枚添付し、「資格で得た知識をチームに展開した」ことを伝える。

よくあるつまずきと回避策

  • 試験対策だけで終わる → 毎週末にRunbookへ1項目追記するルールを決めると、実務転用が進む。
  • クラスタを壊すのが怖い → kind/k3dのローカル環境で必ず破壊テストを実施し、kubectl explainとetcdctlを使うクセを付ける。
  • セキュリティ対応が後回し → CKS範囲のNetworkPolicyと署名付きイメージを最初からテンプレート化し、あと付けで悩まないようにする。

次に読みたい記事

まとめ

Kubernetes資格は「クラスタを安全に回し続ける仕組み」を作れることの証明に変えられます。CKAで基盤力、CKADで開発目線、CKSで安全性をそろえ、RunbookとGitOpsの成果物をセットで提出する。今日この後、kindでクラスタを一つ作り直し、障害シナリオを一つ再現してRunbookに追記してみてください。小さな再現性の積み重ねが、プラットフォームエンジニアとしての信頼を生みます。

Recommended

おすすめ記事

TOPに戻る