Kubernetes（クバネテス、略してK8s）は、Googleが社内で長年運用していたコンテナ管理システム「Borg」の知見をもとに、2014年にオープンソースとして公開したコンテナオーケストレーションプラットフォームです。現在はCNCF（Cloud Native Computing Foundation）に寄贈され、AWS・Azure・GCPすべてがマネージド版を提供するクラウドインフラの事実上の共通基盤になりました。本記事ではKubernetesの設計思想と主要コンポーネントを整理します。
この記事の目次
- Kubernetesが解決する課題
- 中核オブジェクトの整理
- Kubernetesは難しいか
- KubernetesとDockerの役割分担
- まとめ
Kubernetesが解決する課題
コンテナを1台のサーバで動かすだけならDockerで十分です。ところが本番運用となると、「サーバが落ちたらコンテナを別ノードへ移したい」「アクセス急増時に自動でレプリカを増やしたい」「ローリングアップデートしたい」といった要件が一気に増えます。これらをまとめて引き受けるのがKubernetesです。
「宣言的な構成管理」がKubernetesの中核思想です。管理者は「あるべき状態（例: このアプリを3レプリカで動かす）」をYAMLで宣言するだけで、現状とのギャップをKubernetesが自動で埋めてくれます。サーバを再起動した後も、ノード障害が起きた後も、宣言された状態へ向けて常に収束する点が革新でした。
中核オブジェクトの整理
Kubernetesでは、コンテナそのものを直接扱うのではなく、Pod・Deployment・Service・Ingressといった抽象化されたオブジェクトを通して操作します。Podは1つ以上のコンテナをまとめた実行単位、Deploymentは「Podを何個保ちたいか」「どう更新するか」を宣言する上位リソースです。
外部からアクセスする際は、Pod のIPは変動するためServiceで安定したエンドポイントを作り、HTTPなら Ingress でホスト名やパスごとのルーティングを設定する、というのが定型パターンです。アプリの設定や秘密情報は ConfigMap / Secret として外出ししておき、コンテナイメージは環境を問わず使い回せるよう設計します。
Kubernetesは難しいか
Kubernetesは「とにかく学習コストが高い」との評判が定着しています。概念が多く、YAMLが膨大になり、ネットワーク・ストレージ・セキュリティなど周辺領域の知識も求められるため、個人開発のレベルで使うにはオーバースペックなことも事実です。
現場での現実解は「マネージドサービス（Amazon EKS / Google GKE / Azure AKS）に任せる」こと。コントロールプレーンの管理から解放されるだけでも運用負荷は段違いに下がります。「自前運用は手段が目的化していないか」を常に問い直しながら採用判断するのが定石です。
KubernetesとDockerの役割分担
「DockerとKubernetesはどちらを使うべきか」という問いは、本来は対立構造ではなく階層の問題です。Dockerは「コンテナを作る・動かす」道具、Kubernetesは「動いているコンテナ群を束ねて運用する」道具で、両者は補完関係にあります。
なお Kubernetes は2020年にコンテナランタイムとして Docker Engine ではなく containerd や CRI-O を直接使うようになりましたが、Docker でビルドしたイメージは引き続き Kubernetes 上で動かせます。「Dockerイメージを作る → Kubernetesが配って動かす」という基本構図は変わっていません。
まとめ
Kubernetesは強力ですが、複雑さも一級品です。「自分たちの規模に本当に必要なのか」を問いつつ、必要であればマネージド版から始めるのが、現実的なクラウドネイティブ移行の第一歩です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント