mozumasu 教室Kubernetes 解体新書

Kubernetes 解体新書Part 1 Kubernetes の全体像

Kubernetes の 3 つの顔

アプリを動かす人、クラスタを運用する人、機能を足す人。それぞれの視点から Kubernetes を見直します。

  • L0 ブラウザだけ
  • 更新 2026年10月6日

アプリを公開したい人と、クラスタを運用する人では、Kubernetes の気になる部分が違います。 前者はアプリの更新方法を、後者はノードの故障やデータのバックアップを考えます。 さらに、Kubernetes に自分たちの機能を足す人もいます。

この章では、この 3 つの立場から Kubernetes を見直します。 開発コミュニティの分担と、機能を提案したり追加したりする仕組みも見ていきます。

GOAL この章のゴール

  • アプリの利用者、クラスタの運用者、機能の開発者の視点を区別できる
  • Kubernetes の開発や機能提案の進め方が分かる
  • 独自のリソースと controller で機能を追加する仕組みが分かる

3 つの顔

Kubernetes の 3 つの顔: コンテナオーケストレーター、分散システム、プラットフォームのためのプラットフォーム3 つの箱が横に並ぶ。それぞれの顔の特徴を 3 行ずつ。Container Orchestrationアプリを動かす人から見た顔自己修復ロールアウトとロールバック水平スケール、空き資源を見た配置名前解決と負荷分散設定と秘密情報の管理Part 1 の視点Distributed Systemクラスタを運用する人から見た顔Raft で合意する etcd (要バックアップ)apiserver を中心にしたハブアンドスポーク落ちても続きから動く controllerコンポーネント単位の冗長化分野ごとに分かれた小さな部品Part 2・3 の視点Platform for Platforms機能を足す人から見た顔CRD で新しいリソースを足す自作 controller (Operator)CRI / CNI / CSI / CPI の差し替え「PaaS ではなく、部品を提供する」フォーク不要で機能を足せる設計Part 4・5 の視点同じ 1 つのソフトウェアを、誰が見るかで 3 通りに説明できる。
図 1Kubernetes の 3 つの顔。同じ 1 つのソフトウェアを、誰が見るかで 3 通りに説明できる。

1 つ目は、アプリを動かす人から見た顔です。 この Part でここまで見てきた内容は、ほぼすべてここに入ります。 複数のノードに Pod を配置し、落ちたら作り直し、Service で名前を与え、Deployment で入れ替える。 Kubernetes のドキュメントは、この顔の機能として、サービスディスカバリとロードバランシング、自動化されたロールアウトとロールバック、自動のビンパッキング (空き資源を見た配置)、自己修復、設定と秘密情報の管理、水平スケールを挙げています。 ECS や Nomad も、この顔を持っています。

ただし、同じドキュメントは「Kubernetes は単なるオーケストレーションシステムではない」とも書いています。 オーケストレーションの技術的な定義は「決められた手順の実行 (まず A、次に B、次に C)」であるのに対し、Kubernetes は、互いに独立した制御プロセスの集まりが、現在の状態をあるべき状態に向けて動かし続ける仕組みだ、という説明です。 5 章で見た reconciliation loop のことで、A から C にどう辿り着くかは問わない、という設計です。 「オーケストレーター」と呼ばれていても、中ではそれぞれの担当が状態を見て動いています。

2 つ目は、クラスタを運用する人から見た顔です。 全オブジェクトは etcd に置かれ、etcd は複数のサーバーが Raft という合意アルゴリズムで同じ内容を保つ分散データベースです。 Kubernetes のドキュメントは、etcd を「クラスタの全データの保存先」と呼び、定期的なバックアップを取ることを運用者に求めています。 各コンポーネントは apiserver だけを見て動くので、どれが落ちても再起動すれば続きから再開できます。 ノードの故障や、管理情報を失ったときの復旧を考えるのが、この立場です。 クラスタを自分で組む人、障害対応する人に見え、Part 2 と Part 3 でノードの中に入るときに見えているのもこの顔です。

