Kubernetes — 知星図

概要

Kubernetes（クバネティス、略してk8s）は、多数のコンテナを複数のサーバにまたがって自動運用するための基盤（コンテナオーケストレータ）です。「このアプリのコンテナを3つ、常に動かしておいてほしい」という望ましい状態を設定ファイルで宣言すると、Kubernetesがコンテナの配置先を決め、落ちたら立て直し、負荷が増えたら数を増やす — という運用を24時間休まず続けてくれます。

Googleが社内の大規模コンテナ運用の知見をもとに開発し、2014年にオープンソース化しました。現在ではコンテナオーケストレーションの事実上の標準であり、AWS（EKS）、Google Cloud（GKE）、Azure（AKS）といった主要クラウドがすべてマネージドサービスとして提供しています。

なぜ生まれたか

コンテナは1個動かすだけなら簡単ですが、本番システムでは話が変わります。数十〜数千のコンテナを複数のサーバに配置し、どれかが異常終了したら再起動し、サーバごと壊れたら別のサーバに移し、リリースのたびに無停止で入れ替え、負荷に応じて数を調整する — これを人間が手順書とコマンドでこなすのは不可能です。コンテナが普及すればするほど、「コンテナの群れを誰が面倒みるのか」という問題が深刻になりました。

Kubernetesの答えは「宣言的運用」です。人間は手順（どうやるか）ではなく状態（どうあるべきか）だけを書き、システムが現実と宣言のズレを検出して自動修復し続けます。障害対応・再配置・スケールといった判断を機械に委ねるこの発想の転換が、Kubernetesを単なるツールではなく運用パラダイムの代表格にしました。

詳細

クラスタの構造 — コントロールプレーンとノード

Kubernetesは複数のマシンを束ねて1つの「クラスタ」として扱います。クラスタは、全体の司令塔であるコントロールプレーンと、実際にコンテナが動くワーカーノード群から成ります。コントロールプレーンには、操作を受け付けるAPIサーバ、クラスタの状態を保存するetcd（分散キーバリューストア）、コンテナの配置先を決めるスケジューラなどが含まれます。各ノードではkubeletというエージェントが動き、司令塔の指示どおりにコンテナを起動・監視します。

デプロイの最小単位は「Pod」で、1つ以上のコンテナをまとめたものです。通常はPodを直接作らず、「このPodを3つ維持せよ」というDeploymentリソースを定義します。ユーザーがYAMLで書いた宣言はAPIサーバ経由でetcdに保存され、そこから先はKubernetesの仕事です。

YAMLで望ましい状態を宣言kubectl apply でAPIサーバへ送信スケジューラがPodの配置先を決定各ノードのkubeletがコンテナを起動コントローラが状態を監視・自動修復

宣言がクラスタ上の実行状態になるまでの流れ

調整ループ — 自己修復の心臓部

Kubernetesの核心は「Reconciliation Loop（調整ループ）」と呼ばれる仕組みです。コントローラと呼ばれるプログラムが「宣言された状態」と「現実の状態」を絶えず見比べ、差分があれば埋める行動を取ります。Podが3つのはずが2つしかなければ1つ作る。ノードが丸ごと死ねば、そこにいたPodを別ノードに作り直す。この単純なループが休みなく回り続けることが、自己修復（セルフヒーリング）の正体です。

障害対応が「人間がアラートを受けて対処する」から「システムが勝手に直し、人間は後から知る」に変わります。

このループの動きは、下のシミュレータで Pod を殺したり宣言数を変えたりしながら観察すると実感できます。

⚡ 体験: 宣言と現実のズレを調整ループが埋める

望ましい状態: Pod3個

調整ループを開始しました。Podをクリックして障害を起こしてみてください。

調整ループは1秒ごとに現実を観測し、宣言と比較します。障害復旧も余剰の削除も、同じ一つのループの仕事です。

サービス検出と負荷分散、スケーリング

Podは頻繁に作り直され、そのたびにIPアドレスが変わります。そこでKubernetesは「Service」という安定した窓口を用意し、その背後にいる複数のPodへリクエストを振り分けます。クラスタ内にはDNSが組み込まれており、Pod同士はService名で通信できます。外部からのHTTPトラフィックはIngressというリソースで受け、実質的にロードバランサやリバースプロキシとして機能します。また、CPU使用率などの指標に応じてPod数を自動増減するHorizontal Pod Autoscalerがあり、スケーリングもまた宣言の一部として自動化されます。

エコシステムと実務での位置づけ

Kubernetesを中心に、パッケージ管理のHelm、Gitリポジトリを宣言の唯一の情報源としてクラスタを同期させるGitOps（Argo CDなど）、監視のPrometheusといった巨大なエコシステムが形成されています。マイクロサービスのように多数の独立したサービスを運用するアーキテクチャでは、Kubernetesが標準的な足場です。

一方で、その強力さは学習コストと運用コストの重さと表裏一体です。クラスタ自体のバージョンアップ、ネットワークやセキュリティの設定、etcdの運用など、Kubernetes自身の面倒をみる仕事が新たに発生します。マネージドサービスを使ってもこの複雑さは半分しか消えません。小規模なシステムなら、コンテナを1台で動かす、PaaSやサーバレスに載せる、といった選択肢のほうが総コストで勝ることも多く、「本当にこの規模の自動化が必要か」を最初に問うのが、Kubernetesとの正しい付き合い方です。