亚马逊云国际版代充 AWS EKS Cluster autoscaler 无法自动扩容 Pod？IRSA 权限排查

AWS EKS Cluster Autoscaler 无法自动扩容 Pod？先查 IRSA 权限，再查账号与额度

很多人遇到的现象是：Pod 一直处于 Pending，Cluster Autoscaler 看起来“没反应”，但真正的问题往往不是“扩容算法失效”，而是它根本没有拿到权限、没有识别到节点组，或者你的 AWS 账号本身就被支付、风控、配额卡住了。

如果你现在正卡在“明明已经配了 autoscaler，Pod 还是不上去”，建议不要先改 Deployment，而是按下面顺序排查：IRSA 是否生效 → ASG 是否被发现 → 约束条件是否太死 → 账号额度/支付状态是否正常。很多线上故障，最终都落在这四个点上。

一、先看结论：CA 不扩容，最常见不是节点不够，而是它“看不到”或者“没权限动”

IRSA 没配好：Pod 里的 Cluster Autoscaler 不能 Assume Role，日志里常见 AccessDenied、sts:AssumeRoleWithWebIdentity 失败。
ASG 没打标签：CA 只能发现它认识的节点组，没标签就等于“隐身”。
Pod 条件太苛刻：nodeSelector、affinity、taint、PVC、资源请求过大，导致即使扩容也调度不上。
账号配额到了：EC2 vCPU、实例家族、EBS、ENI、Spot 额度不够，节点起不来。
支付或风控异常：新账号、异常登录、付款失败，都会让资源创建失败，看起来像 autoscaler 不工作。

亚马逊云国际版代充二、IRSA 排查：先看日志，再看信任关系，最后看策略

Cluster Autoscaler 的核心问题，很多时候就是 IRSA。你先看它有没有拿到身份：

kubectl -n kube-system logs deployment/cluster-autoscaler

如果日志里出现下面几类信息，基本方向就明确了：

AccessDenied：IAM 权限不够。
WebIdentityErr / AssumeRoleWithWebIdentity 失败：IRSA 信任关系有问题。
No node group found：ASG 标签或发现规则不对。
0 pods are unschedulable：其实不是 CA 的问题，Pod 没触发扩容条件。

你需要逐项确认：

集群是否已经关联 OIDC Provider。没做这一步，IRSA 基本跑不起来。
ServiceAccount 是否绑定了 IAM Role。看注解里有没有 eks.amazonaws.com/role-arn。
Role 信任策略是否限制到正确的 namespace 和 serviceaccount。很多人写了 role，但 namespace 写错一个字，结果就是无法 Assume。
IAM Policy 是否包含扩容所需动作。最少要有对 Auto Scaling 组的描述和修改权限。

常见缺失动作一般包括：

autoscaling:DescribeAutoScalingGroups
autoscaling:DescribeAutoScalingInstances
autoscaling:DescribeLaunchConfigurations
autoscaling:DescribeTags
autoscaling:SetDesiredCapacity
autoscaling:TerminateInstanceInAutoScalingGroup
部分场景还需要 ec2:Describe* 相关只读权限

实际排查里，我见过最多的是：策略文件照着网上抄了，但 trust policy 没改 namespace；或者 OIDC provider 没关联成功；或者 SA 名字变了，Role 还是旧绑定。这种问题不会报得很直白，但日志里通常会留痕。

三、很多“扩容失败”，其实是 Pod 根本没满足扩容触发条件

Cluster Autoscaler 不是看到 Pod Pending 就一定加节点，它只会处理“有机会通过加节点解决”的场景。下面这些最容易把它卡住：

nodeSelector / nodeAffinity 太死：只允许某个很小的节点池。
taint / toleration 不匹配：新节点上来了，Pod 还是不能落。
PVC 绑定到固定 AZ：节点加在别的可用区也没用。
资源请求写太大：单个 Pod 请求已经超过节点规格上限。
max 节点数已经到顶：ASG 的 maxSize 没留余量。

这里有个很实际的经验：如果你做的是有状态服务，先查卷和可用区；如果是无状态服务，先查 requests/limits 和 affinity。很多团队以为是 autoscaler 没扩，最后发现是调度条件把自己锁死了。

四、账号购买、实名认证、支付方式：别等到扩容时才发现账号有问题

