Kubernetes APIサーバーを監視する方法

By 清水 孝郎 - NOVEMBER 17, 2022
Topics: オープンソース, モニタリング

SHARE:

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

Kubernetes APIサーバーを監視する方法を学ぶことは、Kubernetes環境でクラウドネイティブアプリケーションを実行する際に非常に重要です。

Kubernetes APIサーバーは、Kubernetesコントロールプレーンのフロントエンドと見なすことができます。ユーザーや内部のKubernetesコンポーネントとコントロールプレーンとのやり取りやリクエストは、すべてこのコンポーネントを経由します。Kubernetes APIサーバーを確実に適切に監視することは、Kubernetesクラスターが期待通りに動作することを保証するために極めて重要です。

The Kubernetes API Server is the control-plane frontend. Any incoming request, either external or internal is processed by the Kubernetes API Server.
Kubernetes APIサーバーは、コントロールプレーンのフロントエンドです。外部、内部を問わず、受信したリクエストはすべてKubernetes APIサーバーで処理されます。

エラーの監視や、レイテンシー、リクエスト、サチュレーション状態の測定により、Kubernetes APIサーバーのあらゆる問題を予期してください。

APIサーバーの監視についてもっと知りたくありませんか？重要なkube-apiserverのメトリクスが何であるか知りたいですか？

あなたは正しい場所にいます。読み続けてください。🔍

この記事では、以下のトピックを取り上げます。

  • Kubernetes APIサーバーとは？
  • Kubernetes APIサーバーを監視する方法
  • APIサーバーの監視：どのメトリクスを確認すればいいのか？
  • まとめ

Kubernetes APIサーバーとは？

Kubernetes APIサーバーは、Kubernetesクラスターの重要なコンポーネントです。本当にコントロールプレーンのコアと考えることができます。HTTP APIインターフェースを公開することでフロントエンドサービスを提供し、エンドユーザ、Kubernetesの他の内部コンポーネント、および外部コンポーネントが通信を確立できるようにします。Kubernetes APIインターフェースは、Kubernetesオブジェクトに関する情報を照会・要求する方法を提供すると同時に、KubernetesのAPIオブジェクト（Pod、デプロイ、ConfigMap、シークレット、ネームスペースなど）の状態を変更する際に使用するゲートウェイとなります。

In the Kubernetes diagram you can find the Kubernetes API server in the middle, as the frontend for every request from both external and internal requests.
Kubernetesの図では、真ん中にKubernetes APIサーバーがあり、外部と内部の両方のリクエストに対するフロントエンドとなっているのがわかると思います。

Kubernetes APIサーバーは、kube-systemネームスペースのPods内でコンテナ（kube-apiserver）として実行されます。アクセスを容易にするため、デフォルトのネームスペースにあるkubernetesというサービスを通じて公開されています。Kubernetes APIサーバーサービス（kubernetes.default.svc）にアクセスするPodは、Pod自体にマウントされたServiceAccountトークンを使って、Secure HTTPポート443を通じてアクセスを許可されます。

$ kubectl get pods -n kube-system |grep apiserver
kube-apiserver-k8s-control-1.lab.example.com            1/1     Running   6   54d
kube-apiserver-k8s-control-2.lab.example.com            1/1     Running   6   50d
kube-apiserver-k8s-control-3.lab.example.com            1/1     Running   6   50d

$ kubectl get svc kubernetes -n default
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   54d

Kubernetes APIサーバーのエンドポイントは、いずれもKubernetesの各ノード、あるいはクラスター内のこれらのノード上で動作するPodのいずれからもアクセス可能です。いずれにせよ、APIリクエストはデフォルトのkube-apiserverエンドポイントポートである6443を通じて行う必要があります。エンド ユーザーがこれらのエンドポイントのいずれかに直接接続しようとする場合、認証目的でクライアント証明書とキーの両方を所有する必要があります。また、Kubernetes 証明書に署名した認証局に依存するための CA 証明書も必要です。

$ kubectl get ep kubernetes -n default
NAME         ENDPOINTS                                                     AGE
kubernetes   192.168.119.30:6443,192.168.119.31:6443,192.168.119.32:6443   54d

適当なアプリケーションPodからKubernetes APIサーバーをcurlする方法を見てみましょう。

