3. EKS控制面深入

EKS 的控制面是 AWS 托管的 Kubernetes 控制面，它由 API Server、etcd、Controller Manager、Scheduler 等组件构成，但用户不直接接触底层节点，而是通过 AWS 提供的抽象接口来使用。理解控制面的架构与访问模式，是设计安全、稳定、可观测集群的前提。

控制面架构与托管边界

在 EKS 中，控制面运行在 AWS 账户之外的托管环境中，跨多个可用区部署。每个 EKS 集群在创建时，AWS 会在所选子网中放置弹性网络接口（ENI），这些 ENI 是控制面与集群 VPC 之间的连接点。控制面组件本身对用户不可见，用户能操作的是：API Server 端点、认证与授权配置、日志导出、版本升级以及附加组件。控制面的 etcd 由 AWS 管理，默认跨三个可用区复制，用户无需关心备份与恢复，但需要理解其高可用边界——控制面高可用由 AWS 保证，而数据面（节点与工作负载）的高可用需要用户自行设计。

API Server 端点访问模式

EKS 集群创建时，API Server 端点有三种访问模式：公有、私有、公有+私有。公有端点意味着 API Server 有一个可解析的公网地址，任何能访问互联网的客户端都可以尝试连接，但实际能否通过取决于认证与授权。私有端点则只在 VPC 内可访问，适合对安全要求高的场景。混合模式同时提供公网和私有访问，并可通过 CIDR 白名单限制公网来源。

选择访问模式时，需要权衡运维便利性与安全性。如果使用公有端点，建议同时配置 publicAccessCidrs 限制来源 IP，例如只允许公司出口 IP 或跳板机网段。如果使用私有端点，需要确保 kubectl 客户端位于 VPC 内，或通过 VPN、Direct Connect、Transit Gateway 接入。对于 CI/CD 流水线，如果运行在 VPC 外，则需要公有端点或通过代理访问。实际配置示例如下：

aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config \
    endpointPublicAccess=true,\
    endpointPrivateAccess=true,\
    publicAccessCidrs=203.0.113.0/24,198.51.100.10/32

执行后，可通过 aws eks describe-cluster 查看 endpoint 和 endpointPublicAccess、endpointPrivateAccess 字段确认状态。注意，修改端点访问模式不会导致控制面重启，但可能短暂影响新连接的建立。

控制面日志类型与采集

EKS 控制面支持五种日志类型：api、audit、authenticator、controllerManager、scheduler。其中 api 记录 API Server 的请求处理，audit 记录谁在何时对什么资源执行了什么操作，authenticator 记录认证过程，controllerManager 和 scheduler 分别记录控制器与调度器的决策过程。这些日志默认关闭，需要显式启用并指定 CloudWatch Logs 日志组。

启用日志时，建议至少开启 audit 和 authenticator，前者用于安全审计与合规，后者用于排查认证失败。如果正在调试调度问题，可临时开启 scheduler；如果控制器行为异常，可开启 controllerManager。日志会发送到 CloudWatch Logs，日志组名称格式为 /aws/eks/<cluster-name>/cluster。启用命令如下：

aws eks update-cluster-config \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator"],"enabled":true}]}'

日志采集后，可通过 CloudWatch Logs Insights 查询，例如查找特定用户的审计事件：

fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter user.username = "alice"
| sort @timestamp desc
| limit 20

需要注意，控制面日志量可能很大，尤其是 api 和 audit，长期开启会产生可观的 CloudWatch 存储费用。建议设置日志组保留策略，例如保留 30 天，并将重要审计日志导出到 S3 做长期归档。

版本升级策略

EKS 控制面版本升级由 AWS 管理，但用户需要主动触发。升级遵循 Kubernetes 社区版本节奏，通常每个版本支持约 14 个月。升级前需要确认：当前版本与目标版本之间没有跨多个次版本（EKS 不支持跳版本升级），节点组与附加组件兼容目标版本，以及工作负载使用的 API 没有在目标版本中废弃。

升级控制面时，AWS 会滚动更新 API Server 和 etcd，期间 API Server 可能短暂不可用，但通常控制在几分钟内。升级命令为：

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.29

升级后，需要依次升级节点组和附加组件。节点组升级可通过更新 AMI 版本或使用托管节点组的 update-nodegroup-version 实现。附加组件如 VPC CNI、CoreDNS、kube-proxy 需要与集群版本匹配，可通过 aws eks describe-addon-versions 查看兼容版本。建议在非生产环境先验证升级流程，并确保有回滚方案——控制面版本无法回滚，因此升级前必须做好充分测试。

控制面高可用与故障域设计

EKS 控制面本身跨三个可用区部署，具备高可用能力。但用户仍需关注故障域设计：节点组应跨多个可用区分布，避免单可用区故障导致工作负载不可用；API Server 端点如果使用公有访问，应确保客户端不依赖单一 NAT 网关或互联网出口；如果使用私有访问，应确保 VPC 内至少有多个子网可用于 ENI 放置。

对于关键业务，建议采用以下设计：节点组跨至少三个可用区，使用托管节点组并配置 desiredSize 与 minSize 保证容量；API Server 端点使用私有访问，并通过 Transit Gateway 或 VPN 连接多个 VPC；控制面日志全部开启并集中采集；版本升级遵循先测试后生产、先控制面后数据面的顺序。此外，可结合 AWS 的 eksctl 或 Terraform 将集群配置代码化，确保故障域设计可重复、可审计。