AWS 国际站没有国内那种统一的“实名制”流程，但账号的可用性，实际上很受付款方式、账单信息一致性、登录行为、区域选择影响。尤其是新账号，EKS + EC2 + ASG 连续创建，很容易触发风控。

如果你是刚开通的 AWS 账号，建议先确认这几件事：

信用卡是否支持国际线上扣款。不少卡能绑上，但创建实例时扣费失败。
账单地址、电话、邮箱是否一致。信息跳动太大，容易触发审核。
是否允许高频创建资源。刚注册就批量建 EKS、Node Group、EIP，风险更高。
是否有 Root 账号和 MFA。很多代开账号没有交付完整控制权，后面连 OIDC 和 IAM 都改不了。

支付方式上，AWS 更偏向后付费模式，不是你先充值再用那种逻辑。对业务方来说，这意味着两点：

账单没问题时，扩容比较顺。
付款失败或账号被暂停时，新节点创建会直接失败，表现得像 autoscaler“失灵”。

如果你是通过第三方账号购买服务，务必确认：能否拿到 Root 控制权、账单权限、IAM 管理权限、MFA 设置权限。缺一个，后面 IRSA 和权限排查都会被卡住。

五、风控和使用限制：新账号最容易踩的坑，不在代码里，在账户侧

我见过不少项目，代码完全没问题，但账号层面已经先失败了。常见场景：

短时间开太多实例：触发临时限制，ASG 拉新节点慢或者失败。
选择冷门区域：某些区域库存、配额、镜像可用性都不稳定。
实例规格受限：t3、m5、c6i 这些在某些账号上会被单独限额。
Spot 额度不足：你以为能省钱，实际上抢不到容量。

如果你的集群是业务刚上线，建议不要一开始就把 Cluster Autoscaler 的 maxSize 拉得很大。更稳的做法是：先设一个保守上限，确认扩容链路通了，再逐步放大。这样即使账号侧有问题，也不会把成本一下子拉爆。

六、成本对比：别只看节点单价，扩容策略决定月账单

方案	适合场景	成本特点	风险点
On-Demand 节点	稳定业务、排障阶段	单价高，但最直观	扩容快，账单也涨得快
Spot 节点	批处理、弹性流量	通常比按需便宜很多	被回收后会抖动，状态服务要谨慎
混合节点组	核心业务+弹性业务混跑	基础容量稳，峰值成本可控	调度策略复杂，标签和权重要配好

按实际经验，小规模 EKS 集群里，真正花钱的大头通常是节点，不是控制面。如果你现在月账单已经开始失控，先看是不是 autoscaler 把 Spot 和 On-Demand 混用得太激进，或者 max 节点数设得过大，导致夜间流量下去后还在保留冗余资源。

七、一个更贴近现场的排查顺序

看 Pod 是不是 Pending，还是已经被调度但容器起不来。
看 Cluster Autoscaler 日志里有没有 AccessDenied。
确认 IRSA 的 Role、Trust Policy、ServiceAccount 名字完全一致。
确认 ASG 标签是否存在，CA 是否能发现节点组。
看 Pod 的 requests、affinity、toleration、PVC 是否把调度锁死。
查 AWS 账号的 EC2 vCPU 配额、实例规格限制、付款状态。
检查是否触发了风控，尤其是新号、代开账号、异常地域登录。

亚马逊云国际版代充八、FAQ：最常被问到的几个点

Q：日志没报错，但就是不扩容，为什么？
A：多半是 Pod 没被认定为“可通过加节点解决”，常见原因是 nodeSelector、affinity、PVC、资源请求过大。

Q：IRSA 明明创建了，为什么还是 AccessDenied？
A：优先看 trust policy 的 subject 和 namespace，很多时候是 serviceaccount 名字或命名空间变了。

Q：AWS 账号刚开通，为什么创建 EKS 节点很慢？
A：新账号常见有支付验证、额度限制、风控检查，先把账单和配额确认掉，再看 autoscaler。

亚马逊云国际版代充 Q：要不要一上来就用 Spot？
A：如果你还在排障阶段，先用按需节点把链路跑通；Spot 适合后面做成本优化，不适合拿来当第一步验证。

如果你愿意，我可以下一步直接按“Cluster Autoscaler + IRSA 排查清单”给你整理一份可执行的检查表，包含命令、日志关键词、IAM policy 示例和常见误配置对照，方便你直接对着环境排。