Kubernetesを勉強していると、「kubectl create deploymentコマンドを打っただけなのに、どうやって私のコンテナが特定のノードにデプロイされるんだろう？」という疑問が湧いてくるものです。
今日は、Kubernetesアーキテクチャ図を通して、ユーザーのリクエストがMaster(Control Plane)を経由し、Node(Worker Node)に実際のコンテナとして生成されるまでの全行程を非常に詳細に掘り下げてみましょう。🕵️♂️✨
https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/
1. Master領域: コマンドを受け取り、設計図を描く 🧠
すべての旅はユーザーのキーボードから始まり、MasterノードのAPI Serverへと向かいます。
1️⃣ ユーザーリクエスト (User → API Server)
- Action: ユーザーがkubectlコマンドまたはUIを通じてDeploymentの作成をリクエストします。
- Protocol: このとき、リクエストはJSON形式のHTTP通信でAPI Serverに伝達されます。(図の青い矢印 🟦)
- Role: API ServerはKubernetesクラスターの「玄関」であり、すべてのコンポーネントの中心です。
2️⃣ 情報保存 (API Server ↔ etcd)
- Action: API Serverはリクエストが有効であるか検証した後、この情報をetcdに保存します。
- Role: etcdはクラスターのすべてのデータを保存するKey-Valueストアであり、SSOT(Single Source of Truth)です。これでクラスターの「望ましい状態(Desired State)」にDeploymentが記録されました。
3️⃣ コントローラーの設計 (Controller Manager)
次にController Managerが忙しく動き出す番です。(図のピンクの矢印 🟪)
- Deployment Controller: 新しいDeployment情報を検知し、それに見合ったReplicaSet(RS)の生成をAPI Serverにリクエストします。
- ReplicaSet Controller: 生成されたRSを検知し、設定された複製数(Replicas)分のPodオブジェクトの生成をリクエストします。
- Point: ⚠️ 重要！このとき生成されたPod情報は、「どのノードに行くか(nodeName)」がまだ空のPending状態のデータ塊に過ぎません。
4️⃣ スケジューリング (Scheduler)
- Action: SchedulerはnodeNameがない孤独なPodを発見します。(図のピンクの矢印 🟪)
- Logic: ノードの資源状態を確認(Filtering)し、最も適したノード(Scoring)を選出します。例えば、「Node 2」が当選したとしましょう。
- Binding: スケジューラーは「このPodはNode 2に行け！」というバインディング情報をAPI Serverに更新します。
2. Node領域: 設計図を現実に具現化する 🏗️
いよいよ舞台は実際のワークロードが実行されるNode(Worker Node)へと移ります。
5️⃣ Kubeletの任務受領 (API Server → Kubelet)
- Action: 各ノードの船長役であるKubeletは、定期的にAPI Serverと通信し、「自分の担当(Node 2)に割り当てられたPodがあるか」を確認(Watch)します。
- Protocol: この通信は効率性のために主にProtobuf (gRPC)を使用します。(図の紫の矢印 🟪)
- 新しいPod割り当て情報を確認したKubeletは、本格的な作成作業に着手します。
6️⃣ ネットワーク道路の敷設 (Kubelet ↔ CNI)
コンテナが生成されても通信ができなければ無用の長物ですよね？まずネットワークを構築します。
- Interface: KubeletはCNI(Container Network Interface)を通じてネットワークプラグインを呼び出します。(図の水色の矢印 🟦)
- Result: Podが使用するIPが割り当てられ、通信可能なネットワーク環境が構成されます。
7️⃣ コンテナ実行リクエスト (Kubelet ↔ CRI)
ネットワークの準備が整ったので、実際のコンテナを作成する番です。
- Interface: KubeletはCRI(Container Runtime Interface)を通じてコンテナランタイム(Containerd, CRI-Oなど)にコマンドを発行します。
- Protocol: このプロセスはgRPC通信で行われます。(図の緑の矢印 🟩)
8️⃣ OS上でプロセス実行 (Runtime ↔ OCI ↔ OS)
- Action: リクエストを受け取ったContainer Runtimeはイメージを取得し(Pull)、OCI(Open Container Initiative)標準に従ってLinuxカーネル(OS)と通信します。(図の黄色の矢印 🟨)
- Final: ついに隔離された環境で、私たちがリクエストしたアプリケーション(Container)が実行されます！🎉
📝 要約: 流れを一目で！
この複雑に見えるプロセスは、実は4段階の連携です。
- User & API Server: 「Deploymentを作って！」→ 記録 💾
- Controller: 「じゃあRSを作って、Podデータを作成しないと。」⚙️
- Scheduler: 「このPodはNode 2がぴったりだね。割り当て！」⚖️
- Kubelet (Node): 「あれ？私の担当だね？CNIで道を切り開いて、CRIでコンテナを起動！」🚀
この一枚の図には、JSON, gRPC, Protobufのような通信方式から、CNI, CRI, OCIのような標準インターフェースまで、すべてが詰まっています。Kubernetesがいかに体系的でモジュール化されたシステムであるかがわかる点ですね。
さあ、kubectl createを入力する際には、これら数多くのコンポーネントの労苦を一度思い出してみてください！😉
コメントを残す