折腾Kubernetes这两年，踩过的坑和学到的那些事儿

开始】

折腾Kubernetes这两年,踩过的坑和学到的那些事儿 来源：网络技术社区博客、开发者个人经验分享帖、技术会议演讲实录整理）

说起来开始搞Kubernetes,大概是两年前的事儿了，那时候公司说要上容器化，技术选型就定了K8s，觉得这东西是未来，能自动扩容、管理服务特别牛，结果一脚踏进去，才发现理想很丰满，现实很骨感，坑是一个接一个地踩。

第一个大坑：网络，从入门到放弃再到崩溃

刚开始的时候,觉得把应用打包成Docker镜像就行了，网络嘛，K8s不是自己会管吗？结果部署完第一个服务就傻眼了，Pod之间怎么通信？服务怎么从外面访问进来？那时候真是两眼一抹黑。（来源：某开发者博客《我的K8s踩坑记：网络篇》）我们试过Flannel，也折腾过Calico，光是为了搞清楚什么是Overlay网络、什么是BGP就花了小一个星期，最崩溃的一次是，一个测试服务在本地跑得好好的，一上K8s集群就死活连不上数据库，后来排查了大半天，才发现是网络策略（NetworkPolicy）没配置对，某个命名空间下的Pod被默认规则给隔离了，流量根本进不来，从那以后我才明白，K8s的网络模型是“默认全通”或者“默认不通”取决于你用的网络插件，不把这个底层逻辑搞明白，出了问题连debug的方向都找不到，学到的教训就是：千万别想当然地以为网络是透明的，必须亲手画一画流量走向图，把Service、Ingress、Endpoint这些概念和实际的数据包路径对应起来。

第二个坑：存储，比想象中“有状态”多了

我们一开始做的都是无状态应用,觉得用K8s简直太爽了，Pod死了随便重启，等到要部署一个带数据库的有状态服务时，噩梦就开始了。（来源：某技术分享会实录《StatefulSet实战与陷阱》）Persistent Volume（PV）和Persistent Volume Claim（PVC）的关系，一开始总觉得绕不清，明明在节点上创建了硬盘，为什么Pod就是挂载不上？有一次因为StorageClass的配置参数写错了一个字母，导致动态存储供应一直失败，还以为是云平台的问题，跟客服扯皮了好久，还有一次更坑，一个Pod被调度到了另一个节点，但它的数据卷还挂载在原来的节点上，导致新Pod启动失败，这才彻底搞懂了StatefulSet和Deployment的区别，以及为什么数据库这类有状态应用需要稳定的网络标识和存储绑定，学到的关键是：对于存储，一定要搞清楚持久化数据的生命周期和Pod生命周期是解耦的，数据不会因为Pod被删除而自动消失，管理不好反而会成为“垃圾”。

第三个坑：资源配置，轻则慢如蜗牛，重则集群拖垮

刚开始用K8s,给Pod分配资源（CPU和内存）都是瞎写的，要么给得太小，应用动不动就被OOMKilled（内存不足杀死）；要么给得太大，造成资源浪费。（来源：多位社区网友在论坛的讨论汇总）有一次，我们一个不太重要的日志处理Job，因为内存请求设置得太高，导致一个关键的业务Pod因为节点资源不足而无法被调度，差点引发线上故障，还有一次，没有设置资源限制（Limit），一个应用出现内存泄漏，直接把整个节点的内存吃光，导致节点宕机，kubelet都失联了，上面的所有Pod全部殉难，血的教训让我们学会了使用requests和limits，并且开始用kubectl top命令监控资源使用情况。学到的道理是：资源请求和限制不是可选项，而是必选项，这既是保证应用服务质量的基石，也是维护集群稳定的生命线。

第四个坑：部署与更新，不是点一下鼠标就完事了

以为用kubectl apply -f就能高枕无忧了？太天真了。（来源：某资深SRE的博客《K8s部署策略详解》）我们最早用默认的RollingUpdate，有一次更新一个版本有Bug的服务，结果新Pod起不来，老Pod又被逐个干掉，服务直接不可用了，只能狼狈地回滚，后来才研究了各种部署策略，比如蓝绿部署和金丝雀发布，做金丝雀发布的时候，又发现单纯用Deployment的maxSurge和maxUnavailable控制不够精细，还得结合Service的流量权重控制（比如用Istio等工具）才能做到真正的灰度。这个过程让我学到，部署是一门艺术，在K8s里，你需要明确告诉它你想要的更新过程是怎样的，并且要有完善的监控和快速回滚方案，否则“自动化”反而会放大故障。

除了坑，还学到的一些事儿

1. 日志和监控是救命稻草：（来源：普遍共识）在微服务和动态调度的环境下，没有集中的日志收集（比如ELK/Loki）和强大的监控告警（比如Prometheus+Grafana），出了问题就是瞎子摸象，根本不知道哪个环节出了错。
2. 配置管理要讲究：把所有配置都硬编码在YAML文件里是灾难的开始，学会使用ConfigMap和Secret来管理配置，并且考虑用Helm或Kustomize这样的工具来模板化部署文件，能大大提升管理效率。
3. 安全不是事后才想起来的：从一开始就要考虑镜像安全（扫描漏洞）、Pod安全上下文（避免以root权限运行）、网络策略（最小权限访问）等，否则集群就是个敞开的大门。
4. 社区和文档是最好的老师：遇到问题别硬扛，99%的坑前人都踩过，Kubernetes官方文档、GitHub Issues、Stack Overflow、各大技术博客都是宝藏。

折腾K8s这两年,感觉就像学开车，光看交规（文档）没用，必须实际上路（实践），肯定会熄火（踩坑）、刮蹭（出故障），但每解决一个问题，就对它的理解更深一层，现在回头看，虽然过程曲折，但K8s带来的标准化、自动化和弹性能力，确实是现代应用架构不可或缺的，关键是要保持敬畏之心，边学边做，慢慢地把这个强大的工具真正驾驭起来。