PerfectScale

kubectl top podでPodのCPU・メモリ使用量を可視化

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

Aug 30, 202610 min read

About Josh Palmer

Head of Content

I'm Josh Palmer, Head of Content at DoiT, where I split my time across multiple business units including DoiT Cloud Intelligence, PerfectScale (Kubernetes cost optimization), and SELECT (Snowflake, Databricks, and BigQuery cost optimization). Before DoiT, I spent four and a half years at OnBoard building content for a board intelligence platform used by 6,000+ organizations, and before that, two years as Content Marketing Manager at Zylo, a SaaS management platform.

My personal page

TLDR: kubectl top pod は、Metrics Serverを利用してPodごとのCPU(ミリコア)とメモリ(Mi/Gi)の使用量をリアルタイムに表示するコマンドです。リソースを大量に消費するPodの特定に活用でき、--sort-by=cpu/--sort-by=memory でのソートや、--containers によるコンテナ単位の内訳表示が可能です。実際の使用量を設定済みのrequests/limitsと比較すれば、スロットリングやOOM killが発生する前に、過剰・過少なプロビジョニングを検出できます。

この記事の内容:

kubectl top podを使うための前提条件
kubectl top podの基本構文
kubectl top podのユースケース
kubectl top podの出力の読み方
kubectl top podのベストプラクティス

kubectl top podとは

kubectl top pod コマンドを使うと、KubernetesクラスタにおけるPodのCPUおよびメモリ消費量を確認できます。その時点の「ライブ」なスナップショットとして機能し、リソースを大量に消費するワークロードの特定や、Horizontal Pod Autoscaler(HPA)がどのように判断を下しているかの検証に役立ちます。

前提条件:

このコマンドを使うには、クラスタ内に Metrics Server がインストールされ、稼働している必要があります。kube-system名前空間にmetrics-serverのデプロイメントが存在するかどうかで、稼働状況を確認できます。

よく使うコマンド:

現在の名前空間のPodを表示: kubectl top pod
すべての名前空間のPodを表示: kubectl top pod -A
特定の名前空間のPodを表示: kubectl top pod -n <namespace-name>
Pod内の各コンテナのメトリクスを表示: kubectl top pod --containers
特定のリソースでソート: kubectl top pod --sort-by=cpu または --sort-by=memory

出力の読み方:

列	意味
NAME	Podの名前。
CPU(cores)	「ミリコア」(m)単位のCPU使用量。1000mが1コアに相当します。
MEMORY(bytes)	メモリ使用量。通常はメガバイト(Mi)またはギガバイト(Gi)で表示されます。

この記事は、Kubernetesのパフォーマンスに関する連載記事の一部です。

kubectl top podを使うための前提条件

kubectl top pod を使うには、KubernetesクラスタにMetrics Serverがインストールされ、稼働している必要があります。Metrics Serverは各ノードのkubeletからCPUとメモリの使用量データを収集し、Kubernetes Metrics APIを通じて公開します。Metrics Serverがない場合、コマンドは Metrics API not available のようなエラーを返します。

Metrics Serverがインストールされているかどうかは、次のコマンドで確認できます:

kubectl get deployment metrics-server -n kube-system

インストールされていない場合は、Kubernetes公式のコンポーネントリポジトリからデプロイします:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

また、コマンドを実行するユーザーにはPodメトリクスへのアクセス権限が必要です。ロールベースアクセス制御(RBAC)が有効なクラスタでは、アカウントに metrics.k8s.io APIへのアクセス権が付与されている必要があります。

メトリクスが利用可能かどうかを確認するには、次を実行します:

kubectl top nodes

ノードのメトリクスが正常に表示されれば、通常はPodのメトリクスも利用できます。

kubectl top podの基本構文

コマンドの基本構文は次のとおりです:

kubectl top pod [POD_NAME] [flags]

現在の名前空間にあるすべてのPodのリソース使用量を表示するには:

kubectl top pod

出力例:

NAME                      CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    2m           15Mi
api-server-7f89c7d9d      25m          120Mi

フラグとオプション:

特定の名前空間のPodのメトリクスを表示するには:

kubectl top pod -n production

単一のPodの使用量を表示するには:

