企业官网建设流程全解析

• 云原生
• 容器编排
• DevOps

本篇基于 eksctl v0.225.0 的发布说明（docs/release_notes/0.225.0.md）展开，解读该版本引入的三项功能——Pod Identity 关联的permissionPolicyName内联策略命名、Fargate Profile 对 EKS 内部端点的支持、Auto Mode NodeRole 增加 ECR Public 镜像拉取权限——以及一项 goformation 缺陷修复。读完后，你将理解每个变更在代码层面的落点（API 定义、校验逻辑、CloudFormation 模板生成），并能结合源码证据判断这些特性在自建 VPC、私有端点场景下的适用前提与限制。

版本总览

v0.225.0 是一个小版本迭代，变更聚焦而非发散。对照 docs/release_notes/0.225.0.md，本版本包含：

发布说明同时向 @HusainZafar、@ShiriNmi1520、@avoidik 和 @fletcherw 致谢。下面逐项结合仓库源码展开。

功能一：Pod Identity 内联策略命名 permissionPolicyName

背景：podIdentityAssociations 与内联策略

eksctl 允许在集群配置中通过iam.podIdentityAssociations声明 Pod Identity 关联（AWS 对 IRSA 的替代机制），为指定 ServiceAccount 创建并绑定 IAM 角色。角色的权限可以来自受管策略（wellKnownPolicies）、已有策略（permissionPolicyARNs），也可以直接以内联文档形式写在配置里（permissionPolicy）。在此之前，内联策略生成的AWS::IAM::ManagedPolicy资源在 CloudFormation 模板中只能使用默认名称（Policy1），这带来了两个实际问题：

• 模板可读性差：审计或评审 CloudFormation 模板时，Policy1无法反映策略的业务含义；
• 命名冲突风险：同一模板中存在多个内联策略时，默认名容易造成混淆。

v0.225.0 起，PodIdentityAssociation结构体新增了可选字段permissionPolicyName（见 pkg/apis/eksctl.io/v1alpha5/iam.go#L195-L199）：

// +optional PermissionPolicyARNs []string `json:"permissionPolicyARNs,omitempty"` // +optional PermissionPolicyName string `json:"permissionPolicyName,omitempty"` // +optional PermissionPolicy InlineDocument `json:"permissionPolicy,omitempty"`

配置示例（permissionPolicy与permissionPolicyName搭配使用）：

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-pia iam: podIdentityAssociations: - namespace: my-ns serviceAccountName: my-sa permissionPolicyName: MyPodIdentityPolicy permissionPolicy: Version: "2012-10-17" Statement: - Effect: Allow Action: - "s3:GetObject" Resource: "arn:aws:s3:::my-bucket/*"

校验规则

字段并非任意填写。pkg/apis/eksctl.io/v1alpha5/validation.go#L2005-L2023 中的validatePermissionPolicyName定义了约束：

1. permissionPolicyName为空则跳过（保持向后兼容）；
2. 设置了名称但未提供permissionPolicy内联文档时，报错permissionPolicyName requires permissionPolicy to be set——名称只能用于内联策略；
3. 名称中必须至少包含一个字母或数字，否则报错permissionPolicyName %q must contain at least one alphanumeric character。

校验在两个入口生效：集群级iam.podIdentityAssociations（validation.go#L248 对cfg.IAM.PodIdentityAssociations逐项调用），以及addon.podIdentityAssociations（validation.go#L2039 在 addon 关联中同样调用该函数）。对应的行为测试位于 pkg/apis/eksctl.io/v1alpha5/validation_test.go#L3086-L3146，覆盖了合法名称"my-policy"与非法名称"---!!!"的用例。

CloudFormation 模板落点

模板生成侧的实现在 pkg/cfn/builder/iam.go#L364-L389：

func NewIAMRoleResourceSetForPodIdentity(spec *api.PodIdentityAssociation) *IAMRoleResourceSet { attachPolicyName := "Policy1" if spec.PermissionPolicyName != "" { attachPolicyName = spec.PermissionPolicyName } ... }

从源码结构看，attachPolicyName随后在资源集渲染时通过rs.template.AttachPolicy(rs.attachPolicyName, roleRef, rs.attachPolicy)（pkg/cfn/builder/iam.go#L525）传入 goformation 模板，即内联策略对应的AWS::IAM::ManagedPolicy资源名直接采用用户指定值。作为对照，ServiceAccount（IRSA）与 Capability 角色仍固定使用"Policy1"。测试 pkg/cfn/builder/iam_test.go#L462 中设置了PermissionPolicyName: "PodIdentityPolicy"，验证了该名称最终出现在生成的模板输出中。

功能二：Fargate Profile 支持 EKS 内部端点

场景与约束

当 EKS 集群 API 端点仅通过 VPC 内部端点（private endpoint）对外提供时，eksctl 此前在创建 Fargate Profile 的场景下可能不受支持。该限制与集群的端点访问配置相关：clusterEndpoints.privateAccess: true且publicAccess: false，或控制面 ENI 仅部署在私有子网（参见官方示例 examples/49-control-plane-on-private-subnets.yaml，其中通过vpc.clusterEndpoints与vpc.controlPlaneOnPrivateSubnets控制端点暴露面）。

代码落点

Fargate Pod 执行角色（pod execution role）的构建位于 pkg/cfn/builder/fargate.go#L68-L115。v0.225.0 的变更让该路径在处理非标准（内部/自定义）EKS 端点时采用专属的 assume role 策略文档：

