2026-03-28 · 20 分で読める · 10,002 文字

CKA認定試験に3ヶ月で合格するスタディプラン：実践的なロードマップ

本記事では、Kubernetes Certified Administrator（CKA）認定試験に効率的に合格するための、実務に基づいた3ヶ月のスタディプランを紹介します。実装演習を中心とした学習アプローチにより、試験の実技問題で即座に対応できるスキルを習得できます。

CKA試験の概要と現状

Kubernetes Certified Administrator（CKA）は、The Linux Foundationが認定するKubernetes技術者向けの資格です。2024年現在、クラウドネイティブエコシステムの業界標準資格として認識されており、DevOps/SREエンジニアのキャリアにおいて大きなアドバンテージとなります。

試験の特徴を理解することが学習計画の第一歩です。以下が主要な特性です：

• 形式：実技試験のみ。ブラウザ環odynamicroc上のターミナルでKubernetes環境を操作
• 時間：2時間
• 問題数：通常15-20問
• 合格点：66%以上
• 試験環境：複数のKubernetes clusterへのアクセス権（Linux上のコマンドライン操作のみ）

実務では、CKAに合格したエンジニアは企業内のKubernetes環境の構築・保守・トラブルシューティングを独立して実行できるレベルと評価されます。筆者の経験上、CKA学習を通じて習得するclusterの診断スキルは、本番環境のインシデント対応で直結して活用できます。

学習前の準備：環境セットアップ

スタディプランを開始する前に、実践的な学習環境を整備することが非常に重要です。模擬試験環境と同じ条件で演習することが合格率を大幅に向上させます。

ローカル開発環境の構築

Docker DesktopまたはMinikubeを使用して、ローカルマシン上でKubernetesクラスタを立ち上げます：

# macOS / Windowsの場合：Docker Desktopに統合されたKubernetesを有効化
# 設定 > Kubernetes > Enable Kubernetesをチェック

# または、Minikubeでクラスタを起動
minikube start --nodes 3 --driver docker

# クラスタの確認
kubectl get nodes
kubectl get pods -A

必須ツールのインストール

CKA試験で直接使用するツールを事前にインストールして習熟します：

# kubectl：Kubernetes CLIツール
# macOSの場合
brew install kubectl

# kubectlのバージョン確認（試験対象バージョンと揃える）
kubectl version --client

# vim/nano：エディタ（試験環境で利用可能）
# 試験中はvimが最速のため、vimの基本操作を習得必須

# その他の有用なツール
brew install kubectx  # context/namespace切り替え用
brew install stern    # ログ監視用

試験環境の疑似環境構築

実際の試験では複数のクラスタへの切り替えが求められます。以下のコマンドで複数context環境をシミュレートします：

# 複数のクラスタをkubeconfigで管理
kubectl config get-contexts

# contextの切り替え（試験では頻繁に行う）
kubectl config use-context cluster1
kubectl config use-context cluster2

# contextの素早い確認
kubectl config current-context

3ヶ月スタディプラン：月別ロードマップ

効果的な学習を実現するため、以下の3段階のロードマップに従います：

