所有EKS工作节点同时删除或宕机时Kubernetes状态是否保留

1. 已部署应用状态丢失风险与重建逻辑 #

• 所有Kubernetes声明式API资源（包括Deployment、StatefulSet、Service等）的定义全量持久化在EKS托管控制面的ETCD中，只要你仅操作替换Worker节点、不删除控制面、不手动调用API删除集群资源，ETCD存储的期望状态就不会发生变化。新Worker节点启动并成功注册到集群后，控制面会自动将待调度的Pod调度到新节点上，不需要手动重新部署应用。
• 无状态应用不存在数据丢失问题，Pod重建后即可恢复服务。
• 有状态应用分两种情况：如果使用EBS、EFS等独立于Worker节点的持久化存储（PV/PVC未随节点删除），Pod重建后会自动重新挂载存储卷，业务数据完整保留；如果使用emptyDir这类节点本地临时存储，存在临时卷里的数据会随老节点删除一同丢失，这类场景需要提前做数据备份。
• 节点空窗期没有可用计算资源时，所有待运行的Pod会处于Pending状态，等节点资源就绪后自动恢复调度。

2. 无可用Worker节点窗口期的Ingress、Secret留存规则 #

• Ingress、Secret都是Kubernetes原生API资源，其元数据、配置规则全量存储在控制面ETCD中，和Worker节点是否存活没有关联，空窗期内这两类资源不会被删除、配置不会发生变更。
• 新节点上线后，对应的控制器Pod、依赖Secret的业务Pod完成重建后，会直接从API Server拉取已存储的Ingress、Secret配置自动恢复服务，不需要手动重新创建资源。

3. sealed-secrets-controller状态与加密有效性 #

• 不需要重新加密任何已有的SealedSecret资源。
• sealed-secrets的解密私钥默认是以Secret资源的形式存储在kube-system命名空间下，这个Secret本身持久化在ETCD中，不会因为Worker节点全量宕机丢失。
• sealed-secrets-controller是Deployment管理的无状态工作负载，新节点上线后会自动完成调度重建，启动时会自动读取ETCD中存储的私钥Secret，即可正常解密所有已存在的SealedSecret资源，原有解密逻辑完全不受影响。
• 唯一会导致解密失败的场景是你手动删除了sealed-secrets生成的私钥Secret，常规的Worker节点替换操作不会触碰这类资源。

4. aws-load-balancer-controller重建后的Ingress管理能力 #

• 原有Ingress资源配置全量存储在ETCD中不会丢失，aws-load-balancer-controller作为Deployment管理的无状态工作负载，在新节点完成重建启动后，会首先全量拉取集群中所有已存在的Ingress、Service资源，和AWS侧已创建的ALB/NLB资源做状态对账，继续接管原有负载均衡资源，不会重复创建LB、不会丢失原有转发规则。
• 如果你的LB使用实例模式挂载目标，控制器会自动将新节点的对应端口注册到目标组，同时剔除老节点的不健康目标，流量会自动恢复；如果使用IP模式，等业务Pod重建完成后会自动更新目标组的IP列表，不需要手动重新apply Ingress配置。

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