Kubernetesが大規模コンピューティングを支配するまで：第2回 ― なぜKubernetesが業界標準になったのか
本シリーズの第1回では、コンテナが実用的な選択肢となる直前の分散コンピューティングの状況を見てきました。今回は、その後の展開を現在まで追っていきます。
Dockerプロジェクトによって「コンテナ」という言葉が広く知られるようになりましたが、その考え方の起源は、一般的に2000年にFreeBSDがリリースした「Jails（ジェイル）」という機能までさかのぼります。この機能自体も、さらに古いUnixの「chroot」という仕組みに基づいています。chrootは、特定のディレクトリをプロセスのルートディレクトリとして定義し、その外側のファイルシステムへのアクセスを禁止することで、プロセスを隔離する技術です。しかし、Jailsは広く利用されるには機能が十分ではなく、他のオペレーティングシステムでも実装されませんでした。
2008年初頭、LinuxカーネルにはGoogleが2006年に開発したcgroups（control groups）が組み込まれました。この機能により、管理者はカーネルレベルでプロセスを分離し、メモリやCPU使用量を制限するなど、さまざまなプロセス管理を行えるようになりました。QEMUやXENをはじめとする多くの仮想化ツールがcgroupsを採用し、仮想化技術は徐々に発展していきました。
そして2013年が大きな転換点となります。この年にDockerとKubernetesの両方が誕生したのです。2013年3月にはDockerが正式に発表されました。またGoogleは同年夏にコンテナオーケストレーションプラットフォームについて言及し、2015年7月にKubernetesをリリースしました。
Dockerはまさに時代の要請から生まれた存在でした。Linux上で動作し、開発者や管理者にとって馴染み深いLinuxライクなコマンド体系を採用しています。
他の現代的な管理ツールと同様に、Dockerは設定ファイルをもとにイメージを作成します。多少の複雑さもあり、例えばビルドは2段階で行われます。第1段階ではインスタンスをコンパイルするためのツール一式を用意し、第2段階では実行に必要な最小限の環境だけを含めます。それでもプロセス全体は比較的シンプルであり、現代のソフトウェア開発に求められる継続的な更新に対応した迅速な再ビルドを可能にしています。
Docker、そしてその後のKubernetesによって、分散コンピューティングにおける「ちょうどよい落としどころ（sweet spot）」が埋められました。しかし、分散コンピューティングには数多くの管理タスクが伴います。Kubernetesの開発者たちは、そのすべてを自ら解決しようとはしませんでした。新たなCORBA、DCE、あるいはOpenStackを作るつもりはなかったのです。その代わり、後から登場する解決策が生まれやすい基盤を整えました。
それでは、どのようなツールが必要だったのでしょうか。
オーケストレーションの役割
「オーケストレーション」という言葉は、しばしば「ガバナンス」と同様に、分散環境における管理タスク全般を指す抽象的で少し難解な用語として使われます。
分散コンピューティングにおいて、開発者や管理者が実行しなければならない主なタスクには次のようなものがあります。
自動スケーリング
多くのアプリケーションでは、アクセス負荷が急激に変動します。特にWebサイトでは、一度に大量のリクエストが集中することがあります（これは何十年も前から「SlashDot効果」として知られています）。
分散システムは、トラフィックの増加を検知すると必要に応じてクラウド上に新しいノードを追加し、不要になれば迅速に解放する必要があります。
自動再起動と状態維持
負荷を処理するために30台のノードが必要だと判断した場合、1台が障害を起こせば代替ノードを立ち上げなければなりません。
理想的には、障害（ソフトウェアのバグ、ネットワーク切断、ハードウェア故障など）が発生した際には管理者に通知され、根本原因が修正されます。しかし、その間も分散システムは自動的に同一のインスタンスを起動し、システムの望ましい状態を維持しなければなりません。
ロードバランシング
通常、独立したプロキシが使用され、ワーカーノードへ公平にリクエストを振り分けます。
サービスディスカバリー
専用のDNSサーバーやその他の仕組みを通じて、各ノードは依存しているサービスを見つけられる必要があります。
ローリングアップデート
これは、現代のコンピューティングにおけるもう一つの重要な要素である「頻繁で段階的なソフトウェア更新」に関わるテーマです。
ユーザーからの既存のリクエストを処理し続けながら各ノードを更新したい場合、分散システムはアイドル状態のノードを順次停止して新しいノードに置き換え、最終的にすべてのノードを最新状態へ移行できる必要があります。
さらに、これらのタスクにはログ管理、監視、アラート通知など、多くの自動化機能が求められます。
Kubernetesという巨大な存在
Dockerが初めてリリースされてから1年半後の2014年11月、前述した機能をすべて提供するSwarmのバージョン1.0がリリースされました。
Swarmは一定の人気を集めましたが、業界のKubernetesへの熱狂を抑えることはできませんでした。現在では、主にテスト用途や小規模プロジェクト向けの選択肢として見られています。
現在でもDockerはコンテナイメージを作成する重要なツールとして利用されていますが、その多くはKubernetes上で実行されています。
2018年には、Red HatがDockerのほぼ代替となるPodmanを開発しました。Podmanの大きな魅力は、ホストシステム上でroot権限を必要とせず、ユーザーモードで動作する点です（Dockerも「rootless mode」で動作できますが、機能や性能に制限があります）。
PodmanはDockerとのアーキテクチャの違いからSwarmには対応しておらず、「Podman Swarm」が登場することもありません。スケーリングやその他のオーケストレーション機能については、Podmanの開発者もKubernetesを利用しています。
（Red Hatは戦略を全面的にKubernetesへシフトしています。PodmanをはじめとするKubernetes関連ツールを多数開発しているだけでなく、自社の主要製品であるOpenShiftクラウドもKubernetesを基盤としています。）
Kubernetesの強力さを示す例のひとつが、Persistent Volume（永続ボリューム）機能です。
コンテナ（また、仮想マシンやFaaSインスタンスも同様）は一時的な存在であり、サービス全体に影響を与えることなく消滅することを前提に設計されています。そのため、顧客情報など保存が必要な状態データや、後続のプログラムで利用するデータはコンテナ外部に保存する必要があります。
Persistent Volumeは、このニーズを非常に洗練された形で満たしており、Kubernetesと密接に統合されています。
私は、Kubernetesの成功は、莫大なリソースを持つGoogleによる積極的な取り組みと、絶妙なタイミングにあったと考えています。
GoogleはKubernetesを社内プロジェクトを基に開発しました。非常に大きな投資を行っていたため、経営陣はオープンソース化に慎重でした。しかし、最終的に決め手となったのは次の認識だったようです。
「顧客は大量のCPUに対して料金を支払っているが、仮想マシンを利用しているため、その利用率は極めて低い。」
つまりGoogleは、信頼できる強力なオーケストレーションツールを無償かつオープンソースで提供すれば、自社クラウドビジネスを大きく拡大できると判断したのです。
実際、Cloud Foundry（VMwareが2009年に立ち上げたオープンソースプロジェクト）をはじめ、あらゆるPaaSベンダーが、自社サービス上でコンテナを実行するための基盤としてKubernetesを歓迎しました。
Androidと同様に、業界ではGoogle製品には継続的なサポートが期待されています。一方で、オープンソースであることは、誰かがソフトウェアを取り上げたり、利用者のニーズに反する方向へ開発を強制したりできないという信頼につながります。
しかしGoogleは、多くの企業のようにソフトウェアを公開して終わりにはしませんでした。リリースからわずか1年後の2015年7月、Googleはオープンソース界のもう一つの巨人であるLinux Foundationと提携し、ベンダーニュートラルなCloud Native Computing Foundation（CNCF）を設立しました。
CNCFにはコンピューティング業界のほぼすべての主要企業が参加しており、多数の管理ツールを育成するインキュベーターの役割を果たしています。
ここでいう「クラウド」という言葉は限定的な意味で使われています。彼らが対象としているのは仮想マシンではありません。その活動のほとんどはKubernetesに向けられています。
また、Red HatやCNCFが多大なリソースを投入しなくても、コミュニティはKubernetesの複雑な運用を容易にするためのツール群を次々と生み出していたでしょう。
もし「K」で始まるソフトウェア名を耳にしたなら、その多くはKubernetes向けのツールだと考えてよいでしょう。（デスクトップ環境のKDEも同じ命名規則ですが、用途が大きく異なるため混同することはほとんどありません。）
まとめ
数多くの競合プロジェクト（プロプライエタリ、オープンソースを問わず）が存在する中で、Kubernetesは絶妙なタイミングで登場し、現実の顧客ニーズに応え、強力な組織の支援を受けたことで勝者となりました。
また、そのオープンソースライセンスと活発なコミュニティ活動は、Kubernetesを現代コンピューティングにおける最も重要なプロジェクトのひとつへと押し上げる決定的な要因となっています。
