kube-controller-managerを監視する方法

本文の内容は、2022年12月15日にVICTOR HERNANDO が投稿したブログ（https://sysdig.com/blog/how-to-monitor-kube-controller-manager/)を元に日本語に翻訳・再構成した内容となっております。

ReplicationControllerやReplicaSetから新しいPodを作成したり、ネームスペースのServiceAccounts、あるいはServiceの新しいEndPointsを作成する場合、kube-controller-managerはこれらのタスクを実行する役割を担います。Kubernetesコントローラーマネージャの監視は、Kubernetesクラスターを適切に運用するための基本です。

もしあなたがクラウドネイティブの旅を続けていて、Kubernetesの上でワークロードを実行しているなら、kube-controller-managerの観測機能を見逃さないでください。Kubernetesコントローラーマネージャで問題に直面した場合、（多くの異なるオブジェクトの中から）新しいPodが作成されることはないでしょう。そのため、Kubernetesコントローラーマネージャーの監視はとても重要なのです!

Prometheusを使ったKubernetesコントローラマネージャーの監視について、また、確認すべき最も重要なメトリクスは何かについてもっと知りたい方は、このまま読み進めてください。

kube-controller-managerとは？

Kubernetesコントローラーマネージャーは、コントロールプレーンのコンポーネントで、各マスターノード上でPod内のコンテナの形で実行されます。その定義は、すべてのマスターノードで、以下のパスにあります: /etc/kubernetes/manifests/kube-controller-manager.yaml

Kube-controller-managerは、異なるKubernetesコントローラのコレクションで、すべてのコントローラーがバイナリーに含まれ、ループ内で永続的に実行されます。その主なタスクは、オブジェクトの状態の変化を監視し、実際の状態が新しい目的の状態に向かって収束することを確認することです。要約すると、Kubernetesオブジェクトの状態にまつわる調整作業を担当しています。

kube-controller-managerで動作するコントローラーは、リソースに変更があるたびに通知を受けるためにウォッチメカニズムを使用します。各コントローラーは、この通知から求められること（作成／削除／更新）に応じて行動します。

kube-controller-manager内では複数のコントローラーが動作しています。それぞれが独自の種類のObjectを調整する責任を負っています。そのうちのいくつかについて説明します。

• ReplicaSet コントローラ：このコントローラーはReplicaSetに必要なレプリカの数を監視し、その数とPodセレクターに一致するPodを比較します。このコントローラーは、監視メカニズムを通じて希望するレプリカ数の変更が通知された場合、Kubernetes APIを通じてそれに応じて動作します。本当に必要なレプリカ数より少ないため、新しいPodを作成する必要がある場合、コントローラーは新しいPodマニフェストを作成し、APIサーバーにポストします。
• Deployment コントローラー：実際のデプロイメントの状態を、目的の状態と同期させる役割を担います。デプロイメントに変更があった場合、このコントローラーは新バージョンのロールアウトを実行します。その結果、新しいReplicaSetが作成され、新しいPodがスケールアップされ、古いPodがスケールダウンされます。これがどのように実行されるかは、デプロイメントで指定されたストラテジーに依存します。
• Namespace コントローラー：ネームスペースを削除する場合、それに属するすべてのオブジェクトを削除する必要があります。ネームスペースコントローラーは、これらの削除タスクを完了させる役割を担っています。
• ServiceAccount コントローラー：ネームスペースが作成されるたびに、ServiceAccount コントローラは、そのネームスペースにデフォルトの ServiceAccount が作成されるようにします。このコントローラーと同時に、トークンコントローラーも実行され、非同期に動作し、ServiceAccountの作成と削除を監視して、対応するトークンの作成と削除を行います。ServiceAccountのシークレットの作成と削除に適用されます。
• Endpoint コントローラー：Kubernetesクラスター内のEndpointsのリストを更新・管理するコントローラーです。ServicesとPodの両方のリソースを監視します。サービスやPodが追加、削除、更新されると、サービスPodの条件（セレクター）とそのIPとポートに一致するPodをEndpointオブジェクトに選択します。サービスが削除されると、コントローラーは、そのサービスの依存するEndpointsを削除します。
• PersistentVolume コントローラー：ユーザーがPersistentVolumeClaim（PVC）を作成すると、Kubernetesはこのリクエストを満たす適切なPersistent Volumeを見つけ、このクレームにバインドする必要があります。PVCが削除されると、ボリュームはバインド解除され、その再請求ポリシーに従って再請求されます。PersistentVolumeコントローラーは、このようなタスクを担当します。

要約すると、kube-controller-managerとそのコントローラーは、実際の状態と希望する状態を照合し、新しい実際の状態をリソースのステータスセクションに書き込みます。コントローラーは互いに会話することはなく、常にKubernetes APIサーバーと直接会話します。

Kubernetesコントローラマネージャーを監視する方法

Kube-controller-managerはinstrumentedで、デフォルトで独自のメトリクスエンドポイントを提供しており、特別なアクションは必要ありません。メトリクスエンドポイントにアクセスするための公開ポートは、Kubernetesクラスターで稼働しているすべてのkube-controller-manager Podの10257です。

このセクションでは、メトリクスエンドポイントに直接手動でアクセスするために必要な簡単な手順と、Prometheusインスタンスからメトリクスをスクレイピングする方法について説明します。

注意：デフォルト値を使用してkubeadmでKubernetesクラスターをデプロイした場合、10257ポートに到達してPrometheusからメトリクスをスクレイピングすることが困難となる場合があります。Kubeadmはkube-controller-managerのbind-addressを127.0.0.1に設定するので、ホストネットワーク内のPodのみがメトリクスエンドポイントに到達できます：https://127.0.0.1:10257/metrics.

エンドポイントへのアクセスを手動で取得する

前述のとおり、Kubernetesクラスターのデプロイ方法によっては、kube-controller-managerの10257ポートにアクセスする際に問題に直面する可能性があります。そのため、kube-controller-managerのメトリクスに手動でアクセスするには、コントローラPodを –bind-address=0.0.0.0で起動するか、マスターノード自身からアクセスするか、bind-addressが127.0.0.1ならホストネットワーク内のPodからアクセスするしかありません。

十分な権限を持つ ServiceAccount トークンを使って、Podからcurlコマンドを実行することができます：

または、マスターノードから、適切な証明書を使用して、認証プロセスをパスするようにcurlコマンドを実行します：

Prometheusでkube-controller-managerのメトリクスをスクレイピングするための設定方法

kube-controller-managerのメトリクスをスクレイピングする場合、kube-controller-managerが0.0.0.0でリスニングすることが必須となります。そうしないと、Prometheus Podや外部のPrometheusサービスがメトリクスのエンドポイントに到達することができません。

kube-controller-managerからメトリクスをスクレイピングするために、kubernetes_sd_configPod roleに依存させます。先ほど説明した、Kubernetesクラスター内のどのPodからでもメトリクスエンドポイントにアクセスできるようにする、ということを念頭に置いてください。 prometheus.yml の設定ファイルに適切なジョブを設定するだけです。

これは、Community Prometheus Helm Chartにアウトオブボックスで含まれているデフォルトジョブです。

また、これらのPodをスクレイピングできるようにするには、 /etc/kubernetes/manifests/kube-controller-manager.yaml ファイルに次のアノテーションを追加する必要があります。各マスターでこれらのマニフェストを編集すると、新しいkube-controller-manager Podsが作成されます。

kube-controller-managerを監視する：どのメトリクスを確認するのか？

この時点で、kube-controller-managerとは何か、そしてなぜインフラストラクチャーにおいてこのコンポーネントを監視することが重要なのかを学びました。Kubernetesコントローラーマネージャを監視するためにPrometheusを設定する方法についてもすでに見てきました。そこで、今度は質問です。

kube-controller-managerのメトリクスはどれを監視すべきなのでしょうか？

今すぐこのトピックを取り上げましょう。読み進めてください！

免責事項: kube-controller-managerサーバーのメトリクスは、Kubernetesのバージョンによって異なる場合があります。ここでは、Kubernetes 1.25を使用しました。あなたのバージョンで利用可能なメトリクスは、Kubernetes repoで確認できます。

これを表現する良い方法は、分位数を使うことです。以下の例では、kube-controller-managerがワークキュー内のアイテムを処理するのに要した時間の99パーセンタイルを確認することができます。

histogram_quantile(0.99,sum(rate(workqueue_queue_duration_seconds_bucket{container="kube-controller-manager"}[5m])) by (instance, name, le))

