メトリクスサーバーとKubectl Topを使用してKubernetesリソース使用量を監視する方法
Kubernetesクラスタのリソース使用状況を監視することは、パフォーマンスを追跡し、ワークロードが効率的に動作しているかどうかを理解するために不可欠です。kubectl topコマンドは、クラスタから直接メトリクスをストリーム配信し、ターミナルで基本情報にアクセスできるようにします。
このコマンドは、新しいKubernetes環境では通常すぐには動作しません。クラスターにMetrics Serverアドオンがインストールされているかどうかに依存します。このコンポーネントは、ノードとポッドからメトリクスを収集し、データを取得するためのAPIを提供します。
この記事では、Metrics Serverをインストールし、kubectl topを使用してその測定値にアクセスする方法を示します。各ノードとポッドのCPUおよびメモリ消費量を確認できるようになります。
Kubernetesにメトリクスサーバーを追加する
Kubernetesのディストリビューションには通常、Metrics Serverが組み込まれていません。クラスターがすでにサポートされているかどうかは、kubectl topを試して実行することで簡単に確認できます:
kubectl top node
error: Metrics API not available
エラーメッセージは、メトリクスサーバーAPIがクラスターに存在しないことを確認しています。
Metrics ServerはKubernetesの特別興味グループ（SIG）コミュニティ内で管理されています。これは、プレーンなYAMLマニフェストまたはプロジェクトのHelmチャートを使用して、クラスターに追加することができます。
このチュートリアルではマニフェストファイルを使用します。次のKubectlコマンドを実行してMetrics Serverをインストールします:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
Metrics Serverは、Kubernetesのリソース消費データを収集して公開し始めます。インストールがエラーで失敗した場合は、クラスターがプロジェクトの要件を満たしているかを確認する必要があります。Metrics Serverには、特定の依存関係があり、一部の環境ではサポートされていない場合があります。
多くのKubernetesディストリビューションは、自分たちのアドオンシステムを使用してMetrics Serverのサポートをバンドルしています。例えば、次のコマンドを使ってMinikubeクラスターにMetrics Serverを簡単に追加できます。
minikube addons enable metrics-server
Using image k8s.gcr.io/metrics-server/metrics-server:v0.4.2
The 'metrics-server' addon is enabled
Kubectl Top を使用してメトリックを取得する
Metrics Server がインストールされている状態で、kubectl top を実行して、それが収集した情報にアクセスできます。
node サブコマンドを使用して、クラスタ内の各ノードの現在のリソース利用状況を取得します:
kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
minikube 249m 3% 847Mi 2%
pod サブコマンドは、各ポッドに対する個別のメトリクスを提供します:
kubectl top pod
NAME CPU(cores) MEMORY(bytes)
nginx 120m 8Mi
これにより、default 名前空間にある Pods が表示されます。特定の名前空間の Pods に興味がある場合は、--namespace フラグを追加してください:
kubectl top pod --namespace demo-app
NAME CPU(cores) MEMORY(bytes)
nginx 0m 2Mi
--all-namespaces フラグもサポートされており、クラスター内のすべての Pod を一覧表示できます。
新しいPodが作成された後、メトリクスが利用可能になるまでに数分かかる場合があります。メトリクスサーバーのパイプラインには遅延があるため、それ自体がパフォーマンスの問題にならないようになっています。
「kubectl top」コマンドは、何十ものメトリクスで圧倒することはありません。CPUとメモリの使用状況の基本的な情報に焦点を当てています。この基本的なスタートは、全体の使用率の急増を引き起こしたPodを特定するなど、単純に迅速にデータが必要なシナリオには適しています。
混乱の一因は、CPU(cores)フィールドに報告された100mの値です。このコマンドは、CPUの使用率をミリコア単位で表示します。1000mの測定値は、常に1つのCPUコアの100%の消費を意味します。500mは1つのコアの50%の消費を示し、2000mは2つのコアが使用されていることを意味します。
オブジェクトのソート順を変更する
kubectl top コマンドは、出力されるオブジェクトリストを CPU またはメモリ消費量でオプションとしてソートできます。これにより、クラスタリソースへの圧力が最も高いノードやポッドを迅速に特定することが容易になります。
--sort-by フラグを cpu または memory としてその値を追加して、この動作を有効にします:
kubectl top pod --sort-by=memory
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
nginx-1 249m 3% 1790Mi 5%
nginx-2 150m 1% 847Mi 2%
オブジェクトリストのフィルタリング
他のKubectlコマンドと共通して、--selectorフラグを使用すると、特定のラベルを持つアイテムに対してオブジェクトリストをフィルタリングできます。
kubectl top pod --selector application=demo-app
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
nginx-1 249m 3% 1790Mi 5%
nginx-2 150m 1% 847Mi 2%
この例では、application: demo-appラベルを持つPodのみが出力に含まれます。=、==、および!=が演算子としてサポートされています。複数の制約は、application=demo-app,version!=1のようなカンマ区切りの文字列で連結することによって適用できます。オブジェクトは、クエリ内のすべてのラベルフィルターに一致する場合にのみ表示されます。
特定の資源の利用を得ること
top nodeおよびtop podのサブコマンドには、特定のノードまたはポッドの名前を渡して取得することができます。そのアイテムに関連付けられた現在のメトリクスが単独で表示されます。
コマンドに対してオブジェクトの名前を、node または pod の後に直接引数として入力してください:
kubectl top node minikube
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
minikube 245m 3% 714Mi 2%
要約
kubectl top コマンドは、Kubernetes クラスター内のノードとポッドの重要なリソース消費メトリクスを表示します。これを使って、各ワークロードに関連する CPU およびメモリ使用量を迅速に確認できます。この情報は、パフォーマンスの問題を診断し、別のノードを追加する時期を特定するのに役立ちます。
コマンドを使用する前に、クラスターにKubernetes Metrics Serverをインストールする必要があります。これにより、リソースの使用状況データを公開するAPIが提供されます。Metrics Serverを有効にすることはパフォーマンスのオーバーヘッドを伴いますが、通常はほとんどのデプロイメントでは無視できるものです。通常、監視されるノードごとに1mのCPUコアと2MiBのメモリが必要ですが、これは特定の環境で実行されるワークロードによって異なる場合があります。