Kubernetes 監視の原則に関する深い理解

序文

上記に引き続き、 Ubuntu 2204をベースにku​​beadmを使用してk8sクラスターをデプロイし、 helmをベースにmetrics-serverをデプロイしました。

次に、 kubectl topコマンドを使用して、CPU やメモリなどのノードとポッドのリソース使用状況をリアルタイムで表示できます。

この記事では、そのデータリンクと実装原理を紹介し、k8s における監視システムについても説明します。

kubectlトップ

kubectl top はよく使用する基本コマンドですが、監視値を取得するにはmetrics-serverコンポーネントをデプロイする必要があります。

• Kubernetes 1.8 より前では、ヒーターをデプロイする必要がありましたが、これは現在非推奨になっています。
• kubernetes1.8 以降では、 metrics-server をデプロイする必要があります。

使用しているバージョンは最新バージョン 1.24.3 なので、必ずmetrics-server をデプロイしてください。

ノードのリソース使用状況を確認します。

 $ kubectl トップノード
名前CPU ( コア) CPU % メモリ( バイト) メモリ%
 k8s - unode1 158 m 7 % 1814 Mi 47 %
 k8s - unode2 50 m 2 % 874 Mi 23 %
 k8s - unode3 51 m 2 % 943 Mi 24 %
 k8s - unode4 45m 2 % 905mi 23 %
 $ kubectl トップノードk8s - unode1
 名前CPU ( コア) CPU % メモリ( バイト) メモリ%
 k8s - unode1 160 m 8 % 1811 Mi 47 %

ポッドのリソース使用量を確認します。 --containers はポッド内のすべてのコンテナを表示できます。

 $ kubectl top ポッド- n メトリック- サーバー
名前CPU ( コア) メモリ( バイト)
 メトリクス- サーバー- 56 c6866684 - w6n9b 5m 17mi
 $ kubectl top pod -- コンテナ- n メトリック- サーバー
POD 名CPU ( コア) メモリ( バイト)
 メトリクス- サーバー- 56 c6866684 - w6n9b メトリクス- サーバー5m 17mi

指標の具体的な意味:

• ここで、CPU mとメモリmi は、k8s のリクエストと制限と一致しています。 CPUユニット100m=0.1、メモリユニット1MI=1204Ki。
• ポッドのメモリ値は、ポッドの実際のメモリ使用量であり、制限を設定するときに OOM を決定する基礎にもなります。ポッドの使用量は、一時停止コンテナを除くすべてのビジネス コンテナの合計に等しくなります。 Cadvisr の container_memory_working_set_bytes メトリックに相当します。
• ノードの値は、ノード上のすべてのポッドの値の合計と等しくはなく、マシン上で top または free を直接実行して取得した値とも等しくありません。

kubectl top ポッドのメモリ計算

ポッドが起動されるたびに、一時停止コンテナが作成されます。コンテナなので、リソース（通常 2 ～ 3 MB のメモリ）を消費する必要があります。 cgroup ファイルでは、ビジネス コンテナーと一時停止コンテナーは同じ pod フォルダー内にあります。

ただし、cadvisor がポッドのメモリ使用量を照会する場合、まずポッドの下のコンテナ リストを取得し、次に各コンテナのメモリ使用量を 1 つずつ取得します。ただし、ここでのコンテナ リストには一時停止が含まれていないため、最終的なトップ ポッドの結果には一時停止コンテナは含まれません。

ポッドメモリ使用量の計算

kubectl top pod によって取得されるメモリ使用量は、cadvisor のcontainer_memory_usage_bytesではなく、次のように計算されるcontainer_memory_working_set_bytesです。

• container_memory_usage_bytes == container_memory_rss + container_memory_cache + カーネルメモリ。
• container_memory_working_set_bytes = container_memory_usage_bytes – total_inactive_file (非アクティブな匿名キャッシュ ページ)。

container_memory_working_set_bytes は、コンテナによって使用される実際のメモリ量であり、制限が設定されている場合に OOM を決定する基準にもなります。

kubectl top コマンドと top の違いは上記と同じであり、直接比較することはできません。同時に、ポッドに制限を設定した場合でも、ポッド内の top に表示されるメモリと CPU の合計量は、ポッドの割り当て可能な量ではなく、マシンの合計量のままです。

• プロセスの RSS は、プロセスによって使用されるすべての物理メモリ (file_rss + anon_rss)、つまり匿名ページ + マップされたページ (共有メモリを含む) です。
• cgroup RSS は (匿名およびスワップ キャッシュ メモリ) であり、共有メモリは含まれません。どちらにもファイル キャッシュは含まれません。

実施原則

データリンク

k8s ダッシュボード、kubectl top などはすべて、apiserver を通じて監視データを取得します。データリンクは次のとおりです。

