本文の内容は、2020年2月26日にSysdigのCarlos Arillaが投稿したブログ(https://sysdig.com/blog/how-to-monitor-kube-controller-manager/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetesコントロールプレーンの主要コンポーネントであるkube-controller-managerのモニタリングを行う事は重要です。Kube-controller-managerはマスターノードで実行され、さまざまなコントローラープロセスを処理します。これらのコントローラーは、APIを通じてデプロイされたさまざまなサービスのステータスを監視し、実際のステータスと目的のステータスが一致しない場合に修正アクションを実行します。
Kube-controller-managerは、特にノード、ワークロード（レプリケーションコントローラー）、Namespace（ネームスペースコントローラー）、サービスアカウント（serviceaccountコントローラー）を処理します。
kube-controller-managerからメトリクスを取得する
Controller-managerは装備されており、デフォルトでPrometheusメトリクスを公開し、ワークキューとリクエストに関する情報をAPIに提供します。このエンドポイントは簡単にスクレイピングでき、計算する事なくこの情報をすべて取得できます。
マスターノードでネットワークアクセスを使用して、Podからcurlを実行する事で、エンドポイントをテストできます。
curl http://localhost:10252/metrics
この構造を持つメトリクスの長いリストを返します（省略）：
# HELP ClusterRoleAggregator_adds (Deprecated) Total number of adds handled by workqueue: ClusterRoleAggregator
# TYPE ClusterRoleAggregator_adds counter
ClusterRoleAggregator_adds 602
# HELP ClusterRoleAggregator_depth (Deprecated) Current depth of workqueue: ClusterRoleAggregator
# TYPE ClusterRoleAggregator_depth gauge
ClusterRoleAggregator_depth 0
# HELP ClusterRoleAggregator_longest_running_processor_microseconds (Deprecated) How many microseconds has the longest running processor for ClusterRoleAggregator been running.
# TYPE ClusterRoleAggregator_longest_running_processor_microseconds gauge
ClusterRoleAggregator_longest_running_processor_microseconds 0
# HELP ClusterRoleAggregator_queue_latency (Deprecated) How long an item stays in workqueueClusterRoleAggregator before being requested.
# TYPE ClusterRoleAggregator_queue_latency summary
ClusterRoleAggregator_queue_latency{quantile="0.5"} 0
ClusterRoleAggregator_queue_latency{quantile="0.9"} 0
...
APIエンドポイントを取得するようにPrometheusを構成する場合、このジョブをターゲットに追加できます。
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod_name
さらに、Podにアノテーションの追加が必要です。/etc/kubernetes/manifests/kube-controller-manager.manifestにあるマスターノードのマニフェストを変更し、これらをアノテーションの下に追加する必要があります。
prometheus.io/scrape: "true"
prometheus.io/port: "10252"
kube-controller-managerをモニタリングするとき、何を見る必要がありますか？
免責事項：kube-controller-managerメトリクスはKubernetesバージョン間で異なる場合があります。ここでは、Kubernetes 1.15を使用しました。 Kubernetesリポジトリ（1.15.3バージョンのリンク）で使用可能なバージョンのメトリクスを確認できます。
kube-controller-managerインスタンスの数：この値は、ノード内のkubeletの一般的な健全性を示します。期待される値は、クラスター内のノードの数です。Prometheusが見つけたターゲットをカウントするこの値を取得するか、ノードへのLowレベルのアクセス権がある場合はプロセスを確認します。
シングルの統計グラフに対して可能なPromQLクエリは次のとおりです。
sum(up{k8s_app="kube-controller-manager"})
ワークキュー情報：可能性のあるボトルネックまたは異なるコマンドの処理の問題を検出するために、ワークキューに関する情報をメトリクスで提供します。すべてのコントローラーからの集約されたメトリクスに焦点を当てますが、AWSコントローラー、ノードコントローラー、サービスアカウントコントローラーなど、さまざまなコントローラーのキューに使用できるさまざまなメトリクスがあります。
ワークキューのレイテンシー：kube-controller-managerが、クラスターの望ましい状態を維持するためにさまざまなアクションを実行するのにかかっている時間です。 これを表す良い方法は、変位値です：
histogram_quantile(0.99, sum(rate(workqueue_queue_duration_seconds_bucket{k8s_app="kube-controller-manager"}[5m])) by (instance, name, le))
ワークキューレート：単位時間あたりの必要なアクションの数です。値が高い場合、一部のノードのクラスターに問題がある可能性があります。
sum(rate(workqueue_adds_total{k8s_app="kube-controller-manager"}[5m])) by (instance, name)
ワークキューの深さ：キューで実行されるのを待っているアクションの数です。低い値のままにしてください。
sum(rate(workqueue_depth{k8s_app="kube-controller-manager"}[5m])) by (instance, name)
Api-serverへのリクエストに関する情報：api-serverに対して実行されたリクエストに関する情報を提供するため、接続が良好であり、api-serverがコントローラー操作の実行に必要な情報を提供していることを確認できます。
レイテンシー:
histogram_quantile(0.99, sum(rate(rest_client_request_latency_seconds_bucket{k8s_app="kube-controller-manager"}[5m])) by (url, le))
リクエストレートとエラー:
sum(rate(rest_client_requests_total{k8s_app="kube-controller-manager",code=~\"2..\"}[5m]))
sum(rate(rest_client_requests_total{k8s_app="kube-controller-manager",code=~\"3..\"}[5m]))
sum(rate(rest_client_requests_total{k8s_app="kube-controller-manager",code=~\"4..\"}[5m]))
sum(rate(rest_client_requests_total{k8s_app="kube-controller-manager",code=~\"5..\"}[5m]))
サチュレーションメトリクス(node_exporterが必要です):
CPU使用率：
rate(process_cpu_seconds_total{k8s_app="kube-controller-manager"}[5m])
メモリ使用率：
process_resident_memory_bytes{k8s_app="kube-controller-manager"}
kube-controller-managerにおける問題例
必要なワークロードと現在のステータスの不一致
これは多くの異なる問題によって引き起こされる可能性がありますが、kube-controller-managerは現在の状態と望ましい状態の調和を担当する主要なコンポーネントであるため、問題の原因が考えられます。kube-controller-managerインスタンスが起動していること、およびAPIリクエストとワークキューのレイテンシーが通常の値を下回っていることを確認してください。
Kubernetesは実行速度が遅いように思われる。
kube-controller-managerでレイテンシーとワークキューの深さを確認します。 APIでのアクションの実行に問題がある可能性があります。
Sysdig Monitorのkube-controller-managerメトリクス
SysdigモニターでAPIサーバーモニタリングを取得するには、エージェントのyaml設定ファイルにいくつかのセクションを追加する必要があります。
#Enable prometheus metrics
metrics_filter:
# beginning of kube-controller-manager
- include: "workqueue_adds_total"
- include: "workqueue_depth"
- include: "workqueue_queue_duration_seconds*"
- include: "rest_client_requests_total"
- include: "rest_client_request_latency_seconds*"
- include: "go_goroutines"
# end of kube-controller-manager
prometheus:
enabled: true
histograms: true
max_metrics: 3000
max_metrics_per_process: 3000
process_filter:
- include:
kubernetes.pod.label.k8s-app: kube-controller-manager
port: 10252
conf:
tags:
kubernetes.component.name: kube-controller-manager
host: 127.0.0.1
port: 10252
use_https: false
metrics_filterパーツを使用すると、カスタムメトリクスの制限によりこれらのメトリクスが破棄されないようにできます。このリストにないAPIサーバーが提供する特定のメトリクスに関心がある場合は、追加も可能です。
2番目の部分では、Sysdigエージェントがメトリクスをスクレイピングするように設定し、ラベルkube-controller-managerを持つKubernetes podを検索し、ポート10252を介してlocalhostをスクレイピングします。ローカルホストであるため、ノードIPを使用する必要はありません。
その後、これらのメトリクスを使用してカスタムダッシュボードを構築できます。 プレビルドのダッシュボードも用意していますので、興味がある方には共有させて頂く事もできます。
まとめ
モニターkube-controller-managerはKubernetesコントロールプレーンのキーコンポーネントであるため、非常に重要です。 kube-controller-managerは、すべてのデプロイメント、デーモンセット、永続ボリュームクレーム、および他の多くのkubernetes要素に正しい数の要素を持つことに責任があることに注意してください。
kube-controllerマネージャーの問題により、クラスターで実行されているアプリケーションのスケーラビリティと復元力が低下する可能性があります。 kube-controllerマネージャーをモニタリングすることで、検出するのが難しいこれらの複雑な問題を避けることができます。コントロールプレーンをモニタリングすることを忘れないでください！
Sysdigを活用する事は、Kubernetesモニタリングのベストプラクティスを踏襲するには非常に有効です。これは、クラスター内で実行されるワークロードとアプリケーションをモニタリングするのと同じくらい重要です。
より詳しく知りたい方は、https://sysdig.jp/を是非参照ください。試されたい方は、https://sysdig.jp/ 内の無料お試しをクリックすると14日間のトライアルライセンスが発行されます。