【仕組み解説】Kubernetesはどうやってコンテナを管理しているのか — オーケストレーションの裏側を図解

簡単に言うと、たくさんのコンテナを自動で管理してくれる「指揮者」みたいな存在だよ。オーケストラの指揮者が各楽器奏者にいつ演奏するか指示するように、Kubernetesはどのサーバーでどのコンテナを動かすか決めてくれるんだ。

コンテナが数個なら手動でも管理できるけど、何百・何千個になると人間じゃ追いきれないよね。「このコンテナが落ちたから再起動して」「アクセスが増えたからコンテナ増やして」っていう作業を全部自動でやってくれるのがKubernetesだよ。

大きく分けると「Control Plane」と「Node」の2つがあるよ。Control Planeは司令塔で、API Server、Scheduler、etcd、Controller Managerという4つの主要コンポーネントで構成されているんだ。API Serverが全体の窓口、Schedulerがコンテナの配置先を決めて、etcdがクラスタの状態を記録して、Controller Managerが理想の状態を維持する役割だね。

Nodeは実際にコンテナが動くサーバーのことだよ。各Nodeにはkubeletとkube-proxyが入っていて、kubeletはControl Planeからの指示を受けてコンテナを起動・停止する現場監督みたいな存在。kube-proxyはネットワークのトラフィックを適切なコンテナに振り分ける交通整理係だね。

Podはコンテナを入れる最小単位の箱みたいなもので、1つ以上のコンテナをまとめて管理するよ。DeploymentはPodの数や更新方法を定義する設計図で、「このPodを3つ動かしてね」みたいな指示を書くんだ。Serviceは外部からのアクセスを適切なPodに振り分ける入り口の役割だよ。

これがSchedulerの仕事だよ。新しいPodが作られると、SchedulerがすべてのNodeのCPUやメモリの空き状況をチェックして、最適なNodeを選んで配置するんだ。「このNodeはもうパンパンだから別のNodeに置こう」みたいな判断を自動でしてくれるよ。

ここがKubernetesのすごいところで、「自己修復」という機能があるんだ。Controller Managerが常に「Deploymentで指定された数のPodが動いているか」を監視していて、Podが落ちたら自動的に新しいPodを作り直してくれるよ。人間が気づく前に復旧が終わっていることも多いんだ。

スケールアウトという仕組みがあって、Horizontal Pod Autoscalerを設定しておくと、CPUの使用率などを見て自動的にPodの数を増減してくれるよ。たとえば「CPU使用率が80%を超えたらPodを増やす」みたいなルールを決められるんだ。

Helmチャートというパッケージマネージャーがあるよ。アプリのインストールに必要なKubernetesの設定ファイルをまとめてテンプレート化したもので、複雑な設定もコマンド一発でデプロイできるようになるんだ。npmやaptみたいな感覚でKubernetesアプリを管理できるよ。

正直、個人の小さなサービスにはオーバースペックなことが多いよ。Kubernetes自体の運用にもコストがかかるからね。ただ、AWS EKSやGoogle GKEみたいなマネージドサービスを使えばControl Planeの管理はクラウドに任せられるし、学習目的ならMinikubeやkindでローカルにクラスタを立てて試せるよ。本番で使うかどうかは、サービスの規模とチームのスキルに応じて判断するのが大事だね。