mozumasu 教室Kubernetes 解体新書

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

コンテナと Kubernetes の歴史

コンテナ、Docker、Kubernetes は、何を解決するために生まれたのでしょうか。年表を動かして流れをたどります。

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

コンテナの仕組みは、Docker が登場する前から少しずつ作られていました。 それをアプリの作成・配布・起動に使いやすくまとめたのが Docker です。 さらに、複数のマシンでコンテナを動かし続ける道具として Kubernetes が登場しました。

この章では、年表を動かしながら「何に困って、どんな道具が生まれたか」をたどります。 年号を覚えるより、前の道具で足りなかったものが次の道具につながる流れを見てください。

GOAL この章のゴール

  • Docker が使いやすくしたことを、Linux の機能と区別できる
  • Kubernetes が生まれた背景を説明できる
  • 公開後の Kubernetes を誰が開発・支援しているか分かる

年表を動かす

まず全体を眺めます。 スライダか再生ボタンで動かしてください。 点をクリックしても選べます。

19801990200020102020Docker 公開 (dotCloud)

Docker2013.3

Docker 公開 (dotCloud)

PyCon のライトニングトークで披露され、同じ月の 3 月 20 日にオープンソースで公開。レイヤー化したイメージ、レジストリ、1 行の CLI を一つに束ねた。

  • Linux / 隔離技術
  • Docker
  • Kubernetes
  • その他
  • クラウド

8/222013.3 Docker 公開 (dotCloud)

2014 年以降の行には、CRI や kube-proxy のような Kubernetes の部品の名前が出てきます。 どれも 5 章以降で説明するので、今は「そういう出来事があった」と読み流して構いません。

色の違いは、カーネル側の隔離技術、Docker、Kubernetes、クラウド、その他、の 5 種です。 前半はカーネル側ばかりで、2013 年から Docker と Kubernetes が交互に出てくることが見て取れます。

デプロイの 3 つの時代

1 台の物理サーバーに複数のアプリを置くと、あるアプリが CPU を多く使ったときに、ほかのアプリも遅くなることがあります。 アプリごとにサーバーを分ければ影響を分けやすくなりますが、空いている CPU やメモリも増えがちです。

この問題に対して、アプリを分ける単位がどう変わったかを見ます。

次の仮想化の時代では、1 台の物理サーバーの上に複数の VM を置き、アプリを VM ごとに隔離しました。 EC2 はこの時代の延長にあります。 代わりに、「各 VM は自分の OS を含む全部の構成要素を持つ完全なマシン」なので、VM ごとに OS を丸ごと動かす分のオーバーヘッドが生じました。 コンテナの時代は、「アプリの間で OS を共有するように隔離を緩めた」方法として現れました。 1 章で見た違いが、時代の流れとして位置づけられます。

コンテナは昔からあった

1979 年の Version 7 Unix に入った chroot は、前の章で見た通り、プロセスのルートディレクトリを差し替えるシステムコールです。 V7 のマニュアルには chdir と並んで「chroot はルートディレクトリ、すなわち / で始まるパス名の起点を設定する。スーパーユーザーだけが呼べる」とあり、隔離の道具としては書かれていません。 2000 年 3 月の FreeBSD 4.0 は「安全なプロセス実行環境を作るための柔軟性を増す」ものとして jail システムコールを加え、ここにプロセスとネットワークの隔離が足されました。 Sun は 2004 年 11 月の LISA ’04 で Solaris Zones を発表し、2005 年の Solaris 10 に入れています。

Linux 側では、2002 年 8 月の 2.4.19 で mount namespace が入りました (mount_namespaces(7) の HISTORY に「Linux 2.4.19」とあります)。 2006 年 9 月に Google のエンジニアが「Containers」という名前でリソース制御の仕組みを Linux に提案し、翌年「control groups (cgroups)」に改名されて、2008 年 1 月の 2.6.24 に入りました。 同じ 2.6.24 で PID namespace と、ネットワーク namespace の基本部分も入っています。 そして同じ 2008 年の 8 月に、これらをまとめて「コンテナ」として扱うユーザー空間ツールの LXC 0.1.0 が出ています。

ここまでで、前の章の 4 コマのうち「見える世界の分離」「root の入れ替え」「使える量の制限」は揃っています。 Docker が出るまで、まだ 5 年あります。

なぜ 2013 年の Docker で広まったのか

2013 年に揃っていた部品と、Docker が足したもの下段に 2013 年時点で既にあった部品 (namespace、cgroups、AUFS、LXC)。上段に Docker が足した 4 つ (イメージ形式、レジストリ、1 行で動く CLI、Dockerfile)。Docker が足したもの (2013)レイヤー化イメージ差分の tar + 共有レジストリpush / pull で配るdocker run 一発覚えるコマンドが 1 つDockerfile手順がコードに組み合わせて使ったすでにあった部品 (〜2008)namespace2002 (mount) 〜 2008 (pid / net)cgroups2008 (Linux 2.6.24)AUFSカーネル外の union FSLXC2008部品は揃っていた。「作って、配って、動かす」を 1 本の体験にしたのが Docker。
図 12013 年に揃っていた部品 (下) と、Docker が足したもの (上)。部品は新しくなく、束ね方が新しかった。

