Kubernetes for People Who Have to Run It

Kubernetes 教程教你如何部署一个 pod。没有人教你当一个节点在凌晨 3 点悄悄从 Ready 状态掉线时该怎么办，你的值班电话也停不下来。这讲的是第二部分。

资源请求和限制不是可选的

如果跳过容器的 resources.requests 和 resources.limits，调度器只能猜测，而 kubelet 在节点内存不足时不知道该先驱逐什么。将请求设置为容器在正常负载下实际使用的值，而不是你希望它使用的值。内存限制应该设置得接近请求值，因为被 OOM 杀死的 pod 会重启得很干净，但 CPU 限制通常应该宽松或不设，除非你在处理嘈杂邻居的问题，因为在硬限制下的 CPU 节流会导致延迟峰值，这种问题很难调试。定期运行 kubectl top pods -n your-namespace 并与你声明的值进行比较。在拥有超过少数几个服务的集群中，不匹配会迅速堆积。

etcd 是整个集群，要这样对待它

Kubernetes 知道的一切都保存在 etcd 中。丢失它你就丢失了集群状态，不仅仅是某些元数据。在计划中运行 etcdctl snapshot save /backup/etcd-snapshot.db，并至少在一次在临时集群上实际测试恢复。我见过有夜间备份的团队，结果三个月来备份一直是损坏的，因为没人验证过。如果你使用的是托管控制平面（EKS、GKE、AKS），你不用直接管理 etcd，但你应该在需要之前而不是在事故期间了解供应商的备份和恢复方案。

存活性和就绪性探针有时需要不同

常见的错误是对存活性和就绪性探针使用相同的端点。存活性应该答复