用Kubernetes跑生产那些坑和经验，真心话分享给你们看看

最开始的坑：把Kubernetes当虚拟机用

这是新手最容易栽跟头的地方，也是代价最大的坑，我们一开始也是这样，觉得把应用打個Docker镜像，然后像在虚拟机上一样，用latest标签，直接kubectl run一下就完事了,结果呢？

• 坑1：配置信息硬编码在镜像里。 比如数据库的连接地址、密码，直接写死在应用的配置文件里，然后打包进镜像，结果换一个环境（比如从测试换到生产），就要重新打一个镜像，非常蠢而且不安全，后来才知道要用ConfigMap和Secret，把配置和镜像分离开,这才是云原生的做法。
• 坑2：应用不会优雅退出。 这在虚拟机时代问题不大，进程杀了就杀了，但在K8s里，Pod（就是你的应用实例）是会频繁被调度的，比如滚动更新、节点故障，如果你的应用收到终止信号（SIGTERM）后，不等待正在处理的请求完成就立刻退出，用户就会遇到请求失败，我们当时就因为这个，每次更新版本都有少量报错，解决办法是让应用监听SIGTERM信号，做好清理工作，并且给容器设置合理的preStop Hook，比如先睡眠30秒,让负载均衡器把流量切走。
• 坑3：日志还写在容器本地。 容器一删，日志全没了，出了问题想查日志？对不起，没了，必须从一开始就用DaemonSet部署像Fluentd这样的日志采集工具，把日志收集到Elasticsearch或者Loki这样的中心化日志系统里,这也是一个深刻的教训。

资源管理的坑：你以为的“没问题”和实际的“撑爆了”

Kubernetes调度Pod是需要依据你的资源请求（requests）和限制（limits）的，你不说，它就瞎猜，或者干脆让你和别的应用抢资源,最后同归于尽。

• 坑4：不设置资源限制，导致“邻居”吵架。 我们有个测试环境，一开始大家都很客气，没设资源限制，结果有一天，某个开发同事跑了个超级耗内存的测试Job，直接把整个节点内存吃光了，后果就是，这个节点上所有其他的Pod，因为“内存不足”（OOM），被系统无情杀死了，这就是典型的“一颗老鼠屎坏了一锅粥”。给每个Pod都设置合理的内存和CPU的requests和limits，是保证集群稳定的生命线，这点是《Kubernetes硬核实战》那本书里强调过的,我们深以为然。
• 坑5：资源限制设得不合理，导致应用“饿死”。 吃了上面的亏，我们开始狂设限制，但又矫枉过正，给一个Java应用的内存限制设得太小，Java虚拟机（JVM）本身就需要占用一部分内存，你给的应用堆内存（Heap）太小，它动不动就内存溢出（OOM）了，更坑的是，有时候应用实际需要的内存超过了limits，K8s会直接杀掉这个Pod，而不是像在虚拟机上那样让它变慢，设置限制前，一定要用监控工具（比如Prometheus）好好观察一下应用的真实资源消耗。

网络和存储的坑：看不见摸不着，但能要你命

• 坑6：网络策略没管好，出了安全事件。 默认情况下，K8s集群里Pod之间是可以随意通信的，这太危险了，比如前台的Web应用Pod，理论上不应该能直接访问后端的数据库Pod，我们就遇到过因为某个应用有漏洞，被内部其他Pod攻击的情况，后来赶紧上了NetworkPolicy，根据标签来定义“网络防火墙”，只允许必要的服务间通信，这个坑是听了CNCF社区一个分享后惊出一身冷汗,回来马上补上的。
• 坑7：存储卷用错了类型，数据丢了。 存储是Stateful应用（比如数据库）的命根子，如果你给MySQL的Pod用了默认的存储卷，这个卷通常是和Pod生命周期绑定的，一旦Pod被调度到另一个节点，旧节点上的数据卷就和新Pod没关系了，新Pod会用一个空卷启动，数据全丢！有状态服务一定要用StatefulSet配合支持动态供给的、生命周期独立于Pod的存储类（StorageClass）,比如云厂商提供的云盘。

运维监控的坑：上了K8s不是终点，而是起点

很多人以为应用部署上K8s就高枕无忧了，大错特错,它的复杂性从应用本身转移到了集群管理上。

• 坑8：没有完善的监控和告警，等于盲人摸象。 光看Kubectl get pod是看不出性能瓶颈的，必须部署Prometheus监控集群核心指标（CPU、内存、磁盘压力）、应用业务指标，再用Grafana做成Dashboard，更重要的是，设置合理的告警规则，比如节点NotReady、Pod持续重启失败、CPU阈值过高等等，我们曾经因为没监控节点磁盘使用率，导致节点磁盘被日志写满，整个节点瘫痪,才痛定思痛搞监控。
• 坑9：轻视版本更新和备份。 K8s版本更新比较快，你不更新，以后技术债越堆越高，但更新操作有风险，我们有一次更新时，因为没仔细看官方文档的破坏性变更说明，导致某个自定义资源（CRD）的API版本不兼容，服务中断了半小时。更新前必须在测试环境充分验证，并且要有快速回滚的方案，etcd（K8s的大脑，存储所有数据）的定期备份是重中之重，这个要是丢了,整个集群就废了。

最后的真心话：

Kubernetes非常强大，但它不是一个魔法黑盒，它把很多运维工作标准化、自动化了，但同时也要求你和你的团队具备更高的技术能力和运维意识，它不适合所有场景，如果你的应用很简单，业务量也不大，用它会显得杀鸡用牛刀,反而增加复杂度。

上生产前，一定要先在测试环境充分演练：模拟节点故障、模拟网络中断、做压力测试、练习灾难恢复，别等到真正出问题时才手忙脚乱，这些都是我们和很多同行用真金白银和时间换来的经验,希望对你们有帮助。