kubeletはKubernetesクラスタを構成する各ノード（仮想マシンや物理サーバー）に常駐するエージェントで、コントロールプレーンから受け取ったPodSpecの通りにコンテナを起動・監視するのが役目です。2014年にGoogleがKubernetesをオープンソース化した際、最初期から存在する中核コンポーネントの1つで、Go言語で書かれ、Linuxではsystemdサービスとして常時起動するのが一般的な構成です。ノード側でPodを「現場監督」のように世話する存在であり、これが正しく動かないとどれだけAPIサーバーが指示を出しても実際のコンテナは1つも立ち上がりません。
この記事の目次
- kubeletが担う3つの責務
- コンテナランタイムとの境界線
- 運用で押さえておく設定
- kube-apiserverとの役割分担
- まとめ
kubeletが担う3つの責務
kubeletの仕事は大きく3つに整理できます。1つ目はPodSpec実行で、APIサーバーから割り当てられたPod定義を解釈し、CRI（Container Runtime Interface）を介してcontainerdやCRI-Oといったランタイムにコンテナ起動を指示します。イメージのpull・ボリュームのマウント・ネットワーク設定（CNI呼び出し）・ヘルスチェックの登録まで、Pod1つを動かすための雑多な前準備を一通り面倒見ます。
2つ目は健康監視で、PodSpecに書かれたLiveness ProbeやReadiness Probeを設定された間隔で実行し、失敗が続くコンテナは再起動したり、Serviceの転送対象から外したりといった処置を行います。3つ目は資源報告で、ノードのCPU・メモリ・ディスク使用量や、各コンテナの状態をAPIサーバーに定期的に通知します。この報告が止まるとノードはNotReady状態と判定され、スケジューラは新規Podをそのノードに配置しなくなります。kubeletは表に出にくい部品ですが、Podのライフサイクル全体を実際に駆動している存在です。
コンテナランタイムとの境界線
kubelet自身はコンテナを直接動かすわけではなく、CRIという標準インターフェース越しに別プロセスのランタイムへ命令を渡します。古くはDockerに直結していましたが、2016年にCRI仕様が策定されてからは中間層が挟まる構造になり、2020年12月発表のKubernetes 1.20で「Dockershim」と呼ばれていた直結用ラッパーの非推奨化が告知されました。1.24では完全に削除され、現在はcontainerdとCRI-Oが2大ランタイムとして主流です。
ネットワーク設定もkubelet単体では完結せず、CNI（Container Network Interface）プラグインへ橋渡しします。CalicoやCiliumといったCNI実装がIPアドレスの払い出しやルーティング設定を担い、kubeletは「どのPodにどのIPが付いたか」をAPIサーバーに報告する係に徹します。この明確な責務分担のおかげで、ランタイムやネットワークの実装を入れ替えてもkubelet本体は同じバイナリで済む、という拡張性が確保されています。
運用で押さえておく設定
kubeletは長らくコマンドラインオプションで設定していましたが、現在はKubeletConfigurationというYAMLにevictionポリシー・cgroupドライバー・認証方式などをまとめて宣言するスタイルが推奨です。eviction（強制退去）は、ノードのメモリやディスクが逼迫した際にどのPodから止めるかを決める仕組みで、evictionHard・evictionSoftのしきい値を環境に合わせて調整しないと、肝心の業務Podが落ちて障害につながります。
セキュリティ面ではTLS Bootstrappingで証明書を自動更新する仕組みが標準化されており、有効期限切れによる障害を避けられます。ログはコンテナ出力をノード上の/var/log/podsに溜め込むため、ログローテーション設定とディスク監視は必須です。監視ではkubelet_running_pods・volume_manager_total_volumes・node_filesystem_avail_bytesなどを観察し、Pod数の上限（既定110）に近づいていないか、ノードプレッシャーが発生していないかを早めに察知することが重要です。
kube-apiserverとの役割分担
Kubernetesではコントロールプレーンの中心にkube-apiserverがあり、ユーザーや他コンポーネントから来るREST APIを受け付け、認証・認可・admissionを通したうえでetcdに状態を書き込みます。kubeletはそのAPIサーバーをwatchし、自ノードに割り当てられたPod定義を取得して実行する側の存在で、「中央指令を受ける現場の手」と「指令を出す本部」の関係に対応します。
両者は対等な双方向通信をしているわけではなく、kubeletからAPIサーバーへの上り通信が基本的な方向です。ノードからの定期報告と、Pod作成イベントのwatchで成り立っており、APIサーバー側からkubeletを呼び出すのはkubectl execやkubectl logsで実行ログを取りに行く時など限られた経路に絞られています。この分離のおかげで、コントロールプレーン側を冗長化したりマネージドサービスに切り出したりしても、ノード側のkubeletは同じ構成で動作し続けられる柔軟性が生まれています。
まとめ
kubeletはKubernetes全ノードに常駐するエージェントで、PodSpec実行・健康監視・状態報告という3つの責務を担います。コンテナランタイムやCNIへ橋渡ししつつ、APIサーバーとはwatchを中心とした上り通信で結ばれています。本部の指示を現場で具現化する監督役として、クラスタが動き続ける限り休まず働き続ける縁の下の力持ちです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント