通过CloudFormation修改自管EKS集群节点实例类型对服务与部署的影响

一、最直接的影响 #

• Pod会被驱逐重启：修改实例类型后，CloudFormation会逐步替换旧节点，K8s会把旧节点上的Pod全部驱逐，重新调度到新节点上。这个过程中Pod会先进入Terminating状态，再在新节点启动，短时间内如果服务副本数不够，可能出现请求中断。
• 资源不匹配会导致Pod调度失败：新实例的CPU、内存等资源和旧节点不一样，如果你的Pod配置了资源请求/限制（比如要求3G内存），而新实例的可用内存只有2G，这类Pod会一直卡在Pending状态，没法启动。
• 节点标签/污点不兼容的话Pod跑不起来：新节点会自带实例类型的标签（比如eks.amazonaws.com/instance-type），如果你的Pod是通过标签选择器（nodeSelector）绑定旧实例类型的，就没法调度到新节点。另外如果新节点有旧节点没有的污点，或者Pod没配置对应的容忍度，也会调度失败。

二、容易忽略的间接影响 #

• 服务可用性受副本数影响：如果是单副本的服务，Pod重启期间服务会完全不可用；多副本的话，只要不是同时重启所有Pod，影响会小一些，但如果没配置健康检查，负载均衡可能还会把请求发到正在终止的Pod上，导致部分失败。
• 存储卷可能出问题：如果Pod用了本地存储（比如hostPath），旧节点上的本地数据会直接丢失，新节点上的Pod会从零开始。如果用的是EBS卷，只要新节点和旧节点在同一个可用区，K8s会自动把卷挂载过去，但跨AZ的话就不行，得提前确认子网配置。
• 网络配置要一致：CloudFormation里新节点的子网、安全组必须和旧节点匹配，不然新节点可能连不上集群控制平面，Pod也没法访问内部服务或者外部网络。

三、CloudFormation操作时的关键细节 #

• 控制滚动更新的节奏：默认CloudFormation会滚动替换节点，你可以通过UpdatePolicy配置一次替换多少节点，保留多少可用节点，避免一次性把所有旧节点换掉导致集群资源不够。比如：

  UpdatePolicy:
    RollingUpdate:
      MaxBatchSize: 1  # 一次替换1个节点
      MinInstancesInService: 2  # 至少保留2个可用节点
      PauseTime: PT5M  # 每批替换后暂停5分钟，给Pod启动时间
  

• 提前配置Pod中断预算（PDB）：创建PDB可以限制同时被驱逐的Pod数量，保证服务始终有足够的副本在运行。比如给某个服务设置至少2个可用副本：

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-service-pdb
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: my-service
  

• 先做小范围测试：别直接改生产节点组，可以先创建一个临时的小节点组，用新的实例类型，手动调度几个Pod过去试试，确认资源够、网络通、存储正常，再大规模替换。
• 备份重要数据：对用本地存储的Pod，提前把数据备份到外部存储（比如S3）；有状态应用要确保数据存在EBS或者RDS这类持久化存储里，避免替换节点时丢数据。

四、操作完一定要做这些验证 #

• 用kubectl get nodes看新节点是不是都处于Ready状态，旧节点已经被移除。
• 用kubectl get pods --all-namespaces检查所有Pod是不是都在Running状态，有没有Pending或者崩溃重启的。
• 手动访问服务的地址，测试功能是否正常，有没有请求失败的情况。
• 用kubectl top nodes和kubectl top pods看新节点的资源使用率，是不是符合预期（比如内存够不够用）。

内容的提问来源于stack exchange，提问作者Tapan Patel