Kubectl Top が Kubernetes でリソース監視を実行する方法のクラウド ネイティブの詳細な分析

1. Kubectlトップの使用

• kubectl top は基本的なコマンドですが、監視値を取得するにはサポート コンポーネントをデプロイする必要があります。
• • 1.8 未満: ヒープターをデプロイします。
• • 1.8 以降: metric-server をデプロイします。
• kubectl トップ ノード: ノードの使用状況を確認します。

• kubectl トップ ポッド: ポッドの使用状況を確認します。

• ポッド名が指定されていない場合は、名前空間内のすべてのポッドが表示され、 –containers はポッド内のすべてのコンテナーを表示できます。

• インジケーターの意味:
• • k8s のリクエストと制限と一致し、CPU ユニット 100m=0.1 メモリユニット 1Mi=1024Ki。
• • ポッドのメモリ値は実際の使用量であり、制限を制限するときに oom を判断するための基礎でもあります。ポッドの使用量は、一時停止コンテナを除くすべてのビジネス コンテナの合計に等しく、その値は、container_memory_working_set_bytes インジケーターに等しくなります。 cadvisrで;
• • ノードの値は、ノード上のすべてのポッド値の合計と等しくなく、また、マシン上で直接 top または free を実行して表示される値とも等しくありません。

2. 実施原則

① データリンク

• kubectl top、k8s ダッシュボード、HPA などのスケジュール コンポーネントで使用されるデータは同じであり、データ リンクは次のとおりです。

• heapster を使用する場合、apiserver はプロキシ経由でクラスター内の hepaster サービスにメトリック リクエストを直接転送します。

• metrics-server を使用する場合: apiserver は /apis/metrics.k8s.io/ のアドレスを通じてメトリクスにアクセスします。

• kubect がポッドを取得するときのログを比較します。

②メトリクスAPI

• heapster はプロキシ転送を使用していることがわかりますが、metric-server と通常のポッドの両方が api/xx のリソース インターフェイスを使用しています。heapster によって採用されているプロキシ方式には問題があります。
• • proxy は単なるプロキシ リクエストであり、通常はトラブルシューティングに使用されますが、十分に安定しておらず、バージョンは制御できません。
• • heapster のインターフェースは、apiserver のような完全な認証とクライアント統合を行うことができず、汎用 apiserver などの両方の側を維持するにはコストがかかります。
• • ポッドの監視データはコア インジケーター (HPA スケジューリング) であり、ポッド自体と同じステータスを持つ必要があります。つまり、メトリックは metrics.k8s.io などの形式でリソースとして存在する必要があります。メトリクス API。
• 公式はバージョン 1.8 以降徐々にヒープスターを放棄し、上記の Metric API の概念を提案しました。metrics-server はこの概念の公式実装であり、kubelet からインジケーターを取得して以前のヒープスターを置き換えるために使用されます。

③kubeアグリゲーター

• metrics-server コンポーネントを使用すると、必要なデータが収集され、インターフェイスが公開されますが、このステップとヒープスターの間に違いはありません。最も重要なステップは、/apis/metrics.k8s.io リクエストをapiserver metrics-server コンポーネントの場合? 解決策は kube-aggregator です。
• kube-aggregator は apiserver の強力な拡張機能であり、k8s 開発者が独自のサービスを作成し、このサービスを k8s API に登録する、つまり API を拡張することができます。実際、metric-server はバージョン 1.7 で完成していますが、 in kube-aggregator が表示されるまで待ちます。kube-aggregator は apiserver の実装です。一部の k8s バージョンはデフォルトでは有効になっていません。これらの構成を追加して有効にできます。その中心となる機能は、動的登録、検出概要、セキュリティ プロキシです。

• たとえば、metric-server がポッドとノードを登録する場合:

④監視体制

• メトリクス API の概念を提案する際、担当者は新しい監視システムも提案しました。監視リソースは 2 つのタイプに分類されます。
• • コアメトリクス（コア指標）：Kubelet、cAdvisorなどから測定データを取得し、メトリクスサーバーによってDashboard、HPAコントローラなどに提供します。
• • カスタム メトリック: APIcustom.metrics.k8s.io は Prometheus アダプターによって提供され、Prometheus によって収集されたあらゆるメトリックをサポートできます。

• コア インジケーターには、ノードとポッドの CPU とメモリのみが含まれます。一般に、HPA にはコア インジケーターで十分ですが、要求された qps/5xx エラーの数などのカスタム インジケーターに基づいて HPA を実装する場合は、カスタムインジケーターを使用します。現在、Kubernetes のカスタム インジケーターは通常 Prometheus によって提供され、k8s-prometheus-adpater を使用して apiserver に集約され、コア インジケーターと同じ効果を実現します。

