<think>我们正在处理用户关于
kubectl top pods命令返回
错误的
问题，
错误信息为：
Error from server (ServiceUnavailable): the server is currently unable to handle
the request
(get
pods.metrics.k8s.io
)
根据引用内容，这个
问题通常与metrics-
server有关，因为metrics-
server负责提供资源指标数据。下面我们将逐步分析可能的原因和
解决方法。
步骤1：检查metrics-
server是否安装并运行
首先，我们需要确认metrics-
server是否已经部署在kube-system命名空间中，并且其Pod处于运行状态。
执行以下
命令：
kubectl get deployment metrics-
server -n kube-system
kubectl get
pods -n kube-system -l k8s-app=metrics-
server
如果metrics-
server没有部署，则需要安装它。如果已经部署，但Pod没有正常运行，则需要检查Pod的日志以排查
问题：
kubectl logs -n kube-system [metrics-
server-pod-name]
步骤2：检查metrics-
server的日志
如果metrics-
server的Pod处于CrashLoopBackOff状态或不断重启，查看日志可能会发现具体
错误。常见
问题包括：
- 网络
问题：metrics-
server无法与kube-ap
iserver通信，或者无法访问各节点上的kubelet。
- 证书
问题：metrics-
server使用自签名证书，而kubelet默认不信任，需要配置metrics-
server使用正确的证书。
步骤
3：检查metrics-
server的配置
根据引用[4]中提到，在部署metrics-
server时，可能需要修改其部署配置，添加一些参数来绕过证书验证或指定使用节点的主机名。
常见的配置修改是添加以下
命令行参数：
--kubelet-insecure-tls # 不验证kubelet的证书（仅用于测试环境，生产环境建议配置正确证书）
--kubelet-preferred-address-types=InternalIP # 或者使用InternalIP、Hostname等，根据你的网络环境选择
在metrics-
server的Deployment中，可以在容器
命令部分添加这些参数。例如：
containers
:
- name
: metrics-
server
image
: k8s.gcr.io/metrics-
server/metrics-
server:v0.6.1
args
:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
步骤4：检查kube-ap
iserver的配置
引用[4]中提到，需要确保kube-ap
iserver启用了聚合层（Aggregator Layer），即添加了--enable-aggregator-routing=true参数。
检查kube-ap
iserver的启动参数（在master节点上）：
ps -ef | grep kube-ap
iserver | grep enable-aggregator-routing
如果没有启用，需要修改kube-ap
iserver的配置文件（通常是/etc/kubernetes/manifests/kube-ap
iserver.yaml），添加以下参数：
- --enable-aggregator-routing=true
修改后，kube-ap
iserver会自动重启。
步骤5：检查网络
问题
引用[5]中提到，由于网络
问题（如Calico网络配置）导致metrics-
server的Pod与节点之间无法通信。
可以尝试在metrics-
server的Pod内部ping其他节点的IP，或者从节点上ping metrics-
server的Pod IP，检查网络连通性。
如果发现
问题，可能需要调整网络插件（如Calico）的配置。例如，在跨子网的情况下，使用IPIP模式或CrossSubnet模式。
步骤6：重新部署metrics-
server
如果以上步骤无法
解决问题，可以尝试删除metrics-
server并重新安装。确保使用正确的配置。
总结：
解决步骤大致如下：
1. 确认metrics-
server是否安装并运行。
2. 检查metrics-
server的日志，排查
错误。
3. 修改metrics-
server的部署参数，如添加`--kubelet-insecure-tls`等。
4. 检查kube-ap
iserver是否启用聚合层。
5. 检查网络连通性，特别是metrics-
server与各节点之间的网络。
根据引用[
3]和[4]的提示，我们通常可以通过修改metrics-
server的部署配置来
解决证书
问题和网络
问题。
下面是一个修改metrics-
server部署的示例：
kubectl edit deployment metrics-
server -n kube-system
在容器args中添加：
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
保存后，metrics-
server会重新部署。然后等待几分钟，再次尝试运行`
kubectl top nodes`或`
kubectl top pods`。
如果
问题仍然存在，请根据具体
错误信息进一步排查。
注意：在生产环境中，不建议使用`--kubelet-insecure-tls`，而应该配置正确的证书。但在测试环境中，这可以快速
解决问题。
如果用户使用的是k
3s，引用[
3]提到，k
3s默认已经集成了metrics-
server，但可能没有启用。可以通过以下方式启用：
在启动k
3s
server时添加参数`--d
isable metrics-
server`的相反操作（即确保没有禁用），或者使用以下
命令启用：
可以参考k
3s文档：https
://docs.k
3s.io/zh/installation/options#配置选项
对于k
3s，也可以尝试重新安装metrics-
server，例如：
kubectl apply -f https
://github.com/kubernetes-sigs/metrics-
server/releases/latest/download/components.yaml
然后同样需要修改部署参数（添加args）以
解决证书
问题。
希望这些步骤能帮助用户
解决问题。</think>###
解决 `
kubectl top pods` 报错：`
ServiceUnavailable (get
pods.metrics.k8s.io
)`
此
错误通常表明 **Metrics
Server**（负责收集集群资源指标的核心组件）未正常运行或配置有误。以下是逐步
解决方案：
---
### 步骤 1：检查 Metrics
Server 状态
```bash
# 检查 Deployment 状态
kubectl get deployment metrics-
server -n kube-system
# 检查 Pod 日志（替换 <pod-name>）
kubectl logs -n kube-system <metrics-
server-pod-name>
```
- **预期状态**：Deployment 应为 `AVAILABLE`，Pod 状态为 `Running`。
- **常见
问题**：
- Pod 处于 `CrashLoopBackOff`：需检查日志（如证书
错误或网络
问题）。
- Pod 未启动：可能未安装 Metrics
Server。
---
### 步骤 2：修复 Metrics
Server 配置（关键步骤）
修改 Deployment 配置以
解决常见
问题：
```bash
kubectl edit deployment metrics-
server -n kube-system
```
在 `args` 部分添加以下参数：
```yaml
args
:
- --kubelet-insecure-tls # 忽略 Kubelet 证书验证（测试环境适用）
- --kubelet-preferred-address-types=InternalIP # 优先使用节点内网 IP
- --reques
theader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem # 引用[4]
```
**保存后自动重启 Pod**。
---
### 步骤
3：验证 API
Server 聚合层
确保 Kubernetes API
Server 启用了 **Aggregator Routing**：
```bash
# 检查 API
Server 启动参数
ps aux | grep kube-ap
iserver | grep enable-aggregator-routing
```
- **若无输出**：需修改 API
Server 配置（通常在 `/etc/kubernetes/manifests/kube-ap
iserver.yaml`）：
```yaml
spec
:
containers
:
- command
:
- kube-ap
iserver
- --enable-aggregator-routing=true # 添加此行，引用[4]
```
保存后等待 API
Server 自动重启（约 1-2 分钟）。
---
### 步骤 4：排查网络
问题（Calico 等 CNI 插件）
若 Metrics
Server Pod 与节点间网络不通：
1. **检查跨子网通信**（适用于多网段集群）：
```bash
# 查看 Calico IP 池配置
calicoctl get ippool -o yaml
```
2. **修改 Calico 配置**（引用[5]）：
- 设置 `ipipMode
: CrossSubnet` 和 `natOutgoing
: true`：
```yaml
apiVersion
: projectcalico.org/v
3
kind
: IPPool
metadata
:
name
: new-pool
spec
:
cidr
: 10.66.0.0/16
ipipMode
: CrossSubnet # 启用跨子网 IPIP 隧道
natOutgoing
: true # 启用 NAT 出口流量
```
---
### 步骤 5：重新部署 Metrics
Server
若
问题未
解决，彻底重装：
```bash
# 卸载旧版本
kubectl delete -f https
://github.com/kubernetes-sigs/metrics-
server/releases/latest/download/components.yaml
# 重新安装（添加修复参数）
kubectl apply -f https
://github.com/kubernetes-sigs/metrics-
server/releases/latest/download/components.yaml
# 编辑 Deployment 并添加步骤 2 的参数
```
---
### 验证修复
等待 1-2 分钟后执行：
```bash
kubectl top nodes # 应返回节点资源用量
kubectl top pods -A # 应返回所有 Pod 资源用量
```
成功输出示例：
```
NAME CPU
(cores
) MEMORY
(bytes
)
master-1 150m 800Mi
```
---
### 常见原因总结
| 原因 |
解决方式 |
|---------------------|----------------------------------|
| Metrics
Server 未运行 | 检查 Deployment/Pod 状态 |
| 证书验证失败 | 添加 `--kubelet-insecure-tls` |
| 节点网络通信
问题 | 检查 CNI 插件配置（如 Calico） |
| API
Server 未启用聚合层 | 添加 `--enable-aggregator-routing` |
> 提示：生产环境中建议使用有效证书替代 `--kubelet-insecure-tls`[^
3][^4]。
解决k3s环境kubectltoppods报错‘ServiceUnavailable’
当运行kubectltoppods命令遇到“ServiceUnavailable”错误时，问题可能出在度量服务器上。检查并确保度量服务器部署正常，如需，可尝试重启部署以修复问题。
扫一扫
631
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
