AWS EKS 资源管理：从集群创建、网络设计到安全治理¶

这篇文章解决什么问题¶

很多团队第一次接触 AWS EKS 时，容易把它理解成“在 AWS 上创建一个 Kubernetes 集群”。这个理解没有错，但太浅了。

EKS 真正落地时，工程上要同时回答几类问题：

集群资源怎么创建，控制面、节点组、插件和工作负载分别由谁管理
VPC、子网、路由表、NAT Gateway、负载均衡器怎么设计
Pod IP 从哪里来，节点能承载多少 Pod，跨可用区流量怎么走
IAM、RBAC、ServiceAccount、Pod 权限怎么隔离
镜像、密钥、日志、审计、入口流量和出口流量怎么安全管理

这篇文章按“资源创建 -> 网络设计 -> 安全管理 -> 运维检查”的顺序整理。目标不是把所有 AWS 控制台按钮讲一遍，而是建立一套能用于实施、排障和架构评审的 EKS 资源管理框架。

先理解 EKS 管什么，不管什么¶

EKS 是 AWS 提供的托管 Kubernetes 服务。它帮你托管 Kubernetes 控制面，包括 apiserver、etcd 等核心组件。你不需要自己维护控制面节点，也不需要自己做 etcd 备份和控制面高可用。

但这不代表创建 EKS 后就万事大吉。下面这些仍然是平台团队要设计和管理的：

VPC、子网、路由表、安全组、NAT Gateway
Worker Node、Managed Node Group、Fargate Profile
EKS Add-ons，例如 VPC CNI、CoreDNS、kube-proxy、EBS CSI Driver
Ingress Controller、Load Balancer Controller、ExternalDNS、cert-manager
IAM 角色、Pod 权限、Kubernetes RBAC
镜像仓库、日志、监控、审计、备份和升级策略

可以把 EKS 理解成：

AWS 负责托管 Kubernetes 控制面
平台团队负责设计和治理集群运行环境
业务团队负责交付应用工作负载

这也是 EKS 资源管理的核心边界。

EKS 资源创建的基本顺序¶

生产环境里，不建议直接在控制台随手点一个 EKS 集群。更合理的方式是先设计资源边界，再用 eksctl、Terraform、CloudFormation 或 AWS CDK 统一管理。

一个典型创建顺序如下：

规划 VPC 和子网
    |
创建 EKS Cluster IAM Role
    |
创建 EKS 控制面
    |
创建节点 IAM Role
    |
创建 Managed Node Group 或 Fargate Profile
    |
安装/托管 EKS Add-ons
    |
安装 AWS Load Balancer Controller 等平台组件
    |
配置命名空间、RBAC、Pod 权限和安全策略
    |
部署业务应用

这里最重要的不是命令顺序，而是资源所有权要清楚。

建议把 EKS 资源分成几层：

层级	典型资源	管理建议
基础网络层	VPC、Subnet、Route Table、NAT Gateway、Security Group	Terraform/CDK 管理
集群层	EKS Cluster、OIDC Provider、Cluster Add-ons	Terraform/eksctl 管理
节点层	Managed Node Group、Launch Template、Node IAM Role	Terraform/eksctl 管理
平台组件层	Ingress、CSI、ExternalDNS、监控日志组件	Helm/GitOps 管理
应用层	Deployment、Service、Ingress、HPA、ConfigMap	CI/CD 或 GitOps 管理

不要把所有资源都混在一个脚本里。网络、集群、平台组件和应用的生命周期不同，拆开后升级和回滚会更稳。

创建集群前要先定的关键参数¶

创建 EKS 前，至少要先确定这些参数：

AWS Region
Kubernetes 版本
VPC CIDR
Public Subnet 和 Private Subnet 数量
是否跨 2 个或 3 个可用区
节点类型：Managed Node Group、Self-managed Node、Fargate
节点实例规格和磁盘大小
Service 暴露方式：NLB、ALB、Ingress、PrivateLink
集群 API Server 访问方式：公网、私网、公私混合
Pod 权限模型：EKS Pod Identity 或 IRSA
日志审计：control plane logging、CloudWatch、CloudTrail

这些参数后期都能改，但有些修改成本很高。比如 VPC 地址空间、子网规划、集群 endpoint 访问模型和节点组架构，最好在创建前就想清楚。

网络设计：EKS 的第一道难题¶

EKS 的网络设计比自建 Kubernetes 更容易被低估。原因是 AWS VPC CNI 默认让 Pod 直接使用 VPC IP。

这带来一个好处：

Pod 可以像 EC2 一样拥有 VPC 内可路由的 IP

但也带来一个约束：

Pod 会消耗 VPC 子网 IP