⑤キュベレット

• 前述したように、ヒープスターとメトリック サーバーはどちらも単なるデータ転送と集計であり、どちらも kubelet の API インターフェイスを呼び出すことによって取得されるデータであり、kubelet コード内のインジケーターの実際のコレクションは cadvisor モジュールです。ノードで使用されます。 監視データを取得するには、ポート 10255 (バージョン 1.11 以降はポート 10250) にアクセスします。
• • Kubelet 概要メトリクス: 127.0.0.1:10255/metrics、ノードとポッドの概要データを公開します。
• • Cadvisor メトリクス: 127.0.0.1:10255/metrics/cadvisor、コンテナーのディメンション データを公開します。
• 以下に示すように、コンテナーのメモリ使用量は次のとおりです。

• Kubelet はメトリクス インターフェイスを提供しますが、実際の監視ロジックは組み込みの cAdvisor モジュールが担当しており、進化のプロセスは次のとおりです。
• • k8s 1.6 以降、kubernetes は cAdvisor を kubelet に統合し始めており、個別の構成は必要ありません。
• • k8s 1.7 以降、Kubelet メトリクス API には cadvisor メトリクスが含まれなくなりましたが、概要用の独立した API インターフェイスが提供されます。
• • k8s 1.12 以降、cadvisor によって監視されるポートは k8s で削除され、すべての監視データは Kubelet の API によって提供されます。

⑥顧問

• Cadvisor は Google によってオープンソース化され、Go を使用して開発されています。Cadvisor は、CPU 使用率、メモリ使用量、ネットワーク スループット、ファイル システム使用率など、マシン上で実行されているすべてのコンテナに関する情報を収集できるだけでなく、基本的なクエリ インターフェイスと http インターフェイスも提供します。他のコンポーネントがデータをフェッチするのに便利です。
• K8S では、デフォルトの起動項目として Kubelet に統合されており、これが k8s の公式の標準構成です。cadvisor によって取得されるデータ構造の例:

• コア ロジックは、新しい MemoryStorage インスタンスと sysfs インスタンスを通じてマネージャー インスタンスを作成することです。マネージャーのインターフェイスには、コンテナーとマシンの情報を取得するための多くの関数が定義されています。

• cadvisor のインジケーターの解釈: cgroup-v1 (https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt)、cadvisor がインジケーターを取得するとき、実際には runc/libcontainer ライブラリを呼び出します。libcontainer はcgroup ファイルのパッケージ、つまり cadvsior は単なるフォワーダーであり、そのデータは cgroup ファイルから取得されます。

⑦ cgroup

• cgroup ファイル内の値は、次のような監視データの最終的なソースになります。
• • mem 使用量の値は /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、メモリ、ディスク、ネットワーク、その他の情報が含まれます。

