[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-911":3,"consumer-news-interaction-911":41,"consumer-news-related-911":44},{"detail":4,"item":36},{"card":5,"schemaVersion":23,"fields":24,"content":30},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":20,"tags":21,"resolved":22},"NEWS_ARTICLE:911","news","NEWS_ARTICLE",911,"资讯","k8s安装metrics-server，以及相关报错排查","博客园","背景：有监控node节点pod的CPU等资源，实现自动扩缩容的需要下，需要安装metrics-server k8s版本：1.30.14（kubadm安装） 对应metrics-server版本：0.8x（本文使用0.8.1） 1、下载部署清单 wget https:\u002F\u002Fgithub.com\u002Fkube","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1384371\u002F202608\u002F1384371-20260830185204348-546969162.png","","\u002Fnews\u002F911",[18,19],"2026","云原生与运维",{},[19],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":25,"categoryName":19,"summary":13,"description":13,"publishTime":26,"updateTime":27,"sourceUrl":28,"language":29},"枫晴雪缘","2026-08-30T19:00","2026-09-02T20:37:56","https:\u002F\u002Fwww.cnblogs.com\u002Ffqxy\u002Fp\u002F22763744","中文",{"format":31,"policy":32,"normalized":22,"html":33,"text":34,"wordCount":35,"hasBody":22},"HTML","NEWS_CONTENT_V1","\u003Cp>背景：有监控node节点pod的CPU等资源，实现自动扩缩容的需要下，需要安装metrics-server\u003C\u002Fp>\n\u003Cp>k8s版本：1.30.14（kubadm安装） 对应metrics-server版本：0.8x（本文使用0.8.1）\u003C\u002Fp>\n\u003Cp>1、下载部署清单\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>wget https:\u003Cspan>\u002F\u002F\u003C\u002Fspan>\u003Cspan>github.com\u002Fkubernetes-sigs\u002Fmetrics-server\u002Freleases\u002Fdownload\u002Fv0.8.1\u002Fcomponents.yaml\u003C\u002Fspan>\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>2、修改components.yaml配置文件\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>\u003Cspan>containers:\n\u003C\u002Fspan>-\u003Cspan> args:\n  \u003C\u002Fspan>- --cert-dir=\u002F\u003Cspan>tmp\n  \u003C\u002Fspan>- --secure-port=\u003Cspan>10250\u003C\u002Fspan>\u003Cspan>\n  # ... 可能还有其他参数 ...\n  \u003C\u002Fspan>- --kubelet-insecure-\u003Cspan>tls  # 添加这一行（添加）\n  image: registry.k8s.io\u003C\u002Fspan>\u002Fmetrics-server\u002Fmetrics-server:v0.\u003Cspan>8.1\u003C\u002Fspan>\u003Cspan> # 您的镜像地址（修改）\n  name: metrics\u003C\u002Fspan>-server\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>3、部署与验证\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>kubectl apply -\u003Cspan>f components.yaml\n# 查看 metrics\u003C\u002Fspan>-\u003Cspan>server Pod 是否运行正常\nkubectl \u003C\u002Fspan>\u003Cspan>get\u003C\u002Fspan> pods -n kube-system -l k8s-app=metrics-server\u003Cbr>（最好是kubectl get all -A|grep metrics-server验证）\u003C\u002Fpre>\n \u003Cp>ubuntu@VM-0-4-ubuntu:~$ kubectl get all -A|grep metrics-server\u003Cbr>\n  kube-system pod\u002Fmetrics-server-588d67bbf8-k8gjm 1\u002F1 Running 0 98m\u003Cbr>\n  kube-system service\u002Fmetrics-server ClusterIP 10.50.168.106 <none> 443\u002FTCP 98m\u003Cbr>\n  kube-system deployment.apps\u002Fmetrics-server 1\u002F1 1 1 98m\u003Cbr>\n  kube-system replicaset.apps\u002Fmetrics-server-588d67bbf8 1 1 1 98m\u003C\u002Fp>\n\u003C\u002Fdiv>\n\u003Cp>如果 Pod 状态为 \u003Ccode>Running\u003C\u002Fcode>，通常表示安装成功。\u003Cspan>kubectl top nodes会有数据\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>ubuntu@VM-\u003Cspan>0\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-ubuntu:~\u003Cspan>$ kubectl top nodes\nNAME            CPU(cores)   CPU\u003C\u002Fspan>%   MEMORY(bytes)   MEMORY%\u003Cspan>   \nvm\u003C\u002Fspan>-\u003Cspan>0\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-ubuntu   81m          \u003Cspan>2\u003C\u002Fspan>%     2006Mi          \u003Cspan>55\u003C\u002Fspan>%\u003Cspan>       \nvm\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-\u003Cspan>5\u003C\u002Fspan>-ubuntu   57m          \u003Cspan>2\u003C\u002Fspan>%     1042Mi          \u003Cspan>56\u003C\u002Fspan>% \u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>5、版本兼容性\u003C\u002Fp>\n\u003Cp>不同版本的 metrics-server 对 Kubernetes 集群有兼容性要求。选择版本时，请务必参考官方或云服务商提供的兼容性矩阵。\u003C\u002Fp>\n\u003Cp>​​​​​​​6、生产环境安全\u003Cbr>\n 在上述示例中，我们使用了 --kubelet-insecure-tls 参数来跳过证书验证，这仅在测试环境中推荐使用。在生产环境中，为了安全起见，你应该配置和使用有效的 TLS 证书。\u003Cbr>\n 7、重点来了，安装过程中遇到的问题\u003C\u002Fp>\n\u003Cp>由于我们是kubadm安装，因此本文不讲二进制安装k8s后再部署metrics-server问题。kubadm安装的k8s，基本不用考虑apiservice链路聚合问题，二进制安装才会考虑，进而修改api配置文件。\u003C\u002Fp>\n\u003Cp>先描述下我们遇到的问题：\u003C\u002Fp>\n\u003Cp>kubectl get all -A|grep metrics-server检查时，server，pod，deployment都没问题，但是\u003Cspan>kubectl top nodes报错，这个时候就需要排查metrics-server最重要的一个东西：apiservice v1beta1.metrics.k8s.io，这个api是metrics-server向k8s注册的一个api接口，主要负责的就是通过k8s获取各个节点pod的cpu等资源使用情况，下面展示下排查细节\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>ubuntu@VM-\u003Cspan>0\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-ubuntu:~$ kubectl \u003Cspan>get\u003C\u002Fspan>\u003Cspan> apiservice v1beta1.metrics.k8s.io\nNAME                     SERVICE                      AVAILABLE                      AGE\nv1beta1.metrics.k8s.io   kube\u003C\u002Fspan>-system\u002Fmetrics-server   False (FailedDiscoveryCheck)   139m\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>可以看到api状态False，接着看详细描述\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>ubuntu@VM-\u003Cspan>0\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-ubuntu:~\u003Cspan>$ kubectl describe apiservice v1beta1.metrics.k8s.io\nName:         v1beta1.metrics.k8s.io\nNamespace:    \nLabels:       k8s\u003C\u002Fspan>-app=metrics-\u003Cspan>server\nAnnotations:  \u003C\u002Fspan><none>\u003Cspan>\nAPI Version:  apiregistration.k8s.io\u003C\u002Fspan>\u002F\u003Cspan>v1\nKind:         APIService\nMetadata:\n  Creation Timestamp:  \u003C\u002Fspan>\u003Cspan>2026\u003C\u002Fspan>-\u003Cspan>08\u003C\u002Fspan>-30T08:\u003Cspan>09\u003C\u002Fspan>\u003Cspan>:10Z\n  Resource Version:    \u003C\u002Fspan>\u003Cspan>38004\u003C\u002Fspan>\u003Cspan>\n  UID:                 ceda4901\u003C\u002Fspan>-435b-425f-ab56-\u003Cspan>b0abaa5c9348\nSpec:\n  Group:                     metrics.k8s.io\n  Group Priority Minimum:    \u003C\u002Fspan>\u003Cspan>100\u003C\u002Fspan>\u003Cspan>\n  Insecure Skip TLS Verify:  \u003C\u002Fspan>\u003Cspan>true\u003C\u002Fspan>\u003Cspan>\n  Service:\n    Name:            metrics\u003C\u002Fspan>-\u003Cspan>server\n    Namespace:       kube\u003C\u002Fspan>-\u003Cspan>system\n    Port:            \u003C\u002Fspan>\u003Cspan>443\u003C\u002Fspan>\u003Cspan>\n  Version:           v1beta1\n  Version Priority:  \u003C\u002Fspan>\u003Cspan>100\u003C\u002Fspan>\u003Cspan>\nStatus:\n  Conditions:\n    Last Transition Time:  \u003C\u002Fspan>\u003Cspan>2026\u003C\u002Fspan>-\u003Cspan>08\u003C\u002Fspan>-30T10:\u003Cspan>08\u003C\u002Fspan>\u003Cspan>:28Z\n    Message:               failing or missing response \u003C\u002Fspan>\u003Cspan>from\u003C\u002Fspan> https:\u003Cspan>\u002F\u002F\u003C\u002Fspan>\u003Cspan>10.50.168.106:443\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1: Get \"\u003C\u002Fspan>\u003Cspan>https:\u002F\u002F10.50.168.106\u003C\u002Fspan>\u003Cspan>:443\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1\": net\u002Fhttp: request canceled (Client.Timeout exceeded while awaiting headers)\u003C\u002Fspan>\n\u003Cspan>    Reason:                FailedDiscoveryCheck\n    Status:                False\n    Type:                  Available\nEvents:                    \u003C\u002Fspan><none>\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>看，报错metrics-server的service ClusterIP 10.50.168.106   443链接超时\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>vim \u002Fetc\u002Fkubernetes\u002Fmanifests\u002Fkube-\u003Cspan>apiserver.yaml\n添加\n\u003C\u002Fspan>- --tls-\u003Cspan>private\u003C\u002Fspan>-key-file=\u002Fetc\u002Fkubernetes\u002Fpki\u002F\u003Cspan>apiserver.key\n\u003C\u002Fspan>- --enable-aggregator-routing=\u003Cspan>true\u003C\u002Fspan>\u003Cspan>（添加该参数）\n会临时解决报错443超时（不建议使用）\u003Cbr>解释下原理（个人理解）：\u003Cbr>\u003Ccode>参数解释：--enable-aggregator-routing=true\u003C\u002Fcode> 是 Kubernetes API Server 的启动参数，用于启用 API Aggregation 层的路由转发功能，使核心 API Server 能将特定前缀（如 \u003Ccode>\u002Fapis\u002Fmetrics.k8s.io\u003C\u002Fcode>）的请求代理到外部扩展 API Server（如 \u003Cspan>Metrics Server、Custom Metrics API 等）\u003C\u002Fspan>\u003Cbr>参数作用：该参数的作用是‌允许聚合器将请求直接路由到端点 IP（pod IP） 而非集群 IP（Service IP）\u003Cbr>参数要求：部署位置要求‌：若 \u003Ccode>kube-proxy\u003C\u002Fcode> 与 \u003Ccode>kube-apiserver\u003C\u002Fcode> ‌不在同一节点‌，则‌必须启用‌此参数\u003Cbr>在k8s 1.30.1中，该参数默认不开启，也就是说加了该参数，api路由就跳过了metrics-server的service IP，直接去访问pod IP了，也就是我们pod IP的10250端口，但是走的网络还是calico的vxlan模式\u003C\u002Fspan>\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>但是这会引起另一个类似报错是metrics-server的pod 10250超时\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>ubuntu@VM-\u003Cspan>0\u003C\u002Fspan>-\u003Cspan>4\u003C\u002Fspan>-ubuntu:~\u003Cspan>$ kubectl describe apiservice v1beta1.metrics.k8s.io\nName:         v1beta1.metrics.k8s.io\nNamespace:    \nLabels:       k8s\u003C\u002Fspan>-app=metrics-\u003Cspan>server\nAnnotations:  \u003C\u002Fspan><none>\u003Cspan>\nAPI Version:  apiregistration.k8s.io\u003C\u002Fspan>\u002F\u003Cspan>v1\nKind:         APIService\nMetadata:\n  Creation Timestamp:  \u003C\u002Fspan>\u003Cspan>2026\u003C\u002Fspan>-\u003Cspan>08\u003C\u002Fspan>-30T08:\u003Cspan>09\u003C\u002Fspan>\u003Cspan>:10Z\n  Resource Version:    \u003C\u002Fspan>\u003Cspan>38004\u003C\u002Fspan>\u003Cspan>\n  UID:                 ceda4901\u003C\u002Fspan>-435b-425f-ab56-\u003Cspan>b0abaa5c9348\nSpec:\n  Group:                     metrics.k8s.io\n  Group Priority Minimum:    \u003C\u002Fspan>\u003Cspan>100\u003C\u002Fspan>\u003Cspan>\n  Insecure Skip TLS Verify:  \u003C\u002Fspan>\u003Cspan>true\u003C\u002Fspan>\u003Cspan>\n  Service:\n    Name:            metrics\u003C\u002Fspan>-\u003Cspan>server\n    Namespace:       kube\u003C\u002Fspan>-\u003Cspan>system\n    Port:            \u003C\u002Fspan>\u003Cspan>443\u003C\u002Fspan>\u003Cspan>\n  Version:           v1beta1\n  Version Priority:  \u003C\u002Fspan>\u003Cspan>100\u003C\u002Fspan>\u003Cspan>\nStatus:\n  Conditions:\n    Last Transition Time:  \u003C\u002Fspan>\u003Cspan>2026\u003C\u002Fspan>-\u003Cspan>08\u003C\u002Fspan>-30T10:\u003Cspan>08\u003C\u002Fspan>\u003Cspan>:28Z\n    Message:               failing or missing response \u003C\u002Fspan>\u003Cspan>from\u003C\u002Fspan> https:\u003Cspan>\u002F\u002F10.60.139.19\u003C\u002Fspan>\u003Cspan>:10250\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1: Get \"\u003C\u002Fspan>\u003Cspan>https:\u002F\u002F10.60.139.19\u003C\u002Fspan>\u003Cspan>:10250\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1\": net\u002Fhttp: request canceled (Client.Timeout exceeded while awaiting headers)\u003C\u002Fspan>\n\u003Cspan>    Reason:                FailedDiscoveryCheck\n    Status:                False\n    Type:                  Available\nEvents:                    \u003C\u002Fspan><none>\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>到现在，我们弄清楚了报错信息，但是还要找原因\u003C\u002Fp>\n\u003Cp>先说根本原因：网络不通（不要想什么api聚合问题，就是网络原因）\u003C\u002Fp>\n\u003Cp>解释下网络原理（重点）：\u003C\u002Fp>\n\u003Cp>master节点的\u003Cem>\u003Cspan>metrics-server的api发起访问，走calico网络vxlan（4789端口UDP协议），去node节点的\u003Cem>metrics-server pod获取数据（k8s api配置文件未添加\u003C\u002Fem>\u003C\u002Fspan>\u003C\u002Fem>- --enable-aggregator-routing=true参数时，走service IP443端口，添加该参数走pod 10250（可自定义）端口\u003Cem>\u003Cspan>\u003Cem>）\u003C\u002Fem>\u003C\u002Fspan>\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>为什么我笃定是网络原因呢，因此就这个问题我排查了2天，api聚合链路，metrics-server配置文件什么的各种参数，甚至k8s我都重装了一遍，网上也各种搜索，有的文章也说到了是网络问题，但是给出的解决方案安全性不高，基于此才想把该问题分享下\u003C\u002Fp>\n\u003Cp>先说下网上的解决方案：\u003C\u002Fp>\n\u003Cp>在metrics-server配置文件里加一个参数\u003C\u002Fp>\n\u003Cdiv>\n \u003Cpre>      serviceAccountName: metrics-\u003Cspan>server\n      hostNetwork: \u003C\u002Fspan>\u003Cspan>true\u003C\u002Fspan>\u003Cspan> #（加的参数）\n      volumes:\n      \u003C\u002Fspan>-\u003Cspan> emptyDir: {}\n        name: tmp\u003C\u002Fspan>-dir\u003C\u002Fpre>\n\u003C\u002Fdiv>\n\u003Cp>该参数确实能解决以上我们遇到的问题，但是会增加风险：暴露宿主机网络、端口冲突、安全性下降\u003C\u002Fp>\n\u003Cp>\u003Ccode>解释下网络原理：\u003C\u002Fcode>\u003C\u002Fp>\n\u003Cp>\u003Ccode>hostNetwork: true\u003C\u002Fcode> 是 Kubernetes Pod 规格中的字段，启用后 Pod ‌直接使用宿主机的网络命名空间‌（跳过 CNI 网络插件隔离）\u003C\u002Fp>\n\u003Cp>导致：\u003Cem>‌IP 行为‌：Pod IP = 节点 IP；\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>端口暴露‌：容器监听端口直接绑定宿主机端口，‌无需 \u003Ccode>hostPort\u003C\u002Fcode>‌（若同时配置 \u003Ccode>hostPort\u003C\u002Fcode> 会被忽略）\u003C\u002Fp>\n\u003Cp>配置了该参数后，容器流量直连宿主机协议栈，‌不经过 \u003Ccode>calico\u003C\u002Fcode> 虚拟接口、IPIP\u002FVXLAN 隧道或 Calico 路由表‌，跨节点通信依赖物理网络路由而非 Calico 通告的 Pod 网段。也就说走的是宿主机网络10250端口的tcp协议（需要云主机防火墙规则放行10250端口TCP协议）。\u003C\u002Fp>\n\u003Cp>那么有没有什么更安全的解决方案呢？有的。其实能遇到443,10250链接超时问题的小伙伴，我想大多数应该都是在云主机上搭建的测试环境（或者是本地环境的网络配置有问题）\u003C\u002Fp>\n\u003Cp>我的环境就是腾讯云主机的环境，基于此分析，那么为什么我们443,10250会超时就很简单了，就是因为calico vxlan模式使用的是4789端口UDP协议，但是云防火墙该端口协议没开！！！\u003C\u002Fp>\n\u003Cp>只要我们在云主机防火墙规则打开4789端口UDP协议就可以，不用其他什么配置\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"捕获\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F1384371\u002F202608\u002F1384371-20260830185204348-546969162.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>至于本地环境的小伙伴，依据此问题判断，大概率就是路由器规则不允许4789端口UDP协议通行导致的\u003C\u002Fp>\n\u003Cp>最后再解释一下网络原理：\u003C\u002Fp>\n\u003Cp>（跨节点通信，k8s使用的calico网络vxlan模式，metrics-server的pod在node节点上，存在metrics-server的service，metrics-server部署在非node节点，获取信息属于跨节点）\u003C\u002Fp>\n\u003Cp>\u003Cem>metrics-server api发起访问，走calico网络vxlan（4789端口UDP协议），去node节点的\u003Cem>metrics-server pod获取数据（正常是走metrics-server的service端口获取数据）\u003C\u002Fem>\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>当然，这只是本人遇到的443,10250超时的一种情况，若是有其他情况，欢迎补充。\u003C\u002Fp>","背景：有监控node节点pod的CPU等资源，实现自动扩缩容的需要下，需要安装metrics-server k8s版本：1.30.14（kubadm安装） 对应metrics-server版本：0.8x（本文使用0.8.1） 1、下载部署清单 wget https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fmetrics-server\u002Freleases\u002Fdownload\u002Fv0.8.1\u002Fcomponents.yaml 2、修改components.yaml配置文件 containers: - args: - --cert-dir=\u002Ftmp - --secure-port=10250 # ... 可能还有其他参数 ... - --kubelet-insecure-tls # 添加这一行（添加） image: registry.k8s.io\u002Fmetrics-server\u002Fmetrics-server:v0.8.1 # 您的镜像地址（修改） name: metrics-server 3、部署与验证 kubectl apply -f components.yaml # 查看 metrics-server Pod 是否运行正常 kubectl get pods -n kube-system -l k8s-app=metrics-server （最好是kubectl get all -A|grep metrics-server验证） ubuntu@VM-0-4-ubuntu:~$ kubectl get all -A|grep metrics-server kube-system pod\u002Fmetrics-server-588d67bbf8-k8gjm 1\u002F1 Running 0 98m kube-system service\u002Fmetrics-server ClusterIP 10.50.168.106 \u003Cnone> 443\u002FTCP 98m kube-system deployment.apps\u002Fmetrics-server 1\u002F1 1 1 98m kube-system replicaset.apps\u002Fmetrics-server-588d67bbf8 1 1 1 98m 如果 Pod 状态为 Running，通常表示安装成功。kubectl top nodes会有数据 ubuntu@VM-0-4-ubuntu:~$ kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% vm-0-4-ubuntu 81m 2% 2006Mi 55% vm-4-5-ubuntu 57m 2% 1042Mi 56% 5、版本兼容性 不同版本的 metrics-server 对 Kubernetes 集群有兼容性要求。选择版本时，请务必参考官方或云服务商提供的兼容性矩阵。 6、生产环境安全 在上述示例中，我们使用了 --kubelet-insecure-tls 参数来跳过证书验证，这仅在测试环境中推荐使用。在生产环境中，为了安全起见，你应该配置和使用有效的 TLS 证书。 7、重点来了，安装过程中遇到的问题 由于我们是kubadm安装，因此本文不讲二进制安装k8s后再部署metrics-server问题。kubadm安装的k8s，基本不用考虑apiservice链路聚合问题，二进制安装才会考虑，进而修改api配置文件。 先描述下我们遇到的问题： kubectl get all -A|grep metrics-server检查时，server，pod，deployment都没问题，但是kubectl top nodes报错，这个时候就需要排查metrics-server最重要的一个东西：apiservice v1beta1.metrics.k8s.io，这个api是metrics-server向k8s注册的一个api接口，主要负责的就是通过k8s获取各个节点pod的cpu等资源使用情况，下面展示下排查细节 ubuntu@VM-0-4-ubuntu:~$ kubectl get apiservice v1beta1.metrics.k8s.io NAME SERVICE AVAILABLE AGE v1beta1.metrics.k8s.io kube-system\u002Fmetrics-server False (FailedDiscoveryCheck) 139m 可以看到api状态False，接着看详细描述 ubuntu@VM-0-4-ubuntu:~$ kubectl describe apiservice v1beta1.metrics.k8s.io Name: v1beta1.metrics.k8s.io Namespace: Labels: k8s-app=metrics-server Annotations: \u003Cnone> API Version: apiregistration.k8s.io\u002Fv1 Kind: APIService Metadata: Creation Timestamp: 2026-08-30T08:09:10Z Resource Version: 38004 UID: ceda4901-435b-425f-ab56-b0abaa5c9348 Spec: Group: metrics.k8s.io Group Priority Minimum: 100 Insecure Skip TLS Verify: true Service: Name: metrics-server Namespace: kube-system Port: 443 Version: v1beta1 Version Priority: 100 Status: Conditions: Last Transition Time: 2026-08-30T10:08:28Z Message: failing or missing response from https:\u002F\u002F10.50.168.106:443\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1: Get \"https:\u002F\u002F10.50.168.106:443\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1\": net\u002Fhttp: request canceled (Client.Timeout exceeded while awaiting headers) Reason: FailedDiscoveryCheck Status: False Type: Available Events: \u003Cnone> 看，报错metrics-server的service ClusterIP 10.50.168.106 443链接超时 vim \u002Fetc\u002Fkubernetes\u002Fmanifests\u002Fkube-apiserver.yaml 添加 - --tls-private-key-file=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fapiserver.key - --enable-aggregator-routing=true（添加该参数） 会临时解决报错443超时（不建议使用） 解释下原理（个人理解）： 参数解释：--enable-aggregator-routing=true 是 Kubernetes API Server 的启动参数，用于启用 API Aggregation 层的路由转发功能，使核心 API Server 能将特定前缀（如 \u002Fapis\u002Fmetrics.k8s.io）的请求代理到外部扩展 API Server（如 Metrics Server、Custom Metrics API 等） 参数作用：该参数的作用是‌允许聚合器将请求直接路由到端点 IP（pod IP） 而非集群 IP（Service IP） 参数要求：部署位置要求‌：若 kube-proxy 与 kube-apiserver ‌不在同一节点‌，则‌必须启用‌此参数 在k8s 1.30.1中，该参数默认不开启，也就是说加了该参数，api路由就跳过了metrics-server的service IP，直接去访问pod IP了，也就是我们pod IP的10250端口，但是走的网络还是calico的vxlan模式 但是这会引起另一个类似报错是metrics-server的pod 10250超时 ubuntu@VM-0-4-ubuntu:~$ kubectl describe apiservice v1beta1.metrics.k8s.io Name: v1beta1.metrics.k8s.io Namespace: Labels: k8s-app=metrics-server Annotations: \u003Cnone> API Version: apiregistration.k8s.io\u002Fv1 Kind: APIService Metadata: Creation Timestamp: 2026-08-30T08:09:10Z Resource Version: 38004 UID: ceda4901-435b-425f-ab56-b0abaa5c9348 Spec: Group: metrics.k8s.io Group Priority Minimum: 100 Insecure Skip TLS Verify: true Service: Name: metrics-server Namespace: kube-system Port: 443 Version: v1beta1 Version Priority: 100 Status: Conditions: Last Transition Time: 2026-08-30T10:08:28Z Message: failing or missing response from https:\u002F\u002F10.60.139.19:10250\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1: Get \"https:\u002F\u002F10.60.139.19:10250\u002Fapis\u002Fmetrics.k8s.io\u002Fv1beta1\": net\u002Fhttp: request canceled (Client.Timeout exceeded while awaiting headers) Reason: FailedDiscoveryCheck Status: False Type: Available Events: \u003Cnone> 到现在，我们弄清楚了报错信息，但是还要找原因 先说根本原因：网络不通（不要想什么api聚合问题，就是网络原因） 解释下网络原理（重点）： master节点的metrics-server的api发起访问，走calico网络vxlan（4789端口UDP协议），去node节点的metrics-server pod获取数据（k8s api配置文件未添加- --enable-aggregator-routing=true参数时，走service IP443端口，添加该参数走pod 10250（可自定义）端口） 为什么我笃定是网络原因呢，因此就这个问题我排查了2天，api聚合链路，metrics-server配置文件什么的各种参数，甚至k8s我都重装了一遍，网上也各种搜索，有的文章也说到了是网络问题，但是给出的解决方案安全性不高，基于此才想把该问题分享下 先说下网上的解决方案： 在metrics-server配置文件里加一个参数 serviceAccountName: metrics-server hostNetwork: true #（加的参数） volumes: - emptyDir: {} name: tmp-dir 该参数确实能解决以上我们遇到的问题，但是会增加风险：暴露宿主机网络、端口冲突、安全性下降 解释下网络原理： hostNetwork: true 是 Kubernetes Pod 规格中的字段，启用后 Pod ‌直接使用宿主机的网络命名空间‌（跳过 CNI 网络插件隔离） 导致：‌IP 行为‌：Pod IP = 节点 IP； 端口暴露‌：容器监听端口直接绑定宿主机端口，‌无需 hostPort‌（若同时配置 hostPort 会被忽略） 配置了该参数后，容器流量直连宿主机协议栈，‌不经过 calico 虚拟接口、IPIP\u002FVXLAN 隧道或 Calico 路由表‌，跨节点通信依赖物理网络路由而非 Calico 通告的 Pod 网段。也就说走的是宿主机网络10250端口的tcp协议（需要云主机防火墙规则放行10250端口TCP协议）。 那么有没有什么更安全的解决方案呢？有的。其实能遇到443,10250链接超时问题的小伙伴，我想大多数应该都是在云主机上搭建的测试环境（或者是本地环境的网络配置有问题） 我的环境就是腾讯云主机的环境，基于此分析，那么为什么我们443,10250会超时就很简单了，就是因为calico vxlan模式使用的是4789端口UDP协议，但是云防火墙该端口协议没开！！！ 只要我们在云主机防火墙规则打开4789端口UDP协议就可以，不用其他什么配置 至于本地环境的小伙伴，依据此问题判断，大概率就是路由器规则不允许4789端口UDP协议通行导致的 最后再解释一下网络原理： （跨节点通信，k8s使用的calico网络vxlan模式，metrics-server的pod在node节点上，存在metrics-server的service，metrics-server部署在非node节点，获取信息属于跨节点） metrics-server api发起访问，走calico网络vxlan（4789端口UDP协议），去node节点的metrics-server pod获取数据（正常是走metrics-server的service端口获取数据） 当然，这只是本人遇到的443,10250超时的一种情况，若是有其他情况，欢迎补充。",5468,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":40},"2026 · 云原生与运维","#2563eb","16 \u002F 10",[19],{"targetType":8,"targetId":9,"likedByMe":42,"likeCount":43,"commentCount":43,"contentLikeCount":43,"contentCommentCount":43,"sourceLikeCount":43,"sourceCommentCount":43},false,0,[45,51,58,64,73,79,86,94],{"id":46,"kind":7,"title":47,"summary":48,"image":15,"href":49,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":50},"NEWS_ARTICLE:839","Nginx 1.30.4 编译安装与参数调优","Nginx 是一款轻量级、高性能、高并发的开源Web服务器、反向代理与负载均衡软件，凭借低资源占用、高稳定性的核心优势，成为当下互联网行业主流的服务部署组件，广泛应用于各类网站及业务系统的Web服务、反向代理、负载均衡场景。其基于宽松的类BSD开源协议发布，可免费商用。本文将完整展示 Nginx 1","\u002Fnews\u002F839",[19],{"id":52,"kind":7,"title":53,"summary":54,"image":55,"href":56,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":57},"NEWS_ARTICLE:885","【Azure Redis】中国区创建和连接 Azure Managed Redis 的两个注意事项","Azure Managed Redis 介绍 Azure Managed Redis 是微软新一代全托管 Redis 服务，基于 Redis Enterprise 构建，为现代云应用提供低延迟、高吞吐的数据访问能力。相比传统 Azure Cache for Redis，它采用更高效的多分片架构，并提","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2127802\u002F202608\u002F2127802-20260831195905463-1387904592.png","\u002Fnews\u002F885",[19],{"id":59,"kind":7,"title":60,"summary":61,"image":15,"href":62,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":63},"NEWS_ARTICLE:891","K8S接入NFS存储","本文详细演示了在Kubernetes集群中接入NFS作为默认持久化存储的完整流程。针对容器数据易失问题，文章介绍了如何部署NFS Provisioner，并配置StorageClass将其设为集群默认（default）。通过此方案，实现了PVC的动态自动供给，开发者无需手动创建PV即可为Pod分配存","\u002Fnews\u002F891",[19],{"id":65,"kind":7,"title":66,"summary":67,"image":68,"href":69,"meta":70,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":71},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[72],"人工智能",{"id":74,"kind":7,"title":75,"summary":76,"image":15,"href":77,"meta":18,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":78},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":83,"href":84,"meta":18,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":85},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":87,"kind":7,"title":88,"summary":89,"image":15,"href":90,"meta":91,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":92},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[93],"软件开发",{"id":95,"kind":7,"title":96,"summary":97,"image":98,"href":99,"meta":18,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":100},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8]]