K8s生产文档中哪些坑没告诉你？

用 K8s 好几年了从Zui开始的”照着文档搭集群”，到现在管理几十个节点的生产集群，踩过的坑Yi经够写一本书了。

官方文档当然hen重要，但文档告诉你的是”怎么用”，不会告诉你 "用了之后会出什么问题"。hen多坑，只有你真正在生产上跑过、出过事之后才知道。

这篇文章整理了我在生产环境遇到过的一些坑，每一个dou是真金白银的教训。有些坑让我半夜爬起来处理，有些坑让我在复盘会上被问得哑口无言。

希望你kan完之后Neng少走一些我走过的弯路。

某天上午9点，开发同学跑来说：”K8s 集群不Neng创建新 Pod 了。”

$ kubectl run test --image=nginx Error from server : error when creating "test": pods "test" is forbidden: etcdserver: request timed out

不只是创建 Pod，kubectl get nodes dou开始超时了。赶紧 ssh 到 master 节点：

$ journalctl -u etcd --no-pager -n etcdserver: mvcc: database space exceeded

etcd 磁盘空间超限了。

etcd 有一个默认的存储配额，当数据量超过配额时etcd 会变成只读模式，拒绝所有写操作。而 K8s 的几乎所有操作dou依赖 etcd 写入，所以整个集群就”瘫痪”了。

查了一下罪魁祸首是 事件记录。

K8s 会为每个 Pod 的每次事件创建一个 Event 对象，存在 etcd 里。我们有个服务因为配置问题一直在 CrashLoopBackOff，每次重启dou会产生一条 Event。跑了三天产生了30多万条 Event，把 etcd 撑爆了。

紧急止血

$ etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ put quota/bytes -- '8589934592'

扩容后 etcd 恢复写入，集群恢复正常。

上线了一个新服务，调用方反馈”第一次请求特别慢，要5-10秒，之后就正常了”。

第一反应是”连接池冷启动”，但查了应用日志，连接池是预热过的。用 dig 在 Pod 里测试 DNS 解析：

$ kubectl exec -it dev-app-pod -- dig dev-service.default.svc.cluster.local ;; Query time: 12 msec

12ms，kan起来正常。但测试一个不存在的域名：

$ kubectl exec -it dev-app-pod -- dig dev-service.default.svc.cluster.local.xxx ;; Query time: 5000 msec

5秒！ 这就是第一次请求慢的原因。

我们有个服务连接第三方 API，用的密钥存在 K8s Secret 里。密钥到期了运维同学geng新了 Secret：

$ kubectl create secret generic api-secret \ --from-literal=api-key=new-key-123 \ --dry-run=client -o yaml | kubectl apply -f -

geng新完之后通知开发同学”密钥Yigeng新”。开发同学说”好的”，然后继续用。过了半小时第三方 API 那边反馈我们的请求还是用的旧密钥。

HPA 正常触发了扩容，但业务同学说”还是扛不住响应时间还是hen长”。我上去一kan，新 Pod 调度不上去。等于 HPA Zuo了无用功。

有次要升级一批节点的内核版本，需要先把节点上的 Pod 驱逐走。我用了 kubectl drain：然后对 worker-2 执行了同样的操作。然后对 worker-3，然后监控告警炸了：多个服务不可用。

K8s 的滚动geng新kan起来hen美好，但实际操作中还是有hen多需要注意的地方。比如 readinessProbe 的配置、preStop钩子的使用等。Ru果配置不当，hen容易导致服务中断或者请求失败。

Ru果你的团队也在用 K8s，希望这篇文章Neng帮你们少踩一些坑。同时也欢迎在评论区分享你们遇到的 K8s 相关问题和解决方案，让大家一起学习进步。