kubectl top pod nginx-6d4cf56db6-xk8rt

標準的なシェルツールと組み合わせて、Podをリソース消費量でソートすることもできます:

kubectl top pod --sort-by=memory

そのほかに便利なフラグとして、次のものがあります:

--containers — 各Pod内の個々のコンテナのメトリクスを表示します
--all-namespaces — すべての名前空間のPodを表示します
--no-headers — 出力から列ヘッダーを除去します

コンテナレベルのメトリクスの例:

kubectl top pod nginx-6d4cf56db6-xk8rt --containers

kubectl top podのユースケース

以下の表は、kubectl top pod コマンドで一般的なクラスタ運用タスクを実行する方法をまとめたものです。

ユースケース	コマンド	注意点とヒント
現在の名前空間にあるすべてのPodのリソース使用量を表示	`kubectl top pod`	アクティブな名前空間にあるすべてのPodのCPUとメモリの消費量を表示します。
特定の名前空間のPodのリソース使用量を表示	`kubectl top pod -n staging`	`-n` または `--namespace` で対象の名前空間を指定します。
すべての名前空間のメトリクスを表示	`kubectl top pod --all-namespaces`	クラスタ全体でリソースを大量に消費するワークロードを特定するのに便利です。
単一のPodの使用量を表示	`kubectl top pod frontend-5f76c7b9d8-rxk92`	指定したPodのメトリクスのみを表示します。
Pod内の個々のコンテナのメトリクスを表示	`kubectl top pod frontend-5f76c7b9d8-rxk92 --containers`	複数コンテナのPodで、どのコンテナがリソースを消費しているかを特定するのに役立ちます。
すべてのPodのコンテナレベルのメトリクスを表示	`kubectl top pod --all-namespaces --containers`	クラスタ全体のコンテナリソース使用量を詳細に可視化できます。
PodをCPU使用量でソート	`kubectl top pod --sort-by=cpu`	CPU消費量が最も多いPodを出力の先頭に表示します。
Podをメモリ使用量でソート	`kubectl top pod --sort-by=memory`	メモリを大量に消費するワークロードをすばやく特定するのに便利です。
スクリプトや自動化のために列ヘッダーを除去	`kubectl top pod --no-headers`	`awk` や `grep`、スクリプトなどで出力を処理しやすくなります。
最もリソースを消費しているPodを特定	`kubectl top pod --sort-by=memory \| head`	ソートとシェルユーティリティを組み合わせて、上位の結果のみを表示します。
Podのメトリクスを継続的に監視	`watch kubectl top pod`	メトリクスを定期的に更新し、CPUとメモリの使用傾向をほぼリアルタイムで確認できます。

kubectl top podの出力の読み方

kubectl top pod の出力は、Podの現在のCPUおよびメモリ使用量のスナップショットです。各列の意味を理解しておくと、リソースを大量に消費するワークロードの特定やパフォーマンス問題のトラブルシューティングに役立ちます。

出力例:

NAME                      CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    2m           15Mi
api-server-7f89c7d9d      25m          120Mi

各列の意味は次のとおりです:

NAME — Podの名前
CPU (cores) — 現在のCPU使用量
MEMORY (bytes) — 現在のメモリ消費量

CPUの値は通常、ミリコア(m)で表示されます:

1000m は1 CPUコアに相当
250m は0.25 CPUコアに相当

例:

2m はPodがごくわずかなCPUしか使用していないことを意味します
500m はPodがCPUコアの半分を消費していることを意味します

メモリの値はバイナリ単位で表示されます:

Ki = キビバイト
Mi = メビバイト
Gi = ギビバイト

表示される値は、Metrics Serverが収集した現在の使用量メトリクスです。過去の平均値ではないため、コマンドを実行するたびに変化する場合があります。このため、kubectl top pod は長期的なモニタリングよりも、運用時の簡易チェックに適しています。

コンテナ単位の出力:

--containers フラグを使うと、Pod内の各コンテナのメトリクスが出力に含まれます:

kubectl top pod nginx-6d4cf56db6-xk8rt --containers

出力例:

POD                       NAME    CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    nginx   2m           15Mi

