アーキテクチャから読み解くKubernetes～Controllerの仕組み～

【15-A-6】アーキテクチャから学ぶKubernetesの全体像

イベント駆動でリソースを管理するkubelet、ボリュームを利用可能にするCSI Driver

　続いてはkubelet、Kubernetesクラスタの各ノードで動作するコンポーネントだ。コンテナランタイムと連携し、さまざまなイベントをトリガーにワーカーノードで動かすコンテナと関連リソースを管理する。

コンテナ起動を行うKubeletのメインループはControllerライクなイベント駆動型になっている

　例えばAPIサーバー（図の左上）から新しいPodが登録されたとか、PLEG Worker（図の上、右から3つ目）が実行中のコンテナの設定の変更を検知したとか、コンテナの死活判定するワーカーのLiveness Probe（図の上、右から2つ目）がコンテナの異常を検知したとか、こうしたものを検知するとイベントを発火する。

　APIサーバーで新しいPodが作成されて、そのPodに対応するコンテナグループを作るとすれば、Handler、Pod Worker、Runtime Managerを経てコンテナを起動する。その途中でPodが使用するSecretやConfigMapの取得処理、各種probe、ボリュームの初期化などといったコンテナの管理起動を行う処理が様々なイベントをトリガーとして行われるアーキテクチャとなっている。

　最後にCSI Driver、ボリュームを利用するためのプラグインだ。下図の緑の部分がCSI Driver、赤がサイドカーと呼ばれるものでCSI Driverと一緒にデプロイする独立したKubernetes Controllerになる。サイドカーにはexternal-attacherやexternal-provisionerなどがありボリュームのプロビジョニングなどを実施する際にKubernetesのリソース監視を行い、CSI Driverへボリューム処理を依頼する。例えば「PersistentVolumeClaim（PVC）リソース」という名前のボリュームを作成すると、サイドカー（external-provisioner)）がPVCの作成を検知して、ボリューム作成処理が流れる。

コンテナ起動を行うKubeletのメインループはControllerライクなイベント駆動型になっている

　払い出したボリュームを利用するまでは下図のような流れとなる。kube-controller-managerの中でAttach/Detach Controller（図の画面上中央）が稼働していて、このControllerが管理するVolumeAttachementObjectリソースを監視する別のサイドカー（external-attacher）がノードに対してボリュームのアタッチを行い、最後にkubeletがノード上で動作するCSI Driverを通してボリュームの初期化やマウントが行われる。

Pod作成時のボリュームマウントまでのフロー

　先に「Kubernetesでは自作Controllerを利用できる」という話をしたように、ここのCSI Driverは外部から実行するControllerの好例となる。

　まとめとしてbelles17氏は「KubernetesはこのようにController（とそれに類いするアプリケーション）の組み合わせで、いろんなものを実現しています」と述べた。なお今回のセッションの内容をより詳しく知りたければ、下記資料で確認できる。

参考資料

クラウドインフラ領域のスペシャリストがシステムの戦略策定から設計・実装・運用までワンストップでサポート

　SRE、Platform Engineering、k8s、コンテナセキュリティなど、Sreakeが提供するサービスはお客様のエンジニア組織における技術戦略の策定から設計、実装、そして運用まで、クラウドインフラ領域における様々な領域のプロフェッショナルが包括的に支援します。

　本記事で興味を持たれた方は、お問い合わせページよりご連絡ください。