Kubernetes 史 (Google Borg→K8s・2014-2024)（クバネテス）
Googleの内部システム「Borg」を起源とし、2014年に公開されたコンテナオーケストレーションの世界標準。マイクロサービス基盤として、クラウドネイティブなインフラ管理を定義する。
概要
Kubernetes（K8s）の歴史は、Googleが長年運用してきた大規模分散システム管理技術「Borg」の知見を、外部へ開放したことに始まります。2014年の公開以降、単なるコンテナの実行制御に留まらず、パッケージ管理（Helm）、通信制御（Service Mesh）、そしてインフラの抽象化へとその役割を拡大してきました。現在では、あらゆるクラウドプロバイダーがマネージドサービスとして提供しており、現代のマイクロサービスアーキテクチャにおける「分散型オペレーティングシステム」としての地位を確立しています。
進化の系譜（Milestones）
| 年代 | フェーズ | 主な技術的転換点 |
|---|---|---|
| 2003 - 2014 | Borg Era | Google内部での大規模リソース管理技術の確立。コンテナ概念の原型。 |
| 2014 - 2015 | Birth of K8s | CNCF設立とK8s公開。v1.0によるAPIの安定化とエコシステムの始動。 |
| 2016 - 2018 | Ecosystem Expansion | Helmによるパッケージ管理、Istio等のService Mesh登場による通信制御の高度化。 |
| 2020 - 2022 | Runtime Transition | Docker依存からの脱却（CRI導入）。コンテナランタイムの標準化と軽量化。 |
| 2024 - 2026+ | Modern Cloud Native | Sidecar機能の最適化、AI/MLワークロードへの特化、Wasm（WebAssembly）統合の進展。 |
アーキテクチャ変遷比較
| 特徴 | 初期（Docker中心期） | 成熟期（Service Mesh導入期） | 次世代（AI/Serverless指向） |
|---|---|---|---|
| 管理対象 | 単一コンテナのライフサイクル | サービス間の複雑な通信・信頼性 | AIモデル、Wasm、イベント駆動型タスク |
| ネットワーク | 基本的なPod間通信 | サイドカーによる高度な可観測性 | サイドカーレス構成への回帰と軽量化 |
| デプロイ手法 | 手動または単純なスクリプト | Helm/Operatorによる宣言的運用 | GitOps（ArgoCD等）による完全自動化 |
関連用語との違い
Kubernetes vs Docker
Dockerはコンテナの「作成・実行」を行う単体のランタイム技術であり、Kubernetesはその大量のコンテナを「束ねて管理・運用」するためのオーケストレーターです。Dockerが個別のパッケージなら、Kubernetesはそれらを動かす工場全体の司令塔に相当します。
Kubernetes vs Nomad
HashiCorpによるNomadは、より軽量でシンプルに設計されたスケジューラーです。Kubernetesが膨大な拡張機能を持つ「重厚なプラットフォーム」であるのに対し、Nomadは既存の非コンテナワークロードも含めて柔軟に管理できる「軽量な代替案」として位置づけられます。
Kubernetes vs Serverless (FaaS)
Serverlessはインフラ管理を完全に抽象化し、コード実行のみに集中するモデルです。Kubernetesはインフラ（ノードやネットワーク）の制御権をユーザーが保持しつつ、自動化を図るモデルであり、より高度なカスタマイズと一貫した運用環境の構築が可能です。
FAQ
Q1: なぜGoogleは自社のBorg技術を公開したのですか？
Googleは、特定のベンダーに依存しない標準的なインフラ基盤を作ることで、クラウドネイティブなエコシステム全体を拡大させ、自社サービス（GKE等）の競争力を高める狙いがありました。これにより、業界全体のデファクトスタンダード化に成功しました。
Q2: 2020年頃の「Docker Deprecated」とは何が起きたのですか？
Kubernetesがコンテナ実行環境としてDockerを直接操作する仕組みから、より標準的なインターフェース（CRI）を介して動作する仕組みへ移行したことを指します。これにより、Docker以外の軽量なランタイム（containerd等）を柔軟に利用できるようになり、システムの安定性と効率が向上しました。
Q3: 今後のKubernetesのトレンドは？
2025年以降は、AI/MLワークロード（GPUリソースの高度なスケジューリング）への対応と、運用負荷を軽減するための「サイドカーレス」構成やWebAssembly (Wasm) の統合が鍵となります。インフラの複雑さを隠蔽しつつ、より高レイヤーなアプリケーションロジックに集中できる環境へと進化しています。