政策快报平台上线第一年所有服务部署在物理机上。一台机器跑数据库一台跑应用一台跑爬虫。部署靠手动操作发布靠复制文件。那时候发布一次需要30分钟登录服务器、停服务、备份、上传新包、启动、验证。如果出了问题回滚更麻烦。后来我们逐步做了容器化改造从物理机到Docker从Docker到Kubernetes。每次升级都解决了当时最痛的运维问题也引入了新的复杂度。今天复盘这个过程。正文3个阶段的演进阶段一物理机时代第一年部署方式物理机手工部署SSH登录服务器手动停服、上传jar包、重启。数据库单独一台机器应用单独一台爬虫单独一台。主要问题发布慢手工操作每次发布需要30分钟以上回滚难出问题了要找回旧包重新上传、重启来回至少折腾一小时环境不一致开发、测试、生产环境配置不同经常出现“本地跑得好好的上线就挂了”资源利用率低每台机器只能跑一个服务即使CPU闲置也无法复用阶段二Docker时代第二年部署方式应用打包成Docker镜像通过Docker Compose管理多容器编排。镜像推送到私有仓库部署时拉取镜像、启动容器。解决了环境一致性问题镜像即环境开发测试生产跑同一个镜像部署速度提升从30分钟降到5分钟左右资源隔离容器之间互相隔离不会因为一个服务的故障影响其他服务新问题容器编排能力有限Docker Compose适合单机多机部署需要额外工具服务发现和负载均衡需要手动配置容器数量多了之后手动管理变得困难阶段三Kubernetes时代现在部署方式所有服务容器化后迁移到Kubernetes集群3个Master节点5个Worker节点通过YAML定义服务部署使用Helm管理应用版本。GitLab CI自动构建镜像并推送到Harbor仓库ArgoCD自动同步到K8s集群。解决了自动伸缩根据CPU/内存使用率自动扩容Pod副本数流量高峰自动增加实例低谷自动缩容自动恢复Pod异常自动重启、节点故障自动迁移滚动更新发布过程零停机新版本逐步替换旧版本发现问题随时暂停资源优化多服务共享集群资源利用率显著提升关键技术决策与踩坑决策一自建K8s还是用云厂商托管我们选择了云厂商托管K8sACK/TKE因为不需要自己维护Master节点节省运维人力云厂商提供了与SLB、存储、日志的深度集成扩容节点方便点击即可增加Worker节点。踩坑一资源配置不合理初期Pod的CPU/内存request和limit设置不合理。有的服务设得太低流量高峰时OOM有的设得太高资源浪费。经验先观察一周的监控数据根据实际使用量调整request/limit定期review资源使用情况持续优化。踩坑二日志收集混乱容器化之后日志不再写入本地文件而是输出到stdout。如果不用统一收集日志会分散在各个Pod里。经验使用ELK/EFK统一收集容器日志。每个Pod自动将stdout日志发送到ES通过Kibana统一查询问题排查更加高效。踩坑三配置管理复杂不同环境dev/test/prod的配置不同。如果把配置写在镜像里每次环境变更都要重新构建镜像。经验使用ConfigMap管理配置不同环境使用不同的ConfigMap镜像与配置分离。效果数据指标物理机时代容器化K8s后发布耗时30分钟2-3分钟滚动更新回滚耗时30分钟1分钟kubectl rollout undo资源利用率~30%~65%故障恢复手工处理30分钟自动重启2-3分钟扩缩容手工需要加机器自动秒级生效结尾容器化改造不是“为了用新技术而用新技术”是每一步都为了解决当时最痛的问题。物理机时代最痛的是“发布慢、回滚难”Docker解决了环境一致性和部署速度K8s解决了自动化和弹性。每一步都踩过坑但每一步都在解决问题。如果回到起点还是会走同样的路。