$ kubectl exec -it ratings-v1-85c74b6cb4-72tkm -n default -- /bin/bash
node@ratings-v1-85c74b6cb4-72tkm:/opt/microservices$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kuberntes.default.svc/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.119.30:6443"
    }
  ]

Kubernetes API サーバーにアクセスするもう 1 つの方法は、kubeconfig ファイルに埋め込まれた証明書を使用して、API と通信する kubectl CLI ツールを使用することです。 Kubernetes ユーザーが kubectl get pods (またはその他のオブジェクト) を実行したり、 kubectl edit を介してオブジェクトを編集したりするたびに、実際に起こっているのは、CLI が Kubernetes API サーバーと通信することです。

Kubernetes APIサーバーを監視する方法

前述の通り、APIサーバーはすでにインスツルメンテーションされており、Kubernetes APIサーバーを監視するためのメトリクスエンドポイントを提供しています。このエンドポイントは、追加のエクスポーターを必要とせず、非常に簡単にスクレイピングすることができます。kubernetesサービスのHTTPsポート（443）、またはエンドポイントのHTTPsポート（6443）のいずれかを介してアクセスするだけです。

では、どのようにメトリクスにアクセスするのか見てみましょう。🔧

エンドポイントに手動でアクセスする

curlやwgetを使って、ホストネットワーク上やデフォルトIPのSDNレンジ上のPodからkubernetesサービスにアクセスします。Kubernetesの証明書に署名した認証局に依存するためのCA (ca.crt) ファイルと、認証のためのトークンが必要です。Podに割り当てられたServiceAccountは、メトリクスエンドポイントにアクセスするのに十分なパーミッションを持っている必要があります。

$ kubectl get clusterrolebinding prometheus-server -n monitoring -o json|jq ".roleRef,.subjects"
{
  "apiGroup": "rbac.authorization.k8s.io",
  "kind": "ClusterRole",
  "name": "prometheus-server"
}
[
  {
    "kind": "ServiceAccount",
    "name": "prometheus-server",
    "namespace": "monitoring"
  }
]

$ kubectl get clusterrole prometheus-server -o json |jq ".rules[2]"
{
  "nonResourceURLs": [
    "/metrics"
  ],
  "verbs": [
    "get"
  ]
}

$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/metrics

# HELP aggregator_openapi_v2_regeneration_count [ALPHA] Counter of OpenAPI v2 spec regeneration count broken down by causing APIService name and reason.
# TYPE aggregator_openapi_v2_regeneration_count counter
aggregator_openapi_v2_regeneration_count{apiservice="*",reason="startup"} 0
aggregator_openapi_v2_regeneration_count{apiservice="k8s_internal_local_delegation_chain_0000000002",reason="update"} 0
aggregator_openapi_v2_regeneration_count{apiservice="v3.projectcalico.org",reason="add"} 0
aggregator_openapi_v2_regeneration_count{apiservice="v3.projectcalico.org",reason="update"} 0
# HELP aggregator_openapi_v2_regeneration_duration [ALPHA] Gauge of OpenAPI v2 spec regeneration duration in seconds.
# TYPE aggregator_openapi_v2_regeneration_duration gauge
aggregator_openapi_v2_regeneration_duration{reason="add"} 0.083819032
aggregator_openapi_v2_regeneration_duration{reason="startup"} 0.02308697

(output truncated)

よくできました！すでにkube-apiserverのメトリクスが手元にありますね!

それでは、PrometheusからこれらのKubernetes APIサーバーのメトリクスをどのようにスクレイピングするか、最も興味深い部分を見ていきましょう。

PrometheusでKubernetes APIサーバーのメトリクスをスクレイピングするための設定方法

このセクションでは、PrometheusインスタンスがKubernetes APIサーバーメトリクスエンドポイントからメトリクスをスクレイピングできるようにする方法について学びます。コミュニティのPrometheus Helmチャートを使ってPrometheusをデプロイした場合、この設定と他の設定はすでにデフォルトで有効になっていることに気づきます。

続いて、Prometheusのジョブが表示されます。PrometheusのConfigMapを編集して、scrape_configsセクションの下に追加するだけです。

$ kubectl get cm prometheus-server -n monitoring -o yaml > prometheus-server.yaml
$ vi prometheus-server.yaml
scrape_configs:
…
    - bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      job_name: kubernetes-apiservers
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - action: keep
        regex: default;kubernetes;https
        source_labels:
        - __meta_kubernetes_namespace
        - __meta_kubernetes_service_name
        - __meta_kubernetes_endpoint_port_name
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

