KubernetesのコアとなるControllerとは？
コンテナオーケストレーションツールとして有名なKubernetes。代表的な特徴を挙げるとサービスディスカバリとロードバランシングがある。Serviceリソースを定義することで、多数起動されているコンテナに接続する経路を自動で調整してくれるものだ。他にもコンテナでボリュームを使う時のストレージオーケストレーションもある。
他にも自動化されたロールアウトやロールバック、自動ビンパッキング、セルフヒーリングなど挙げるときりがないものの、bells17氏は「個人的にはKubernetes Controllerがすべてを支えていると言っても過言ではないと思う」と言う。そこで今回はKubernetesの基盤となるControllerにフォーカスを当てて解説する。
まずはざっとKubernetesの全体像から見ていこう。図の左がKubernetesのコントロールプレーン、右下がノードでクラスタに参加しているサーバーだ。
コントロールプレーンには「etcd」というキーバリューストア（データベース）があり、Kubernetesはこれをデータストアとして使用している。これと直接やりとりするのはkube-api-serverというサーバーだけで、他のコンポーネントはすべてこのサーバーを経由して処理する仕組みになっている。
コントロールプレーン側でkube-api-serverとやりとりする代表的なコンポーネントにはkube-controller-managerとcloud-controller-managerの2種類のマネージャーと、kube-schedulerの他、KubernetesのWorker Node上で動作するkube-proxyとkubeletがある。cloud-controller-managerから伸びているクラウドは（AWSなどのパブリッククラウドよりは）Kubernetes実行基盤とイメージするといいだろう。kube-schedulerは新たにコンテナを実行する時に適切なノードを選択するものとなる。
Controllerはざっくり言うと、監視対象リソースの変更や一定時間経過などのイベントをトリガーとして調整ループ（Reconciliation Loop）を実行する。調整ループとは「公式ドキュメントには登場しないもののよく使われる。YAMLなどで宣言されたあるべき状態と現在の状態と比較して、変更や調整を行う制御ループ」とbells17氏は説明する。
Kubernetesにおけるkube-api-server以外のコンポーネントは、Controllerやそれに似たイベント駆動の仕組みがいろんなところで採用されている。そのためKubernetesでよく言われる「“宣言的API”はControllerの組み合わせで成り立っていると言っても過言ではない」とbells17氏は言う。
なおControllerはKubernetes開発者だけが作るものではなく、ユーザーが自作しデプロイすることでKubernetesの機能を拡張することもできる。KubernetesのCustom Resource（CR）というユーザー独自にデータを定義できる仕組みと、独自のControllerを組み合わせれば独自の仕組みを開発することもできる。これは「Kubernetes Operator」とも呼ばれている。
例えば、CRを利用してロードバランサーで使用する証明書の発行や管理を行う「cert-manager」、Kubernetesの名前空間を階層化できる「Hierarchical Namespace Controller」、GitOptsによるデプロイを実現する「Argo CD」などがある。bells17氏は「こうしたことを自作するフレームワークもあるので、Kubernetesを基盤にして独自プラットフォームの機能をいろいろ作りあげている会社さんも見かけます」と話す。
