kubeasz 实践指南Kubernetes HPA 自动水平伸缩原理与 Metrics Server 指标落地【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeaszHPAHorizontal Pod Autoscaling是 Kubernetes 中最能体现弹性伸缩、完全自动化能力的核心特性应用负载Pod可以根据资源使用率自动扩容、缩容从容应对业务高峰与低谷这也是区别于传统运维方式的显著优势。本文以 kubeasz 项目使用 Ansible 脚本安装 K8S 集群为环境完整讲解 HPA 的指标模型、基于autoscaling/v1的 CPU 示例实验以及其底层数据来源 Metrics Server 的架构与部署验证读者学习后可独立完成 HPA 的搭建、压测与排障。HPA 是什么自动水平伸缩的动机与价值运行在 Kubernetes 上的应用负载Pod其资源使用率通常都有高峰和低谷白天业务繁忙、夜间访问稀疏或者电商大促、热点事件导致瞬时流量激增。如果人工运维要么提前申请大量节点与副本造成资源浪费要么在流量突增时来不及扩容导致服务过载。HPAHorizontal Pod Autoscaling水平 Pod 自动伸缩正是为解决这一矛盾而生的 Kubernetes 内置特性它根据 CPU 使用率或自定义 metrics 自动扩展 Pod 数量支持 replication controller、deployment 等 workload 类型扩容时按水平方向增加副本数Scale Out缩容时减少副本数Scale In并且整个过程完全自动化不需要人工干预。监控指标的获取方式演进HPA 判断资源使用率依赖集群的监控指标管线其获取方式在不同版本间有明显演进这也是理解 HPA 原理的关键背景k8s 1.6 版本之前通过 kubelet 直接获取监控指标k8s 1.6 版本之后通过 api server、heapster 或者 kube-aggregator聚合器来获取监控指标。也就是说新版 Kubernetes 中 HPA 控制器是通过 API Server 的聚合层Aggregation Layer访问 Metrics API如metrics.k8s.io来取得 Pod 的实时资源用量而不再是直接与 kubelet 对话。HPA 支持的 Metrics 类型与判断逻辑HPA 依据所在 API 版本决定可用的指标类型判断资源使用率时靠以下指标API 版本支持的指标说明autoscaling/v1CPU仅支持基于 CPU 使用率requests 的百分比的伸缩autoscaling/v2alpha1内存、自定义 metrics、多 metrics 组合支持更丰富的指标来源对于autoscaling/v2alpha1引入的多 metrics 组合其核心逻辑是根据每个 metric 的值分别计算出 scale 值并将最大的那个值作为扩容的最终结果从而保证任何一项指标超限都能被及时响应。在 kubeasz 项目中HPA 实验环境基于 k8s 1.8 和 1.9仅使用autoscaling/v1版本 API注意确保 k8s 集群插件kubedns和heapster或等价指标组件工作正常。HPA 基础示例php-apache 自动伸缩全流程实验本实验采用经典的hpa-example示例镜像完整复现创建应用 → 创建 autoscaler → 加压 → 观察扩容 → 减压 → 观察缩容的全过程。第一步创建 Deployment 和 Service# 创建deploy和service $ kubectl run php-apache --imagepilchard/hpa-example --requestscpu200m --expose --port80要点说明--requestscpu200m为每个 Pod 声明 CPU request 为 200 millicores0.2 核这是 HPA 计算使用率百分比的分母基准--expose --port80同时生成对应的 Service供后续负载发生器通过http://php-apache访问。第二步创建 Autoscaler# 创建autoscaler $ kubectl autoscale deploy php-apache --cpu-percent50 --min1 --max10参数含义--cpu-percent50目标 CPU 使用率相对 requests 的百分比为 50%--min1副本数下限 1即使完全空闲也至少保留 1 个 Pod--max10副本数上限 10防止无限扩容打爆集群。第三步查看 HPA 初始状态# 等待3~5分钟查看hpa状态 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 0% / 50% 1 10 1 3m此时无负载TARGETS 显示0% / 50%副本保持 1 个。第四步增加负载触发扩容# 增加负载 $ kubectl run --rm -it load-generator --imagebusybox /bin/sh Hit enter for command prompt $ while true; do wget -q -O- http://php-apache; done;用一个 busybox 容器持续向php-apache服务发起 HTTP 请求模拟高并发访问# 等待约5分钟查看hpa显示负载增加且副本数目增加为4 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 430% / 50% 1 10 4 4m负载达到430% / 50%远超目标值 50%HPA 自动将副本扩容到 4 个。第五步观察扩容速度限制与持续扩容# 注意k8s为了避免频繁增删pod对副本的增加速度有限制 # 实验过程可以看到副本数目从1到4到8到10大概都需要4~5分钟的缓冲期 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 86% / 50% 1 10 8 9m $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 52% / 50% 1 10 10 12m从输出可以清晰看到两个关键机制扩容有缓冲期副本从 1 → 4 → 8 → 10 每步之间大约需要 4~5 分钟。这是 Kubernetes 为了避免频繁增删 Pod抖动而刻意引入的速度限制副本数受 max 上限约束即使 TARGETS 仍高于目标值副本数也不会突破--max10的限制。第六步清除负载观察缩容# 清除负载CTRLC 结束上述循环程序稍后副本数目变回1 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 0% / 50% 1 10 1 17m在 load-generator 容器中按CTRLC结束循环后负载归零HPA 检测到长期低负载后逐步把副本缩回下限 1 个。整个实验完整演示了高峰自动扩容、低谷自动缩容的闭环。HPA 的底层数据源Metrics Server 架构与部署HPA 要工作前提是集群中必须存在一个可用的指标数据源。从 k8s v1.8 开始资源使用情况的度量如容器的 CPU 和内存使用通过Metrics API获取其前提是集群中部署了Metrics Server。Metrics Server 从 Kubelet 公开的 Summary API 采集指标信息符合 Kubernetes 的监控架构设计受 heapster 项目启发并且相比 heapster 的优势在于访问不需要 apiserver 的代理机制提供认证和授权等能力。很多集群内组件都依赖 Metrics ServerHPA、scheduler、kubectl top因此它应当作为集群默认组件运行。Metrics Server 的部署前提Metrics Server 是一个扩展的 apiserver依赖 kube-aggregator聚合层因此需要满足两个前提在 apiserver 中开启聚合层相关参数。kubeasz 在 kube-apiserver.service.j2 模板中已经配置了完整的聚合层参数... # 省略 --requestheader-client-ca-file{{ ca_dir }}/ca.pem \ --requestheader-allowed-namesaggregator \ --requestheader-extra-headers-prefixX-Remote-Extra- \ --requestheader-group-headersX-Remote-Group \ --requestheader-username-headersX-Remote-User \ --proxy-client-cert-file{{ ca_dir }}/aggregator-proxy.pem \ --proxy-client-key-file{{ ca_dir }}/aggregator-proxy-key.pem \ --enable-aggregator-routingtrue \生成 aggregator proxy 相关证书由 kubeasz 的 kube-master 角色 自动完成签发无需手工干预。kubeasz 中的自动安装方式从 kubeasz 0.1.0 开始metrics-server 已经默认集成安装。相关开关与版本号定义在集群配置文件中如 example/config.yml 的 cluster-addon 段# metric server 自动安装 metricsserver_install: yes metricsVer: __metrics__实际部署入口是 07.cluster-addon.yml 与 cluster-addon/tasks/metrics-server.yml该任务将 components.yaml.j2 模板渲染为metrics-server.yaml后执行kubectl apply且 tasks/main.yml 中通过检查metrics-server not in pod_info.stdout实现幂等安装已存在则跳过。安装命令如下# 默认已经集成安装假设集群名为xxxx ezctl setup xxxx all # 如果需要分步安装 ezctl setup xxxx 07 # 如果需要手动安装 kubectl apply -f /etc/kubeasz/clusters/xxxx/yml/metrics-server.yaml从模板看 Metrics Server 的实现细节kubeasz 渲染出的 components.yaml.j2 完整定义了 Metrics Server 所需的全部对象可以从中看到关键实现镜像easzlab.io.local:5000/easzlab/metrics-server:{{ metricsVer }}版本号由metricsVer变量控制支持离线/私有镜像仓库部署imagePullPolicy: IfNotPresent关键启动参数--secure-port10250、--kubelet-insecure-tls、--kubelet-preferred-address-typesInternalIP,ExternalIP,Hostname、--kubelet-use-node-status-port、--metric-resolution15s每 15 秒采集一次指标健康检查配置了livenessProbe/livez与readinessProbe/readyz失败阈值 3 次、每 10 秒探测一次最小资源requests 为 cpu 100m / memory 200Mi安全加固runAsNonRoot: true、runAsUser: 1000、readOnlyRootFilesystem: true、seccompProfile: RuntimeDefault并 drop 所有 capabilitiesRBAC创建system:aggregated-metrics-reader、system:metrics-server两个 ClusterRole并通过metrics-server:system:auth-delegatorClusterRoleBinding 委托认证通过metrics-server-auth-readerRoleBinding 读取extension-apiserver-authentication-readerAPIService 注册v1beta1.metrics.k8s.io将metrics.k8s.io组路由到 kube-system 命名空间下的metrics-server服务从而接入 apiserver 聚合层。验证 Metrics Server 与 HPA 联动验证新 API 已注册$ kubectl get apiservice|grep metrics v1beta1.metrics.k8s.io 1d看到v1beta1.metrics.k8s.io处于可用状态说明聚合层与 Metrics Server 已正常联通。验证 kubectl top 命令无需额外安装 heapster即可直接使用资源查询命令$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 192.168.1.1 116m 2% 2342Mi 60% 192.168.1.2 79m 1% 1824Mi 47% 192.168.1.3 82m 2% 1897Mi 49% $ kubectl top pod --all-namespaces # 输出略验证基于 metrics-server 的 HPA 自动缩放kubectl top能够输出数据即证明metrics.k8s.ioAPI 可被正常消费此时再执行上文php-apache 自动伸缩全流程实验中的kubectl autoscale系列命令HPA 控制器即可依据 Metrics Server 提供的实时 CPU 指标完成自动扩容与缩容详见 docs/guide/metrics-server.md 中的完整验证流程。排障与注意事项指标延迟Metrics Server 默认 15 秒采集一次指标HPA 控制器本身也有评估周期因此从加压到观察到扩容通常需要数分钟属正常现象不要误判为故障扩容节奏Kubernetes 为避免频繁增删 Pod 造成抖动对扩容速度有限制实验中 1 → 4 → 8 → 10 每步约 4~5 分钟缓冲期缩容则更保守request 声明不可省略基于autoscaling/v1的 CPU 百分比计算依赖 Pod 的requests.cpu未声明 requests 的 Pod 无法被该版本 HPA 正确评估数据源前提确保kubedns或 coredns与指标组件heapster 或 metrics-server工作正常且v1beta1.metrics.k8s.ioAPIService 处于 Healthy 状态若 HPA 一直显示unknown优先检查 Metrics Server 的--kubelet-insecure-tls与 kubelet 端口连通性版本约束本文实验基于 k8s 1.8/1.9 与autoscaling/v1新版集群如 kubeasz 默认支持的更新版本建议使用autoscaling/v2及内存/自定义指标但底层依赖的 Metrics Server 安装与验证方式完全一致。小结通过本文可以掌握 HPA 的完整链路从负载高峰/低谷的业务动机到autoscaling/v1基于 CPU 的伸缩模型再到 kubeasz 一键部署的 Metrics Server 为 HPA 提供实时指标。实验中可以看到副本数随负载从 1 → 4 → 8 → 10 自动扩容、负载归零后自动缩回 1 的完整闭环这正是 Kubernetes 弹性能力与传统运维相比最直观的优势体现。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kubeasz 实践指南：Kubernetes HPA 自动水平伸缩原理与 Metrics Server 指标落地
kubeasz 实践指南Kubernetes HPA 自动水平伸缩原理与 Metrics Server 指标落地【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeaszHPAHorizontal Pod Autoscaling是 Kubernetes 中最能体现弹性伸缩、完全自动化能力的核心特性应用负载Pod可以根据资源使用率自动扩容、缩容从容应对业务高峰与低谷这也是区别于传统运维方式的显著优势。本文以 kubeasz 项目使用 Ansible 脚本安装 K8S 集群为环境完整讲解 HPA 的指标模型、基于autoscaling/v1的 CPU 示例实验以及其底层数据来源 Metrics Server 的架构与部署验证读者学习后可独立完成 HPA 的搭建、压测与排障。HPA 是什么自动水平伸缩的动机与价值运行在 Kubernetes 上的应用负载Pod其资源使用率通常都有高峰和低谷白天业务繁忙、夜间访问稀疏或者电商大促、热点事件导致瞬时流量激增。如果人工运维要么提前申请大量节点与副本造成资源浪费要么在流量突增时来不及扩容导致服务过载。HPAHorizontal Pod Autoscaling水平 Pod 自动伸缩正是为解决这一矛盾而生的 Kubernetes 内置特性它根据 CPU 使用率或自定义 metrics 自动扩展 Pod 数量支持 replication controller、deployment 等 workload 类型扩容时按水平方向增加副本数Scale Out缩容时减少副本数Scale In并且整个过程完全自动化不需要人工干预。监控指标的获取方式演进HPA 判断资源使用率依赖集群的监控指标管线其获取方式在不同版本间有明显演进这也是理解 HPA 原理的关键背景k8s 1.6 版本之前通过 kubelet 直接获取监控指标k8s 1.6 版本之后通过 api server、heapster 或者 kube-aggregator聚合器来获取监控指标。也就是说新版 Kubernetes 中 HPA 控制器是通过 API Server 的聚合层Aggregation Layer访问 Metrics API如metrics.k8s.io来取得 Pod 的实时资源用量而不再是直接与 kubelet 对话。HPA 支持的 Metrics 类型与判断逻辑HPA 依据所在 API 版本决定可用的指标类型判断资源使用率时靠以下指标API 版本支持的指标说明autoscaling/v1CPU仅支持基于 CPU 使用率requests 的百分比的伸缩autoscaling/v2alpha1内存、自定义 metrics、多 metrics 组合支持更丰富的指标来源对于autoscaling/v2alpha1引入的多 metrics 组合其核心逻辑是根据每个 metric 的值分别计算出 scale 值并将最大的那个值作为扩容的最终结果从而保证任何一项指标超限都能被及时响应。在 kubeasz 项目中HPA 实验环境基于 k8s 1.8 和 1.9仅使用autoscaling/v1版本 API注意确保 k8s 集群插件kubedns和heapster或等价指标组件工作正常。HPA 基础示例php-apache 自动伸缩全流程实验本实验采用经典的hpa-example示例镜像完整复现创建应用 → 创建 autoscaler → 加压 → 观察扩容 → 减压 → 观察缩容的全过程。第一步创建 Deployment 和 Service# 创建deploy和service $ kubectl run php-apache --imagepilchard/hpa-example --requestscpu200m --expose --port80要点说明--requestscpu200m为每个 Pod 声明 CPU request 为 200 millicores0.2 核这是 HPA 计算使用率百分比的分母基准--expose --port80同时生成对应的 Service供后续负载发生器通过http://php-apache访问。第二步创建 Autoscaler# 创建autoscaler $ kubectl autoscale deploy php-apache --cpu-percent50 --min1 --max10参数含义--cpu-percent50目标 CPU 使用率相对 requests 的百分比为 50%--min1副本数下限 1即使完全空闲也至少保留 1 个 Pod--max10副本数上限 10防止无限扩容打爆集群。第三步查看 HPA 初始状态# 等待3~5分钟查看hpa状态 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 0% / 50% 1 10 1 3m此时无负载TARGETS 显示0% / 50%副本保持 1 个。第四步增加负载触发扩容# 增加负载 $ kubectl run --rm -it load-generator --imagebusybox /bin/sh Hit enter for command prompt $ while true; do wget -q -O- http://php-apache; done;用一个 busybox 容器持续向php-apache服务发起 HTTP 请求模拟高并发访问# 等待约5分钟查看hpa显示负载增加且副本数目增加为4 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 430% / 50% 1 10 4 4m负载达到430% / 50%远超目标值 50%HPA 自动将副本扩容到 4 个。第五步观察扩容速度限制与持续扩容# 注意k8s为了避免频繁增删pod对副本的增加速度有限制 # 实验过程可以看到副本数目从1到4到8到10大概都需要4~5分钟的缓冲期 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 86% / 50% 1 10 8 9m $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 52% / 50% 1 10 10 12m从输出可以清晰看到两个关键机制扩容有缓冲期副本从 1 → 4 → 8 → 10 每步之间大约需要 4~5 分钟。这是 Kubernetes 为了避免频繁增删 Pod抖动而刻意引入的速度限制副本数受 max 上限约束即使 TARGETS 仍高于目标值副本数也不会突破--max10的限制。第六步清除负载观察缩容# 清除负载CTRLC 结束上述循环程序稍后副本数目变回1 $ kubectl get hpa php-apache NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 0% / 50% 1 10 1 17m在 load-generator 容器中按CTRLC结束循环后负载归零HPA 检测到长期低负载后逐步把副本缩回下限 1 个。整个实验完整演示了高峰自动扩容、低谷自动缩容的闭环。HPA 的底层数据源Metrics Server 架构与部署HPA 要工作前提是集群中必须存在一个可用的指标数据源。从 k8s v1.8 开始资源使用情况的度量如容器的 CPU 和内存使用通过Metrics API获取其前提是集群中部署了Metrics Server。Metrics Server 从 Kubelet 公开的 Summary API 采集指标信息符合 Kubernetes 的监控架构设计受 heapster 项目启发并且相比 heapster 的优势在于访问不需要 apiserver 的代理机制提供认证和授权等能力。很多集群内组件都依赖 Metrics ServerHPA、scheduler、kubectl top因此它应当作为集群默认组件运行。Metrics Server 的部署前提Metrics Server 是一个扩展的 apiserver依赖 kube-aggregator聚合层因此需要满足两个前提在 apiserver 中开启聚合层相关参数。kubeasz 在 kube-apiserver.service.j2 模板中已经配置了完整的聚合层参数... # 省略 --requestheader-client-ca-file{{ ca_dir }}/ca.pem \ --requestheader-allowed-namesaggregator \ --requestheader-extra-headers-prefixX-Remote-Extra- \ --requestheader-group-headersX-Remote-Group \ --requestheader-username-headersX-Remote-User \ --proxy-client-cert-file{{ ca_dir }}/aggregator-proxy.pem \ --proxy-client-key-file{{ ca_dir }}/aggregator-proxy-key.pem \ --enable-aggregator-routingtrue \生成 aggregator proxy 相关证书由 kubeasz 的 kube-master 角色 自动完成签发无需手工干预。kubeasz 中的自动安装方式从 kubeasz 0.1.0 开始metrics-server 已经默认集成安装。相关开关与版本号定义在集群配置文件中如 example/config.yml 的 cluster-addon 段# metric server 自动安装 metricsserver_install: yes metricsVer: __metrics__实际部署入口是 07.cluster-addon.yml 与 cluster-addon/tasks/metrics-server.yml该任务将 components.yaml.j2 模板渲染为metrics-server.yaml后执行kubectl apply且 tasks/main.yml 中通过检查metrics-server not in pod_info.stdout实现幂等安装已存在则跳过。安装命令如下# 默认已经集成安装假设集群名为xxxx ezctl setup xxxx all # 如果需要分步安装 ezctl setup xxxx 07 # 如果需要手动安装 kubectl apply -f /etc/kubeasz/clusters/xxxx/yml/metrics-server.yaml从模板看 Metrics Server 的实现细节kubeasz 渲染出的 components.yaml.j2 完整定义了 Metrics Server 所需的全部对象可以从中看到关键实现镜像easzlab.io.local:5000/easzlab/metrics-server:{{ metricsVer }}版本号由metricsVer变量控制支持离线/私有镜像仓库部署imagePullPolicy: IfNotPresent关键启动参数--secure-port10250、--kubelet-insecure-tls、--kubelet-preferred-address-typesInternalIP,ExternalIP,Hostname、--kubelet-use-node-status-port、--metric-resolution15s每 15 秒采集一次指标健康检查配置了livenessProbe/livez与readinessProbe/readyz失败阈值 3 次、每 10 秒探测一次最小资源requests 为 cpu 100m / memory 200Mi安全加固runAsNonRoot: true、runAsUser: 1000、readOnlyRootFilesystem: true、seccompProfile: RuntimeDefault并 drop 所有 capabilitiesRBAC创建system:aggregated-metrics-reader、system:metrics-server两个 ClusterRole并通过metrics-server:system:auth-delegatorClusterRoleBinding 委托认证通过metrics-server-auth-readerRoleBinding 读取extension-apiserver-authentication-readerAPIService 注册v1beta1.metrics.k8s.io将metrics.k8s.io组路由到 kube-system 命名空间下的metrics-server服务从而接入 apiserver 聚合层。验证 Metrics Server 与 HPA 联动验证新 API 已注册$ kubectl get apiservice|grep metrics v1beta1.metrics.k8s.io 1d看到v1beta1.metrics.k8s.io处于可用状态说明聚合层与 Metrics Server 已正常联通。验证 kubectl top 命令无需额外安装 heapster即可直接使用资源查询命令$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 192.168.1.1 116m 2% 2342Mi 60% 192.168.1.2 79m 1% 1824Mi 47% 192.168.1.3 82m 2% 1897Mi 49% $ kubectl top pod --all-namespaces # 输出略验证基于 metrics-server 的 HPA 自动缩放kubectl top能够输出数据即证明metrics.k8s.ioAPI 可被正常消费此时再执行上文php-apache 自动伸缩全流程实验中的kubectl autoscale系列命令HPA 控制器即可依据 Metrics Server 提供的实时 CPU 指标完成自动扩容与缩容详见 docs/guide/metrics-server.md 中的完整验证流程。排障与注意事项指标延迟Metrics Server 默认 15 秒采集一次指标HPA 控制器本身也有评估周期因此从加压到观察到扩容通常需要数分钟属正常现象不要误判为故障扩容节奏Kubernetes 为避免频繁增删 Pod 造成抖动对扩容速度有限制实验中 1 → 4 → 8 → 10 每步约 4~5 分钟缓冲期缩容则更保守request 声明不可省略基于autoscaling/v1的 CPU 百分比计算依赖 Pod 的requests.cpu未声明 requests 的 Pod 无法被该版本 HPA 正确评估数据源前提确保kubedns或 coredns与指标组件heapster 或 metrics-server工作正常且v1beta1.metrics.k8s.ioAPIService 处于 Healthy 状态若 HPA 一直显示unknown优先检查 Metrics Server 的--kubelet-insecure-tls与 kubelet 端口连通性版本约束本文实验基于 k8s 1.8/1.9 与autoscaling/v1新版集群如 kubeasz 默认支持的更新版本建议使用autoscaling/v2及内存/自定义指标但底层依赖的 Metrics Server 安装与验证方式完全一致。小结通过本文可以掌握 HPA 的完整链路从负载高峰/低谷的业务动机到autoscaling/v1基于 CPU 的伸缩模型再到 kubeasz 一键部署的 Metrics Server 为 HPA 提供实时指标。实验中可以看到副本数随负载从 1 → 4 → 8 → 10 自动扩容、负载归零后自动缩回 1 的完整闭环这正是 Kubernetes 弹性能力与传统运维相比最直观的优势体现。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考