top podの出力をPodの問題診断に活用する:

異常なリソース消費を確認したら、実際の使用量を設定済みのrequestsおよびlimitsと比較しましょう。これにより、Podが適切なサイズになっているか、あるいはパフォーマンスとリソース効率を改善するために調整が必要かを判断できます。

kubectl top podのベストプラクティス

このコマンドを使う際に役立つプラクティスをいくつか紹介します。

1. Metrics Serverが正常に稼働していることを確認する

kubectl top pod を活用する前に、クラスタ内でMetrics Serverが正しくインストールされ、正常に動作していることを確認しましょう。ステータスは kubectl get deployment metrics-server -n kube-system で確認でき、ログでエラーの有無をチェックできます。

Metrics Serverの設定に誤りがあったり正常に動作していなかったりすると、kubectl top pod は不完全なデータを返すか、コマンド自体が失敗する可能性があります。リソースメトリクスがワークロードの現状を正しく反映するように、Metrics Serverの状態を定期的に監視してください。

例:

kubectl --namespace=kube-system get deployment metrics-server

出力:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           45d

メトリクス収集の確認:

kubectl top nodes

出力:

NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
worker-node-1    420m         21%    3120Mi           39%
worker-node-2    365m         18%    2875Mi           36%

2. 必ず正しい名前空間を確認する

Kubernetesクラスタは複数の名前空間を持つことが多く、それぞれに異なるワークロードや環境が含まれています。kubectl top pod を使う際、デフォルト以外の名前空間で作業している場合は -n フラグで正しい名前空間を指定してください。

名前空間の指定を怠ると、問題を見逃したり、リソース使用量について誤った結論を導いたりする可能性があります。たとえば、デフォルトの名前空間しか確認していないと、ステージング環境でのリソース急増を見落とすかもしれません。

例:

kubectl --namespace production top pod

出力:

NAME                        CPU(cores)   MEMORY(bytes)
frontend-76d9c7f7f5-qn9p8   65m          210Mi
backend-5c8b7d9f67-jh2wt    220m         580Mi
redis-0                     15m          140Mi

3. CPUまたはメモリでソートして問題のあるPodを素早く見つける

PodをCPUまたはメモリ使用量でソートすると、最もリソースを消費しているPodが一目でわかります。--sort-by=cpu または --sort-by=memory を使うと、リソース消費の多いPodが出力の先頭に表示されます。リソース消費量に基づいてPodを確認することで、ボトルネックへの対処やキャパシティプランニングに役立ちます。

例:

kubectl top pods -n production --sort-by=memory

出力:

NAME                          CPU(cores)   MEMORY(bytes)
analytics-worker-7f4b7d5c8d   320m         1850Mi
api-server-6b8f4d5f4d         140m         720Mi
frontend-76d9c7f7f5           60m          220Mi

4. 使用量をrequestsおよびlimitsと比較する

リソースメトリクスを正しく解釈するには、kubectl top pod が報告する実際の使用量を、Pod仕様で定義されたrequestsおよびlimitsと比較しましょう。Podが頻繁にリソースリミットに近づいている場合、スロットリングや退避(eviction)が発生する可能性があります。逆に、requestsに対して常に使用量が低い場合は、過剰なプロビジョニングが疑われます。この比較により、リソース割り当てを調整し、OOMKill やCPUスロットリングといった問題を回避できます。

例:

現在の使用量を確認:

kubectl -n production top pod api-server-6b8f4d5f4d

出力:

NAME                     CPU(cores)   MEMORY(bytes)
api-server-6b8f4d5f4d    850m         920Mi

設定されたリソースを確認:

kubectl -n production describe pod api-server-6b8f4d5f4d

出力(抜粋):

Limits:
  cpu:     1
  memory:  1Gi
Requests:
  cpu:     500m
  memory:  512Mi

この例では、PodがCPUとメモリの両方のリミットに近づいており、調整が必要になる可能性があります。

5. ラベルを活用してワークロード単位でチェックする

Kubernetesのラベルを使うと、アプリケーション、環境、カスタムキーなどでPodを絞り込み・グループ化できます。kubectl top pod と -l フラグを組み合わせることで、特定のワークロード、チーム、マイクロサービスのリソース使用量を監視できます。

