A Deep Dive into Kubernetes Metrics — Part 4

第4章 Kubernet APIサーバー

gavin.zhou
Sep 5, 2018 · 8 min read

TL;DR

このmulti-part seriesの第四章では、Kubernetクラスターで収集できる全てのメトリックについてお話します。

前回の第三章では、kubeletによってエクスポートされた全てのコンテナリソースメトリックについて詳しくお話しました。今回はKubernete APIサーバーによってエクスポートされたメトリックについてお話したいと思います。

Kubernet APIサーバーというのはKubernetがプロバイドする全ての機能に対応したインターフェースです。Kubernetの実行可能なオペーレションをすべてコントロールするためにAPIサーバーを使用します。この重要なコンポーネントをモニタリングすることは、確実にクラスターがスムーズに動作するために非常に重要なのです。

APIサーバーメトリックは以下のカテゴリーに分けられます。

  • リクエスト レートとレイテンシー
  • コントローラーのワーク クエリのパフォーマンス
  • Etcd helper cache ワーククエリ とキャッシュ パフォーマンス
  • 一般的な処理状況(ファイル デスクリプション/メモリー/CPU秒数)
  • Golang の状況(GC/メモリー/スレッド)

ここでは、マスターがあなたのためにホストされている環境でも、Kubernetes API サーバーからメトリックを取得するために使用するプロメテウスの構成は、次のとおりです。

- job_name: kubernetes-apiservers
scrape_interval: 10s
scrape_timeout: 10s
metrics_path: /metrics
scheme: https
kubernetes_sd_configs:
- api_server: null
role: endpoints
namespaces:
names: []
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
separator: ;
regex: default;kubernetes;https
replacement: $1
action: keep

今170以上のメトリックを集めている状況です。それでは、APIサーバーによって何が分かるようになるのか、見ていきましょう。


Request Rates and Latencies

このシリーズでは以前、重要なメトリックを選ぶために特別なメソッドを使うと述べました。第二章では、REDメソッド、レート、エラー、所要時間などは“サービス”にアプライされると説明しました。APIサーバーは、以前説明したその“サービス”のことです。それでは、それらのメトリックを見ていきましょう。

APIサーバーはKuberneten をnode,ポッド、ネームスペースのようなものだと理解しています。もしリソースがリクエストされる頻度を知りたいと思えば、 .というメトリックを参照すれば分かります。これがRateメトリックです。

sum(rate(apiserver_request_count[5m])) by (resource, subresource, verb)

このレートメトリックでは“ヴァーブ(動詞)”によって全てのKubernetリソースの5分のレートが表示されます。この場合のヴァーブ(動詞)というのはHTTP動詞のことで、WATCH, PUT, POST, PATCH, LIST, GET, DELETE, CONNECTを指します。

APIサーバーのErrorsはHTTP 5xxエラーとしてトラックされます。リクエストレートに対してのエラー率を算出するためにこのクエリを使います。

rate(apiserver_request_count{code=~"^(?:5..)$"}[5m]) / rate(apiserver_request_count[5m])

所要時間に関しては、全てのリソースとヴァーブのためにp90thレイテンシーを参照しましょう。そしてこのメトリック:を使ってください。

histogram_quantile(0.9, sum(rate(apiserver_request_latencies_bucket[5m])) 
by (le, resource, subresource, verb) ) / 1e+06

Performance of Controller Work Queues

Kubernet クラスターに送信したすべてのワークはコントローラーによって管理されています。このワークはキューされ、コントローラーはキューをそのコントロール ループとして動かします。多くのメトリックがワーク キューのパフォーマンスについて収集されます。

どのコントローラーにおいても、APIサーバーからリポートされた9つのシリーズが存在します。それでは、 コントローラーメトリックを例として使ってみましょう。

  • —システムのアド数を数える。このバリューに対してはrate()を使う
  • —ワーク キューのデプス。一般的には、これはいつもzeroに近い値になる
  • — キューの中に存在していたメトリックの合計の文意数を含む
  • — ワークキューの中にあったアイテムの数のカウントを含む(一番最後のリスタートから数える)
  • — このワークキューの中で存在していた全ての時間の合計を含む
  • —リトライの数のカウンター
  • —実行中のメトリックの合計の分位数を含む
  • —ワークキューの中のアイテムの数のカウントを含む
  • —全ての処理時間の合計の合計を含む

Etcd Interactions

APIサーバーはetcdから対象としたもののwrite-throughキャッシュを保持します。メトリックは以下のようになります。

  • — キャッシュの中のエレメントの数
  • — キャッシュhit回数
  • — ミスカウントしたキャッシュ
  • —キャッシュにエントリーを追加するための時間(マイクロセカンド)
  • — キャッシュアドの数のためのカウンター
  • — キャッシュにアイテムを入れ込む時間の総合計
  • — キャッシュからのエントリーを得るための時間(マイクロセカンド)
  • — キャッシュが獲得した数のためのカウンター
  • — キャッシュからアイテムを取得している時間の総合計

Standard Prometheus Golang Client Library Metrics

Prometheusのためのgolang client libraryは実行中の多くのメトリックやgolangのランタイムを収集しています。ここですべてのメトリックを例に挙げて説明することはしませんが、こちらでプロセスメトリックの定義、こちらでgolangメトリックの定義をご自身で確認して頂けますのでご覧ください。

まとめ

Kuberneteの場合と同じく、APIサーバーはPtometheusメトリックフォーマットを使ったとても素晴らしい機能を持ち合わせています。


Orangesys.ioでは、kuberneteクラスターの内部動作を明らかにするお手伝いをぜひ私たちにおまかせください。

Orangesys

Orangesys Inc.

gavin.zhou

Written by

gavin@orangesys.io

Orangesys

Orangesys

Orangesys Inc.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade