全14機構の総ざらいで第1巻完走

新卒インフラエンジニア向け「Kubernetes 実践教科書① CKAD アプリケーション開発編」の第19回、最終回です。第18回までで、コンテナの基礎から Helm・Gateway API・HTTPS 公開まで、fanclub-api を構成する全機構を 1 つずつ積み上げてきました。最終回は、それらをクリーンな kind クラスタにゼロから通し構築する総ざらい演習です。目標時間は 120 分。最後にブラウザから https://fanclub.local で CRUD 操作ができれば、第1巻完走です。CKAD の全ドメイン（D1〜D5）を横断します。

動作確認バージョン：K8s v1.35.0 / kind v0.31.0 / Calico v3.32.0 / Helm v4.1.4 / Gateway API v1.4.0 / Traefik chart v39.0.9（v3.6.15）/ cert-manager v1.20.0 / fanclub-backend:0.3.2 / fanclub-frontend:1.0.0（2026-07-03 実機検証時点）

コンテンツ

今ここマップ（全 19 回中の現在地）
この回のゴール
総ざらい演習の概要
- 手順0：クラスタと下地を作る
14 機構の通し演習
ブラウザで CRUD を通す（機構 14）
CKAD 試験形式の最終チェック
第1巻完走宣言
やってみよう
理解度チェック
まとめ
次のステップ
シリーズ一覧

今ここマップ（全 19 回中の現在地）

現在地は第 6 部「パッケージ管理と HTTPS 公開」の第 19 回、第1巻の最終回です。ここまでの全機構を 1 回の演習で連携させ、完走マイルストーンに到達します。

第 1 部コンテナと Docker（第 1〜4 回）
第 2 部 Kubernetes 基礎（第 5〜6 回）
第 3 部アプリリソース（第 7〜11 回）
第 4 部ワークロード戦略（第 12〜14 回）
第 5 部セキュリティ基礎（第 15〜16 回）
第 6 部パッケージ管理と HTTPS 公開（第 17〜19 回）★ ← 今ここ（完走）

この回のゴール

19 回で習得した全 14 機構を 1 回の通し演習で連携させられる。
クリーンな kind クラスタから https://fanclub.local のブラウザ CRUD 動作までを、目標 120 分以内に再現できる。
CKAD 試験の形式と、時間短縮のための高速操作を把握する。

総ざらい演習の概要

この回は新しい技術を導入しません。第1〜18回で個別に習得した機構を、何もないクリーンな kind クラスタに一から積み直し、連携して動くことを確認します。作業はすべて、作業端末 k8s-ops に一般ユーザー developer で SSH した状態で行います。設定ファイル（kind-config.yaml / calico.yaml / traefik-values.yaml / ca-issuer.yaml / fanclub-chart/）は、これまでの回で作った developer のホーム（~）のものをそのまま使います。

大半の機構は第17回で作った Helm chart に集約済みなので、下地（クラスタ・CNI・Gateway 実装・証明書）を整えたうえで helm install 一発で 11 機構がまとめて立ち上がります。全体の流れは次のとおりです。

第19回の構築順序フロー図。手順0（kind クラスタ作成→レジストリ設定→Calico）を土台に、Gateway API CRD→Traefik→cert-manager→自己署名 CA の下地を整え、helm install で 11 機構を一括展開し、最後にブラウザ CRUD で動作確認する流れを上から下へ示す。 — 図1：クリーン環境からの構築順序（下地 → helm install → 動作確認）

手順0：クラスタと下地を作る

まず既存クラスタを破棄し、第5回の kind-config.yaml（disableDefaultCNI + podSubnet 10.244.0.0/16 + extraPortMappings 80/443）でクリーンなクラスタを作ります。実行コマンド：

$ kind delete cluster
$ kind create cluster --config ~/kind-config.yaml

ここで忘れやすい落とし穴があります。第4回で作った k8s-registry（192.168.1.123:5000・HTTP の非 TLS レジストリ）から自作イメージを pull するための設定は、クラスタを作り直すと消えます。新しいノードの containerd に、レジストリの参照設定（hosts.toml）を置き直します。実行コマンド：