同様に、Kubernetes APIサーバーメトリクスエンドポイントのスクレイピングに必要なClusterRoleは、コミュニティのPrometheus Helmチャートを使用してPrometheusをデプロイする際に、そのまま提供されます。そうでない場合は、ServiceAccountがすでに十分なパーミッションを持つClusterRoleにバインドされていることを確認してください。

rules:
- nonResourceURLs:
  - /metrics
  verbs:
  - get

次に、新しい設定を適用してPrometheus-serverのPodを再作成します。

$ kubectl replace -f prometheus-server.yaml -n monitoring
$ kubectl delete pod prometheus-server-5df7b6d9bb-m2d27 -n monitoring

apiserver_response_sizes_sum metric example.
apiserver_response_sizes_sum メトリクスの例です。

ConfigMapに新しいジョブが追加されたら、Prometheus Podを再作成して、再び起動するまで待ちます。PrometheusのWeb UIに移動し、Kubernetes APIサーバーのいずれかのメトリクスを探します。

APIサーバーの監視：どのメトリクスを確認すればいいのか？

Kubernetes APIサーバーを監視する方法はすでにご存知だと思いますが、まだ答えが出ていない質問が1つあります。どのメトリクスをチェックすべきなのか？

Kubernetes APIサーバーの主要メトリクスに興味がある方は、ペンと紙を手に取ってみてください! 📝

Kubernetes APIサーバーを監視するための4つのゴールデンシグナルということで、4つのカテゴリーに分けて考えてみましょう。

免責事項: APIサーバーのメトリクスは、Kubernetesのバージョンやプラットフォームによって異なる場合があります。ここでは、Kubernetes 1.25を使用しました。あなたのバージョンで利用可能なメトリクスは、Kubernetesのレポで確認できます（1.25バージョンのリンク）


レイテンシー

レイテンシーは、リクエストの処理にかかる時間として考えることができます。APIサーバーのリクエストのレイテンシーを監視するとよいでしょう。こうすることで、APIサーバーがどのように応答しているかをよりよく理解することができます。高いレイテンシーや時間の経過に伴うレイテンシーの増大は、APIサーバーのコンポーネントの一部にパフォーマンスや可用性の問題があることを示している可能性があります。レイテンシーを測定するために使用される以下のメトリクスは、verbごとにセグメント化することができます。そうすることで、問題に直面した場合、それが情報の読み取り（GET）または書き込み（POST）の問題であるかどうかなどを簡単に特定することができます。

  • apiserver_request_duration_seconds_bucket: このメトリクスは、Kubernetes APIサーバーへの各リクエストのレイテンシーを秒単位で測定します。データはverb、グループ、バージョン、リソース、コンポーネントなど、さまざまなカテゴリーに分類されます。verb間でレイテンシーがどのように分布しているかを確認するために、histogram_quantileを使用するとよいでしょう。

histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{job="kubernetes-apiservers"}[5m])) by (verb, le))

# HELP apiserver_request_duration_seconds [STABLE] Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.
# TYPE apiserver_request_duration_seconds histogram
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.005"} 7624
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.025"} 7977
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.05"} 7978
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.1"} 7980
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.2"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.4"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.6"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="0.8"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="1"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="1.25"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="1.5"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="2"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="3"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="4"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="5"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="6"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="8"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="10"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="15"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="20"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="30"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="45"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="60"} 7981
apiserver_request_duration_seconds_bucket{component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version="",le="+Inf"} 7981

(output truncated)

トラフィック

APIサーバーが処理したトラフィックの総量です。リソース（apiservices、daemonsets、Pods、namespaces、デプロイメントなど）ごとのリクエスト総量の確認、verb（GET、POST、LIST、WATCHなど）ごとの処理量の監視、さらにはリクエストごとやリクエストグループのHTTPコードも確認したい場合があるかと思います。2xx HTTPリクエストと4xxおよび5xx HTTPリクエストを測定して比較することで、トラフィック量の良し悪しを評価することができます。トラフィックやサチュレーションのメトリクスは、トラフィックの問題を特定し、相関させるのに役立ちます。

  • apiserver_request_total: このメトリクスは、Kubernetes APIサーバーへのリクエスト数、リクエスト元、アクセス先コンポーネント、成功したか否かをカウントするのに使用できます。Kubernetes APIサービス全体のリクエストの成功率を簡単に測定することができます（2xx HTTPレスポンスコードを確認する）。