devices：设备权限控制。
cpuset：分配指定的 CPU 和内存节点。
cpu：控制 CPU 占用率。
cpuacct：统计 CPU 使用情况。
memory：限制内存的使用上限。
freezer：冻结（暂停）Cgroup 中的进程。
net_cls：配合 tc(trafficcont.roller）限制网络带宽。
net_prio：设置进程的网络流量优先级。
huge_t1b：限制 HugeTLB 的使用。
perf_event：允许 PeIf 工具基于 Cgroup 分组做性能监测。

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

memory. usage_in_bytes      已使用的内存量(包含cache和buffeT）（字节），相当于1inux的usedmen
memory.limit_in_bytes       限制的内存总量(字节），相当于1inux的total_mem
memory.failent              申请内存失败次数计数
memory-mensw.usage_in_bytes 已使用的内存和swap(字节）
memory.memsw.Limit_in_bytes 限制的内存和swap容量（字节）
memory. memsw.failcnt       申请内存和swap失败次数计数
memory. stat                内存相关状态

• Memory.stat 内の情報が最も完全です。

3. 問題分析

① kubectl top がエラーを報告するのはなぜですか?

• 一般に、次のような上位のエラー レポートがあり、kubectl top pod -v=10 を使用して特定の呼び出しログを確認できます。
• • ヒープスターまたはメトリックサーバーがデプロイされていない場合、またはポッドが異常に実行されている場合は、対応するポッドのログを確認できます。
• • 表示されるポッドは構築されたばかりで、インジケーターはまだ収集されていないため、見つからないエラーが報告されます。デフォルトは 1 分です。
• 上記 2 つのどちらでも、kubelet のポート 10255 が開いているかどうかを確認できます。デフォルトでは、この読み取り専用ポートはインジケーターの取得に使用されます。証明書を heapster または metric-server の構成に追加して置き換えることもできます10250認証ポート付き。

② 一時停止コンテナを含む kubectl のトップポッドメモリを計算するにはどうすればよいですか?

• ポッドが開始されるたびに、一時停止コンテナが作成されます。コンテナであるため、リソースの消費が必要です (通常 2 ～ 3M のメモリ)。cgroup ファイルでは、ビジネス コンテナと一時停止コンテナは同じポッドの下にあります。フォルダ。
• ただし、cadvisor がポッドのメモリ使用量をクエリする場合、まずポッド配下のコンテナ リストを取得し、次にコンテナのメモリ使用量を 1 つずつ取得しますが、コンテナ リストには一時停止が含まれていないため、最終的な結果はトップポッドのメモリ使用量には一時停止コンテナポッドは含まれません メモリ使用量の計算 kubectlトップポッドで取得されるメモリ使用量はcadvisorのcontainer_memory_usage_bytesではなくcontainer_memory_working_set_bytesになります。
• • コンテナーメモリ_使用量_バイト = コンテナーメモリ_rss + コンテナーメモリ_キャッシュ + カーネル メモリ
• • container_memory_working_set_bytes =container_memory_usage_bytes – total_inactive_file (非アクティブな匿名キャッシュ ページ)。
• container_memory_working_set_bytes はコンテナが使用する実際のメモリ量であり、制限が制限されている場合の oom の判断基準にもなります。cadvisor のcontainer_memory_usage_bytes は、cgroup のmemory.usage_in_bytes ファイルに対応しますが、container_memory_working_set_bytes 用の特定のファイルはなく、その計算ロジックは次のように cadvisor のコード内にあります。

• 同様に、ノードのメモリ使用量もcontainer_memory_working_set_bytesになります。

③ kubectl のトップノードはどのように計算されますか?また、ノード上の直接トップとの違いは何ですか?

• kubectl トップ ノードによって取得される CPU およびメモリの値は、ノード上のすべてのポッドの合計ではないため、直接追加しないでください。最上位ノードは、マシンの cgroup ルート ディレクトリにある統計の概要です。

• マシン上の top コマンドで直接見られる値を kubectl のトップ ノードと直接比較することはできません。メモリなどの計算ロジックが異なるためです。おおよその対応関係は次のとおりです (前者はマシン上のトップ、後者はkubectlトップ):

rss + cache = (in)active_anon + (in)active_file

④ kubectlのtop podとexecがpodに入った後に表示されるtopは異なりますか？

• topコマンドの違いは上記と同じなので直接比較することはできませんが、Podに制限が設定されている場合でも、topからPod内で見えるメモリとCPUの合計量は依然として合計です。ポッドによって割り当てられる量ではなく、マシンの量です。
• • プロセスの RSS は、プロセスによって使用されるすべての物理メモリ (file_rss+anon_rss)、つまり匿名ページ + マップされた apge (共有メモリを含む) です。
• • cgroup RSS は (匿名およびスワップ キャッシュ メモリ) であり、共有メモリは含まれません。どちらにもファイルキャッシュは含まれません。

⑤ kubectl top podとdocker statsで取得される値が異なるのはなぜですか？

• docker stats dockerID は、コンテナーの現在の使用状況を確認できます。

• ポッド内にコンテナーが 1 つだけある場合、docker stats の値は kubectl top の値、container_memory_usage_bytes やcontainer_memory_working_set_bytes のいずれとも等しくないことがわかります。これは、docker stats と cadvisor の計算方法が異なり、全体の値が異なるためです。 kubectl top よりも小さくなります。計算ロジックは次のとおりです。

docker stats = container_memory_usage_bytes - container_memory_cache

4. まとめ

• 一般に、ノードやポッドの使用状況を常に気にする必要はありません。これら 2 種類のリソース変更に対処するためのクラスター オートスケーラーとポッド水平スケーリング (HPA) があり、リソース インジケーターの方がより意味があるためです。 prometheus を使用して、履歴を遡ったり、アラームを送信したりするために cadvisor のデータを保持するのに適しています。
• その他の追加事項:
• • kubectl のトップ ヘルプにはストレージがサポートされていることが示されていますが、バージョン 1.16 まではまだサポートされていません。
• • Heapster is required before 1.13, and metric-server is required after 1.13. kubectl トップ ヘルプのこの部分の出力は間違っており、その中で heapster のみが言及されています。
• • k8s ダッシュボードの監視グラフはデフォルトで heapster を使用します。metric-server に切り替えると、データが異常になります。インターフェース変換のために追加の metric-server-scraper ポッドをデプロイする必要があります。詳細は、ダッシュボードを参照してください。