这几年一直在云原生 K8S 领域做些研发、设计、运维的工作，说些对云原生的一点总结和思考，抛砖引玉

1、 以 K8S 为底座的云原生将会成为 PaaS 的唯一标准平台，更贴近用户的商用特性决定平台的竞争力

前几年移动互联网的发展，以微服务架构为主的软件和运维体系发生了较大的变化，业内唯一能支撑微服务架构的底座只有 K8S，它本质是运维标准化。

K8S 的流行在移动互联网访问量暴涨下，促使互联网应用改造成可弹性的微服务架构，传统单体架构已经无法满足互联网要求的可弹性、应用资源成本、组件可靠性、开发迭代效率的要求了，2015年之前，开始基于虚拟机 VM 的场景打造了一套较完整的变更和运维体系，要解决应用的运维复杂性和自动化问题，追求稳态和敏态，让研发高效、让运维透明，开始强调工具自动化和屏蔽复杂性。从 2015 伊始，K8S 开始兴起，构建相比 VM 为主的下一代以应用为标准的运维体系，把 Docker Swarm 干掉后成为行业内运维的唯一标准，随着 CNCF 开源社区快速发展，在短短5年内，已经孵化了从CICD、监控告警、服务发现治理、负载均衡网关、中间件等微服务全软件和运维生命周期的框架和工具，为基础设施层以上的应用层构建了全面的生态体系，同时各家的商业化版本也持续发展起来，用户的微服务真正能够 Deploy Anywhere，Ops Anywhere。

K8S 除了标准化带来的成功，自身优秀地可扩展性也非常成功，从容器运行时的 CRI 接口、容器网络 CNI 接口、容器存储 CSI 接口、容器网关 Gateway API、V2 调度扩展、控制器 Operator 扩展等，得益于这种开放性，平台商能够根据自身 IaaS 优势构建更强大的计算、存储、网络、调度、控制等关键商用能力，形成平台的差异化竞争，最终在平台的特性、稳定性、可靠性、弹性上构建竞争力。

2、K8S 将成为一个代名词，以”面向终态的声明式 API+场景化控制器”将会改变当前的运维模式

虽然运维一直在强调自动化，但其实这种自动化还只是人使用工具的自动化，仍然需要运维人员的判断和介入，未实现场景的全闭环，比如从定义、发现、修复、恢复未有效串联闭环，还是处于遇到问题解决问题的过程式模式。我认为这个根本原因还是 Ops 和 Devs 中间存在较大 Gap，导致 Devs 并不了解现网运维，只按照 Ops 的要求进行了工具化，而 Ops 又不能把运维经验产品化，缺少全局场景的设计和产品能力和意识。

Google 的 SRE 并没有这个问题，因为 Google SRE 具有很强的研发设计能力，人人能编码，SRE 在运维实践过程中把经验直接代码化，形成了类 K8S 的平台，提出了”面向终态的声明式 API+控制器”模式在重塑运维，API 定义好对现网的期望状态，Controller 根据状态不断进行修正，最终根据场景把运维动作全自动化，无需 Ops 的中途介入，比如 nodeOperator，在节点发生异常的时候，自动迁移应用、留存现场、尝试修复并重置 OS、最后恢复应用，全部运维动作由 Devs 开发的控制器完成。事实上，这种运维思想已经在很多大厂开始实践了，从最开始重构 kube-scheduler 调度器，到现在的 kube-controller 控制器、kubelet 等，核心组件已经根据不同的场景做了重构。

所以 K8S 实现了什么已经不重要了，重要的是开放了这种面向终态的思想，我认为将会改变目前的运维思维和模式。

3、用户趋向多集群和多云的部署方式

首先，随着应用容器化规模扩大，对性能要求越来越高，针对单 K8S 集群内的 kube-api、scheduler、proxy 等组件优化程度有限，侵入性地修改又导致与社区版本冲突。其次对可靠性要求也高，单集群控制面因人为或软件 bug 导致的故障风险没法完全消除。再次，用户不希望被单个云厂商锁定，同时希望在不同区域，线上和线下混合云场景能够平滑迁移和弹性。

因此多集群部署和管理是一个必然的选择。但多集群能力目前还需要做很多工作，社区支持并不友好，比如要解决集群间服务发现、切流、部署、扩容等等问题。社区精力依旧在单 K8S 集群内的功能和稳定性上面，多集群（多云）管理将是一个新的方向。（Google 推出 K8S 时不知道是否有意在打破云厂商锁定）

4、微服务框架是传统应用转型云原生的关键点

云原生虽然是大势所趋，但引导和帮助传统应用云原生化还是有诸多的阻力和困难。最难的是云原生化后的效率和成本收益要得到认可，即 CICD 效率、弹性、故障运维、调度优化等，对于已有成熟的运维体系的平台来讲改造就更困难。随后在改造阶段，这个过程可能是漫长的，需要分步分批过渡，部分应用先容器化，并与虚拟化应用共存，这将带来对 K8S 的改造，比如要求 POD 的原地升级、容器网络与虚拟网络拉平等，这一定程度与 K8S 的期望架构有一定的冲突，但又客观存在必须解决。

微服务框架是一个关键切入点，传统应用可以先利用框架的能力先做微服务化，解决服务之间互访、注册发现等问题，让容器化应用和虚拟化应用平滑互通，然后再逐步过渡到 K8S 上来。因此如果不是全面切入云原生，采用微服务框架是一个关键点。

5、云原生化面向 SaaS 用户，帮助最终用户解决业务痛点

PaaS 平台核心解决的是效率和成本问题，但并不直接解决最终用户的业务痛点，有的用户更专注营收，传统应用在多年运维体系建构后，自身已经基本处于稳态，如果不是成本、稳定性等考虑或技术驱动，可能不太希望做较大的改变，同时又顾虑云原生的成熟度、与现有运维体系的匹配度、稳定性，推动改造起来更加困难。

如果能帮助最终用户解决业务痛点的是 SaaS 应用，那云原生化转向 SaaS 用户是否更好？SaaS 用户希望在多云环境、线上线下多环境进行部署，追求标准化和效率，同时还有弹性和成本的要求，看上去他们有意愿云原生化，如果把 SaaS 厂商定义成苹果应用中的开发，最终用户定义为苹果应用中的消费者，那么 PaaS 平台就是苹果应用开发平台，需要提供整套完整的开发、构建、部署、运维工具和标准了。这会是云原生一个巨大的舞台。