所以 EKS 网络规划不是只给节点留 IP，还要给 Pod 留足 IP。

VPC 和子网规划¶

一个常见生产设计是：

VPC: 10.20.0.0/16

Public Subnet:
  10.20.0.0/24    ap-southeast-1a
  10.20.1.0/24    ap-southeast-1b
  10.20.2.0/24    ap-southeast-1c

Private Subnet:
  10.20.10.0/22   ap-southeast-1a
  10.20.14.0/22   ap-southeast-1b
  10.20.18.0/22   ap-southeast-1c

设计原则：

EKS 节点优先放在 Private Subnet
Public Subnet 主要放互联网入口资源，例如 ALB、NAT Gateway、Bastion
每个可用区至少一个 Public Subnet 和一个 Private Subnet
Private Subnet 要给节点和 Pod 留足地址空间
不要让 VPC CIDR 和办公网、IDC、其他云、VPN 网段冲突

如果集群规模可能增长，Private Subnet 不要切得太小。EKS 使用 VPC CNI 时，Pod IP 会从子网里分配，子网 IP 不够会直接影响 Pod 调度。

Public Subnet 和 Private Subnet 的职责¶

推荐职责如下：

Public Subnet:
  - Internet-facing ALB/NLB
  - NAT Gateway
  - 少量运维入口组件

Private Subnet:
  - EKS Worker Node
  - 业务 Pod
  - 内部 NLB
  - 内部平台组件

外部用户访问业务时，常见路径是：

Internet
  -> Internet-facing ALB
  -> EKS Ingress
  -> Service
  -> Pod in Private Subnet

Pod 访问公网时，常见路径是：

Pod
  -> Node
  -> Private Subnet Route Table
  -> NAT Gateway
  -> Internet

不要为了省事把工作节点直接放在 Public Subnet 并暴露公网 IP。这样短期方便，长期会增加攻击面和安全治理成本。

跨可用区设计¶

生产集群至少跨两个可用区，更推荐三个可用区。

跨可用区时要注意：

每个可用区都有节点组容量
Ingress/LoadBalancer 覆盖多个可用区
业务副本通过 topologySpreadConstraints 或反亲和分散
NAT Gateway 最好每个可用区一个，避免单点和跨可用区绕行
有状态服务要关注 EBS 卷的可用区绑定

EBS 是可用区级资源。Pod 如果挂载了 EBS，重建时通常只能调度到同一个可用区的节点上。这类工作负载要配合 StorageClass、节点标签和调度策略一起设计。

AWS VPC CNI 和 Pod IP¶

EKS 默认使用 AWS VPC CNI。它会给 Pod 分配 VPC 内的 IP，底层依赖 ENI 和辅助私有 IP。

需要重点关注：

每种 EC2 实例规格支持的 ENI 数量不同
每张 ENI 支持的私有 IP 数量不同
实例规格会影响单节点最大 Pod 数
子网剩余 IP 会影响 Pod 是否能继续创建

一个常见现象是：节点 CPU 和内存还有很多，但 Pod 调度失败。原因可能不是资源不够，而是子网 IP 或 ENI IP 不够。

排查时可以看：

kubectl describe node <node-name>
kubectl -n kube-system logs daemonset/aws-node
kubectl get pods -A -o wide

如果事件里出现 IP 分配失败，就要检查 VPC CNI、子网可用 IP、实例规格和 aws-node 日志。

集群 API Server 访问方式¶

EKS 控制面 endpoint 可以配置公网访问、私网访问，或两者同时开启。

常见选择：

模式	适合场景	风险点
Public endpoint	个人实验、临时环境、远程管理方便	暴露面更大，需要限制来源 CIDR
Private endpoint	生产、内网运维、合规要求高	需要 VPN、专线、堡垒机或云内运维环境
Public + Private	过渡阶段或多团队管理	要认真收敛公网访问来源

生产建议：

优先开启 private endpoint
如果必须开启 public endpoint，限制 allowed CIDR
不要把 0.0.0.0/0 长期放在 API Server 访问白名单里
运维入口通过 VPN、SSO、堡垒机或受控跳板机进入

入口流量设计¶

EKS 里常见入口方式有三类：

方式	典型组件	适合场景
Service type LoadBalancer	NLB	四层 TCP/UDP 服务
Ingress	AWS Load Balancer Controller + ALB	HTTP/HTTPS 七层服务
自建 Ingress Controller	Nginx Ingress + NLB/ALB	需要自定义 Nginx 行为

如果是标准 Web/API 服务，推荐：

Route 53
  -> ALB
  -> AWS Load Balancer Controller
  -> Kubernetes Ingress
  -> Service
  -> Pod

如果是 TCP 服务，例如数据库代理、消息队列入口、私有协议服务，可以考虑 NLB。