workqueue_adds_total: このメトリクスは、ワークキューで処理された追加数を測定します。高い値は、クラスタや一部のノードに問題があることを示しているかもしれません。

kube-controller-managerのワークキューへの追加率を確認したい場合があります。以下のクエリーを実行して追加率を確認します。

sum(rate(workqueue_adds_total{container="kube-controller-manager"}[5m])) by (instance, name)

workqueue_depth: ワークキューがどれくらいの大きさなのかを検証できるメトリクスです。ワークキューに処理待ちのアクションがいくつあるか？これは低い値のままであるべきです。以下のクエリーを使用すると、kube-controller-managerのキューの増加率を簡単に確認することができます。ワークキューが大きくなればなるほど、処理しなければならないことが多くなります。したがって、ワークキューの増加傾向は、Kubernetesクラスターに問題があることを示している可能性があります。

sum(rate(workqueue_depth{container="kube-controller-manager"}[5m])) by (instance, name)

rest_client_request_duration_seconds_bucket: このメトリクスは、APIサーバーへの呼び出しのレイテンシーまたは秒単位の継続時間を測定します。kube-controller-managerとAPI間の通信を監視し、これらの要求が想定時間内に応答されているかどうかを確認するのに適しています。

Kubernetes APIサーバーへのリクエストのレイテンシーの99パーセンタイルを計算したい場合は、このクエリーを使用します。

histogram_quantile(0.99, sum(rate(rest_client_request_duration_seconds_bucket{container="kube-controller-manager"}[5m])) by (url, le))

rest_client_requests_total: このメトリクスは、kube-controller-managerに対するHTTPクライアントリクエストの数をHTTPレスポンスコード別に提供します。

HTTP 2xxクライアントリクエストのレートを取得したい場合は、以下のクエリーを実行します。これは、HTTP成功リクエストのレートをレポートします。

sum(rate(rest_client_requests_total{container="kube-controller-manager",code=~"2.."}[5m]))HTTP 3xxクライアントリクエストのレートは、以下のクエリーを使用します。HTTPリダイレクトのリクエスト数に対するレートが表示されます。

sum(rate(rest_client_requests_total{container="kube-controller-manager",code=~"3.."}[5m]))

次のクエリーは、クライアントエラーHTTPリクエストのレートを表示します。これを徹底的に監視して、クライアントエラーレスポンスを検出します。

sum(rate(rest_client_requests_total{container="kube-controller-manager",code=~"4.."}[5m]))

最後に、サーバーエラーのHTTPリクエストを監視したい場合は、以下のクエリーを使用します。

sum(rate(rest_client_requests_total{container="kube-controller-manager",code=~"5.."}[5m]))

process_cpu_seconds_total:  インスタンスごとの kube-controller-manager に費やされた CPU 時間の合計（秒）です。

以下のクエリーを実行することで、CPUレートの消費時間を取得することができます。

rate(process_cpu_seconds_total{container="kube-controller-manager"}[5m])

process_resident_memory_bytes: このメトリクスは、インスタンスごとのkube-controller-managerの常駐メモリサイズをバイト単位で測定します。

このクエリーで簡単にkube-controller-managerの常駐メモリサイズを監視することができます。

rate(process_resident_memory_bytes{container="kube-controller-manager"}[5m])

まとめ

今回は、Kubernetesコントローラーマネージャが、ウォッチ機構を介してKubernetes APIと通信することで、Kubernetesオブジェクトの望ましい状態に到達させる役割を担っていることを学びました。この内部コンポーネントは、Kubernetesのコントロールプレーン内の重要なピースであり、何か問題が発生した場合の防御のためにkube-controller-managerを監視することが鍵となります。

kube-controller-managerを監視し、問題のトラブルシューティングを最大10倍高速化します。

Sysdigは、Sysdig Monitorに含まれるアウトオブボックスのダッシュボードで、kube-controller-managerやKubernetesコントロールプレーンの他の部分の問題の監視とトラブルシューティングを支援します。Sysdig Monitorに統合されたツールであるAdvisorは、Kubernetesクラスターとそのワークロードのトラブルシューティングを最大10倍まで加速させます。

30日間のトライアルアカウントにサインアップして、ご自身でお試しください！