Node Group Sizing 与 Readiness/Liveness Probes 的配置，在教科书里很少被坦诚讨论。作者分享了一个真实案例：大节点 vs 小节点的取舍，以及探针混合配置导致的级联重启。两个看似常规的选择，在故障场景下会暴露出完全不同的失败模式。
1. Node Group Sizing
最初使用 10 个节点，每个 32 CPU，总容量 320 CPU。单个节点失效时，调度器需要重新调度 320 CPU 的工作负载，集群自动缩放器处理不了，Pod 挂起 10 分钟。后来改为 20 个节点，每个 16 CPU，总容量不变。单节点失效时，只需重调度 160 CPU，90 秒内恢复。成本相同，爆炸半径减半。大节点“更高效”，小节点“更具弹性”，取决于你想面对一个大问题还是多个小问题。
2. Readiness vs Liveness Probes
某团队将 Readiness 与 Liveness 设为相同探测逻辑：能连数据库就认为正常。数据库变慢后，探测失败，Pod 被标记为“not ready”并从负载均衡摘除（正确），但 Liveness 也失败导致 Kubernetes 杀死并重启 Pod。新 Pod 启动后立即再次失败，30 个 Pod 每秒重启 30 次，看起来像应用 bug，实际是探针配置错误。修复：Readiness 用短超时检测数据库连接，慢就拒绝流量；Liveness 只检测进程是否响应，更严格阈值，只在真正挂起时重启。同样数据库慢速，Pod 变不健康但不会重启循环，集群稳定。
这两个决策的共同点是：压力下才会浮现的隐藏故障模式。Node 选型在节点失效前看不出问题，探针配置在数据库缓慢前看不出问题。理解实际优化的失效模式，比仅仅遵循“最佳实践”更重要。
#开发者 #工具 #Kubernetes #EKS #DevOps #SRE #NodeSizing #LivenessProbes #ReadinessProbes
📢 频道：@DevToolboxHub