$ docker exec kind-control-plane mkdir -p /etc/containerd/certs.d/k8s-registry:5000
$ cat <<'EOF' | docker exec -i kind-control-plane tee /etc/containerd/certs.d/k8s-registry:5000/hosts.toml
[host."http://192.168.1.123:5000"]
  capabilities = ["pull", "resolve"]
  skip_verify = true
EOF

これで k8s-registry:5000 宛の pull が http://192.168.1.123:5000 の非 TLS レジストリへ向きます。なお docker.io や quay.io からの公式イメージ（Traefik・cert-manager・Calico・PostgreSQL など）は、kind create が developer シェルのプロキシ設定を読み取ってノードに引き継ぐため、alma-proxy 経由で pull できます（レジストリ宛の 192.168.1.123 は no_proxy でプロキシを迂回します）。続いて CNI の Calico を入れ、ノードが Ready になるまで待ちます。実行コマンド：

$ kubectl apply -f ~/calico.yaml
$ kubectl wait --for=condition=ready node --all --timeout=180s

次に、第18回で導入した外部公開の下地（Gateway API CRD・Traefik・cert-manager・自己署名 CA）を、同じ手順で整えます。Helm リポジトリ（traefik / jetstack）は第18回で追加済みで、クラスタを作り直しても残っています（未追加なら helm repo add で入れ直します）。実行コマンド：

$ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml
$ helm install traefik traefik/traefik --version 39.0.9 \
    -n traefik --create-namespace -f ~/traefik-values.yaml
$ helm install cert-manager jetstack/cert-manager --version v1.20.0 \
    -n cert-manager --create-namespace --set crds.enabled=true
$ kubectl apply -f ~/ca-issuer.yaml

GatewayClass traefik が ACCEPTED=True、ClusterIssuer fanclub-ca-issuer が READY=True になれば下地は完成です。

14 機構の通し演習

下地が整ったら、fanclub-api を helm install します。helm コマンドは chart を ./fanclub-chart の相対パスで指すので、developer のホーム（~）で実行します。この 1 コマンドで、Namespace から NetworkPolicy まで 11 の機構がまとめて展開され、Gateway / HTTPRoute / Certificate も有効になります。chart が pull する fanclub-backend:0.3.2（第15回）と fanclub-frontend:1.0.0（第18回）は、これまでの回で k8s-registry に push 済みです。k8s-registry は kind とは別のホストなので、クラスタを作り直しても残っています（起動したままにしておきます）。実行コマンド：

$ helm install fanclub ./fanclub-chart \
    --set gateway.enabled=true --set frontend.image.tag=1.0.0

fanclub-api は 1〜数分で全 Pod が Running になります（初回はノードがイメージを pull するぶん時間がかかります）。実行コマンド：

$ kubectl get pods -n fanclub

実行結果（例）：Backend（サイドカー込み 2/2）・DB・Frontend・ログコレクタがすべて Running です。

NAME                               READY   STATUS    RESTARTS   AGE
fanclub-backend-6896d48bd9-stdqd   2/2     Running   0          51s
fanclub-db-0                       1/1     Running   0          51s
fanclub-frontend-7d9b4667f-p7bqz   1/1     Running   0          51s
fanclub-logcollector-bvvvw         1/1     Running   0          51s

この演習で連携させた 14 機構と、対応する CKAD ドメイン・習得した回は次のとおりです。1〜11 は chart（機構 12＝Helm）が一括展開し、13 は下地の Gateway 一式、14 が動作確認です。

#	機構	CKAD	習得回
1	Namespace + ResourceQuota + LimitRange	D4	第14回
2	PostgreSQL StatefulSet + PVC	D1	第9回
3	DB マイグレーション Job	D1	第11回
4	Backend Deployment（3 Probe + resources）	D2・D3	第12回
5	Frontend Deployment	D1	第8・18回
6	ClusterIP Service（Backend / Frontend / DB）	D5	第8回
7	ConfigMap / Secret（設定の外部化）	D4	第10回
8	ServiceAccount + Role + RoleBinding	D4	第15回
9	SecurityContext（非 root / 読取専用 RootFS / cap drop）	D4	第15回
10	DaemonSet（ログコレクタ模擬）	D1	第11回
11	NetworkPolicy（default-deny + 段階的許可）	D5	第16回
12	Helm chart で全体管理（helm install 一発）	D2	第17回
13	Gateway API + Traefik + cert-manager（HTTPS）	D5	第18回
14	動作確認（`https://fanclub.local` で CRUD）	横断	第19回

