Special Feature — Kubernetes
コンテナのオーケストレーションは、用語を暗記する学問ではありません。
図解とYAML、確認コマンドで、5章をじっくり読めば手が動くようになる特集です。
一度に全部読んで消化不良になるより、1日1章のペースで手を動かしながら読む方が身につきます。そこでこの特集は、本日2026年10月19日の特集トップから始めて、翌日から第1章、第2章と毎日1ページずつ公開していきます。最終日の10月24日に第5章「本番運用」が出そろいます。
各章はこのページにリンクが追加されていきます。明日「どこで読んだっけ」と探さなくて済むように、このトップページを保存しておくのがいちばん確実です。
毎日の公開は、X（@BusinessHub413）でもお知らせします。
| Day | 公開日 | ページ | 内容 | 状態 |
|---|---|---|---|---|
| Day 1 | 10/19（月） | 特集トップ（このページ） | 全体像、用語の地図、学習環境の準備 | 公開中 |
| Day 2 | 10/20（火） | 第1章 Kubernetesの基礎 | Pod・Node・Control Plane、宣言的API、kubectl、最初のPodを動かして壊す | 明日公開 |
| Day 3 | 10/21（水） | 第2章 アーキテクチャ | API Server・etcd・Scheduler・Controller・kubelet。YAMLがコンテナになるまで | 公開予定 |
| Day 4 | 10/22（木） | 第3章 ワークロード | Deployment・Service・ConfigMap/Secret・Job・Probe・更新とロールバック | 公開予定 |
| Day 5 | 10/23（金） | 第4章 ネットワークとストレージ | Service/DNS・Ingress・Gateway API・NetworkPolicy・PV/PVC・バックアップ | 公開予定 |
| Day 6 | 10/24（土） | 第5章 本番運用 | 可用性・RBAC・監視・オートスケール・コスト・更新・障害対応・マネージド選定 | 公開予定 |
途中から来た人も大丈夫です。各章は前の章の用語を前提にしますが、このページの「先に覚える用語」を読んでおけば、どの章からでも追いつけるように書いています。
Dockerで docker run まではできた。でもKubernetesの入門書を開いた瞬間、Pod、Deployment、Service、Ingress、etcd、kubelet、と知らない言葉が一気に並び、閉じてしまった。そんな経験をした人は多いはずです。挫折の原因はたいてい次の3つで、能力の問題ではありません。
10個以上の新しい名前が、どれがどれの「中」にあり、どれが誰に「頼む」のかが見えないまま出てきます。
手順どおり kubectl apply して「できた」けれど、裏で何が動いたか説明できないので、少しでも違うことをすると詰まります。
minikubeで動いたYAMLが、クラウドでは動かない。ロードバランサー、ストレージ、権限、料金が環境ごとに違うからです。
💡 この特集の主題: Kubernetesは「コンテナを起動するコマンド集」ではなく、「こうなっていてほしい」という状態を宣言すると、裏側の部品たちがその状態へ近づけ続けてくれる基盤です。この一文が腑に落ちれば、残りの用語はぜんぶ「誰が・何を・どう近づけるか」の役割分担として読めます。
最初にこの図だけ頭に入れてください。5章のどこを読んでいても、この図のどこを話しているのかが分かるようにします。あなたが kubectl で「望ましい状態」を伝え、Control Plane（司令塔）が判断し、Node（作業者）がコンテナを動かす。利用者は、入れ替わるPodの代わりにServiceという固定の入口へアクセスします。
図1: あなたは「望ましい状態」を伝えるだけ。配置と維持はControl Planeとkubeletの仕事。利用者はServiceから入る。
この図で覚えてほしいのは3点だけです。
5つの章は「Kubernetesに何を頼み、何を自分で責任を持つか」を外側から順に広げていく構成です。1章ずつ、前の章で出た用語だけを使って次の章を説明します。
公開済みの章から順にリンクが有効になります。公開前の章は、扱う内容と公開日だけ先にお知らせします。
コンテナとの関係、Control PlaneとNode、Pod、宣言的API、kubectl、最小構成。はじめてのPodを動かし、わざと壊して状態の読み方を身につけます。
10/20（火）公開予定API Server、etcd、Scheduler、Controller Manager、kubelet、コンテナランタイム。YAMLが実際のコンテナになるまでの流れを図で追います。
10/21（水）公開予定Deployment、Service、ConfigMapとSecret、Job、StatefulSet、Probe、requests/limits、更新とロールバック。Webアプリを複数台で安定して動かします。
10/22（木）公開予定ServiceとDNS、IngressとGateway API、NetworkPolicy、PV/PVCとStorageClass、バックアップ。外から届く経路と、消えないデータを設計します。
10/23（金）公開予定可用性、RBAC、イメージ管理、監視、オートスケール、コスト、アップグレード、障害対応、マネージドサービスの選び方。本番導入チェックリスト付き。
10/24（土）公開予定Dockerを触ったことがある人向けに、「Dockerで言えば何に近いか」も添えました。たとえは理解の足場であって厳密な対応ではありません。各章で正確な意味に置き換えていきます。
| 用語 | ひとことで言うと | Dockerで言えば（たとえ） |
|---|---|---|
| Cluster | Kubernetesが管理するマシン全体のまとまり | Dockerが動くマシンが複数台集まって、1つの基盤として見えるもの |
| Control Plane | 司令塔。「こうしたい」を受け取り、どこで動かすかを決め、ずれを直し続ける側 | Dockerにはない。docker compose up を読んで動かす側が、常駐して複数台を見ているイメージ |
| Node | Podを実際に動かすマシン（物理でも仮想でも） | Dockerデーモンが動いている1台 |
| Pod | コンテナを1つ以上まとめた最小の実行単位。IPはPodごとに付く | docker run で起動した1つのコンテナ（＋同じネットワークを共有する相棒） |
| Deployment | 「このイメージのPodを何個」を宣言し、更新とロールバックも面倒を見る | composeの services に replicas と更新手順が付いたもの |
| Service | 入れ替わるPodの前に立つ、固定の名前とIP | composeでサービス名で名前解決できる仕組み＋ロードバランサー |
| Manifest | 望ましい状態を書いたYAMLファイル | docker-compose.yml に近い |
| Label | 選び出すための「キー=値」のタグ。ServiceはLabelでPodを探す | docker run --label |
| Namespace | リソースを論理的に区切る箱。ただし強いセキュリティ境界ではない | composeのプロジェクト名で区切るイメージ |
| Reconciliation | 「こうしたい」と「今こう」の差を、Controllerが埋め続ける処理 | restart: always の考え方を、台数や配置まで広げたもの |
📌 読み方のコツ: 新しい用語に出会ったら「図1のどこにいるか」「誰に何を頼むものか」の2つを確認してください。それが答えられれば、暗記は要りません。
この特集のYAMLは学習用で、壊してよい環境で試す前提です。本番クラスターで練習するのは、Node台数、ロードバランサー、ディスク、ログの料金がかかるのと、誤って本番に適用する事故を避けるためにおすすめしません。
どれか1つで十分です。いずれも公式のセットアップ手順に従ってください。環境によってIngress、LoadBalancer、永続ボリュームの挙動が変わります。その差は各章で注記します。
| 環境 | 向いている人 | 特徴 |
|---|---|---|
| kind | Dockerが入っていて、軽く始めたい | Dockerコンテナの中にKubernetesのNodeを作る。作り直しが速い |
| minikube | アドオンで色々試したい | Ingressやダッシュボードをコマンド1つで追加できる |
| Docker Desktop | すでにDocker Desktopを使っている | 設定画面でKubernetesを有効にするだけ。1ノード構成 |
次の4つがエラーなく返れば、第1章から読み始められます。kubectl はAPI Serverに話しかけるクライアントです。最初の1行で「いまどのクラスターに向いているか」を必ず確認する習慣をつけてください。本番と学習環境を取り違える事故は、これで防げます。
# いまどのクラスターに向いているか（本番と間違えないために毎回）
kubectl config current-context
# API Serverに届いているか
kubectl cluster-info
# 作業者（Node）は何台か。STATUSがReadyならOK
kubectl get nodes
# 全Namespaceの Pod を眺める。Kubernetes自身のPodが見えるはず
kubectl get pods -A特集全体を通して、状態を読む順番はいつも同じです。「リソースが存在するか」→「PodがReadyか」→「Serviceにエンドポイントがあるか」→「イベントに警告が出ていないか」。この順で kubectl get、describe、logs を使っていきます。
ゴールは「資格試験に受かる知識」ではなく、ブラウザ向けのWebアプリを例に、次のことを自分の手で説明しながらできる状態です。
単一のWebサービスや少数の定期ジョブなら、AWS ECSやCloud Runのようなマネージドコンテナ実行基盤の方が、運用負荷、費用、学習コストに合うことがよくあります。この特集を読み終えたとき「うちはまだKubernetesでなくていい」と判断できたなら、それは理解できたという証拠です。技術選定では機能の多さではなく、必要な可用性、変更の頻度、チームの当番体制を比べてください。第5章で、この判断の軸を表にして整理します。
特集は公式ドキュメントの代わりではありません。各章の説明で気になった箇所は、必ず一次情報で確かめてください。
※本特集の記述は2026年10月時点の公式ドキュメントに基づきます。Kubernetesはおよそ4か月ごとにマイナーバージョンが出るため、コマンドやAPIの詳細は公式のバージョン別ドキュメントで確認してください。
🔖 明日10月20日（火）、第1章「Kubernetesの基礎」を公開します。 このページをブックマークして、明日また来てください。ページ上部のブックマーク案内からURLをコピーできます。
「うちはKubernetesが要るのか」「ECSやCloud Runで足りるのか」から、
クラスター設計・運用体制づくりまで、30分の無料相談で承ります。