云原生后端容器编排弹性伸缩【免费下载链接】metrics-serverScalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.项目地址https://gitcode.com/gh_mirrors/me/metrics-server点击查看免费下载Metrics Server 是 Kubernetes 内置自动扩缩容管线的核心数据源它以轻量、高效的方式从 Kubelet 采集容器资源指标并通过 Metrics APImetrics.k8s.io暴露给 Horizontal Pod AutoscalerHPA、Vertical Pod AutoscalerVPA以及kubectl top使用。本文以本仓库gh_mirrors/me/metrics-server的 README.md 为骨架结合 cmd/metrics-server/app/options/options.go、pkg/scraper/scraper.go、pkg/server/server.go 等核心源码深入讲解其工作原理、部署前置条件、安装方式、高可用与性能扩展策略帮助读者在生产集群中正确部署并调试这一关键组件。[!CAUTION] Metrics Server 仅面向自动扩缩容场景设计。请勿将其用于向监控系统转发指标或作为监控解决方案的数据源。这类场景应直接采集 Kubelet 的/metrics/resource端点。一、项目定位自动扩缩容管线中的资源指标来源Metrics Server 是一个可扩展、高效的容器资源指标来源专为 Kubernetes 内置自动扩缩容管线服务。它在每个采集周期内从各节点的 Kubelet 收集资源指标并将聚合结果通过 Metrics API 暴露给 Kubernetes apiserver供以下消费方使用Horizontal Pod AutoscalerHPA基于 CPU/内存指标实现水平扩缩容Vertical Pod AutoscalerVPA自动调整或建议容器所需的资源请求kubectl top命令行直接查询节点与 Pod 的实时资源使用情况便于调试扩缩容管线。其核心设计目标体现在三个维度单一部署即适配多数集群只要满足前置要求即可工作详见 Requirements 一节快速扩缩容默认每 15 秒采集一次指标对应 manifests/base/deployment.yaml 中的--metric-resolution15s资源效率高每节点约消耗 1 毫核 CPU 与 2 MB 内存可支撑最多 5,000 节点的集群规模。1.1 使用场景边界适合使用 Metrics Server 的场景基于 CPU/内存的 HPA 水平自动扩缩容自动调整/建议容器资源请求的 VPA 垂直扩缩容。不适合使用 Metrics Server 的场景非 Kubernetes 集群需要精确资源使用指标的场景Metrics Server 缓存的是采样值而非精确值基于 CPU/内存以外资源如自定义业务指标的水平扩缩容——这类需求应转向 Prometheus 等完整监控方案。二、部署前置要求RequirementsMetrics Server 对集群与网络配置有明确要求且这些要求并非所有集群发行版的默认配置。部署前务必确认集群发行版支持以下条件kube-apiserver 必须启用聚合层aggregation layerMetrics Server 才能以 APIService 方式接入metrics.k8s.io组节点必须启用 Webhook 认证与授权Kubelet 的--authentication-token-webhook与--authorization-modeWebhookMetrics Server 才能以 TokenReview/SubjectAccessReview 方式访问 KubeletKubelet 证书必须由集群 CA 签发或通过向 Metrics Server 传入--kubelet-insecure-tls关闭证书校验仅用于测试容器运行时必须实现容器指标 RPCCRI 的 ContainerStats或提供 cAdvisor 支持网络连通性需满足两个方向控制平面 → Metrics Server控制平面节点需要能够访问 Metrics Server 的 Pod IP 和 10250 端口若启用hostNetwork则访问节点 IP 与自定义端口Metrics Server → 各节点 Kubelet需要能到达节点地址与 Kubelet 端口。地址与端口配置在 Kubelet 中并发布在 Node 对象的.status.addresses地址列表和.status.daemonEndpoints.kubeletEndpoint.port端口默认 10250字段中。2.1 节点地址选择机制--kubelet-preferred-address-typesMetrics Server 会按--kubelet-preferred-address-types指定的优先级顺序清单中默认InternalIP,ExternalIP,Hostname从 Node 对象地址列表中选择第一个匹配的地址用于连接 Kubelet。其实现位于 pkg/utils/address_resolver.go 的prioNodeAddrResolver.NodeAddress()按优先级遍历地址类型再从节点地址列表中返回第一个匹配地址若全部类型均无匹配则返回错误。代码中 pkg/utils/address_resolver.go 定义的默认优先级为Hostname → InternalDNS → InternalIP → ExternalDNS → ExternalIP程序默认值与部署清单中的显式覆盖值InternalIP,ExternalIP,Hostname不同这也是多网卡、混合云集群中常见的网络问题根源——务必确认所选地址类型在目标网络环境中可被 Metrics Server 实际访问。2.2 Kubelet 端口选择--kubelet-use-node-status-port从源码 cmd/metrics-server/app/options/kubelet_client.go 可见Kubelet 客户端相关参数包括--kubelet-port连接 Kubelet 的端口程序默认 10250--kubelet-use-node-status-port改用 Node 状态中发布的daemonEndpoints.kubeletEndpoint.port端口且优先于--kubelet-port--kubelet-request-timeout单次 Kubelet 请求的超时时间默认 10 秒必须带时间单位--kubelet-certificate-authority校验 Kubelet 服务证书的 CA 路径--kubelet-client-certificate/--kubelet-client-key客户端双向 TLS 证书二者必须同时提供--kubelet-insecure-tls跳过 Kubelet 证书 CA 校验仅限测试--node-selector-l按标签过滤需要采集指标的节点。这些参数在 manifests/base/deployment.yaml 中以--kubelet-use-node-status-port形式默认启用。三、安装方式3.1 YAML 清单安装快速开始安装最新版本基于components.yaml清单kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml历史版本的安装说明可查阅 Metrics Server 各 release 的发布说明。本仓库中对应的清单源文件位于 manifests/base/deployment.yaml、manifests/base/apiservice.yaml、manifests/base/rbac.yaml 与 manifests/base/service.yaml其中 deployment 默认参数如下args: - --cert-dir/tmp - --secure-port10250 - --kubelet-preferred-address-typesInternalIP,ExternalIP,Hostname - --kubelet-use-node-status-port - --metric-resolution15s resources: requests: cpu: 100m memory: 200Mi3.2 兼容性矩阵Compatibility MatrixMetrics ServerMetrics API group/version支持的 Kubernetes 版本0.9.xmetrics.k8s.io/v1beta11.340.8.xmetrics.k8s.io/v1beta11.310.7.xmetrics.k8s.io/v1beta11.270.6.xmetrics.k8s.io/v1beta11.250.5.xmetrics.k8s.io/v1beta1*1.80.4.xmetrics.k8s.io/v1beta1*1.80.3.xmetrics.k8s.io/v1beta11.8-1.21* Kubernetes 版本低于 v1.16 时需要额外传入--authorization-always-allow-paths/livez,/readyz命令行参数。从源码 pkg/api/install.go 可以看到Metrics Server 同时向v1beta1与v1两个版本的资源映射注册了nodes与pods存储即同时提供metrics.k8s.io/v1beta1与metrics.k8s.io/v1两套 APImanifests/base/apiservice.yaml 中对应声明了v1.metrics.k8s.io与v1beta1.metrics.k8s.io两个 APIService。3.3 kube-apiserver 版本偏移Version SkewMetrics Server 遵循 Kubernetes Version Skew Policykube-apiserver 的版本必须处于上方兼容性矩阵所支持的 Kubernetes 版本范围内。部署前请核对集群控制平面版本与 Metrics Server 版本的匹配关系。3.4 高可用部署High AvailabilityMetrics Server 支持通过 YAML 清单直接以高可用模式安装将replicas设为大于 1或通过官方 Helm chart 设置replicas值实现。按 Kubernetes 版本选择清单Kubernetes v1.21kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21.yamlKubernetes v1.19-1.21kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml[!NOTE] 该配置要求集群中至少有 2 个可供 Metrics Server 调度的节点。本仓库中对应清单位于 manifests/components/high-availability/patch.yamlreplicas: 2、rollingUpdate.maxUnavailable: 1、requiredDuringSchedulingIgnoredDuringExecution的 Pod 反亲和将两个副本分散到不同节点与 manifests/components/high-availability/pdb.yamlPodDisruptionBudgetv1.21 变体见 manifests/components/high-availability-1.21/patch-pdb-version.yaml。此外为最大化该高可用配置的效率建议在 kube-apiserver 上添加--enable-aggregator-routingtrueCLI 标志使发往 Metrics Server 的请求在两个实例之间负载均衡。3.5 Helm Chart 安装官方 Helm chart 作为本仓库的附加组件维护随每次 Metrics Server 发布也可独立按需发布发布到基于gh-pages分支的 chart 仓库。仓库代码位于 charts/metrics-server其默认值定义见 charts/metrics-server/values.yamlimage.repository: registry.k8s.io/metrics-server/metrics-serverdefaultArgs默认包含--cert-dir/tmp、--kubelet-preferred-address-typesInternalIP,ExternalIP,Hostname、--kubelet-use-node-status-port、--metric-resolution15sapiService.create: true同时创建v1与v1beta1两个 APIServicehostNetwork.enabled: false在使用如 EKS Weave 等无法让 apiserver 访问 Pod IP 的覆盖网络时需开启addonResizer.enabled: false可配合 addon-resizer 依据节点数自动调整资源nanny段定义了每节点 1m CPU / 2Mi 内存的增量tls.type支持metrics-server自签证书/helmHelm 生成证书/cert-managercert-manager 维护证书/existingSecret复用已有 Secret四种模式注意不应直接引用master分支上的 chart因为它可能包含自上次发布以来的未发布修改查看 chart 代码请使用 chart 发布 tag。四、安全上下文Security ContextMetrics Server 需要CAP_NET_BIND_SERVICE能力才能在非 root 用户下绑定特权端口如默认的 10250。如果运行环境启用了 Pod Security StandardsPSS或其他限制 Pod 能力的机制必须允许 Metrics Server 使用该能力。这一点即使通过--secure-port将监听端口改为非特权端口也同样适用。对应实现可见 manifests/base/deployment.yaml 中的 securityContextrunAsNonRoot: true、runAsUser: 1000、readOnlyRootFilesystem: true、allowPrivilegeEscalation: false、seccompProfile: RuntimeDefault、capabilities.drop: [ALL]而 Helm chart 中 charts/metrics-server/values.yaml 的securityContext亦采用相同的最小权限配置。五、扩展与资源规划Scaling从 v0.5.0 起Metrics Server 自带默认资源请求在大多数不超过 100 节点的集群配置下可保证良好性能100m CPU200Mi 内存Metrics Server 的资源消耗由多个相互独立的维度共同决定构成所谓的可扩展性包络Scalability Envelope。默认配置适用于不超出以下任一阈值的集群数量命名空间阈值集群阈值#节点n/a100每节点 Pod 数7070带 HPA 的 Deployment 数100100资源可按集群节点数做比例调整。对于超过 100 节点的集群每节点额外分配1m 核心 CPU2Mi 内存也可用同样的方法下调资源请求但存在边界——过低可能会影响其他扩展维度如每节点最大 Pod 数。若希望自动完成这种按节点数的资源缩放可在 Helm 中启用addonResizer见 charts/metrics-server/values.yaml 的addonResizer段其nanny配置minClusterSize: 100、extraCpu: 1m、extraMemory: 2Mi与上文扩展公式一致。5.1 常用配置标志Configuration根据集群环境不同可能需要调整传给 Metrics Server 容器的标志。最常用的有--kubelet-preferred-address-types连接节点时使用的节点地址类型优先级程序默认[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP]清单默认InternalIP,ExternalIP,Hostname--kubelet-insecure-tls不校验 Kubelet 服务证书的 CA仅限测试使用--requestheader-client-ca-file指定用于校验入站请求客户端证书的根证书 bundle--node-selector基于节点标签筛选需要采集指标的节点。获取完整配置标志列表docker run --rm registry.k8s.io/metrics-server/metrics-server:v0.9.0 --help从源码 cmd/metrics-server/app/options/options.go 可见 Metrics Server 自身的核心参数--metric-resolution指标保留/采集周期最小值 10 秒校验逻辑见 options.go程序默认 60 秒部署清单覆盖为 15 秒--version显示版本--kubeconfig连接 apiserver 与 Kubelet 的 kubeconfig 路径默认使用集群内配置。另外注意校验约束metric-resolution的 9/10 必须大于kubelet-request-timeout否则启动校验会报错--kubelet-certificate-authority与--kubelet-insecure-tls互斥--kubelet-client-key与--kubelet-client-certificate必须成对出现。六、设计原理从kubectl top到内存缓存的完整链路Metrics Server 是 Kubernetes 核心指标管线中的组件其整体架构遵循 Kubernetes 监控架构设计。请求处理与数据采集两条关键链路分别如下。6.1 查询链路处理一次kubectl top pods请求从源码看这条链路的落地位于 pkg/api/install.goInstall()将nodemetrics与podmetrics两个资源注册进metrics.k8s.ioAPI group并安装到 GenericAPIServer 中pkg/api/pod.go 与 pkg/api/node.go 则负责从内存存储中查询 Pod/Node 指标并组装成metrics.PodMetricsList/NodeMetricsList响应。由此可知查询路径不接触任何 Kubelet只读内存缓存因此延迟极低且对 Kubelet 无压力。6.2 采集链路周期性从 Kubelet 拉取资源指标采集循环由 pkg/server/server.go 驱动RunUntil启动 Node/Pod informer 并等待缓存同步cache.WaitForCacheSync随后runScrape以metric-resolution为周期定时执行tick——每次tick先调用scraper.Scrape(ctx)抓取所有节点再把结果写入存储storage.Store并记录tick_duration_seconds直方图指标。抓取本身在 pkg/scraper/scraper.go 实现关键设计包括通过 Node lister按node-selector过滤一次性列出全部节点对每个节点启动独立 goroutine 并发请求 Kubelet 的/metrics/resource具体协议与寻址由 pkg/scraper/client 负责TLS 与认证参数由 cmd/metrics-server/app/options/kubelet_client.go 的Config()组装引入随机抖动延迟delayPerSourceMs * len(nodes)上限 4 秒错峰发起请求避免网络拥塞scraper.go单请求超时受kubelet-request-timeout约束且整体抓取必须在metric-resolution周期内完成tick使用 resolution 作为 context 超时抓取结果聚合为MetricsBatch含节点级与 Pod 级指标点后交给 pkg/storage/storage.go 的内存存储更新缓存抓取过程暴露metrics_server_kubelet_request_duration_seconds、metrics_server_kubelet_request_total、metrics_server_kubelet_last_request_time_seconds等指标scraper.go 顶部定义用于监控抓取健康度。6.3 健康检查探针manifests/base/deployment.yaml 中配置了readinessProbe/readyz与livenessProbe/livez。这些探针背后是 pkg/server/server.go 的RegisterProbes()注册的四类检查metric-storage-readyreadyz内存存储中已有可服务的指标metric-informer-syncreadyzNode/Pod informer 缓存已同步metric-collection-timelylivez最近一次采集 tick 未超时——若tick距当前超过 1.5 倍采集周期则判定不健康metadata-informer-sync元数据 informer 同步状态。这组探针正是排查 Metrics Server 就绪但无数据 类问题的重要抓手。七、常见问题与延伸阅读部署或使用中遇到问题时建议优先查阅仓库内的 FAQ.md常见问题与 KNOWN_ISSUES.md已知问题避免重复提交 issue。更多背景资料可参考本仓库的 CONTRIBUTING.md贡献指南与 RELEASE.md发布流程。本项目由 Kubernetes SIG Instrumentation 维护参与社区讨论、贡献与支持请遵循 code-of-conduct.md 中的行为准则。核心源码速查表关注点文件命令行参数定义与校验cmd/metrics-server/app/options/options.goKubelet 客户端 TLS/认证/端口参数cmd/metrics-server/app/options/kubelet_client.go节点地址优先级解析pkg/utils/address_resolver.go周期性采集与并发抓取pkg/scraper/scraper.go采集循环、存储与健康探针pkg/server/server.gometrics.k8s.ioAPI 注册pkg/api/install.go内存存储与指标读写pkg/storage/storage.go部署清单默认参数/探针/安全上下文manifests/base/deployment.yamlAPIService 声明v1 与 v1beta1manifests/base/apiservice.yaml高可用补丁replicas2 反亲和manifests/components/high-availability/patch.yamlHelm 默认值与全部可调参数charts/metrics-server/values.yaml至此从架构定位、部署前置条件、安装与高可用方案到参数调优、扩展容量规划以及请求/采集两条核心链路的源码级原理均已覆盖。读者可以以此为地图在实际集群中完成 Metrics Server 的部署、排障与容量规划。赞分享云原生后端容器编排弹性伸缩【免费下载链接】metrics-serverScalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.项目地址https://gitcode.com/gh_mirrors/me/metrics-server点击查看免费下载相关推荐Metrics Server安全部署指南生产环境最佳实践Metrics Server安全部署指南生产环境最佳实践 本文深入探讨了在生产环境中安全部署Metrics Server的全面指南涵盖了TLS证书配置与Ku云原生后端容器编排弹性伸缩Kubernetes Metrics Server最佳实践生产环境部署清单Kubernetes Metrics Server最佳实践生产环境部署清单 Kubernetes Metrics Server是Kubernetes集群中用于云原生后端容器编排弹性伸缩UJCMS Kubernetes部署云原生架构实践UJCMS Kubernetes部署云原生架构实践 前言传统部署的痛点与云原生解决方案 你是否还在为UJCMS的传统部署方式而烦恼每次版本更新都需要手动部后端前端CMS企业应用上一篇Eko浏览器扩展开发构建智能侧边栏聊天界面的完整指南下一篇cheat 源码开发指南从零跑通 make check 完整工作流做出你的第一个贡献创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