3 つ目は、機能を足す人から見た顔です。 Kubernetes のドキュメントは、Kubernetes を「高度に設定可能で拡張可能」で、「フォークやパッチの提出が必要になることは滅多にない」と説明しています。 新しいリソースの種類 (CRD) と、それを見張る controller を足せます。 ランタイム、ネットワーク、ストレージ、クラウド連携は、CRI / CNI / CSI / CPI というインターフェースで差し替えられます。 Cluster API (クラスタ自体を Kubernetes のリソースとして作る)、Argo CD (Git の YAML をクラスタに適用し続ける)、cert-manager (証明書を発行する)、Cilium (ネットワークを担当する) はどれも、この拡張の仕組みを使って機能を足したソフトウェアです。 「Kubernetes の上に自社のプラットフォームを作った」という人は、この顔を見ています。 Part 4 と Part 5 で扱うのはこの顔です。

3 つの顔は、同じソフトウェアをどの立場で触るかによる見え方の違いです。 アプリを置くだけなら 1 つ目で足り、クラスタを運用するなら 2 つ目が、クラスタの上に道具を作るなら 3 つ目が見えてきます。

Kubernetes がしないこと

3 つ目の顔を理解するには、Kubernetes が「自分ではやらない」と決めていることを知っておくと早いです。 Kubernetes のドキュメントには「Kubernetes でないもの」という節があり、Kubernetes は「従来の、何でも入りの PaaS ではない」と書かれています。 具体的には、次のことをしません。

  • ソースコードのデプロイやビルドはしない (CI/CD の流儀は組織が決める)。
  • ミドルウェア (メッセージバス)、データ処理基盤 (Spark)、データベース (MySQL)、キャッシュ、クラスタストレージ (Ceph) のようなアプリケーションレベルのサービスを、組み込みでは提供しない。
  • ログ、監視、アラートの方法を指定しない。
  • 設定言語 (Jsonnet など) を提供も強制もしない。
  • マシンの設定、保守、管理の仕組みを提供しない。

その代わりに、同じ節は「Kubernetes は開発者向けプラットフォームを作るための部品 (building blocks) を提供する」と書いています。 Kubernetes 自身は一枚岩ではなく、既定の部品は任意で差し替え可能だ、という位置づけです。 3 つ目の顔は、この設計方針から出てきます。

誰が作っているのか

Kubernetes の組織: Steering Committee の下に分野ごとの SIG があり、横断的な課題は WG が扱う。CNCF は外側でホスティングする上に CNCF と Steering Committee。中央に 5 つの SIG。下に WG (横断) と、各 SIG の中にサブプロジェクトがある注記。CNCF (Linux Foundation の一部)プロジェクトのホスティング、適合性の認定 (Certified Kubernetes)Kubernetes Steering Committeeプロジェクト全体の統治SIG Nodekubelet / CRISIG NetworkService / CNI / Ingress / DNSSIG StoragePV / CSISIG Cloud Provider各クラウドとの連携SIG Docs / Release文書 / リリース (24 SIG の一部)WG (Working Group): SIG をまたぐ話題を扱う (例: WG Batch、WG Device Management、WG AI Gateway)決定は担当の SIG が行い、長引いたときだけ Steering Committee に上がる。各 SIG は複数の会社のメンバーからなり、サブプロジェクトを持つ。
図 2Kubernetes の組織。Steering Committee の下に分野ごとの SIG があり、横断的な課題は WG が扱う。CNCF は外側でホスティングする。

3 章で見た通り、Kubernetes は 2015 年の 1.0 と同時に CNCF に移管され、以降はコミュニティが開発しています。 その開発組織の単位が SIGシグSpecial Interest Group。Kubernetes の分野ごとの開発グループ。SIG Node、SIG Network、SIG Storage など 24 個ある。各 SIG は複数の会社のメンバーで構成され、設計の決定はここで行われる。用語集で見る です。 コミュニティの統治文書は、「Kubernetes プロジェクトは主に SIG に組織されている」「各 SIG は複数の会社や組織のメンバーからなり、ネットワークやドキュメントのような特定の話題についてプロジェクトを前に進める」と書いています。 プロジェクトのあらゆる部分 (リポジトリ、ディレクトリ、API、テスト) は、どれかの SIG が所有する、という原則です。

