4. Amazon EKS集群搭建与核心对象

Amazon EKS（Elastic Kubernetes Service）是 AWS 提供的托管 Kubernetes 服务。理解它的关键，不是把 Kubernetes 的所有概念重新背一遍，而是先分清“谁负责什么”：控制平面由 AWS 托管，节点与工作负载由你在账号内管理。EKS 的控制平面运行在 AWS 托管的账户中，跨多个可用区部署，API Server、etcd、调度器与控制器管理器由 AWS 负责可用性与补丁；你负责的是节点组、网络、权限、工作负载以及如何把服务暴露出去。这个责任边界决定了后续所有操作的组织方式。

Kubernetes 基础对象在 EKS 中的落点

Kubernetes 的最小调度单位是 Pod，一个 Pod 可包含一个或多个共享网络命名空间与存储卷的容器。Pod 本身是易失的，因此生产上不会直接管理 Pod，而是通过 Deployment 声明期望副本数，由 ReplicaSet 保证实际副本与期望一致。Service 为一组 Pod 提供稳定虚拟 IP 与 DNS 名称，解决 Pod IP 变化的问题。ConfigMap 与 Secret 分别承载非敏感配置和敏感配置，通过环境变量或卷挂载注入容器。Namespace 用于逻辑隔离，EKS 中常见的 default、kube-system 以及按团队或环境划分的命名空间，是权限与资源配额的基本边界。

在 EKS 上，这些对象最终都通过 API Server 写入 etcd。kubectl 只是 API Server 的客户端，它把 YAML 清单提交为对象，控制器再驱动实际状态向期望状态收敛。理解“声明式 + 控制器循环”这一点，比记住每个字段更重要。

EKS 控制平面与节点组

创建 EKS 集群时，控制平面版本（如 1.29）一旦确定，升级需要显式操作。控制平面暴露一个 API Server 端点，kubectl 通过该端点认证并操作集群。节点组是实际运行 Pod 的计算资源，常见有两类：托管节点组（Managed Node Group）由 EKS 负责节点生命周期、AMI 更新与滚动替换；自管理节点组则由你通过 Auto Scaling 组自行维护。节点组底层是 EC2 实例，通过 VPC 网络与控制平面通信，因此集群 VPC、子网、安全组必须提前规划。

节点加入集群依赖 aws-auth ConfigMap（或 EKS 访问条目）把 IAM 角色映射为 Kubernetes 用户或组。若节点无法加入，通常先检查节点 IAM 角色是否包含 AmazonEKSWorkerNodePolicy、AmazonEKS_CNI_Policy 与 AmazonEC2ContainerRegistryReadOnly，以及节点所在子网是否具备到控制平面的网络路径。

kubectl 与 Helm 入门

kubectl 是与 EKS 交互的主工具。集群创建后，用 aws eks update-kubeconfig --name my-eks --region ap-northeast-1 把集群上下文写入本地 kubeconfig，再用 kubectl get nodes 验证节点是否 Ready。常用命令包括 kubectl get pods -n default、kubectl describe pod <name>、kubectl logs <pod> 与 kubectl apply -f deploy.yaml。describe 与 logs 是排障时最先使用的两个命令。

Helm 解决的是“一组相关对象如何作为一个版本化单元发布”的问题。Chart 是模板与默认值的集合，values.yaml 提供可覆盖参数，Release 是一次安装实例。相比逐个 apply YAML，Helm 支持版本回滚、依赖管理与环境差异化。入门时先掌握 helm create、helm install、helm upgrade、helm rollback 与 helm list 即可。

把微服务部署到 EKS 并暴露服务

下面给出一个可直接参考的 Deployment 与 Service 示例，镜像使用示例仓库地址，副本数为 2，容器端口 8080。该示例用于说明字段关系，实际镜像与标签需替换为你的 ECR 地址。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/order-service:v1
        ports:
        - containerPort: 8080
        envFrom:
        - configMapRef:
            name: order-service-config
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  type: ClusterIP
  selector:
    app: order-service
  ports:
  - port: 80
    targetPort: 8080

应用后依次观察：kubectl get deploy order-service 的 READY 是否为 2/2；kubectl get pods -l app=order-service 是否 Running；kubectl get svc order-service 是否获得 ClusterIP；在集群内用 kubectl run curl --rm -it --image=curlimages/curl -- curl http://order-service 验证连通性。若 Pod 处于 ImagePullBackOff，检查 ECR 权限与镜像地址；若 Pending，检查节点资源与子网 IP 余量。

对外暴露时，生产上更推荐 Ingress + AWS Load Balancer Controller，由 ALB 按 Host/Path 转发到 Service，而不是直接给每个服务创建 LoadBalancer 类型 Service，否则会产生大量负载均衡器与费用。若只是临时验证，可把 Service 类型改为 LoadBalancer，等待 EXTERNAL-IP 出现后访问。无论哪种方式，都应确认安全组放行、子网具备公网或 NAT 出口，并用 kubectl get ingress 与 ALB 目标组健康检查结果判断是否真正可用。

核心对象速查

把以上对象串起来看：kubectl 或 Helm 把清单提交给 API Server，控制平面把期望状态写入 etcd，节点上的 kubelet 与 CNI 让 Pod 真正运行，Service 与 Ingress 再把流量引到这些 Pod。掌握这条链路，EKS 的日常操作与排障就有了清晰的落点。