はじめに
私はマネージド K8s (Azure AKS, Amazon EKS など)を何度か利用したことがあります。
kubectl コマンドの利用時に裏で何らか API が実行されていることは認識していましたが、その先で何が行われているかまで理解していませんでした。
Kubernetes をしっかりと理解するには、マネージド K8s であまり意識していないコントロールプレーンを理解する必要があると感じ、調べてみました。
コントロールプレーンって何だっけ
下記に記載があります。
コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deployment の replicas フィールドが満たされていない場合に、新しい Pod を起動する等)。
クラスタを維持する上で重要な、クラスターの状態を管理・制御するコンポーネント群、ですね。
情報を整理して監視し、指示を出す、高性能な脳ミソ、というイメージをしました。
指示を出すまでで、実際に作業をするのはワーカーノード上のコンポーネントになります。
以降で、重要なコンポーネントをいくつか紹介できればと思います。
kube-apiserver：全ての入り口
下記に記載があります。
API サーバーは、Kubernetes API を外部に提供する Kubernetes コントロールプレーンのコンポーネントです。 API サーバーは Kubernetes コントロールプレーンのフロントエンドになります。
Kubernetes API サーバーの主な実装は kube-apiserver です。
コントールプレーンには Kubernetes API を外部に提供するコンポーネントが必要であり、その実装として kube-apiserver がある、ということですね ?
kubectl コマンドの通信先も kube-apiserver となります。
kubectl apply -f manifest.yaml のようなコマンドが何をしているか、でいうと、後述の etcd に直接マニフェストファイルを追加するのではなく、この kube-apiserver を経由してマニフェストファイルの定義を適用しています。
etcd：データを守る番人
下記に記載があります。
一貫性、高可用性を持ったキーバリューストアで、Kubernetes の全てのクラスター情報の保存場所として利用されています。
RDB ではなくキーバリューストアですね。
シンプルな記載ですが、「一貫性」「高可用性」「Kubernetes の全てのクラスター情報の保存場所」という思い言葉が並び、非常に重要で「落とせない」ことが伝わってきます。
kube-scheduler：Pod の新居を決める
下記に記載があります。
コントロールプレーン上で動作するコンポーネントで、新しく作られた Pod にノードが割り当てられているか監視し、割り当てられていなかった場合にその Pod を実行するノードを選択します。
Pod が動作する場所を手配してくれる存在です。
Pod リソースが「作成された」だけでは Pod の実体はなくて、「ノードが割り当て」られてそこで実体を作られて初めて動く、ということをイメージしました。
スケジューリングの決定は、Pod あるいは Pod 群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。
様々な条件をもとに、どのノードに割り当てるかを決定するようです。
まとめ
概要レベルですが、コントロールプレーンについて整理してみました。
コントロールプレーンは実務を負わないことが分かり、ワーカーノード上に K8s のコンポーネントが必要なことを認識できました。
マネージド K8s では見えにくい部分でしたが、理解することで以下のような気づきが得られました：
- クラスター操作のリクエストは必ず kube-apiserver を経由する
- クラスターの状態は etcd に保存されている
- Pod の配置は様々な条件を考慮して kube-scheduler が決定する
次回はワーカーノードについて調べてみたいと思います。