2026 年 10 月時点で SIG は 24 あります。 SIG Node は「Pod とホストの資源とのやりとりを支えるコンポーネント」 (kubelet と CRI)、SIG Network は Pod のネットワーク、Service、Ingress、DNS、NetworkPolicy、SIG Storage は PV と CSI、SIG Cloud Provider は各クラウドとの連携、SIG Scheduling は「Pod の配置を決めるコンポーネント」を担当します。 ドキュメント (SIG Docs) やリリース (SIG Release) も SIG です。 各 SIG は憲章 (charter) で担当範囲と決め方を定め、Steering Committee がそれを承認します。 SIG をまたぐ短期の話題は、Working Group (WG) が扱います。 2026 年 10 月時点では WG Batch、WG Device Management、WG AI Gateway など 9 つがあります。 担当する SIG が決定を持ち、議論が長引いたときだけ Steering Committee に上げる、という順序です。

CNCF は、その外側にある財団です。 Linux Foundation の一部で、Kubernetes を含む 200 を超えるプロジェクトをホストしています。 プロジェクトには sandbox、incubating、graduated の成熟度があり、Kubernetes は 2018 年 3 月に最初の graduated プロジェクトになりました。 containerd (2019 年)、Cilium (2023 年) も graduated です。 rkt のように、活動が止まってアーカイブされたプロジェクトもあります (2019 年 8 月)。 CNCF は設計の判断を SIG に任せていて、口を出しません。

機能が入るまで

機能が入るまでの流れ: KEP を SIG が承認し、alpha、beta、GA の順に昇格する。年 3 回のリリースで進む左から KEP (提案)、担当 SIG の承認、alpha (既定で無効)、beta (機能は通常、既定で有効)、GA (常に有効)。下に nftables kube-proxy の例と、年 3 回のリリースの注記。KEP提案書 (provisional)担当 SIG が承認implementable にalpha既定で無効beta機能は通常、既定で有効GA常に有効、API は v1例: kube-proxy の nftables モードは 1.29 で alpha、1.33 (2025 年 4 月) で GA。beta と GA の間は通常 2 リリース以上空ける。リリースは年に約 3 回。各 minor は約 14 か月 (12 か月 + 保守 2 か月) パッチを受け取る。
図 3機能が入るまでの流れ。KEP を担当 SIG が承認し、alpha、beta、GA の順に昇格する。

新しい機能は KEPケップKubernetes Enhancement Proposal。機能追加の提案書。担当 SIG が承認し、alpha から GA までの昇格基準を定める。1 つの KEP が 1 つの機能の一生に対応する。用語集で見る という提案書から始まります。 KEP は「新しい取り組みを提案し、伝え、調整するための方法」で、ささいな変更を除くほとんどの新機能に必須です。 提案者はまず担当の SIG に相談し、SIG がその KEP を所有します。 KEP には provisional (提案され、定義中)、implementable (承認者が実装を承認した)、implemented (実装済み) の状態があり、承認者は影響を受ける SIG から選ばれます。

承認された機能は、alpha、beta、GA の 3 段階を進みます。 alpha は既定で無効で、feature gate (各コンポーネントの --feature-gates フラグ) で有効にします。 予告なく削除されることもあります。 beta の機能は通常、既定で有効になり、十分にテストされた状態です。 GA (stable) は常に有効で、feature gate は不要になります。 1 つの KEP が alpha から GA まで通しで対応し、beta から GA に進むために新しい KEP は要りません。 beta と GA の間は通常 2 リリース以上空けます。 利用者からの報告を受ける期間が必要だからです。 2021 年の 1.21 以降は、本番で安全に運用でき、無効化や切り戻しができるかを別のチームが審査する Production Readiness Review を通らないと、リリースに入れません。

リリースは年に約 3 回です。 各 minor バージョンは約 14 か月 (12 か月の通常サポートと 2 か月の保守期間) パッチを受け取り、同時に直近 3 つの minor が保守されます。 2026 年 10 月時点の最新は 1.37 で、この教材のクラスタも 1.37.1 です。 「この機能はいつから使えるか」は、KEP のページを見れば alpha / beta / GA の予定バージョンが書いてあります。 この教材で「1.33 で GA」のように書いているのは、この段階の話です。

