Kubernetes Cluster Autoscaler 在阿里云AliCloud上的部署与源码级原理详解【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler导读本文基于本仓库autoscaler项目中 cluster-autoscaler/cloudprovider/alicloud/README.md 及其配套源码系统讲解如何让 Cluster AutoscalerCA在阿里云 Kubernetes 集群中基于弹性伸缩组Auto Scaling GroupASG自动扩缩容 Worker 节点。你将掌握两种身份认证方式AccessKey 与 STS/RAM Role的配置方法、ESS 伸缩组与伸缩配置的搭建要点、完整的 Deployment 部署清单以及--nodes、--expander、--scale-down-delay等关键参数的含义同时结合仓库源码理解 CA 与阿里云 ESS/ECS API 的真实调用链与底层实现细节做到既会部署、又懂原理。前置条件Kubernetes 版本要求按官方文档说明AliCloud 上的 Cluster Autoscaler 要求运行在v1.9.3 或更高版本的 Kubernetes 集群之上。CA 组件本身以Deployment的形式运行在你的集群内部负责监控集群中无法调度的 Pod并通过阿里云 ESS API 调整指定伸缩组内 ECS 实例的数量从而实现节点的自动扩缩容。支持的实例类型AliCloud 云厂商实现覆盖了四种 ECS 实例形态见 README标准实例Standard Instancex86 架构适用于网站、API 服务等常见场景GPU/FPGA 实例异构计算适用于高性能计算场景裸金属实例Bare Metal Instance兼具虚拟机的弹性与物理服务器的高性能、全特性抢占式实例Spot Instance按需折扣实例可在某些场景下显著降低 ECS 成本。从源码角度印证CA 的 AliCloud 实现内置了 GPU 节点支持alicloud_cloud_provider.go 中定义了 GPU 标签常量GPULabel aliyun.accelerator/nvidia_name并声明了可识别的 GPU 类型集合availableGPUTypesTesla-P4、M40、P100、V100。alicloud_instance_types.go 在构建节点模板时会通过DescribeInstanceTypes拉取实例规格并缓存vcpu、memoryInBytes、gpu等容量信息用于扩容前的调度模拟。两种部署路径总览ACS 控制台部署如果使用阿里云容器服务ACS/ACK托管集群可以直接在控制台开启“节点自动伸缩”能力属于托管化的一键部署路径详细操作见阿里云官方帮助文档本文不再赘述。自定义部署Custom Deployment适用于自行管理集群的场景也是本文 README 的核心内容分为以下三步准备身份认证AccessKey 或 STS RAM Role在 ESS 中创建伸缩组与伸缩配置含 User Data 入节点脚本部署cluster-autoscalerDeployment 并配置参数。第一步准备身份认证CA 通过阿里云 OpenAPIESS/ECS操作资源因此必须先为它提供云账号凭据。仓库支持两种经典方式另外源码中还额外支持了 RRSARAM Roles for Service Accounts方式。方式一使用 access-key-id 和 access-key-secret创建一个名为cloud-config的 Secret将阿里云 AccessKey ID、AccessKey Secret 与 Region ID 以base64 编码注意不要携带末尾换行符可使用echo -n your_access_key_id | base64生成后填入apiVersion: v1 kind: Secret metadata: name: cloud-config namespace: kube-system data: # insert your base64 encoded Alicloud access id and key here, ensure theres no trailing newline: # such as: echo -n your_access_key_id | base64 access-key-id: BASE64_ACCESS_KEY_ID access-key-secret: BASE64_ACCESS_KEY_SECRET region-id: BASE64_REGION_ID方式二使用 STS RAM Role为 CA 使用的 RAM 角色授予最小权限策略覆盖伸缩组的查询、扩缩容与实例移除所需的核心 API。将下面的策略附加到 RAM 角色上CA 即可在运行时通过 STS 换取临时凭证部署时无需再注入长期 AccessKey{ Version: 1, Statement: [ { Action: [ ess:Describe*, ess:CreateScalingRule, ess:ModifyScalingGroup, ess:RemoveInstances, ess:ExecuteScalingRule, ess:ModifyScalingRule, ess:DeleteScalingRule, ess:DetachInstances, ecs:DescribeInstanceTypes ], Resource: [ * ], Effect: Allow } ] }权限边界说明上述策略覆盖了 alicloud_auto_scaling.go 中autoScaling接口实际调用的绝大部分 API——包括DescribeScalingGroups、DescribeScalingConfigurations、DescribeScalingInstances、ModifyScalingGroup、RemoveInstances、CreateScalingRule/ModifyScalingRule/DeleteScalingRule、ExecuteScalingRule、ScaleWithAdjustment等ecs:DescribeInstanceTypes用于 alicloud_instance_types.go 的实例规格缓存。生产环境建议为该 RAM 角色仅保留清单内 Action避免过度授权。源码补充三种认证的判定逻辑与 RRSA 方式alicloud_cloud_config.go 中的cloudConfig.isValid()展示了三种认证的完整优先级AccessKey 方式环境变量ACCESS_KEY_ID、ACCESS_KEY_SECRET、REGION_ID均非空即采用klog输出 “Using AccessKey authentication”RRSA 方式当REGION_ID、ALIBABA_CLOUD_OIDC_PROVIDER_ARN、ALIBABA_CLOUD_OIDC_TOKEN_FILE、ALIBABA_CLOUD_ROLE_ARN、ALIBABA_CLOUD_SESSION_NAME五者齐备时启用兼容ALICLOUD_*旧前缀变量名适合 ACK 上基于 OIDC 的免密 ServiceAccount 认证STS元数据方式若前两者缺失CA 会尝试从 ECS 元数据服务读取绑定到实例上的 RAM RolevalidateSTSToken()通过后启用STSEnabled且 alicloud_auto_scaling.go 中会以refreshClientInterval 60 * time.Minute为周期定时刷新 STS 客户端确保证书不过期。对应的 RRSA 部署清单可直接参考仓库示例 cluster-autoscaler-rrsa-standard.yaml其核心是 Secret 中注入oidc-provider-arn、oidc-token-file-path、role-arn、session-name、region-id五个字段并通过 projected volume 挂载有效期expirationSeconds: 7200、audience 为sts.aliyuncs.com的 ServiceAccountToken 到/var/run/secrets/tokens。第二步ASG伸缩组配置在 ESS 控制台essnew.console.aliyun.com中完成两部分配置创建伸缩组Scaling Group使用有效配置创建一个伸缩组作为 CA 扩缩容的载体为该伸缩组创建伸缩配置Scaling Configuration指定合法的instanceType实例规格与User Data。在 User Data 中写入初始化脚本用于初始化节点环境并将新节点加入 Kubernetes 集群。若你的 Kubernetes 集群由 ACS 托管可在 User Data 中使用类似如下的 attach 脚本其中 token 由 ACS 控制台生成#!/bin/sh # The token is generated by ACS console. https://www.alibabacloud.com/help/doc-detail/64983.htm?spma2c63.l28256.b99.33.46395ad54ozJFq curl http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/pkg/run/attach/[kubernetes_cluster_version]/attach_node.sh | bash -s -- --openapi-token [token] --ess true自行管理集群非 ACS 托管时需要编写你自己的入节点脚本本质上是“初始化环境 将节点 join 到集群”。需要特别说明的是CA 的 AliCloud 实现只支持静态指定伸缩组不支持 Auto-Discovery见下文专节。因此伸缩组创建好后其 ID形如asg-xxxx将被直接写进 Deployment 的--nodes参数。第三步部署 cluster-autoscaler Deployment使用 access-key-id 和 access-key-secret以Deployment形式部署将 Secret 中的三项凭据通过secretKeyRef注入环境变量并挂载宿主机的 CA 证书/etc/ssl/certs/ca-certificates.crtapiVersion: apps/v1 kind: Deployment metadata: name: cluster-autoscaler namespace: kube-system labels: app: cluster-autoscaler spec: replicas: 1 selector: matchLabels: app: cluster-autoscaler template: metadata: labels: app: cluster-autoscaler spec: priorityClassName: system-cluster-critical serviceAccountName: admin containers: - image: registry.cn-hangzhou.aliyuncs.com/acs/autoscaler:v1.3.1.2 name: cluster-autoscaler resources: limits: cpu: 100m memory: 300Mi requests: cpu: 100m memory: 300Mi command: - ./cluster-autoscaler - --v4 - --stderrthresholdinfo - --cloud-provideralicloud - --nodes[min]:[max]:[ASG_ID] imagePullPolicy: Always env: - name: ACCESS_KEY_ID valueFrom: secretKeyRef: name: cloud-config key: access-key-id - name: ACCESS_KEY_SECRET valueFrom: secretKeyRef: name: cloud-config key: access-key-secret - name: REGION_ID valueFrom: secretKeyRef: name: cloud-config key: region-id volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs/ca-certificates.crt readOnly: true imagePullPolicy: Always volumes: - name: ssl-certs hostPath: path: /etc/ssl/certs/ca-certificates.crt使用 STS RAM Role使用 STS 方式时无需注入任何云账号密钥仅需保留启动参数与资源配额凭据通过 ECS 元数据服务获取apiVersion: apps/v1 kind: Deployment metadata: name: cluster-autoscaler namespace: kube-system labels: app: cluster-autoscaler spec: replicas: 1 selector: matchLabels: app: cluster-autoscaler template: metadata: labels: app: cluster-autoscaler spec: priorityClassName: system-cluster-critical serviceAccountName: admin containers: - image: registry.cn-hangzhou.aliyuncs.com/acs/autoscaler:v1.3.1.2 name: cluster-autoscaler resources: limits: cpu: 100m memory: 300Mi requests: cpu: 100m memory: 300Mi command: - ./cluster-autoscaler - --v4 - --stderrthresholdinfo - --cloud-provideralicloud - --nodes[min]:[max]:[ASG_ID] imagePullPolicy: Always关键启动参数解析参数取值示例说明--cloud-provideralicloud指定云厂商实现对应源码中 alicloud_cloud_provider.go 的ProviderName alicloud并通过builder.RegisterCloudProvider注册为默认 Provider--nodes[min]:[max]:[ASG_ID]--nodes1:10:asg-xxxx静态声明节点组可重复传入以管理多个伸缩组min/max为扩缩容上下限ASG_ID为 ESS 伸缩组 ID格式对应源码addNodeGroup注释minNodes:maxNodes:asgName--v4klog 日志级别级别越高输出越详细便于排查扩缩容决策--stderrthresholdinfo将 info 及以上级别日志输出到 stderr--nodes的解析路径在 alicloud_cloud_provider.go 中体现BuildAliCloudProvider会检查discoveryOpts.StaticDiscoverySpecified()逐条调用addNodeGroup(spec)经dynamic.SpecFromString(value, true)解析出min/max/name并在启动时立即调用getScalingGroupByID校验该伸缩组确实存在否则报错your scaling group: %s does not exist并拒绝启动。RBAC 与完整部署清单README 的 Deployment 中使用了serviceAccountName: admin更规范的实践是使用最小权限 ServiceAccount。仓库在 examples/cluster-autoscaler-standard.yaml 中提供了完整的“ServiceAccount ClusterRole Role ClusterRoleBinding RoleBinding Secret Deployment”一体化清单权限覆盖对nodes的watch/list/get/update对pods/eviction的create驱逐 Pod 用对 Pod、Service、Deployment 等资源的只读能力用于调度模拟与统计对configmapscluster-autoscaler-status、cluster-autoscaler-priority-expander的读写支撑状态展示与 priority expander。生产环境建议直接基于该示例清单部署并将其中[YOUR_BASE64_AK_ID]等占位符替换为实际值。Auto-Discovery当前暂不支持README 明确指出Auto Discovery 目前在 AliCloud 上不被支持。这一点在源码中得到强印证alicloud_cloud_provider.go 的BuildAliCloudProvider中当discoveryOpts.AutoDiscoverySpecified()为真时会直接返回错误if discoveryOpts.AutoDiscoverySpecified() { return nil, fmt.Errorf(only support static discovery scaling group in alicloud for now) } return nil, fmt.Errorf(failed to build alicloud provider: node group specs must be specified)也就是说AliCloud 实现只能通过--nodes静态声明节点组新增伸缩组必须同步修改 Deployment 参数并重新部署。这是与其他支持自动发现的云厂商实现如 AWS的重要差异规划多伸缩组架构时需提前设计好--nodes参数的管理方式。常用参数与注意事项Common Notes and Gotchas部署上线后以下参数与行为直接影响扩缩容的实际表现CA 证书挂载/etc/ssl/certs/ca-certificates.crt在 ECS 实例上默认存在Deployment 通过 hostPath 挂载它供 CA 访问云 API 时使用若缺失将导致 TLS 校验失败。跳过 kube-system 节点默认情况下 CA不会缩容运行有 kube-system 命名空间 Pod 的节点。如需允许缩容可传入--skip-nodes-with-system-podsfalse。缩容冷却时间默认情况下两次缩容操作之间等待10 分钟。可通过--scale-down-delay调整例如--scale-down-delay5m将缩容延迟缩短到 5 分钟。这与 CA 的防抖动设计一致避免节点刚缩下去又被立刻拉起。多 ASG 时的扩容选择--expander当运行多个伸缩组时--expander支持三种策略random扩容时随机选择一个 ASGmost-pods选择能调度最多 Pod 的 ASG 进行扩容least-waste选择 CPU/内存浪费最少的 ASG 进行扩容。 在平局tie情况下CA 会回退到random策略。kubelet 的 provider-id如果你自行管理 kubelet必须以--provider-id参数启动。这是因为 CA 依赖节点对象上的spec.providerID反查 ECS 实例与伸缩组的归属关系详见下一节缺失该字段的节点无法被正确识别与缩容。源码级原理CA 如何与阿里云 ESS/ECS 协同工作节点归属判定与 ProviderID 格式CA 通过节点的providerID建立“Kubernetes Node ↔ ECS 实例 ↔ 伸缩组”的映射。AliCloud 的 providerID 格式为REGION.INSTANCE_ID例如cn-hangzhou.i-xxxx解析逻辑见 alicloud_cloud_provider.go 的ecsInstanceIdFromProviderId按.切分后取第二段作为 ECS 实例 ID。对应测试 alicloud_cloud_provider_test.go 中的TestEcsInstanceIdFromProviderId验证了cn-hangzhou.instanceId→instanceId的解析结果。NodeGroupForNode据此调用manager.GetAsgForInstance完成节点归属查询。Asg 对 NodeGroup 接口的实现alicloud_auto_scaling_group.go 中的Asg结构体完整实现了 CA 的cloudprovider.NodeGroup接口核心行为包括IncreaseSize先校验delta 0再校验扩容后的规模不超过MaxSize最后调用SetAsgSizeDecreaseTargetSize / DeleteNodes缩容时先校验不低于MinSize并确保所有待删节点都属于当前 ASG通过Belongs反查随后批量调用DeleteInstancesTemplateNodeInfo通过getAsgTemplate读取伸缩组当前生效的伸缩配置ActiveScalingConfigurationId与实例规格构建“模板节点”用于扩容前的调度可行性模拟。扩容/缩容的底层 API 调用链查询规模alicloud_manager.go 的GetAsgSize优先返回EnableDesiredCapacity时的DesiredCapacity否则返回ActiveCapacity PendingCapacity InitCapacity之和调整规模alicloud_auto_scaling.go 的setCapacityInstanceSize使用 ESS 的ScaleWithAdjustment接口AdjustmentType TotalCapacity直接设定目标容量并携带SyncActivity true同步等待伸缩活动同时附加ActivityMetadata标记{cluster-autoscaler/alicloud/managed:true}便于在伸缩活动中识别 CA 的扩缩容行为移除实例DeleteInstances会先校验所有实例属于同一个 ASG再逐台调用RemoveInstances并通过sdkCoolDownTimeout 200ms的休眠避免触发 API 流量控制flow control实例分页getScalingInstancesByGroup按每页 10 条defaultRequestPageSize分页拉取伸缩组内全部实例处理大规模节点组时分页会持续进行直到TotalCount取尽。GPU 与模板节点能力alicloud_manager.go 的buildNodeFromTemplate从实例规格缓存中取得vcpu、memoryInBytes、gpu后构建模拟 NodeCPU/内存/GPU 分别写入ResourceCPU、ResourceMemory、ResourceGPUnvidia.com/gpuPod 数量上限固定为defaultPodAmountsLimit 110同时通过buildGenericLabels为模板节点附加topology.kubernetes.io/region、zone、实例规格标签以及伸缩配置中携带的自定义 Tags。这使得 CA 在扩容前能够准确评估“新节点能否容纳待调度 Pod”避免盲目扩容。验证与日常运维建议观察日志以--v4启动后可通过kubectl logs -n kube-system cluster-autoscaler-pod观察“扩容决策、ESS 调用、伸缩活动 ID”等关键日志查看状态CA 会维护kube-system/cluster-autoscaler-statusConfigMap其中记录了各节点组的 min/max/当前规模与最近伸缩事件变更伸缩组新增或修改 ASG 时同步更新 Deployment 的--nodes参数注意--expander策略对多 ASG 扩容选择的影响缩容预期记住默认 10 分钟缩容延迟、默认不缩容 kube-system Pod 节点这两个“保护性”行为避免误判为故障权限最小化长期运行建议从serviceAccountName: admin收敛到 cluster-autoscaler-standard.yaml 中定义的最小 RBAC 权限并将 AccessKey 换用 STS/RRSA 方式以降低密钥泄露风险。总结本文完整复现了 AliCloud 云厂商从身份认证、ESS 伸缩组配置到 CA Deployment 部署的全部官方流程并补充了 RBAC 示例、RRSA 免密方式、Auto-Discovery 限制以及源码级调用链解析。核心要点可归纳为--nodes[min]:[max]:[ASG_ID]静态声明节点组、三种认证方式按 AccessKey → RRSA → STS 元数据的优先级判定、--expander决定多 ASG 扩容策略、providerID 必须为REGION.INSTANCE_ID格式。结合 README、examples 目录与alicloud_*.go源码即可在生产集群中稳定落地基于阿里云 ESS 的节点自动伸缩。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考