新卒インフラエンジニア向け「Kubernetes 実践教科書 ② CKA クラスタ構築・運用編」（全16回）の第1回です。第1巻（CKAD アプリケーション開発編）を完走したあなたは、kind の上に fanclub-api を載せ、ブラウザから https://fanclub.local で CRUD を動かすところまで到達しました。この第2巻では、その一段下のレイヤー、つまり「クラスタそのものを本番想定で自分の手で作り、運用する」領域に進みます。ゴールは、kubeadm による HA（高可用）クラスタを自力で構築・運用できるようになること、そして CKA（Certified Kubernetes Administrator）の受験準備を整えることです。
第1回は、これから何を・なぜ・どの順で学ぶのかという「地図」を渡す回です。破壊的な操作は行いません。第2巻の全体像、CKA 試験の姿、kubeadm という道具の位置づけ、そして他ディストロとの違いを俯瞰し、学習の見通しを立てます。
目次
今ここマップ（全 16 回中の現在地）
本シリーズは 6 部構成です。現在地は第1部「クラスタ構築」の第1回です。
- 第1部 クラスタ構築（第1〜5回）← 今ここ
- 第2部 ワークロード管理（第6〜8回）
- 第3部 ネットワーク（第9〜11回）
- 第4部 ストレージ（第12回）
- 第5部 監視・運用（第13〜14回）
- 第6部 トラブルシュート（第15〜16回）
- Kubernetes v1.35.0（第1巻完走の kind クラスタ）
- 第2巻で構築する本番は kubeadm + Kubernetes v1.35
- kubectl v1.35.6
- Helm v4.1.4
- kind v0.31.0
- AlmaLinux 10.2
- 確認日 2026-07-04
この回のゴール
本回を終えると、次のことができるようになります。到達できたかは記事末の「やってみよう」と「理解度チェック」で確認します。
- 第2巻の最終ゴール（kubeadm HA クラスタの自力構築・運用と CKA 受験準備）と、第1巻からの位置づけの違いを説明できる
- CKA が 2 時間・合格 66% の実技試験であることと、5 ドメインの配点（D5 トラブルシューティングが 30% で最大）を把握している
- 試験中に参照できる公式ドキュメントの範囲を把握し、参照できないものと区別できる
- kubeadm が Kubernetes 公式のクラスタ構築ツールであることと、RKE2 / k0s / OKD / kind との違いを説明できる
- 第2巻の検証環境である 9 VM の役割分担を把握し、fanclub-api がどの回でどこまで移行していくかの道筋を描けている
第2巻で身につくもの（スコープとゴール）
第2巻の最終ゴールは明確です。kubeadm で本番想定の HA クラスタ（Control Plane ×3 + Workload Node ×2）を自力構築し、運用できるレベルに到達すること。そして完走時点で CKA 受験準備が完了していることです。ここで Control Plane Node は以前マスターノード、Workload Node は以前ワーカーノードと呼ばれていた役割で、本シリーズでは役割が明確な現行の呼称に統一します。第1巻がアプリ開発者（CKAD）の視点だったのに対し、第2巻は基盤運用者（CKA）の視点で K8s を捉え直します。
第1巻で作った fanclub-api は、第2巻を通して kind から本番クラスタへ段階的に引っ越していきます。この「移行物語」が学習の背骨になります。
- 第4回：kind から kubeadm HA クラスタへ移行（同一 Helm chart を再利用）
- 第8回：HPA による自動スケールを確認
- 第9回：MetalLB で LoadBalancer を利用可能に
- 第11回：Traefik + Gateway API + cert-manager で HTTPS 外部公開を復活（
https://fanclub.local） - 第12回：ストレージを Longhorn へ移行
- 第13回：Prometheus + Grafana + Loki で監視
- 第14回：ArgoCD で GitOps 化
ひとつ先に頭へ入れておくと迷わない点があります。第1巻の https://fanclub.local は、kind の extraPortMappings（80/443 をホストへ直結する仕組み）に支えられていました。本番の kubeadm クラスタにはこの仕組みがありません。そのため第4回で移行した直後は kubectl port-forward で疎通を確認し、ブラウザからの外部 HTTPS 公開は第9回（MetalLB）と第11回（Traefik）が入ってから復活させます。「第4回で移したのにブラウザで開かない」と慌てないよう、この順序を覚えておいてください。
CKA 試験を知る
CKA は Kubernetes の運用管理スキルを問う実技試験です。多肢選択ではなく、ブラウザ上のターミナルで実際に kubectl や kubeadm を操作して課題を解きます。まず試験の輪郭を押さえます。
| 項目 | 内容 |
|---|---|
| 試験形式 | 実技試験（ブラウザ端末で kubectl・kubeadm を実操作） |
| 試験時間 | 2 時間 |
| 合格点 | 66% |
| 問題数 | 15〜20 問程度 |
| 参照可能ドキュメント | kubernetes.io/docs・kubernetes.io/blog・helm.sh/docs・gateway-api.sigs.k8s.io |
| 有効期限 | 2 年 |
| 模擬試験 | Killer.sh が 2 回分付属（本番より難しめ） |
申込みは Linux Foundation の認定ページから行います。受験を申し込むと Killer.sh の模擬試験が 2 回分付いてきます。本番よりも難易度が高く設定されているため、仕上げの実力チェックとして活用してください。
試験中に参照できるのは kubernetes.io/docs・kubernetes.io/blog・helm.sh/docs・gateway-api.sigs.k8s.io の 4 件だけという点は重要です。この後で触れる RKE2 や k0s、OKD などの外部ドキュメントは試験中に開けません。GitHub も開けないため、リポジトリの README を当てにした準備は通用しません。逆に言えば、kubernetes.io に載っている kubeadm や kubectl の使い方は、試験中にいつでも確認できます。普段から kubernetes.io を「引ける」状態にしておくことが得点に直結します。
時間配分のコツも先に共有しておきます。2 時間で 15〜20 問を解くため、配点の高いドメイン（後述の D5 トラブルシュートが 30%）から着手し、kubectl のエイリアスや --dry-run=client -o yaml で入力を短縮し、詰まった問題は印（flag）を付けて後回しにするのが定石です。
CKA 5 ドメインと第2巻の対応
CKA の出題範囲は 5 つのドメインに分かれ、それぞれ配点比率が決まっています。第2巻の 16 回は、この 5 ドメインを完全に網羅するよう設計されています。
| CKA ドメイン | 配点 | 第2巻での対応回 |
|---|---|---|
| D1: クラスタアーキテクチャ・構築・設定 | 25% | 第1〜6回・第8回（RBAC）・第14回 |
| D2: ワークロードとスケジューリング | 15% | 第7〜8回 |
| D3: サービスとネットワーク | 20% | 第9〜11回 |
| D4: ストレージ | 10% | 第12回 |
| D5: トラブルシューティング | 30% | 第13〜16回 |
注目すべきは D5 トラブルシューティングが 30% と最大配点である点です。本番のクラスタ運用では「壊れたものを直す」力が最も問われるという試験思想の表れです。第2巻ではこの重みに合わせ、後半の第13〜16回をトラブルシュートに集中配分しています。単に構築するだけでなく、壊して直す訓練を最後にまとめて積む構成です。
kubeadm とは何か
kubeadm は、Kubernetes 公式のクラスタ構築ツールです。VM や物理マシンの上に、Control Plane（API Server・etcd・スケジューラ・コントローラマネージャ）と Workload Node を組み立て、正しく動くクラスタを作り上げます。このうち etcd は、クラスタの全状態を保存するキーバリューストア（データベース）で、第5回でバックアップとリストアを扱います。覚えるべき中心コマンドは 3 つです。
kubeadm init：最初の Control Plane Node を初期化してクラスタを起動するkubeadm join：Control Plane Node や Workload Node を既存クラスタへ参加させるkubeadm upgrade：クラスタのバージョンをアップグレードする
CKA との相性が良い理由は、試験が kubeadm の操作を直接問うからです。/etc/kubernetes/manifests/ に置かれる Static Pod（API Server などをファイルとして定義する仕組み）や、/etc/kubernetes/admin.conf という管理者用 kubeconfig といった標準パスは、そのまま試験問題に登場します。これらは Control Plane Node 上に root 所有で置かれる特権ファイルです。admin.conf は第2回で作業端末 k8s-ops へコピーし（所有者 developer・パーミッション 600 に整えます）、そこから kubectl で操作します。第1巻の kind 用 kubeconfig（~/.kube/config）を温存するため当初は別ファイル ~/.kube/kubeadm.conf として置き、kind を破棄する第4回で正式な ~/.kube/config へ昇格させます。kubeadm を学ぶことは、クラスタの内部構造を最も透明な形で理解することにつながります。
第1巻で使った kind との違いも押さえておきます。kind は「Docker コンテナの中に K8s ノードを作る」開発・CI 向けの道具でした。手軽な反面、コンテナの内側という制約があります。一方 kubeadm は「VM に素で K8s を構築する」本番向けの道具です。この違い、つまりコンテナの中の K8s から、マシンの上の K8s へ、という視点の切り替えが第2巻の学びの核になります。
なお本巻では、kubeadm や kubelet を導入する際にバージョンを v1.35.x に固定（ピン留め）します。最新版へ自動追従する stable channel をそのまま使うと、時間が経つと手順とバージョンがずれて再現性が失われます。バージョンを固定するのは、本番運用でも教材でも共通の基本作法です。
kubeadm vs RKE2 / k0s / OKD / kind 概観
Kubernetes を構築する道具は kubeadm だけではありません。現場では用途に応じて別のディストリビューションも使われます。全体像を俯瞰しておきます。
| ディストロ | 主なユースケース | 本シリーズでの扱い |
|---|---|---|
| kubeadm | CKA 試験・学習・標準的な K8s 構築 | 本巻（第2巻）の主軸 |
| RKE2 | SUSE / Rancher 系の本番環境・FIPS 対応 | 別シリーズで詳解予定 |
| k0s | 軽量・シングルバイナリ・エッジ環境 | 別シリーズで詳解予定 |
| OKD / OpenShift | Red Hat エンタープライズ環境 | 別シリーズで詳解予定 |
| kind | ローカル開発・CI | 第1巻で使用 |
その中で本巻が kubeadm を主軸に選ぶ理由は 3 つあります。
- CKA 試験が kubeadm の操作（
kubeadm init/join/upgrade）を直接問うため、教材と試験の手順が一致する - Kubernetes 公式ツールであり、クラスタのアーキテクチャを最も透明に理解できる
- Static Pod や kubeconfig といった標準パスが試験に直結する
RKE2・k0s・OKD は本巻のスコープ外で、概観のみに留めます。現場ではこれらも使われるため存在は知っておくべきですが、まずは公式の kubeadm でクラスタの素の姿を理解することが、他ディストロを学ぶ際の土台にもなります。
第2巻の検証環境（9 VM）
第1巻は k8s-ops と k8s-registry の 2 VM で完結していました。第2巻では HA クラスタを本番想定で組むため、ここに 7 VM を追加した 9 VM 構成で学びます。これから使う舞台を一覧で確認します（本回で構築するわけではなく、第2回以降で順に立ち上げます）。
| VM 名 | IP | vCPU | RAM | 役割 |
|---|---|---|---|---|
| alma-proxy | 192.168.1.121 | 1 | 1 GB | DNS / NTP / Squid プロキシ |
| k8s-ops | 192.168.1.122 | 2 | 6 GB | 作業端末（kubectl・Helm v4 等） |
| k8s-registry | 192.168.1.123 | 2 | 2 GB | Docker Registry |
| k8s-lb | 192.168.1.124 | 1 | 1 GB | HAProxy（API Server LB + Gateway 転送） |
| k8s-cp-01 | 192.168.1.125 | 2 | 4 GB | Control Plane Node #1 |
| k8s-cp-02 | 192.168.1.126 | 2 | 4 GB | Control Plane Node #2 |
| k8s-cp-03 | 192.168.1.127 | 2 | 4 GB | Control Plane Node #3 |
| k8s-wl-01 | 192.168.1.128 | 4 | 8 GB | Workload Node #1 |
| k8s-wl-02 | 192.168.1.129 | 4 | 8 GB | Workload Node #2 |
ネットワークは 2 面で構成します。192.168.1.0/24 の External ネットワークは管理・kubectl・LB アクセス用、10.0.10.0/24 の Internal ネットワークは etcd や CNI（Pod 間通信を担うネットワークプラグイン）といったクラスタ内部通信専用です。この 2 面構成が、本番クラスタのネットワーク設計を実機で確認する材料になります。
読者の方は 1 台のホストで再現できるよう Vagrantfile を用意しています。これらの VM の具体的な構築手順（Vagrantfile の使い方を含む）は第2回以降で順に案内するため、本回で準備する必要はありません。9 VM を同時に動かすため物理メモリは 48 GB 程度が目安です。メモリが足りない場合は Control Plane や Workload Node の RAM を絞る縮小構成でも学習を進められます。
やってみよう
第1回は概念中心ですが、手を動かして自分の第1巻環境を確認します。以下のコマンドは、第1巻から作業端末として使ってきた k8s-ops に SSH でログインし、一般ユーザー developer として実行します。プロンプトの $ は一般ユーザー、# は root を表します。kubectl は第1巻で設定した kubeconfig（~/.kube/config・所有者 developer・パーミッション 600・kind クラスタを指す context）をそのまま使うため、本回では追加の設定は不要です。
第1巻の kind クラスタを確認する
実行コマンド：
$ kubectl get nodes -o wide実行結果：
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kind-control-plane Ready control-plane 12h v1.35.0 172.18.0.2 <none> Debian GNU/Linux 12 (bookworm) 6.12.0-211.22.1.el10_2.x86_64 containerd://2.2.0第1巻の kind クラスタは 単一ノード（kind-control-plane が 1 台）で動いています。OS-IMAGE 列が Debian GNU/Linux 12 と表示されるのは、kind のノードが AlmaLinux ホストの内側でさらに Debian ベースのコンテナとして動いているためです。これがそのまま「コンテナの中の K8s」の実物です。第2巻では、これを Control Plane ×3 + Workload Node ×2 の 5 ノード HA クラスタへと組み替えます。kubeadm では各ノードが AlmaLinux の VM そのものになるため、OS-IMAGE 列には AlmaLinux が並びます。今の 1 行が、完走時には 5 行になる、というのが第2巻の到達イメージです。
自分の環境のバージョンを確認する
実行コマンド：
$ kind version
$ kubectl version
$ helm version --short実行結果：
kind v0.31.0 go1.25.5 linux/amd64
Client Version: v1.35.6
Kustomize Version: v5.7.1
Server Version: v1.35.0
v4.1.4+g05fa379記事冒頭の「動作確認バージョン」と自分の環境が一致しているかを確認してください。バージョンがずれていると、この先の手順で出力が食い違う原因になります。
CKA の公式範囲を自分の目で見る
CNCF の Curriculum リポジトリ（github.com/cncf/curriculum）と Linux Foundation の CKA 認定ページを開き、5 ドメインの配点比率を自分の目で確認してください。本記事の配点表と照らし合わせ、D5 トラブルシューティングが 30% で最大であることを確かめてください。ゴールを具体的な数字で把握しておくと、各回の学習の重みづけが見えてきます。
まとめ
第1回では、第2巻の地図を広げました。ゴールは kubeadm HA クラスタの自力構築と CKA 受験準備です。CKA は 2 時間・合格 66% の実技試験で、D5 トラブルシューティングが 30% と最重視されます。kubeadm は Kubernetes 公式のクラスタ構築ツールであり、試験と教材の手順が一致する点が学習に有利です。そして 9 VM の舞台が、これからの構築の場になります。
理解度チェック（○×形式・全 7 問）
次の各文が正しいか（○）誤りか（×）を判断してください。下の「解答と解説」を開くと答え合わせができます。
- CKA は多肢選択式の試験である。
- CKA の合格ラインは 66% である。
- 試験中に RKE2 の公式ドキュメントを参照してよい。
- kubeadm は Kubernetes 公式のクラスタ構築ツールである。
- CKA で最も配点が高いのは D5 トラブルシューティング（30%）である。
- 第2巻では kind を使って本番 HA クラスタを構築する。
- Killer.sh の模擬試験は CKA の申込みに 2 回分付属する。
解答と解説
1=×（実技試験）／2=○／3=×（参照できるのは kubernetes.io/docs・kubernetes.io/blog・helm.sh/docs・gateway-api.sigs.k8s.io の 4 件）／4=○／5=○／6=×（kubeadm で構築する。kind は第1巻）／7=○
次回予告
次回・第2回では、いよいよ手を動かします。alma-proxy の whitelist を第2巻向けに拡張し、pkgs.k8s.io の公式リポジトリから kubelet・kubeadm・kubectl を導入します。そして kubeadm init でシングルノードのクラスタを起動し、Calico を CNI として適用してノードが Ready になるところまでを体験します。本番クラスタ構築の第一歩です。