CRD と controller で機能を足す

拡張前提の API: CRD で新しいリソースの種類を足し、自作の controller がそれを reconcile する。組み込みのリソースと同じ仕組みで動く中央に kube-apiserver。左に組み込みリソース (Deployment) と kube-controller-manager。右に CRD で足した Certificate と、それを見張る cert-manager。両者とも apiserver を watch する同じ形。kube-apiserver組み込みも CRD も同じ REST / watch同じ RBAC、同じ kubectl組み込みkind: Deploymentapps/v1kube-controller-managerDeployment controllerapplywatch拡張 (CRD + controller)kind: Certificatecert-manager.io/v1 (CRD)cert-manager自作の controller (Operator)applywatch形が同じなので、Cluster API、Argo CD、Cilium の CRD も全部この方式。「Kubernetes の上に Kubernetes 風の何か」を作れる。
図 4CRD で新しいリソースの種類を足し、自作の controller がそれを reconcile する。組み込みのリソースと同じ仕組みで動く。

3 つ目の顔を支えているのが CRDシーアールディーCustomResourceDefinition。apiserver に新しいリソースの種類を登録する仕組み。登録すると kubectl、RBAC、watch、etcd への保存が組み込みのリソースと同じように使える。用語集で見る です。 Kubernetes のドキュメントは、カスタムリソースを「既定の Kubernetes には必ずしも無い、Kubernetes API の拡張」と定義し、「導入すると、利用者は Pod のような組み込みリソースと同じように kubectl でそのオブジェクトを作成し、参照できる」と説明しています。 kind: Certificate のような新しい種類を apiserver に登録すると、kubectl get certificates が使えるようになり、RBAC で権限を絞れ、etcd に保存されます。 自分で API サーバーを書く必要はありません。

ただし、CRD だけでは「構造化されたデータの保存と取り出し」ができるだけです。 「Certificate が作られたら証明書を発行する」という実際の動作は、Certificate を watch して reconcile する controller (cert-manager) が行います。 Kubernetes のドキュメントは、カスタムリソースと自作の controller を組み合わせたものを Operator と呼び、「Kubernetes 自身のコードを変えずに、controller をカスタムリソースに結びつけてクラスタの振る舞いを拡張する」パターンだと説明しています。 組み込みの Deployment と Deployment controller の関係と、CRD の Certificate と cert-manager の関係は、形が同じです。 どちらも apiserver を watch し、spec と status の差分を埋めます。 5 章で見た reconciliation loop を、自分のリソースについて書けるということです。 Cluster API は「Kubernetes クラスタ」を CRD にして、クラスタの作成を reconcile します。 この教材の自分専用クラスタも、管理クラスタ上の Cluster API のリソースとして作られています。

CRD のほかに、別の API サーバーを書いて apiserver の背後に束ねる API aggregation という拡張の方法もあります。 CRD では表現できない場合に使う、より重い選択肢です。 インターフェース (CRI / CNI / CSI / CPI) も拡張点ですが、こちらは「kubelet や controller-manager が外部のプログラムを呼ぶ規約」で、CRD とは別の仕組みです。 Part 4 でまとめて扱います。

ふりかえり

Q「機能を足す人」の顔を支えている仕組みはどれ?

CRD と controller による機能の追加と、差し替え可能なインターフェースが 3 つ目の顔です。etcd は運用者の顔、ReplicaSet はアプリを動かす人の顔です。

QKubernetes の設計の決定を行うのはどこ?

決定は担当の SIG が行い、議論が長引いたときだけ Steering Committee に上がります。CNCF はホスティングと認定の財団で、開発には口を出しません。Google は多くのコントリビューターを出している会社の 1 つです。

QCRD で登録したリソースが作られたとき、実際の動作 (たとえば証明書の発行) を行うのは?

apiserver は保存と配信をするだけで、そのリソースで何をするかは知りません。実際の動作は、リソースを watch して reconcile する controller が行います。

参考