Gateway が PROGRAMMED=True、Certificate が READY=True になっていることも確認します。実行コマンド：

$ kubectl get gateway,certificate -n fanclub

ブラウザで CRUD を通す（機構 14）

仕上げに、ブラウザを動かす端末の hosts に 127.0.0.1 fanclub.local を追記し（第18回と同じ・kind と別端末なら kind ホストの IP を指す）、https://fanclub.local を開きます。会員の一覧・登録・詳細・編集・削除が一通り動けば、14 機構すべてが連携しています。コマンドラインで CRUD を確認するなら次のようにします（自己署名なので -k、社内プロキシを迂回するため --noproxy）。実行コマンド：

$ curl -k --noproxy '*' --resolve fanclub.local:443:127.0.0.1 \
    https://fanclub.local/api/members

実行結果（例）：会員一覧の JSON が返ります。ブラウザ →(HTTPS)→ Gateway → Frontend →(Nginx が /api を中継)→ Backend → DB の一本道が、クリーン環境から通っています。

[{"createdAt":"2026-07-03T12:18:01.790546","email":"hanako@example.com","id":1,"name":"鈴木花子","plan":"standard"},{"createdAt":"2026-07-03T12:18:01.790546","email":"ichiro@example.com","id":2,"name":"佐藤一郎","plan":"free"}]

完走時の fanclub-api 全体アーキテクチャ図。ブラウザから HTTPS で入り、Gateway（Traefik・TLS 終端）→ Frontend → Backend → DB の三層に、ConfigMap/Secret・RBAC・NetworkPolicy・ResourceQuota・DaemonSet・CronJob などの機構が付随し、全体を Helm chart が一括管理していることを俯瞰で示す。 — 図2：完走時の fanclub-api 全体アーキテクチャ（14 機構の連携）

CKAD 試験形式の最終チェック

CKAD は実技試験です。知識の暗記ではなく、CLI で実際にリソースを作れるかを問われます。概要は次のとおりです。

形式：performance-based（実際の CLI 上でタスクを解く）／試験時間 2 時間／合格 66%／有効 3 年。
参照可能：試験中に kubernetes.io/docs・helm.sh/docs・github.com/kubernetes を閲覧できる。暗記より「探して使う」力が要る。
ドメイン配分：D1 Application Design and Build 20% / D2 Deployment 20% / D3 Observability and Maintenance 15% / D4 Environment, Configuration and Security 25% / D5 Services and Networking 20%。本シリーズの各回はこの配分に沿っています。

時間内に解ききるには、高速操作が欠かせません。次の 3 つは特に効きます。

alias：alias k=kubectl（本シリーズは早期に導入済み）。タイプ量を大きく減らせる。
dry-run + YAML 生成：kubectl create deployment web --image=nginx --dry-run=client -o yaml > web.yaml で雛形を作り、必要箇所だけ編集する。ゼロから書くより速い。
explain：kubectl explain pod.spec.containers でフィールドを即確認。ドキュメントを探すより速いことが多い。

仕上げの模擬試験には Killer.sh（CKAD 申込みに 2 回分付属）が定番です。本番より難しめの構成で、時間感覚と弱点を洗い出せます。本シリーズの 14 機構をゼロから 120 分で組めるようになっていれば、実技の土台はできています。

第1巻完走宣言

ブラウザから会員の登録・一覧・編集・削除が動く状態を確認できたら、第1巻完走です。第1〜19回で、コンテナと Docker の基礎から始め、kind で K8s を立て、Pod・Service・StatefulSet でアプリを組み、ConfigMap/Secret/RBAC/SecurityContext/NetworkPolicy で守り、Helm でパッケージ化し、Gateway API と cert-manager で HTTPS 公開する——ここまでを、クリーンな環境から自力で再構築できるようになりました。これは CKAD の実技で問われる力そのものです。

次の一歩は、この状態を土台にした本番運用です。第2巻「CKA クラスタ構築・運用編」では、kind を離れて kubeadm で本番相当の HA クラスタを自力構築し、MetalLB・Longhorn・監視・GitOps まで扱います（第2巻の公開に合わせてリンクを追加します。ここでは案内のみです）。まずは第1巻の完走、おめでとうございます。CKAD 受験の準備が整いました。

