解決策
Googleはコンテナが流行する10年前からLinuxコンテナを大規模に運用していた。Borgシステムは最大数万台のマシンからなるクラスタにまたがる数十万のジョブを、宣言的なジョブ仕様言語と、インスタンスが死んだ際の自動再起動・再スケジューリングによって管理していた。
2014年にオープンソース化されたKubernetesは、Borgの教訓をGoogleの外へ持ち出した。共有の永続ストア、バージョニングとバリデーションを備えたドメイン固有のREST API、そしてすべてのオブジェクトに共通するSpec/Status構造である。設計目標は、複雑な分散システムのデプロイと管理を容易にしつつ、コンテナが可能にする利用率の向上を保つことだった。
コントローラは望ましい状態と観測された状態を比較し、その差分に基づいて行動するだけなので、このプラットフォームは本質的に自己修復的かつ拡張可能である。オートスケーラは望ましいレプリカ数の調整だけを行い、それを整合させる仕組みには一切触れない。その一つの抽象化が業界のデフォルトになった。
達成したこと
望ましい状態を宣言する。ループが現実を整合させる
うまくいった理由
宣言的な仕様により、同じYAMLが準拠したどのクラスタでも動き、ポータビリティの負担を取り除いた
統一されたオブジェクトAPIにより、ユーザー、内部コンポーネント、自動化のすべてが同じシステムを動かせる
制御ループにより、ロールアウト、ヘルスチェック、スケーリングが個別のコードではなく一つの仕組みの機能になる
CNCFの下でのオープンソース化により、すべてのベンダーが対等な席を得たため、クラウド大手はロックインではなくサービスで競争した
応用できること
命令的なスクリプトではなく宣言的な契約を提供せよ。ユーザーは何を望むかを述べ、仕組みがどのように実現するかを担う。その契約こそが、Kubernetesをあらゆるクラウドが採用できる抽象化にした。
その後
Kubernetesは事実上のコンテナオーケストレーション標準となった。主要なクラウドはすべてマネージド版を提供しており、CNCFの調査では最も広く使われるプラットフォームの一つに位置づけられている。BorgはGoogleの内部システムとして残っているが、その公開された子孫は業界のソフトウェアデプロイ方法を標準化した。
出典をたどる
出典
- Large-scale cluster management at Google with Borg (abstract) Google Research / EuroSys 2015 · research.google
- Borg, Omega, and Kubernetes ACM Queue · queue.acm.org
- Kubernetes Overview Kubernetes Documentation · kubernetes.io