本文の内容は、2020年10月15日にDavid Lorite Solanasが投稿したブログ(https://sysdig.com/blog/monitor-kube-proxy/)を元に日本語に翻訳・再構成した内容となっております。
この記事では、クラスターネットワークの正しい健全性を確保するためにkube-proxyを監視する方法を学びます。Kubernetesコントロールプレーンの主要なコンポーネントの1つであり、クラスターの頭脳です。
Kubernetesの利点の一つは、ネットワークやポッドが物理的にどのように相互接続しているかを気にしなくて済むことです。
kube-proxyから最も重要なメトリクスを収集し、このサービスを監視するためにそれらを使用する方法を学ぶために読み進めてください。
kube-proxy とは何ですか？
kube-proxy はネットワークプロキシとロードバランスの実装で、各ノードと api-server のリンクとして機能します。クラスタの各ノードで動作し、クラスタの内外からポッドに接続することができます。 kube-proxyは各ノードに存在します。
kube-proxyを監視する方法
マスターノードを除くすべてのクラスタノードで、kube-system ネームスペースの下にある kube-proxy を監視する必要があります。
kube-proxy からのメトリクスの取得
Kubernetes の他のコントロールプレーンパーツと同様に、kube-proxy には Prometheus のメトリクスがインスツルメントされており、デフォルトでは 10249 番ポートで公開されています。このメトリクスのエンドポイントは簡単にスクレイプすることができ、追加のスクリプトやエクスポーターを必要とせずに有用な情報を得ることができます。
メトリクスが公開されているので、curl で各 kube-proxy ポッドをスクレイプするだけです。
curl https://[kube_proxy_ip]:10249/metrics
これは、この構造を持つメトリクスの長いリスト(省略)を返します。
...
# HELP rest_client_request_duration_seconds Request latency in seconds. Broken down by verb and URL.
# TYPE rest_client_request_duration_seconds histogram
rest_client_request_duration_seconds_bucket{url="/https://XXXX%7Bprefix%7D",verb="GET",le="0.001"} 41
rest_client_request_duration_seconds_bucket{url="https://XXXX/%7Bprefix%7D",verb="GET",le="0.002"} 88
rest_client_request_duration_seconds_bucket{url="https://XXXX/%7Bprefix%7D",verb="GET",le="0.004"} 89
rest_client_request_duration_seconds_count{url="https://XXXX/%7Bprefix%7D",verb="POST"} 7
# HELP rest_client_request_latency_seconds (Deprecated) Request latency in seconds. Broken down by verb and URL.
# TYPE rest_client_request_latency_seconds histogram
rest_client_request_latency_seconds_bucket{url="https://XXXX/%7Bprefix%7D",verb="GET",le="0.001"} 41
...
rest_client_request_latency_seconds_sum{url="https://XXXX/%7Bprefix%7D",verb="POST"} 0.0122645
rest_client_request_latency_seconds_count{url="https://XXXX/%7Bprefix%7D",verb="POST"} 7
# HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host.
# TYPE rest_client_requests_total counter
rest_client_requests_total{code="200",host="XXXX",method="GET"} 26495
rest_client_requests_total{code="201",host="XXXX",method="POST"} 1
rest_client_requests_total{code="<error>",host="XXXX",method="GET"} 91
Prometheus サーバで kube-proxy をスクレイプするように設定したい場合は、次のジョブをスクレイプ設定に追加してください。
- job_name: kube-proxy honor_labels: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: '/' regex: 'kube-system/kube-proxy.+' - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\:\\d+)?
replacement: $1:10249
必要に応じて独自のラベルやリラベル設定でカスタマイズすることを忘れないでください。
kube-proxyの監視：何を見ればいいのか？
kube-proxyの監視にはGolden Signalsを使用する必要があります。Golden Signalsは、サービスが顧客のためにどのようにパフォーマンスを発揮しているかについて適切な洞察を与えるメトリクスを通してサービスを監視する技術です。これらのメトリクスは、レイテンシー、リクエスト、エラー、サチュレーションです。
免責事項: kube-proxyのメトリクスはKubernetesのバージョンによって異なる場合があります。ここではKubernetes 1.18を使用しました。バージョンに応じたメトリクスは Kubernetes repo で確認できます (1.18.3 バージョンの場合はリンク)。
Kubeのプロキシノードが立ち上がっている チェックすべき主要なメトリクスは、各作業ノードで kube-proxy が稼働しているかどうかです。Kube-proxy はデーモンセットとして動作しているため、up メトリクスの合計が作業ノードの数と同じであることを確認する必要があります。
Kube-proxy ポッドが起動していることを確認するアラートの例は次のようになります。
sum(up{job=\"kube-proxy\"}) < number of working nodes
Rest クライアントの待ち時間：この情報はメトリクスrest_client_request_duration_seconds_bucketにあります。
# HELP rest_client_request_duration_seconds Request latency in seconds. Broken down by verb and URL.
# TYPE rest_client_request_duration_seconds histogram
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.001"} 41
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.002"} 88
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.004"} 89
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.008"} 91
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.016"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.032"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.064"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.128"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.256"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="0.512"} 93
rest_client_request_duration_seconds_bucket{url="https://URL/%7Bprefix%7D",verb="GET",le="+Inf"} 93
rest_client_request_duration_seconds_sum{url="https://URL/%7Bprefix%7D",verb="GET"} 0.11051893900000001
rest_client_request_duration_seconds_count{url="https://URL/%7Bprefix%7D",verb="GET"} 93
このアラートは、過去5分間にクラスターネットワークで遅いPOSTリクエストが60件以上あった場合に警告します。
histogram_quantile(0.99, sum(rate(rest_client_request_duration_seconds_bucket{job="kube-proxy",verb="POST"}[5m])) by (verb, url, le)) > 60
ルール syncレイテンシー：kube-proxy は常にノード間でネットワークルールを同期しています。このプロセスにかかる時間をチェックするのは良いアイデアです。
# HELP kubeproxy_sync_proxy_rules_duration_seconds SyncProxyRules latency in seconds
# TYPE kubeproxy_sync_proxy_rules_duration_seconds histogram
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.001"} 2
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.002"} 2
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.004"} 2
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.008"} 2
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.016"} 2
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.032"} 75707
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.064"} 199584
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.128"} 209426
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.256"} 210353
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="0.512"} 210411
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="1.024"} 210429
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="2.048"} 210535
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="4.096"} 210550
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="8.192"} 210562
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="16.384"} 210565
kubeproxy_sync_proxy_rules_duration_seconds_bucket{le="+Inf"} 210567
kubeproxy_sync_proxy_rules_duration_seconds_sum 8399.833554354082
kubeproxy_sync_proxy_rules_duration_seconds_count 210567
リクエストのコード：クラスタ内のすべての HTTP リクエストの HTTP レスポンスコードを監視する必要があります。エラーのあるリクエストの数が増えている場合は、何かが間違っている可能性があります。
# HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host.
# TYPE rest_client_requests_total counter
rest_client_requests_total{code="200",host="host_url",method="GET"} 26495
rest_client_requests_total{code="201",host="host_url",method="POST"} 1
rest_client_requests_total{code="<error>",host="host_url",method="GET"} 91
rest_client_requests_total{code="<error>",host="host_url",method="POST"} 6
例えば、コード5xxでリクエスト数の増加を警告するには、以下のようなアラートを作成します。
sum(rate(rest_client_requests_total{job="kube-proxy",code=~"5.."}[5m])) by (host,method)/sum(rate(rest_client_requests_total{job="kube-proxy"}[5m])) by (host,method) > 0.10
kube-proxyのメトリクスをSysdig Monitorで監視する
Sysdig Monitorでkube-proxyをトラッキングするためには、SysdigエージェントのYAML設定ファイルにいくつかのセクションを追加し、Prometheusサーバーを使用してメトリクスをフィルタリングする必要があります。
中間のPrometheusサーバーを使わないという選択もできますが、kube-proxyは多くのメトリクスを提供していることを覚えておかなければなりません。必要なのはそのうちのいくつかだけなので、この戦略は物事を非常に単純化します。
まず第一に、Prometheus サーバが稼働している必要があります。
もし、それを持っていないのであれば、心配する必要はありません。新しいPrometheusのデプロイは、2つのコマンドを実行するだけで簡単です。1つ目はPrometheus用のネームスペースを作成し、2つ目はhelm 3を使ってデプロイします。
kubectl create ns monitoring
helm install -f values.yaml prometheus -n monitoring stable/prometheus
values.yamlファイルの内容は以下のようになります。
server: strategy: type: Recreate podAnnotations: prometheus.io/scrape: "true"
prometheus.io/port: "9090"
Prometheus が稼働したら、必要なメトリクスを選択するためのフィルタリングルールを作成する必要があります。これらのルールは、どのメトリクスが収集されるべきかを知るためにSysdigエージェントによって使用されるカスタムラベルを持つ新しいメトリクスを作成します。
ルールはPromCat.ioで見つけることができます。また、Sysdigでkube-proxyを監視するために必要な全てのステップを見つけることができます。
これはエージェントのconfigmapの例です：
apiVersion: v1
kind: ConfigMap
metadata:
name: sysdig-agent
namespace: sysdig-agent
data:
prometheus.yaml: |-
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'prometheus' # config for federation
honor_labels: true
metrics_path: '/federate'
metric_relabel_configs:
- regex: 'kubernetes_pod_name'
action: labeldrop
params:
'match[]':
- '{sysdig="true"}'
sysdig_sd_configs:
- tags:
namespace: monitoring
deployment: prometheus-server
まとめ
kube-proxy は通常、クラスターの中で忘れ去られている部分ですが、kube-proxy に問題があるとクラスターネットワークがダウンしてしまうことがあります。何か変なことが起こっているときには、それについてアラートを出しておく必要があります。
Sysdig Monitor での kube-proxy の監視は簡単です。たった一つのツールで、kube-proxyとKubernetesの両方を監視することができます。Sysdig Monitorエージェントがkube-proxyのメトリクスを全て収集してくれるので、最も重要なkube-proxyのアラートを素早く設定することができます。
まだSysdig Monitorをお試しになっていない方は、1クリックで無料トライアルをお試しいただけます。