var assumeRolePolicyDocument interface{} if cfg.IsCustomEksEndpoint() { // Use beta assume role policy for beta stacks with Fargate-specific service principals assumeRolePolicyDocument = createBetaFargateAssumeRolePolicy(sourceArnCondition) } else { assumeRolePolicyDocument = cft.MakeAssumeRolePolicyDocumentForServicesWithConditions( sourceArnCondition, MakeServiceRef("EKSFargatePods"), // Ensure that EKS can schedule pods onto Fargate. ) }

要点：

• 标准 AWS 分区下，角色的 assume policy 以eks-fargate-pods.amazonaws.com服务主体为 Principal，并附带aws:SourceArn条件（pkg/cfn/builder/fargate.go#L117-L127 中makeSourceArnCondition生成arn:partition:eks:region:account:fargateprofile/cluster/*），这是 AWS 官方建议的防止 confused deputy 的写法；
• 对于IsCustomEksEndpoint()返回 true 的集群（即使用内部/自定义端点的场景），改用createBetaFargateAssumeRolePolicy生成的策略，其服务主体引用按分区映射表解析，保证不同分区（含 govcloud/china 等内部端点形态）下服务主体名称正确；
• Fargate 客户端本身（pkg/fargate/fargate.go、pkg/fargate/create.go）通过 provider 注入的 EKS API 客户端与DescribeFargateProfile等 API 交互，因此只要集群端点可达（例如客户端位于 VPC 内或通过私有端点路由），创建 Fargate Profile 即可成功。

需要说明的适用前提：该特性面向端点仅内部可达的集群；如果你的集群仍是默认公网端点，行为不变。

功能三：Auto Mode NodeRole 支持 ECR Public 镜像拉取

变更内容

EKS Auto Mode 节点角色（NodeRole）用于 Auto Mode 实例启动。v0.225.0 为其增加了从 ECR Public 拉取容器的权限，使得 Auto Mode 节点可以直接运行来自 ECR Public Gallery 的公共镜像。

模板证据

该权限声明在 Auto Mode 节点角色的 CloudFormation 角色模板 pkg/cfn/builder/roles/auto-mode-node-role.yaml#L20-L25 中：

ManagedPolicyArns: - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly" - !If [IsAWSPartition, !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonElasticContainerRegistryPublicReadOnly", !Ref "AWS::NoValue"] - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy"

从源码结构看，这里有两点值得注意：

• 分区条件IsAWSPartition：模板顶部定义了Conditions: IsAWSPartition: !Equals [!Ref "AWS::Partition", "aws"]，只有标准 AWS 分区才附加AmazonElasticContainerRegistryPublicReadOnly策略——因为 ECR Public 在 GovCloud/China 等非 aws 分区不可用，用!If ... !Ref "AWS::NoValue"的条件式 ARN 避免了其他分区下模板校验失败；
• 策略来源：该模板由 pkg/cfn/builder/auto_mode.go 通过//go:embed roles/auto-mode-node-role.yaml内嵌并解析，AutoModeNodeRoleARN作为 stack 输出（pkg/cfn/builder/auto_mode.go#L100-L102）供后续资源引用；角色本身仍以 EC2 服务为主体、附加AmazonEC2ContainerRegistryPullOnly（私有 ECR 拉取）与AmazonEKSWorkerNodeMinimalPolicy等最小权限受管策略。

对应的配置入口见 examples/42-auto-mode.yaml（autoMode.enabled: true），创建启用 Auto Mode 的集群后，节点角色自动携带上述拉取权限，无需额外配置。

缺陷修复：goformation 移除多余 condition

本版本还包含一项 goformation（eksctl 内嵌的 CloudFormation 模板生成库）修复：#8691 "Remove redundant condition in property.go"，移除了 pkg/goformation/generate/property.go（代码生成器）产出逻辑中一个多余的 condition。goformation 的生成代码覆盖了 pkg/goformation/cloudformation/ 下几乎所有 AWS 资源类型的模板序列化逻辑，此类修复减少了生成模板中的冗余条件节点，使集群、节点组等 CloudFormation 模板输出更干净，也更贴近手工编写的模板形态。该变更不影响命令行行为，属于底层库的卫生性修复。

小结

v0.225.0 的三项功能都指向更严格的网络隔离与更细粒度的 IAM 治理方向：

1. permissionPolicyName让 Pod Identity 内联策略在 CloudFormation 模板中拥有可辨识的资源名，规则是"必须与permissionPolicy同时出现、且至少含一个字母数字"（pkg/apis/eksctl.io/v1alpha5/validation.go#L2005-L2023）；
2. Fargate Profile 的创建链路在IsCustomEksEndpoint()分支下切换到分区感知的 Fargate 服务主体策略（pkg/cfn/builder/fargate.go#L88-L96），使仅暴露内部端点的集群也能正常挂载 Fargate 工作负载；
3. Auto Mode NodeRole 按分区条件附加AmazonElasticContainerRegistryPublicReadOnly（pkg/cfn/builder/roles/auto-mode-node-role.yaml），补齐 Auto Mode 节点拉取公共镜像的能力。

结合仓库中现有的校验测试（pkg/apis/eksctl.io/v1alpha5/validation_test.go）、模板测试（pkg/cfn/builder/iam_test.go）与官方示例（examples/49-control-plane-on-private-subnets.yaml、examples/42-auto-mode.yaml），可以确认上述行为已在当前主干代码中落地并可复现。

• 云原生
• 容器编排
• DevOps