flowchart TD
    A["1ヶ月目：基礎構築
Podの作成・管理から始める"] --> B["2ヶ月目：実装スキル
Deployment/Service/Networkingの深掘り"]
    B --> C["3ヶ月目：統合演習
複雑なシナリオと模擬試験"]
    C --> D["合格"]

1ヶ月目：基礎知識と基本操作の定着

最初の1ヶ月は、Kubernetesの基本概念を理解し、CLIでの基本操作を反復演習します。

週1-2：Podとコンテナ管理

PodはKubernetesにおけるデプロイの最小単位です。この週はkubectl runとkubectl createを使い、多数のPod作成・削除演習を行います。

# Podの直接実行
kubectl run nginx-pod --image=nginx:latest

# Podの詳細確認
kubectl describe pod nginx-pod

# Podのログ確認
kubectl logs nginx-pod

# Pod内でのコマンド実行
kubectl exec -it nginx-pod -- /bin/bash

# Podの削除
kubectl delete pod nginx-pod

実務では、本番環境のトラブルシューティングでkubectl execを使用してコンテナ内を調査する頻度は非常に高いです。実際のシナリオとして、Podが起動しない場合のログ確認とイベント確認を何度も反復してください。

週3-4：Namespace・Label・Selector

複数環境（本番/ステージング/開発）を管理するため、Namespaceの概念は必須です：

# Namespaceの作成
kubectl create namespace production
kubectl create namespace staging

# Namespaceを指定してPodを作成
kubectl run app-pod --image=app:v1 --namespace=production

# すべてのNamespaceのPodを表示
kubectl get pods --all-namespaces

# デフォルトNamespaceの変更
kubectl config set-context --current --namespace=production

Labelは、リソースを分類・検索するKubernetesの重要な機能です。試験では頻繁にLabel selectorで特定のポッドを検索する問題が出題されます：

# Labelを指定してPodを作成
kubectl run web-server --image=nginx --labels="tier=frontend,env=prod"

# Labelで検索
kubectl get pods -l tier=frontend

# 複数のLabelで検索（AND条件）
kubectl get pods -l tier=frontend,env=prod

# Labelで除外検索
kubectl get pods -l tier!=backend

2ヶ月目：ワークロードと通信層の実装

2ヶ月目は、本番環境で実際に使用される主要なリソースの作成・管理を深掘りします。

週5-6：Deployment・ReplicaSet・StatefulSet

Deploymentは、Podの自動スケーリング・ローリングアップデートを管理する最重要リソースです。YAML宣言による定義を習得します：

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: web-app:v1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "200m"

このファイルをkubectl apply -f deployment.yamlで適用し、以下の操作を繰り返し練習します：

# Deploymentのステータス確認
kubectl get deployment -o wide

# Deploymentの詳細情報（イベントを含む）
kubectl describe deployment web-app

# ローリングアップデートのシミュレーション
kubectl set image deployment/web-app web-app=web-app:v2 --record

# アップデート履歴の確認
kubectl rollout history deployment/web-app

# 前のバージョンにロールバック
kubectl rollout undo deployment/web-app

実務では、不具合が発生した際にkubectl rollout undoで即座に前バージョンに戻すことが重要です。試験でもロールバック操作は頻出です。

週7-8：Service・Ingress・ネットワークポリシー

Serviceは、Pod群への通信を管理する抽象層です。CKA試験では、Service types（ClusterIP、NodePort、LoadBalancer）の使い分けが問われます：

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: production
spec:
  type: LoadBalancer
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30080

# Service作成後の動作確認
kubectl get svc -o wide

# Service経由でのPod通信テスト
kubectl run test-pod --image=busybox -it --rm -- wget http://web-service

Ingressは、HTTP/HTTPSレベルでのルーティングを定義します。試験では、複数のドメインを同一clusterで管理するシナリオが出題されることがあります：

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

3ヶ月目：トラブルシューティング・セキュリティ・本番シナリオ

最終月は、複雑な実装シナリオと試験頻出のトラブルシューティング技法を習得します。

週9-10：クラスタ管理・リソースクォータ・Pod Disruption Budget

本番環境のクラスタでは、リソース使用率の管理が重要です：

# ResourceQuota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

# Pod Disruption Budget（Podの強制削除からの保護）
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-app

週11-12：模擬試験と実践問題

最後の2週間は、以下のリソースを活用して模擬試験を複数回実施します。試験本番では時間管理が重要なため、時間を制限した環境下での演習が必須です：

• Linux Foundation公式CKAページ：試験範囲の確認
• Kubernetes公式ドキュメント：完全な参考資料
• 市販のCKA模擬試験プラットフォーム（Udemy「CKA Practice Exams」など）

# secure-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    image: app:v1
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    emptyDir: {}

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: default
  namespace: production

# pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  hostPath:
    path: "/mnt/data"

---
# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 5Gi

---
# Pod内での使用例
apiVersion: v1
kind: Pod
metadata:
  name: data-app
  namespace: production
spec:
  containers:
  - name: app
    image: app:v1
    volumeMounts:
    - name: storage
      mountPath: /data
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: pvc-data

# job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: backup-job
  namespace: production
spec:
  backoffLimit: 3
  completions: 1
  parallelism: 1
  template:
    spec:
      containers:
      - name: backup
        image: backup-tool:v1
        command: ["backup.sh"]
      restartPolicy: Never

---
# cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
  namespace: production
spec:
  schedule: "0 2 * * *"  # 毎日2時
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:v1
            command: ["backup.sh"]
          restartPolicy: OnFailure

# 現在のcontextを確認して、間違ったクラスタで作業するのを防ぐ
kubectl config current-context

# 正しいcontextに切り替えてから作業開始
kubectl config use-context cluster2

# 問題文に「cluster2で実行する」と書かれていても、うっかり前のcontextで作業してしまう
# 対策：毎回の作業前に、必ずcurrent-contextを確認する習慣をつける

# 常にmetadata内にnamespaceを明記する
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: production  # ← 必ず明記
spec:
  containers:
  - name: app
    image: app:v1

# vimの設定ファイル（~/.vimrc）に以下を追加
set expandtab        # タブをスペースに変換
set tabstop=2        # スペース2個
set shiftwidth=2     # インデント幅

# 試験環境ではこの設定が利用できない可能性があるため、事前に試験環境と同じ条件で演習

# bash環境でのオートコンプリート設定
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

# zsh環境の場合
source <(kubectl completion zsh)
echo "source <(kubectl completion zsh)" >> ~/.zshrc

# 複数のkubeconfigマージ
export KUBECONFIG=/path/to/config1:/path/to/config2:/path/to/config3
kubectl config view --merge

# contextの確認
kubectl config get-contexts

# ノードの状態確認
kubectl get nodes -o wide
kubectl describe node node-name

# 全リソースの確認
kubectl get all -A

# イベントの確認（トラブルシューティングで最初にすべき作業）
kubectl get events -A --sort-by='.lastTimestamp'

# Podが起動しない場合の診断フロー
kubectl get pods -n namespace
kubectl describe pod pod-name -n namespace
kubectl logs pod-name -n namespace
kubectl logs pod-name -n namespace --previous  # クラッシュしたコンテナのログ

stateDiagram-v2
    [*] --> 基礎学習
    基礎学習 --> 2週間チェック
    2週間チェック --> 理解十分: YES
    2週間チェック --> 復習必要: NO
    復習必要 --> 基礎学習
    理解十分 --> 次のトピック
    次のトピック --> [*]

まとめ

• 環境準備が重要：Docker Desktop/Minikubeでローカル環境を構築し、試験環境と同じ条件で演習する
• 月別ロードマップに従う：1ヶ月目は基礎、2ヶ月目は実装、3ヶ月目は統合演習というステップで着実に習得できる
• 実装演習を重視：YAMLマニフェストの手作成、kubectl操作の反復が、試験の実技問題への対応力を高める
• トラブルシューティング技法の習得：context確認、ログ確認、イベント確認といった診断フローを体に染み込ませる
• ハマりポイント対策：Namespace忘却、context切り替え失敗は、試験中の時間無駄の主原因。チェックリストを確立する
• 学習期間中の定期評価：2週間ごとに進捗をチェックし、弱点を特定して補強する
• 公式ドキュメントの活用：試験本番ではKubernetes公式ドキュメントへのアクセスが許可されるため、試験対策期間中からドキュメント検索の効率化を練習する

CKA認定試験は、Kubernetes実務スキルの客観的評価基準として、業界で高く認識されています。本スタディプランに沿った継続的な学習により、3ヶ月での合格は十分に達成可能です。試験合格後は、クラウドネイティブインフラの設計・運用という更に高度な領域へのキャリア展開が期待できます。