Docker は、dotCloud という PaaS の会社が社内の実行基盤を切り出したもので、2013 年 3 月の PyCon でのライトニングトークで披露され、同じ月の 3 月 20 日に最初のバージョンが公開されました。 LWN の記事が書くように「最初期の Docker は実際には LXC のラッパー」で、コンテナを作る部分は LXC に任せていました。 Docker 自身が足したのは次の 4 つです。

  1. レイヤー化されたイメージ。AUFS を使って、ファイルシステムの差分を層として積み、共有できるようにした。
  2. レジストリ。イメージを push / pull で配る場所を用意し、2014 年 6 月に Docker Hub として公開した。
  3. docker run 一発。LXC の設定ファイルを書かずに、1 行でコンテナが動く CLI。
  4. Dockerfile。イメージを作る手順をコードとして残せるようにした。

つまり Docker の発明は「作って、配って、動かす」を 1 本の体験にしたことです。 LXC を使っていた人は、イメージを自分で tar に固めて scp していました。 Docker はそこを docker push / docker pull にしました。 イメージの配布と起動を短いコマンドで試せるようになりました。 2014 年 3 月の Docker 0.9 で LXC は「任意の実行ドライバー」に格下げされ、自前の libcontainer で namespace と cgroups を扱うようになりました。 この libcontainer が、2015 年 6 月に OCI (Open Container Initiative) へ寄贈されて runc になります。

Kubernetes が Google の手を離れるまで

Kubernetes の出自: Google 社内の Borg の運用知見を、Docker を使った OSS として外に出し、CNCF に移管した左に Google 社内の Borg (2003〜)。中央に 2014 年の Kubernetes 公開 (Docker)。右に 2015 年の CNCF 移管とコミュニティ主体の開発。Borg (Google 社内)10 年以上の運用、論文は 2015Pod / Service / Label / IP-per-PodKubernetes (2014.6)Borg の開発者が設計Docker のコンテナを使う「API に書いた状態を維持し続ける」設計1.0 と同時CNCF (2015.7)Linux Foundation 傘下Google の手を離れSIG ごとのコミュニティ開発へBorg から受け継いだのは考え方と 4 つの機能。コードは新しく Go で書かれた。
図 2Borg の運用知見をもとに Kubernetes が作られ、1.0 と同時に CNCF が発足して移管された。

Google は Borg という社内のクラスタ管理基盤を、2015 年の時点で「10 年以上」運用していました。 その 2015 年 4 月に Borg の論文 (EuroSys 2015) が公開され、Kubernetes のブログは「Kubernetes は Borg の直系の子孫で、Kubernetes を作っている開発者の多くは元 Borg の開発者である」と書いています。 Docker が広まった 2014 年 6 月、Google は Kubernetes を「コンテナをマシン群にデプロイする、無駄のない強力なオープンソースのコンテナ管理ツール」として公開しました。 コンテナの実行には Docker を使い、「API に書かれた状態を正として、基盤上でその状態を維持し続ける」設計です (5 章で中身を見ます)。 同じブログは、Borg から受け継いだ 4 つの機能として、Pod (Borg では alloc)、Service (名前付けと負荷分散)、Label、Pod ごとの IP を挙げています。 この設計は 2026 年でも変わっていません。

2015 年 7 月 21 日、Google は Kubernetes 1.0 のリリースを発表し、同じ発表の中で「Linux Foundation と業界のパートナーと共に Cloud Native Computing Foundation (CNCF) を設立する」と述べています。 Kubernetes は CNCF の最初のプロジェクトとして移管されました。 以降の開発は、SIG と呼ばれる分野ごとのグループで、複数の会社のメンバーが行っています (7 章「Kubernetes の 3 つの顔」で扱います)。 Google が公開したことから Google の製品だと思われることがありますが、1.0 以降の持ち主は CNCF で、Google はコントリビューターを多く出している会社の 1 つです。 CNCF は 2018 年 3 月に Kubernetes を最初の「graduated」プロジェクトと認定しています。

Docker と Kubernetes の距離

Kubernetes は最初 Docker で動くことを前提に作られましたが、その後、Docker 以外のコンテナランタイムも使えるように作り替えられました。 2016 年 7 月の 1.3 で CoreOS の rkt が使えるようになり、同年 12 月の 1.5 で kubelet とランタイムの間のインターフェース (CRI) が alpha として入っています。 2020 年には「Kubernetes が Docker を非推奨にした」と騒がれた出来事もあります。 この経緯は、Kubernetes がノードの上でコンテナをどう起動しているかを知ってからのほうが追いやすいので、5 章の終わりで扱います。

読み方の注意

年表は「何がいつ出たか」を並べますが、「いつ主流になったか」は別です。 Docker 以外のランタイムを選べる仕組みは 2016 年に出ましたが、kubelet が Docker 経由で動く道が閉じたのは 2022 年の 1.24 です。 クラスタの外からの通信を受ける新しい API の Gateway API は 2023 年 10 月に v1.0 (GA) になりましたが、従来の Ingress を使い続けているクラスタは 2026 年現在も多くあります。 kube-proxy の nftables モードも 2025 年 4 月の 1.33 で GA になりましたが、互換性のため既定は iptables のままです。 公開や安定版の登場と、現場での普及は分けて読んでください。 移行にかかる時間は、互換性や運用方針によって変わります。

ふりかえり

QDocker が 2013 年に足したものとして正しいのは?

カーネルの機能は 2008 年までに揃っていました。Docker は「作って、配って、動かす」を 1 本にしました。分離は VM より弱く、1 章で見た通りカーネルを共有します。

QKubernetes の開発を主導しているのは?

2015 年の 1.0 と同時に CNCF に移管され、以降は複数の会社のメンバーが SIG ごとに開発しています。

QKubernetes 1.0 のリリースと同じ日に起きたことは?

2015 年 7 月 21 日の 1.0 と同時に CNCF の設立が発表され、Kubernetes はその最初のプロジェクトになりました。containerd の寄贈は 2017 年 3 月です。

参考