什么是云原生：采用K8S+Docker进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
云原生，缘起
2020年年初，因为疫情很多人被封在家里。日子比较无聊，只能上网娱乐，和小伙伴聊聊天。
4年前的我对技术仍然有热爱有憧憬有动力，当时一个小伙伴跟我介绍他在学习 docker 和 k8s，我心动了。
随后就是漫长的学习过程（请原谅我的愚笨吧）。
作为一个从IBM小型机时代走过来的老人，彼时我的认知仍然停留在集中式架构，但在日常的运维工作中已经感受到了新时代的冲击。
那时我所在的运维小组负责了一个叫数字营销平台的系统，微服务架构，当时整个公司这种架构的系统都很少。
之前的系统投产时一般会申请几台虚拟机，应用部署一套 was 集群，dmgr 控制台集中管理。但这个系统弄了几十台虚拟机，每台虚拟机上部署了好几个服务。应用投产时步骤也整得比较复杂，一堆jar包替换、启停服务的操作。
后来，在运维过程中就发现有麻烦了。有时，业务上有点异常，不知道几十个服务哪个服务出了问题，排查起来就比较吃力。每次操作，还得对照一张资源清单，看登录哪个 IP 地址，用哪个用户去操作，执行哪个脚本去重启服务。
有些烦人。
接触到docker 和 k8s 之后，我觉得这应该是一个比较好的解决手段。同时，我了解到很多同业正在做或者已经做了好几年，而且这个技术也在火热发展当中，我就放心了。
这波入股应该不亏。
学习的过程很痛苦，docker 部分相对来说还算是比较好理解，做实验也容易。但到了 k8s 那块，出现了无数新名词：Etcd、Kubelet、Api Server、Pod、NodePort、Deployment、StatefulSet、pvc、configmap、calico 等等等等，太多了。
我晕头转向，脑子成了浆糊。
我好像在学习游泳，在泳池里努力扑腾却怎么也换不到气，挫败感很强烈。
反复阅读之后，突然有一天，这些名词仿佛渐渐融入了记忆，晦涩的技术描述不再像天堑一样横在前方的路上，慢慢地我迈过去了。那一刻，我觉得我理解了，它的运行机制、它的各个组成、它的过去现在和未来（不一定真的懂），一个新的世界在我眼前被揭开了面纱。
但，这只是认识它的第一步。
知易行难。
只有真正落地的技术才有价值。
千里之行始于足下
按照我司正常做项目的步骤，在官网挂了交流公告。
通过交流，了解了各个公司的产品，并做了一些测试之后，我发现这些产品虽然界面风格不太一样，但基本的操作流程大同小异，似乎用哪家的产品都能满足使用上的基本需求，只有在一些高阶的功能上可能有一些差别。
一个想法，不知道对不对：
基于成熟开源技术的产品使用方不担心绑定，但对于供应商，却很难构建技术上的护城河。
当时测了有六七家公司，在测试的过程中学习到了很多实践上的知识，了解了技术上的工程实现，对云原生架构有了更直观的认知。
在那段时间，我继续学习 kubernetes 网络、kubernetes 权威指南以及其它一些资料（现在都忘得差不多了），包括和几家公司进行了更深入的交流。总之，心里是越来越有底了。
2020 年 12 月，我通过了 CKA 的认证。
当时整个公司对容器、k8s、云原生了解甚至听过这几个词的人都很少，当我提出要立项做这个云原生平台的时候，不少人不理解，甚至可能会觉得我有点吃饱了撑的。
昨夜西风凋碧树，独上高楼，望尽天涯路。
对我个人而言，这个也是从业生涯负责过的项目中技术最复杂的，而且需要沟通研发、质量、主机、网络、存储等多个条线，有不小的挑战。
纸上得来终觉浅，绝知此事要躬行
好事多磨。
经历了商务流程调整、疫情反复、服务器延迟到货等等，本来 2021 年的容器云平台项目拖到了 2022 年年中才招完标，等项目组进场已经是 2022 年 10 月了。项目需求我写的比较贪心，DevOps 流水线、微服务治理、中间件即服务、可观测、容器安全全都包含进去了。
麻雀虽小五脏俱全。
选择什么系统试点是个难题，小的系统体现不出来价值，大的系统不一定放心用新技术新平台，这里要感谢领导和同事们对我的信任和支持，决定让两个比较重要的新建系统试水上云。
即使我自诩对容器云技术算是研究的比较多了，但在实际做的时候，还是遇到了很多困难，举几个栗子：
1、平台自带的流水线工具不符合我司版本管理人员的使用习惯和管理方式，如何将容器化应用发版整合到现有体系和工具里面，就这个事讨论了好几轮，反复了好几次，最终还是使用现有的 svn+jekins，在最后一步进行容器镜像构建，推送到镜像仓库；
2、项目组比较习惯传统的虚拟机使用方式，对于容器化的使用完全不了解，需要反复的培训和讲解；
3、容器网络架构相比传统环境更复杂，开发人员不太清楚如何进行配置能让请求成功地转发过来。
不过，在大家的齐心协力下，问题都一一解决。
2023年5月，平台先一步投产。集群的管理节点使用了虚拟机（避免资源浪费），工作节点使用了物理机（追求极致性能）。
2023 年 6 月，第一个项目顺利投产，9 月，第二个项目成功投产，10 月，之前说的数字营销平台也成功迁移上云。
投产之后我非常紧张，如果平台出问题了，那我肯定会身败名裂，然后夹起尾巴低调做人，再也不提搞什么新玩意。
事实上当时我就是这么想的。
运行了几个月之后，这个平台收到了一些这样的好评：
1、发布过程变简单了，而且稳定不会出错；
2、测试资源提供的非常快捷和方便；
3、服务自动重启自动恢复让运维工作轻松了。
上图是项目验收汇报时总结的收益。
这让我们更坚定了推广的信心。
后来，我们在内网建立了一个容器云文档站，把相关的规范、要求、操作指南等等都放了上去，在工作过程中不断完善。新项目组进场后可以在文档站上随时查阅这些资料。
长风破浪会有时
容器云作为一个功能复杂的 PaaS 层平台，作为一个和应用系统有一定耦合度的平台，作为一个提供了不少原先需要单独部署的组件能力的平台，怎么保证它安全稳定地运行？
虽然它是分布式架构，节点宕机不影响业务，但没经历过生产考验（在咱们这儿），说不准会踩到什么坑呢。
好在公司产品比较靠谱，驻场小伙伴也很认真负责，保持着一周一次生产环境的巡检频次，告警信息处理得都比较及时，产品功能也在不断优化升级。
我们一步步很谨慎，但在不断向前进。
到 2024 年年底，总算有 9 套业务系统成功运行在了容器云平台上，还有一些项目已经在开发测试环境接入了，明年会投产运行。
随着微服务架构逐渐成为应用系统的标配，云原生的概念越来越被大家熟知和接受，明年将会有更多系统选择容器化上云（在我们的忽悠下）。
云原生之路仍在继续。
加油吧，少年（已经不是了）！