sum(rate(apiserver_request_total{job="kubernetes-apiservers",code=~"2.."}[5m]))

# HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.
# TYPE apiserver_request_total counter
apiserver_request_total{code="0",component="apiserver",dry_run="",group="",resource="pods",scope="resource",subresource="exec",verb="POST",version="v1"} 3
apiserver_request_total{code="200",component="",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version=""} 7981
apiserver_request_total{code="200",component="",dry_run="",group="",resource="",scope="",subresource="/livez",verb="GET",version=""} 1602
apiserver_request_total{code="200",component="",dry_run="",group="",resource="",scope="",subresource="/readyz",verb="GET",version=""} 16006
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="cluster",subresource="",verb="LIST",version="v1"} 1
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="cluster",subresource="",verb="WATCH",version="v1"} 36
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="namespace",subresource="",verb="LIST",version="v1"} 89
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="namespace",subresource="",verb="WATCH",version="v1"} 1775
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="resource",subresource="",verb="GET",version="v1"} 7850
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="configmaps",scope="resource",subresource="",verb="PUT",version="v1"} 8704
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="endpoints",scope="cluster",subresource="",verb="LIST",version="v1"} 1
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="endpoints",scope="cluster",subresource="",verb="WATCH",version="v1"} 33
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="endpoints",scope="namespace",subresource="",verb="LIST",version="v1"} 1
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="endpoints",scope="resource",subresource="",verb="GET",version="v1"} 2121
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="endpoints",scope="resource",subresource="",verb="PUT",version="v1"} 1
apiserver_request_total{code="200",component="apiserver",dry_run="",group="",resource="events",scope="resource",subresource="",verb="PATCH",version="v1"} 570

(output truncated)

エラー

トラフィックを監視するのと同じ方法で、APIサーバーが処理しているエラーの割合と量を確認することができます。これはAPIサーバーレベル、あるいはコントロールプレーンの他のコンポーネントにおける問題を特定する簡単な方法です。

  • apiserver_request_total: 同じメトリクスを使って、今度は4xxと5xxのHTTPレスポンスコードを探して、エラーを測定することができます。

sum(rate(apiserver_request_total{job="kubernetes-apiservers",code=~"[45].."}[5m]))

リクエストの総量に対するエラー率を監視するのはさらに面白く、この方法でKubernetes APIサーバーのリクエストに対するエラーの大きさを知ることができます。

sum(rate(apiserver_request_total{job="kubernetes-apiservers",code=~"[45].."}[5m]))*100/sum(rate(apiserver_request_total{job="kubernetes-apiservers"}[5m]))

This metric helps you to get the error rate percentage vs the total API server requests.このメトリクスは、APIサーバーの総リクエスト数に対するエラー率のパーセンテージを取得するのに役立ちます。

サチュレーション

Kubernetes APIサーバーのCPU、メモリ、ネットワーク使用量などのシステムリソース消費メトリクスを使用して、Kubernetes APIのサチュレーション状態を簡単に監視することができます。

その他にも、Kubernetes APIサーバーのパフォーマンスをより深く理解するためのメトリクスがいくつかあります。

  • workqueue_adds_total: このメトリクスは、ワークキューで処理された追加数を測定します。

rate(workqueue_adds_total{job="kubernetes-apiservers"}[5m])

# HELP workqueue_adds_total [ALPHA] Total number of adds handled by workqueue
# TYPE workqueue_adds_total counter
workqueue_adds_total{name="APIServiceRegistrationController"} 1733
workqueue_adds_total{name="AvailableConditionController"} 17171
workqueue_adds_total{name="DiscoveryController"} 2150
workqueue_adds_total{name="DynamicCABundle-aggregator-proxy-cert"} 1
workqueue_adds_total{name="DynamicCABundle-client-ca-bundle"} 3
workqueue_adds_total{name="DynamicCABundle-request-header"} 3
workqueue_adds_total{name="DynamicCABundle-serving-cert"} 1
workqueue_adds_total{name="DynamicServingCertificateController"} 267
workqueue_adds_total{name="admission_quota_controller"} 925
workqueue_adds_total{name="autoregister"} 3896
workqueue_adds_total{name="cluster_authentication_trust_controller"} 267
workqueue_adds_total{name="crdEstablishing"} 0
workqueue_adds_total{name="crd_autoregistration_controller"} 2220
workqueue_adds_total{name="crd_finalizer"} 0
workqueue_adds_total{name="crd_naming_condition_controller"} 1944
workqueue_adds_total{name="crd_openapi_controller"} 1944
workqueue_adds_total{name="crd_openapi_v3_controller"} 1944
workqueue_adds_total{name="kubernetes_api_approval_conformant_condition_controller"} 1944
workqueue_adds_total{name="non_structural_schema_condition_controller"} 1944
workqueue_adds_total{name="open_api_aggregation_controller"} 32142
workqueue_adds_total{name="open_api_v3_aggregation_controller"} 48322
workqueue_adds_total{name="priority_and_fairness_config_queue"} 1

  • workqueue_depth：今回は、ワークキューの大きさを計測しています。ワークキューにあるアクションのうち、処理待ちのものがいくつあるか？

# HELP workqueue_depth [ALPHA] Current depth of workqueue
# TYPE workqueue_depth gauge
workqueue_depth{name="APIServiceRegistrationController"} 0
workqueue_depth{name="AvailableConditionController"} 0
workqueue_depth{name="DiscoveryController"} 0
workqueue_depth{name="DynamicCABundle-aggregator-proxy-cert"} 0
workqueue_depth{name="DynamicCABundle-client-ca-bundle"} 0
workqueue_depth{name="DynamicCABundle-request-header"} 0
workqueue_depth{name="DynamicCABundle-serving-cert"} 0
workqueue_depth{name="DynamicServingCertificateController"} 0
workqueue_depth{name="admission_quota_controller"} 0
workqueue_depth{name="autoregister"} 0
workqueue_depth{name="cluster_authentication_trust_controller"} 0
workqueue_depth{name="crdEstablishing"} 0
workqueue_depth{name="crd_autoregistration_controller"} 0
workqueue_depth{name="crd_finalizer"} 0
workqueue_depth{name="crd_naming_condition_controller"} 0
workqueue_depth{name="crd_openapi_controller"} 0
workqueue_depth{name="crd_openapi_v3_controller"} 0
workqueue_depth{name="kubernetes_api_approval_conformant_condition_controller"} 0
workqueue_depth{name="non_structural_schema_condition_controller"} 0
workqueue_depth{name="open_api_aggregation_controller"} 0
workqueue_depth{name="open_api_v3_aggregation_controller"} 0
workqueue_depth{name="priority_and_fairness_config_queue"} 0

まとめ

Kubernetes APIサーバーは、コントロールプレーンの中核となるものです。クエリー、Kubernetesオブジェクトに関する情報のリクエスト、およびこれらのオブジェクトのステータスに関する変更は、このコンポーネントを通じて処理されます。

Kubernetesクラスターの安定性とパフォーマンスを確保したい場合、Kubernetes APIサーバーを監視することは極めて重要です。このようなタスクに失敗すると、新しいPod、サービス、ReplicationControllerなどを停止、更新、開始できなくなるなど、ワークロードやサービスに多くの困難をもたらす可能性があります。

この記事では、Kubernetes APIサーバーを監視する方法と、Prometheusインスタンスを使用してメトリクスエンドポイントをスクレイピングする方法について学びました。さらに、主要な kube-apiserver メトリクスについて詳しく学んだので、API サーバーの監視を成功させるために必要なすべてのツールを手に入れることができました。

Kubernetes APIサーバーを監視し、問題のトラブルシューティングを最大10倍速く行うことができます

Sysdigは、Sysdig Monitorに含まれるアウトオブボックスのダッシュボードを使用して、Kubernetesクラスターの監視とトラブルシューティングを支援します。Sysdig Monitorに統合されたツールであるAdvisorは、Kubernetesクラスターとそのワークロードのトラブルシューティングを最大で10倍高速化します。

Thanks to the Sysdig Monitor out-of-the-box dashboards, you'll have all the Kubernetes API Server metrics handy.
Sysdig Monitorのアウトオブボックスダッシュボードを活用すると、Kubernetes APIサーバーのメトリクスをすべて手元に置いておくことができます。

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


https://youtu.be/2mbq9DxrsH4