例:

特定のラベルを持つPodを取得:

kubectl -n production get pods -l app=web

出力:

NAME                       READY   STATUS
web-6d7f9d8f8b-7xt2m       1/1     Running
web-6d7f9d8f8b-kq4pn       1/1     Running

それらのPodのリソース使用量を確認:

kubectl top pod -n production | grep web

出力:

web-6d7f9d8f8b-7xt2m   35m   120Mi
web-6d7f9d8f8b-kq4pn   42m   135Mi

これにより、無関係なワークロードに目を通すことなく、特定のアプリケーションやサービスのリソース消費量を素早く評価できます。

PerfectScaleでPodリソースを継続的にライトサイジングする方法

kubectl top pod はCPUとメモリ使用量のリアルタイムなスナップショットを提供しますが、その値をもとに数百のワークロードに対して適切なrequestsとlimitsを設定し続けるのは、終わりのない手作業です。PerfectScaleのパフォーマンス最適化ソリューションは、ワークロードを自律的にライトサイジングし、ダウンタイムを防ぎ、99.99%の可用性に向けてリソース利用を最適化することでKubernetesのパフォーマンスを高めます。kubectl top pod で見つけた使用パターンを、安全でデータドリブンな設定変更へと直接つなげることができます。

PerfectScaleの主な機能:

問題の自動修復: OOM、CPUスロットリング、退避(eviction)といったリソースの過少プロビジョニングを含むレジリエンシーリスクを即座に特定・修正し、稼働時間を最大化してレイテンシを排除します。
CPUとメモリの自律的なライトサイジング: ワークロードを継続的に分析し、実際の需要に基づいてCPUとメモリのrequestsおよびlimitsをライトサイジング。スロットリングのリスクを低減しながらクラウドコストを削減し、kubectl top pod で検出できる過剰・過少なプロビジョニングに対処します。
インフラの強化: ノード全体を包括的に可視化し、設定ミスをプロアクティブに検出。精度の高いメモリリミット推奨によるノードのオーバーコミット防止、ノードアフィニティやtaintの検証、Podに最適なノードタイプの選定を実現します。
影響度に基づく優先順位付け: 自動優先順位付けにより重大な問題をリアルタイムで解決し、SLA/SLOに沿ったアラートを設定。Slack、MS Teams、Datadogなどのチャネルで即時通知し、ワンクリックで問題をチケットとしてエスカレーションできます。

手動のスナップショットから自律的な最適化へ移行しませんか? PerfectScaleがKubernetesのパフォーマンスをどう高めるかをご覧ください。

FAQ

kubectl top pod が「Metrics API not available」を返すのはなぜですか? クラスタにMetrics Serverがインストールされていないか、正常に動作していません。kubectl get deployment metrics-server -n kube-system で確認し、存在しない場合は公式のコンポーネントマニフェストからインストールしてください。

CPU(cores)列は実際に何を意味していますか? ミリコア(m)で表示されます。1000mが1 CPUコアに相当するため、250mはコアの4分の1、2mはごくわずかなCPU使用量を意味します。

kubectl top pod は長期的なモニタリングに適していますか? いいえ。Metrics Serverから取得するリアルタイムのスナップショットであり、過去の平均値ではないため、トレンド分析よりも運用時の簡易チェックに適しています。長期的なモニタリングにはPrometheus/Grafanaなどを使用してください。

Pod単位ではなくコンテナ単位のメトリクスを見るにはどうすればよいですか? --containers フラグを追加します: kubectl top pod <pod-name> --containers

名前空間内で最もリソースを消費しているPodを見つけるにはどうすればよいですか? kubectl top pod -n <namespace> --sort-by=cpu または --sort-by=memory を使うと、消費量の多い順にPodをソートできます。

Podのプロビジョニングが過少か過剰かを判断するにはどうすればよいですか? kubectl top pod によるリアルタイムの使用量を、Podに設定されたrequestsおよびlimits(kubectl describe pod で確認可能)と比較します。使用量が常にリミットに近い場合は過少プロビジョニングのリスクがあり、requestsを大きく下回る場合は過剰プロビジョニングが疑われます。