• heapster を使用する場合: apiserver はプロキシを介してクラスター内の hepaster サービスにメトリック要求を直接転送します。
• metrics-server を使用する場合: apiserver はアドレス /apis/metrics.k8s.io/ を通じてメトリックにアクセスします。

監視システム

メトリック API の概念が提案されたとき、公式ページでは新しい監視システムが提案され、監視リソースは次の 2 つのタイプに分けられました。

• コアメトリクス: Kubelet、cAdvisor などからメトリクスデータを取得し、metrics-server によってダッシュボード、HPA コントローラーなどに提供します。
• カスタム メトリック: Prometheus アダプターは、Prometheus によって収集されたすべてのメトリックをサポートできる API custom.metrics.k8s.io を提供します。

• コア インジケーターには、ノードとポッドの CPU とメモリのみが含まれます。一般的に言えば、HPA にはコア指標で十分です。ただし、リクエスト qps/5xx エラー番号などのカスタム インジケーターに基づいて HPA を実装する場合は、カスタム インジケーターを使用する必要があります。
• 現在、Kubernetes のカスタム インジケーターは一般的に Prometheus によって提供され、その後、k8s-prometheus-adpater を使用して apiserver に集約され、コア インジケーター (metric-server) と同じ効果が得られます。

クベレット

廃止された heapster と metric-server はどちらも単なるデータ転送と集約です。どちらも kubelet API インターフェースを呼び出してデータを取得します。インジケーターを収集するための cAdvisor モジュールは実際には kubelet コードに統合されており、監視データは kubelet によって公開されるポート 10250 を通じて取得できます。

• Kubelet サマリー メトリック: 127.0.0.1:10250/metrics、ノードとポッドのサマリー データを公開します。
• Cadvisor メトリック: 127.0.0.1:10250/metrics/cadvisor、コンテナ メトリック データを公開します。

kubelet はメトリック インターフェースを提供しますが、実際の監視ロジックは組み込みの cAdvisor モジュールによって処理されます。

cアドバイザー

cAdvisor は Google によってオープンソース化されており、Go 言語で開発されています。プロジェクトアドレス: https://github.com/google/cadvisor。

cadvisor は、CPU 使用率、メモリ使用率、ネットワーク スループット、ファイル システム使用率など、マシン上で実行されているすべてのコンテナーに関する情報を収集できるだけでなく、他のコンポーネントによるデータ キャプチャを容易にするための基本的なクエリ インターフェイスと HTTP インターフェイスも提供します。 K8S では、デフォルトの起動項目として Kubelet に統合されており、k8s の公式標準となっています。

cadvisor がインジケーターを取得すると、実際には runc/libcontainer ライブラリが呼び出されます。libcontainer は cgroup ファイルのカプセル化です。つまり、cadvsior は単なるフォワーダーであり、そのデータは cgroup ファイルから取得されます。

cグループ

cgroup ファイル内の値は、次のような監視データの最終的なソースです。

• メモリ使用量の値は、/sys/fs/cgroup/memory/docker/[containerId]/memory.usage_in_bytes から取得されます。
• メモリ制限がない場合は Limit = machine_mem となり、それ以外の場合は /sys/fs/cgroup/memory/docker/[id]/memory.limit_in_bytes から取得されます。
• メモリ使用量 = memory.usage_in_bytes / memory.limit_in_bytes。

通常、cgroup フォルダーの内容には、CPU、メモリ、ディスク、ネットワークなどの情報が含まれます。

 デバイス: デバイス制御権限
cpuset: 指定されたCPUとメモリノードを割り当てる
cpu: CPU使用率を制御する
cpuacct: CPU 使用率の統計
メモリ: メモリ使用量の上限を制限する
freezer: Cgroup内のプロセスをフリーズする
net_cls: (トラフィックコントローラ) と連携してネットワーク帯域幅を制限する
net_prio: プロセスのネットワークトラフィックの優先度を設定する
huge_tlb: HugeTLBの使用を制限する
pref_event: perf ツールが cgrgoup グループに基づいてパフォーマンス監視を実行できるようにします。

メモリ内でよく使用されるいくつかのインジケーターの意味:

 memory.usage_in_bytes : 使用されているメモリの量（キャッシュとバッファを含む）（バイト単位）。Linux の userd_mem に相当します。
 メモリ。 limit_in_bytes : 制限されたメモリの合計量（バイト）。Linux の total_mem に相当します。
 メモリ。 failcnt : 失敗したメモリ要求の数
メモリ。 stat : メモリ関連のステータス
メモリ。 メムスワ。 usage_in_bytes : 使用されたメモリとスワップ
メモリ。 メムスワ。 limit_in_bytes : メモリとスワップを制限する
メモリ。 メムスワ。 failcnt : 失敗したメモリおよびスワップ要求の数