1.1.1　etcd

etcdはKubernetesのデータストアとして、先程登場したmanifestファイルから適用された各種リソース情報を保存するために利用されます。

ちなみに、kubeadmなどを使ってKubernetesクラスターを構築すると、etcdやControl PlaneはKubernetesクラスターのノード上に構築されますが、Control PlaneやetcdはKubernetesのWorker Nodeの外で実行することも可能です。
(Kubernetesのマネージドサービスはこういった構成を取っているのではないかという気がしています)

1.1.2　Control Plane

Control PlaneはKubernetesクラスターを動かすためのいくつかのコンポーネントのことで

• API Server
• Kube Controller Manager
• Cloud Controller Manager
• Scheduler

の４種類があります。

API Server

API Serverはkubectlやclient-go*1といったSDKを通してリクエストを受けるAPI Serverです。Kubernetesに関する操作は基本的に全てこのAPI Serverを経由して行われ、データストアであるetcdへの接続もこのAPI Serverを通してのみ行われます。

API Serverにはリソースに関する操作をフックするAdmission Webhookという仕組みがあります。
(https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)

Admission Webhookには

• リクエストされたデータの書き換えを行うMutating Webhook
• リクエストされたデータのバリデーションを行うValidating Webhook

の2種類があり、登録・更新されるKubernetesのリソースのバリデーションや値の書き換え操作が可能となっています。

また、API ServerにはExtension API ServerというAPI Serverを独自に拡張する方法が提供されており、Kubernetesの https://github.com/kubernetes/sample-apiserver リポジトリでサンプルのExtension API Serverが提供されているので、興味がある方はこちらを試して見ていただければと思います。

Kube Controller Manager

Kube Controller ManagerはKubernetesの各種リソースをもとに宣言された状態に調整するコントローラーというものをまとめて実行するコンポーネントです。現時点で30を超えるコントローラーがこのKube Controller Manager上で実行されているようです。

例えば、Deploymentリソースを作った際にReplicaSet~Podリソースが作成されるのは

• Deployment Controller
• ReplicaSet Controller

といったコントローラーがKube Controller Managerの内部で動いているからです。これらのコントローラーによってReplicaSetやPodリソースが作成されています。

Cloud Controller Manager

Cloud Controller Managerは、Kube Controller ManagerからKubernetesクラスターが動くIaaSと連携するための4つのコントローラーをまとめたものになります。

具体的には

• パブリッククラウドやVMware、OpenStackといったIaaSと連携して登録されたWorker Nodeの設定
• Serviceリソースと呼ばれるKubernetesのリソースと連携して、IaaS側のL4ロードバランサーを構築~構築したL4ロードバランサーからKubernetesクラスター上で実行されているPod(コンテナをグルーピングした実行単位)への経路を確保

といった機能がCloud Controller Managerを介して実行されます。

Cloud Controller Managerは対象の実行環境向けのCloud Providerと呼ばれる、IaaSと連携するためのインターフェイスを満たしたパッケージと連携することで、IaaSとの連携を実現するコントローラー群になります。

上記のような機能をCloud Providerを利用して実現するために、Cloud Controller Managerでは

• Node Controller
• Node Lifecycle Controller
• Route Controller
• Service Controller

という4つのコントローラーを実行します。

図1.2: Cloud Controller Managerの全体像

この図のようなイメージで各コントローラーがそれぞれ必要な処理をCloud Providerのインターフェイスを通して実行環境に要求し、処理を行います。

Cloud Controller Managerの詳細については

• 筆者がCloud Native Days 2020にて発表したCloud Controller Manager Deep Diveというセッション(https://speakerdeck.com/bells17/cloud-controller-manager-deep-dive)
• Kubernetes Internal #2というKubernetesの内部実装に関する勉強会(https://youtu.be/eET4AfQr3VM)

で解説を行っていますので、こちらをご覧ください。

Scheduler

SchedulerにはPodをどのWorker Nodeで実行するのかを選定するロジックが入っています。通常のWebアプリケーションを利用しているだけだと、あまり意識することは少ないですが、例えばKubernetesを機械学習基盤に利用する際には、このSchedulingの最適化を行うために、独自にSchedulingロジックを入れたりする事例をよく耳にします。

SchedulerにはScheduling Frameworkというスケジューリングの仕組みを独自に拡張していける仕組みがあるようで、こちらについては以前チェシャ猫さん(https://twitter.com/y_taka_23)がKubernetes Internal #3(https://youtu.be/TRy_SZQ53Ao)で行っていただいたセッションで詳細が解説されていますので、興味があればご覧ください。

1.1.3　Worker Node

Worker Nodeでは

• kube-proxy
• Kubelet

の2種類のコンポーネントが動作します。

kube-proxy

kube-proxyはWorker Nodeのネットワーク設定を行うコンポーネントです。具体的には、KubernetesのServiceリソースの

• type: ClusterIP
• type: NodePort

の2種類(つまりtype: LoadBalancer以外)から生成されるEndpoint/EndpointSliceというリソースに基づいて、NodeとPodの通信経路を制御します。

Kubelet

最後にKubeletです。これが本書でメインで扱っていくコンポーネントになります。

KubeletはKubernetesのコアコンポーネントの1つで、各Worker Nodeで動作します。 Kubeletは実行されているNode(サーバー)で動作し

1. Kubeletを実行しているサーバーをKubernetesのWorker Nodeとして登録・管理する
2. 実行しているWorker Nodeで実行すべきPod(コンテナ)情報を取得し、実行する

ということを主に実行します。

これらの詳細について、次章以降で説明していきたいと思います。