状況HorizontalPodAutoscalerを設定して負荷に応じてデプロイメントがスケールアウトすることを期待していたのに、何も起きません。kubectl describe hpaを実行すると次のメッセージが表示されます：
Warning FailedGetResourceMetric 15s horizontal-pod-autoscaler unable to get metrics for resource cpu: no metrics returned from resource metrics API
HPAにはTARGETS: <unknown>/50%と表示され、Podが明らかに高負荷な状態でもレプリカ数は固定されたままです。
原因HPAコントローラーはCPUとメモリのデータをmetrics-serverに問い合わせます。metrics-serverがなければデータが取得できず、データがなければスケーリングの判断ができません。
主な原因は3つあります：
- クラスターにmetrics-serverがインストールされていない- metrics-serverは起動しているがヘルスチェックに失敗している（多くの場合はTLS/証明書の不一致）- metrics-serverが各ノードのkubeletに到達できない（ネットワークポリシーまたはAPIフラグの不足）## ステップ1：問題の確認まずHPAのステータスを確認します：
kubectl get hpa -n your-namespace
kubectl describe hpa your-hpa-name -n your-namespace
Eventsセクションまでスクロールすると、unable to get metricsの警告が確認できるはずです。
次に、metrics-serverがインストールされているか確認します：
kubectl get deployment metrics-server -n kube-system
Error from server (NotFound)と表示された場合はインストールされていません。存在する場合は実際に動作しているか確認します：
kubectl get pods -n kube-system | grep metrics-server
kubectl logs -n kube-system deployment/metrics-server
TLSの問題はログに明確に表示されます：
E0318 10:23:45.123456 1 scraper.go:139] "Failed to scrape node" err="Get \"https://192.168.1.10:10250/metrics/resource\": x509: certificate signed by unknown authority"
クイック修正：metrics-serverのインストールまたはパッチ適用### ケースA — metrics-serverがインストールされていない場合公式マニフェストを使用してインストールします：
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
約60秒待ってから確認します：
kubectl top nodes
kubectl top pods -n your-namespace
kubectl top nodesにデータが表示されればmetrics-serverは正常に動作しています。
ケースB — metrics-serverがインストール済みだがクラッシュしている場合（x509 / TLSエラー）ベアメタルクラスターやkubeadm環境ではこの問題が頻繁に発生します。kubeletが自己署名証明書を使用しており、metrics-serverはデフォルトでこれを拒否します。TLS検証を無効にするワンラインのパッチで解決できます：
kubectl patch deployment metrics-server -n kube-system \
--type='json' \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-insecure-tls"}]'
ロールアウトの完了を待ちます：
kubectl rollout status deployment/metrics-server -n kube-system
恒久的な修正：カスタムmetrics-serverマニフェスト再インストールのたびにkubectl patchを実行するのは手間がかかります。本番環境では、パッチ適用済みのcomponents.yamlをインフラリポジトリに保存しておきましょう。まず公式ファイルをダウンロードします：
curl -LO https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
ファイルを開き、DeploymentセクションのContainerのargsに--kubelet-insecure-tlsを追加します：
spec:
template:
spec:
containers:
- name: metrics-server
args:
- --cert-dir=/tmp
- --secure-port=10250
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --kubelet-use-node-status-port
- --metric-resolution=15s
- --kubelet-insecure-tls # この行を追加
適用します：
kubectl apply -f components.yaml
このファイルをリポジトリにコミットしておきましょう。再インストールやクラスターアップグレード後もこのフラグが維持されます。
Helmを使用する場合（代替方法）Helmでmetrics-serverを管理している場合は、インストール時にフラグを指定します：
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install metrics-server metrics-server/metrics-server \
--namespace kube-system \
--set args={--kubelet-insecure-tls}
修正の確認kubectl topがデータを返していることを確認します：
kubectl top nodes
# 期待される出力：
# NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
# node-1 245m 6% 2312Mi 30%
kubectl top pods -n your-namespace
# NAME CPU(cores) MEMORY(bytes)
# my-app-7d4b9c6f8-xk2pq 12m 128Mi
HPAを確認します — TARGETS列に<unknown>ではなく実際の数値が表示されるはずです：
kubectl get hpa -n your-namespace
# NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
# my-hpa Deployment/my-app 8%/50% 2 10 2
HPAをリアルタイムで監視します：
kubectl get hpa -n your-namespace -w
スケールアップのテストを行うには、Podに対してCPU負荷を発生させます。1〜2分以内にレプリカ数が増加し始めるはずです。
まだエラーが続く場合metrics-serverは正常に見えるのにTARGETSが依然として<unknown>の場合は、以下の点を確認してください：
- リソースリクエストが設定されていない：HPAはPodの
resources.requests.cpuを基準にCPU使用率を計算します。このフィールドがない場合、生のメトリクスが存在していても使用率の計算ができません。resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "256Mi"- APIアグリゲーションが登録されていない：一部のクラスターでは、メトリクスAPIエンドポイントが完全に欠落していることがあります。kubectl api-versions | grep metricsを実行してmetrics.k8s.io/v1beta1が出力に含まれているか確認してください。- NetworkPolicyがmetrics-serverをブロックしている：厳格なポリシーにより通信がサイレントにドロップされることがあります。kube-system内のmetrics-serverがすべてのノードのkubeletのポート10250に到達できることを確認してください。