連載: Kubernetesのカスタムコントローラを作ろう！ ～第1回 Kubernetesのコンポーネント～
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
Kubernetesはコンテナオーケストレーションとして広く利用されるようになりました。
Deployment, StatefulSet, Ingress等様々なリソースがKubernetes上であらかじめ定義されており、汎用的で非常に使いやすく便利です。
これらのリソースを作成すると、Kubernetesのコンポーネントが実際に処理を行い、コンテナを作ったりコンテナ間の通信のルーティングを設定したりします。
このコンポーネントのことをKubernetesではコントローラといいます。
コントローラとはクラスタに登録されたリソースの定義を監視して、望ましい状態に近づけるために何かしら処理を実行するものです。
例えばレプリカ数が3のReplicaSetが作成されれば、3つのPodが起動してくることが望ましい状態であるため3つのPodを作成します。
それらのPodが何かしらの理由により削除されてしまった場合、Kubernetesのコントローラは望ましい状態である3つとなるように処理します。
Kubernetesでは複数のコントローラが実行されており、時にはKubernetesのリソースを通じて協力しあって動作します。
コントローラはKubernetesのコンポーネントの専売特許ではなく、誰でも作成可能であり、これらはカスタムコントローラと呼ばれます。
カスタムコントローラの例としてcert-managerやexternal-secretsがあります。
カスタムコントローラは誰でも作成できますが、「そうは言ってもどこから手を付けてよいかわからない...」そんなことを考えている方々はたくさんいるのではないでしょうか？
そういった方々のために0からKubernetesのコントローラを作成する方法を連載形式で説明していきます。
今回はその第一回となります。
第一回からコントローラをいきなり作成していくのではなく、まずはKubernetesのコンポーネントについて確認していきます。
読者の方にはもう既に知っているよ！という方もいらっしゃるかと思いますが、改めてコントローラという観点からこれらを確認していきましょう。
Kubernetesのコンポーネント
Kubernetesには下図のようにいくつかのコンポーネントから成り立っています。
それぞれコントローラの観点からどのような役割を担っているか説明します。
画像: https://kubernetes.io/docs/concepts/overview/components/
kube-apiserver
外部へAPIを提供するコンポーネントです。
DeploymentやServiceなどKubernetesに保存されるリソースは基本的にこのコンポーネントを通して操作することとなります。
そのためオブジェクトを操作する時、kubectlやカスタムコントローラは主にこちらのコンポーネントと通信します。
kube-controller-manager
こちらはDeploymentやStatefulSetなど各種Kubernetesのリソースのためのコントローラの集合となっています。
Deploymentが更新されると新しいReplicaSetが作成されたり、DaemonSetリソースを作成すると条件にマッチするPodが作成されるのは、このコンポーネントのおかげです。
一般的にKubernetesのコントローラはkube-apiserverへ都度リソースを取得するのではなく、できる限りキャッシュを利用することで負荷を下げる実装をしています。
kube-controller-managerのように複数のコントローラを一つのコンポーネントにまとめることで、同じキャッシュを使い回すことができます。
主なカスタムコントローラを実装するためのライブラリでもこのような実装が可能となっています。
kube-scheduler
Podリソースを作成したとき、Podが動作するノードを決定するコントローラです。
各ノードのリソースの空き状況を確認し、最も適切と考えられるノードへ配置します。
具体的にはPodの .spec.nodeName を埋めるものです。この値を埋めるだけで、実際にPodを起動するコンポーネントではありません。
kubelet
各ノードで実行されており、実際にPodをコンテナランタイムを通して起動するコントローラです。
kube-schedulerが埋めてくれたPodの .spec.nodeName を見て、自分のノードであればPodを動かします。
kube-proxy
EndpointSliceリソースなどのリソースを見て、通信を制御するコントローラです。
例えばServiceのClusterIPに紐づくPodをどのような経路を通れば通信できるかなどをノードへ設定します。
最後に
Kubernetes自体が複数のコントローラにより成り立っていることを改めて確認していただけたかと思います。
あるコントローラが作成・編集したリソースを他のコントローラが見て何かアクションを発生させるなど、各コントローラ間でも連携が見られます。
このように一つのコントローラで全ての処理を実装するのではなく、1つのコントローラの責務が可能な限り小さくなるように作ることも、カスタムコントローラを開発する上でポイントとなります。
カスタムコントローラもKubernetesのコントローラと同じ作法で作成することとなるので、これらを頭の隅に入れておくことはカスタムコントローラを実装する上でも非常に役に立ちます。
クリエーションラインではKubernetesに関する様々なトレーニングを提供しております。
詳しくはこちらをご参照ください。
また、この連載の更新通知を受け取りたい方は、Twitterアカウントのフォローや、このページ下部にリンクのあるCL LAB MAIL MAGAZINEへの登録をぜひお願いします！
