用Kubernetes的时候那些必须注意的坑和重点到底有哪些啊

综合整理了知乎专栏“Kubernetes实践指南”中的常见问题、CNCF社区博客中的用户案例分享、以及《Kubernetes Patterns》一书中强调的重点，旨在用大白话指出实际使用中容易踩坑的地方。）

一个最经典的坑就是资源限制没设置好,很多人觉得把应用塞进Kubernetes就万事大吉了，CPU和内存限制随便写写，或者干脆不写，结果就是，某个应用突然发疯吃掉所有内存，直接把整个节点拖垮，导致节点上所有其他应用一起崩溃，这就像合租房里有个室友不限电用电磁炉，结果跳闸了大家全都摸黑，必须给每个容器都设置合理的requests和limits，而且内存限制尤其重要，因为Linux内核在内存不足时会直接杀掉“超支”的进程，你连反应时间都没有。

健康检查配置不当是导致服务断续续的元凶,Kubernetes靠liveness和readiness探针来判断容器是不是活着、是不是准备好了接收流量，但很多人图省事，要么检查路径不对，要么检查间隔太频繁，一个应用启动慢，要30秒才能准备好，但你设置的liveness探针10秒就检查，一次失败Kubernetes就认为它挂了，立马重启，结果就是容器陷入“启动-被杀-重启”的死循环，永远无法提供服务，这就好比一个人刚起床还没刷牙，你每隔十秒就去摸他鼻子看还有没有气，摸不到就直接认定他死了，这不合理，探针的超时时间、检查间隔和失败阈值一定要根据应用的实际情况仔细调校。

第三,持久化存储的坑又深又隐蔽，用Kubernetes最怕的就是数据丢了啊，如果你用了本地磁盘做存储，当Pod被调度到另一个节点时，数据可就留在旧节点上找不回来了，所以生产环境一定要用网络存储，比如云盘或者Ceph这类分布式存储，即使用了网络存储，也要小心PersistentVolume的回收策略，如果设置成Delete，当你删除PVC时，底层的存储卷也会被一起删掉，数据就彻底没了，如果是重要数据，务必把回收策略设置成Retain，手动处理数据回收。

第四,配置文件管理混乱，很多人把配置信息直接写死在YAML里，或者用环境变量硬编码，一旦配置要改，就得重新打包镜像或者修改一堆YAML文件，非常容易出错，正确的做法是使用ConfigMap和Secret来管理配置和敏感信息，但这里也有坑：如果ConfigMap或Secret更新了，已经运行的Pod是不会自动更新的，除非你用一些第三方工具，或者把ConfigMap挂载为Volume，并让应用支持热重载配置，否则就得重启Pod才能生效，这就好比你在手机上改了Wi-Fi密码，但家里所有连着的设备都得手动重连一遍才行。

第五,网络策略和安全性容易被忽略，默认情况下，Kubernetes集群里所有Pod之间是可以自由通信的，这就像一个大通铺，没有任何隔断，如果有一个应用被黑了，攻击者就能轻易访问集群里的任何其他服务，一定要用NetworkPolicy来设置网络防火墙，实现“最小权限原则”，只允许必要的服务之间互相通信，镜像安全也是大事，随便从网上下个不明不白的Docker镜像就跑，里面带个挖矿病毒或者后门，整个集群就危险了。

第六,日志和监控没跟上，出了问题就是瞎子摸象，在Kubernetes里，容器挂了会被重启，Pod调度也会漂移，传统的登录服务器查日志的方式根本行不通，你必须建立集中式的日志收集系统，把所有容器的日志自动收集到一个地方，监控也一样，不仅要监控节点的CPU、内存，更要监控Pod的状态、副本数、网络流量等，不然服务已经不可用了，你可能还浑然不知，这就好比开着一辆没有仪表盘的车，车坏了你只能靠猜。

第七,升级和回滚策略不完善，直接用kubectl set image升级镜像非常危险，如果新版本有bug，所有Pod会同时被替换，导致服务全面中断，应该使用RollingUpdate策略，逐步用新Pod替换旧的，并且要设置好maxUnavailable和maxSurge参数，控制升级速度，一定要先在小范围测试，并且确保有快速回滚的方案，别等到用户投诉如潮水般涌来，才发现自己没留后路。

也是一个观念上的重点：别把Kubernetes当神奇黑箱，它确实能自动化很多操作，但并不意味着你可以完全撒手不管，底层节点的健康、网络插件的稳定性、存储系统的性能，这些都需要持续关注，就像你开自动挡的车，也得时不时看看油表和水温，不能只管踩油门。