入口安全建议：

公网入口只暴露 ALB/NLB，不直接暴露节点
使用 ACM 管理 TLS 证书
需要防护时接入 AWS WAF
管理后台不要直接公网开放，至少限制来源 IP 或接入身份认证
内部服务使用 internal ALB/NLB

出口流量设计¶

Pod 出公网一般通过 NAT Gateway。这里也要做治理，不然很容易变成“所有 Pod 都能访问任意公网地址”。

建议：

每个可用区部署 NAT Gateway
路由表按子网绑定，避免跨可用区走 NAT
使用 VPC Endpoint 访问 AWS 服务，减少 NAT 成本和公网暴露
对访问 S3、ECR、CloudWatch、STS 等服务优先使用 VPC Endpoint
对外部第三方 API 做出口域名、IP 或代理层治理

常见 VPC Endpoint：

S3 Gateway Endpoint
ECR API Endpoint
ECR DKR Endpoint
CloudWatch Logs Endpoint
STS Endpoint
Secrets Manager Endpoint

这样可以让节点和 Pod 拉镜像、写日志、取密钥时尽量走 AWS 内网路径。

权限设计：IAM 和 Kubernetes RBAC 要分清¶

EKS 权限有两套体系：

AWS IAM:
  管 AWS 资源权限，例如 EC2、ELB、ECR、S3、CloudWatch

Kubernetes RBAC:
  管 Kubernetes 集群内权限，例如 Pod、Service、Secret、Deployment

不要混淆这两层。

例如：

用户能不能 kubectl get pod，主要由 EKS 访问入口和 Kubernetes RBAC 决定
Pod 能不能访问 S3，主要由 Pod 绑定的 IAM 权限决定
AWS Load Balancer Controller 能不能创建 ALB，取决于它的 IAM Role 权限

人员访问权限¶

生产建议：

不使用长期 Access Key 作为日常运维入口
使用 IAM Identity Center 或 SSO 管理人员登录
通过 EKS access entry 或 aws-auth 映射到 Kubernetes RBAC
管理员、只读、发布、审计角色分开
不给普通用户 cluster-admin

典型角色可以这样分：

角色	Kubernetes 权限	用途
platform-admin	cluster-admin	平台管理员，人数严格控制
app-developer	指定 namespace 的编辑权限	业务发布和排障
readonly	只读权限	审计、排查、观察
ci-deployer	指定 namespace 的发布权限	CI/CD 系统使用

Pod 访问 AWS 资源¶

业务 Pod 不应该共用节点 IAM Role 的权限。更好的方式是给每类工作负载单独绑定最小权限。

EKS 里常见方案：

EKS Pod Identity
IAM Roles for Service Accounts，也就是 IRSA

设计目标是：

某个 ServiceAccount
  -> 绑定一个最小权限 IAM Role
  -> 只有使用该 ServiceAccount 的 Pod 能访问指定 AWS 资源

比如某个应用只需要读一个 S3 bucket，就不要给它 s3:*，更不要让它继承节点角色的宽权限。

安全管理：从默认可用到最小暴露¶

EKS 安全治理可以按四层看：

云账号安全
  -> 网络边界安全
  -> 集群访问安全
  -> 工作负载运行安全

云账号安全¶

建议：

root 用户只用于账号初始化和紧急操作
root 用户开启 MFA
日常操作全部走 IAM 用户、角色或 SSO
禁止共享 Access Key
CI/CD 使用 OIDC 或临时凭证
开启 CloudTrail 记录 API 操作

网络边界安全¶

建议：

节点放 Private Subnet
安全组按用途拆分，不使用大范围入站规则
API Server public endpoint 限制来源 CIDR
管理入口通过 VPN、堡垒机或 SSM Session Manager
公网入口只开放必要端口
内部服务使用 internal LB

集群访问安全¶

建议：

开启控制面日志，至少包括 api、audit、authenticator
对 namespace 做权限边界
默认不把 Secret 明文写入 Git 仓库
使用 External Secrets 或 Secrets Manager 管理敏感配置
定期审计 ClusterRoleBinding，尤其是 cluster-admin

工作负载安全¶

建议：

镜像来自可信 ECR 仓库
镜像构建阶段做漏洞扫描
Pod 不使用特权容器，除非有明确必要
限制容器以 root 用户运行
给容器配置 requests/limits
对 namespace 使用 ResourceQuota 和 LimitRange
使用 NetworkPolicy 做东西向访问控制

EKS 默认 VPC CNI 不直接提供 NetworkPolicy enforcement。需要网络策略时，要确认所用 CNI 或附加组件是否支持并实际启用。

节点组管理¶