やってみよう

kind delete cluster → kind create cluster --config ~/kind-config.yaml でクリーンなクラスタを作り、レジストリ用 hosts.toml を置き直して Calico を入れ、ノードが Ready になることを確認する。
Gateway API CRD・Traefik・cert-manager・自己署名 CA を入れ、GatewayClass と fanclub-ca-issuer が使える状態になることを確認する。
helm install fanclub ./fanclub-chart --set gateway.enabled=true --set frontend.image.tag=1.0.0 を実行し、kubectl get pods -n fanclub で 4 つの Pod が Running になることを確認する。
ブラウザで https://fanclub.local を開き、会員の登録・編集・削除を操作する。
ここまでを 120 分以内に通しでできるか計測し、詰まった機構を復習する。

理解度チェック

次の各文が正しいか（○）誤りか（×）を判断してください。解答は下にまとめています。

クリーンな kind クラスタを作り直すと、k8s-registry を参照する containerd の設定も消えるため、置き直しが必要である。
fanclub-api の機構 1〜11 は、helm install 1 コマンドでまとめて展開できる。
CKAD は知識を問う選択式試験である。
CKAD の試験時間は 2 時間で、合格ラインは 66% である。
kubectl create ... --dry-run=client -o yaml は、マニフェストの雛形を素早く作るのに使える。
CKAD 試験中は kubernetes.io/docs などの公式ドキュメントを参照できる。
Calico を入れる前でも、NetworkPolicy は確実にエンフォースされる。

解答

1. ○：レジストリ参照（hosts.toml）はノード側の設定なので、作り直すと消える。
2. ○：機構 1〜11 は chart に収めてあり、helm install で一括展開される。
3. ×：CKAD は CLI で実タスクを解く実技試験。
4. ○：2 時間・66% 合格・有効 3 年。
5. ○：雛形生成 → 必要箇所だけ編集が定石。
6. ○：試験中に公式ドキュメントを参照できる。
7. ×：NetworkPolicy をエンフォースするのは CNI。Calico 導入前は効かない。

まとめ

最終回は、第1〜18回の全 14 機構をクリーンな kind クラスタにゼロから通し構築しました。クラスタ作成・レジストリ設定・Calico で下地を作り、Gateway API・Traefik・cert-manager で外部公開の土台を整え、helm install 一発で 11 機構を展開し、https://fanclub.local のブラウザ CRUD まで通しました。これで第1巻は完走です。CKAD は実技試験であり、alias・dry-run・explain の高速操作と、Killer.sh の模擬試験で仕上げれば、受験準備が整います。

次のステップ

第1巻「CKAD アプリケーション開発編」はこれで完結です。次は第2巻「CKA クラスタ構築・運用編」で、kind を離れて kubeadm で本番相当の HA クラスタを自力構築し、ロードバランサ・分散ストレージ・監視・GitOps まで、基盤を運用する側の力を付けていきます。第1巻で作った fanclub-api の Helm chart は、第2巻でもそのまま活躍します。完走、おめでとうございます。

シリーズ一覧

第1部：コンテナと Docker

第2部：Kubernetes 基礎

第3部：アプリリソース

第4部：ワークロード戦略

第5部：セキュリティ基礎

第6部：パッケージ管理 + HTTPS 公開

第17回 Helm v4 + chart 化 + フルサイクル
第18回 Gateway API + HTTPRoute + Ingress 対比 + Traefik + cert-manager
第19回 fanclub-api 全機構連携の実技総ざらい総合演習 + 第1巻完走宣言 ★ ← 今ここ

※ 第2巻「CKA クラスタ構築・運用編」は準備が整い次第の公開です。公開にあわせて、ここにリンクを追加します。

今ここマップ（全 19 回中の現在地）

この回のゴール

総ざらい演習の概要

手順0：クラスタと下地を作る

14 機構の通し演習

ブラウザで CRUD を通す（機構 14）

CKAD 試験形式の最終チェック

第1巻 完走宣言

やってみよう

理解度チェック

まとめ

次のステップ

シリーズ一覧

第1部：コンテナと Docker

第2部：Kubernetes 基礎

第3部：アプリリソース

第4部：ワークロード戦略

第5部：セキュリティ基礎

第6部：パッケージ管理 + HTTPS 公開

第1巻完走宣言