EKS 节点建议优先使用 Managed Node Group。它能简化节点生命周期管理，包括创建、扩缩容、滚动升级和与 Auto Scaling Group 集成。

节点组设计建议：

系统组件和业务组件可以拆不同节点组
对 GPU、高内存、Spot 实例等场景使用独立节点组
节点组按可用区和实例类型做好容量规划
使用 taint/toleration 控制特殊节点用途
使用 labels 让工作负载按节点类型调度

一个常见设计：

system-node-group:
  - CoreDNS
  - ingress controller
  - observability agent

app-node-group:
  - 普通业务服务

spot-node-group:
  - 可中断任务
  - 异步计算
  - 非核心服务

Spot 节点可以降低成本，但不适合承载关键单副本服务。使用 Spot 时要配合多副本、PDB、自动扩缩容和中断处理。

EKS Add-ons 管理¶

EKS 常见核心插件包括：

Amazon VPC CNI
CoreDNS
kube-proxy
Amazon EBS CSI Driver

建议使用 EKS managed add-ons 管理核心组件版本。这样可以减少手工升级 YAML 带来的漂移。

升级时要注意：

插件版本要和 Kubernetes 版本兼容
先在测试集群验证
升级 VPC CNI 前确认自定义配置
升级 CoreDNS 前确认副本数和资源限制
升级 kube-proxy 前确认集群网络模式

可观测性和审计¶

EKS 的可观测性至少要覆盖：

控制面日志
节点系统日志
Pod 日志
应用指标
Kubernetes 事件
AWS API 审计
网络入口和出口日志

常见组合：

CloudTrail:
  AWS API 审计

CloudWatch Logs:
  控制面日志、应用日志

Container Insights / Prometheus:
  集群指标、Pod 指标

ALB/NLB Access Log:
  入口访问日志

VPC Flow Logs:
  网络流量审计

排障时，建议按路径查：

DNS
  -> ALB/NLB
  -> Ingress
  -> Service
  -> EndpointSlice
  -> Pod
  -> AWS 依赖服务

这和普通 Kubernetes 排障一样，只是 AWS 侧还要多看 Load Balancer、Target Group、安全组、路由表和 IAM。

成本治理¶

EKS 成本不只是控制面费用。真正容易增长的是：

EC2 节点
NAT Gateway
ALB/NLB
EBS 卷
CloudWatch Logs
跨可用区流量
公网出口流量

建议：

对 namespace、团队、应用打标签
节点组按业务类型拆分，方便成本归属
日志设置合理保留周期
大流量 AWS 服务访问优先走 VPC Endpoint
对非生产环境设置定时缩容
对可中断任务使用 Spot
定期清理未使用的 LoadBalancer、EBS、EIP、快照

一套推荐的生产基线¶

如果让我从零设计一个中小规模生产 EKS，我会先用这套基线：

一个独立生产 VPC，CIDR 至少 /16
三个可用区
每个可用区一个 Public Subnet 和一个 Private Subnet
节点全部放 Private Subnet
每个可用区一个 NAT Gateway
公网入口使用 ALB，证书用 ACM
内部服务使用 internal ALB/NLB
API Server 开启 private endpoint，public endpoint 限制来源 CIDR
节点使用 Managed Node Group
核心插件使用 EKS managed add-ons
Pod 访问 AWS 资源使用 EKS Pod Identity 或 IRSA
人员访问使用 SSO + RBAC
开启 CloudTrail 和 EKS control plane audit log
业务 namespace 配 ResourceQuota、LimitRange、RBAC
关键服务多副本并跨可用区分布
基础设施用 Terraform/CDK 管理，应用用 Helm/GitOps 管理

这套不是唯一答案，但它能避免大多数“刚开始能用，后面难治理”的问题。

面试或方案汇报时怎么表达¶

如果面试官问“你怎么做 EKS 资源管理”，不要只回答“我会创建 EKS 集群”。可以按这条线说：

我会先做 VPC 和子网规划，把公网入口、私有节点、NAT 出口和 VPC Endpoint 分清楚。然后用 Terraform 或 eksctl 创建 EKS 控制面和 Managed Node Group，核心插件使用 EKS managed add-ons 管理。权限上把 AWS IAM 和 Kubernetes RBAC 分开，人员访问走 SSO/RBAC，Pod 访问 AWS 资源用 Pod Identity 或 IRSA。安全上节点放私有子网，API Server 收敛访问来源，公网入口只通过 ALB/NLB 暴露，并开启 CloudTrail、控制面审计日志和监控告警。这样 EKS 不只是能创建出来，而是能持续扩容、升级、排障和治理。

这个回答的重点是你能把 EKS 当成一套云上平台，而不是一个单独的 Kubernetes 集群。