不吹不黑，今天我们来聊一聊 Kubernetes 落地的三种方式

出身豪门、大厂背书的 Kubernetes 项目自 2014 年 6 月开源以来，在众多厂商和开源爱好者的共同努力下迅速崛起，时至今日已成长为容器管理领域的事实标准。凭借超前的设计理念、开放的参与门槛、国内外大厂和开发者的大力支持，它的成功不言而喻。

国内外对 Kubernetes 这波潮流的追捧，包括各大云厂商，蚂蚁金服、京东、美团、滴滴等各大公司都把 Kubernetes 作为自己的基础设施重心，"一万个人眼中就有一万个哈姆雷特"，虽说 Kubernetes 是容器管理领域的事实标准，但实际上在不同背景的企业中，Kubernetes 的落地方式上是存在差异的。大致可分为三类：

 

• 一类是完全在 Kubernetes 的之上 (Above) 以其原生方式部署和应用，这类用户大部分是一些初创企业，没有过多的技术栈负担，并且主要集中在使用公有云的 Kubernetes 方案和服务；
• 一类是基于 Kubernetes (On) 构建的容器管理平台，复用了 Kubernetes 的一些概念但是并没有把应用的管理交给 Kubernetes 来管理，保持着旧的服务治理方式，这类企业发展时间比较久，技术负担比较重，无法立即切换到云原生的服务治理方式，一时无法抛弃多年的技术积累，这类用户主要集中在一些中型或大型的私有云的 Kubernetes 使用场景；
• 另一类是基于 Kubernetes 的设计理念 (In) 通过自定义应用负载来解决和适应本地化的应用管理需求，将本地化的负载和管理融入到原生的 Kubernetes 架构中，这也是目前应用管理的一个趋势，既能吃到云原生和社区 Kubernetes 的红利，又能更好地将多年的技术积累发展演进，融入其中，这是一种拥抱云原生的一种绝佳道路。

基础"斧"：Above Kubernetes

如果现在让你选择一个容器管理平台，相信应该没人会错过 Kubernetes，尤其对于没有任何技术负担的用户，选择 Kubernetes 无疑是最明智的一个选择。

Above Kubernetes，这种落地方式很好理解，就是你把原生的、标准的、无任何接触和侵入改动的社区版本的 Kubernetes 拿来，直接部署运行起来即可，完全在 Kubernetes 之上构建自己的应用，通过标准的 Kubernetes API 来访问集群。你可以完全跟着社区升级演进你的 Kubernetes，保持与社区同步，完全借助于社区的力量维护你的 Kubernetes。

这种落地方式无疑是最理想的，你不必考虑与社区和业界的主流脱离，同时也降低了管理和运维的成本。

如上图，你可以安装标准的、主流的云原生体系来落地 Kubernetes，可以拥抱社区的一整套完整的架构方案，并且足以满足你的需求。

高阶"斧"：On Kubernetes

能够使用原生的 Kubernetes 集群诚然非常好，但是有些场景并不一定走得通。大家都知道，Kubernetes 的概念和设计其实是很超前的，谷歌的软件开发和应用部署理念虽然好，但业界大部分的企业还是陈旧的技术理念和更复杂的场景，对于一些由技术积淀的企业用户而言，想要一下子抛弃当前的应用管理和部署方式改为原生的 Kubernetes 的应用部署和管理方式，确实有些吃不消。那对于这些用户而言，肯定不能看着别人吃肉自己啃窝窝头。

On Kubernetes 的落地形态其实是一种妥协和中间过程，一方面很难一下子抛弃已有的基础设施，例如服务治理、监控、网络拓扑等等，只能在原生的 Kubernetes 基础上做一些本地化改造使得 Kubernetes 能够满足当前的应用管理方式，例如抛弃 kube-proxy 使用扁平化的内网环境、通过富容器的方式包装一些监控和代理组件等等。

这种落地方式一方面能够做少了改动就吃到这波技术红利，一方面可以探索属于自己的云原生的道路，内部技术栈也可以朝着云原生的方向发展演进，不至于在这波潮流中落后太多，而且可以根据自己的场景做定制化的 Kubernetes 开发，甚至比社区的 Kubernetes 走的更远或者解决一些社区没有解决的问题。

有得必有失，虽然可以借助于 Kubernetes 的设计理念和管理能力，但是同时由于本地化的改造不能完全与社区版本的 Kubernetes 兼容，升级就会比较麻烦，每次升级不得不重新打 patch，还会出现同时维护多个 Kubernetes 版本的窘境，这无疑会给开发和运维带来很多麻烦，所以这也不是一般的小公司能够走得通的道路，需要一定的研发和技术能力。比较典型的是阿里巴巴的 Sigma、美团点评的 HULK 2.0 以及京东的 JDOS 2.0 。

在这种高阶的玩法中，没有标准的套路，只有符合自己的方案。例如美团点评结合自己已有的设施在 Kubernetes 上构建了 HULK2.0 系统，在存储、网络、负载生命周期管理以及应用监控等方面做了本地化改造，但是仍然保持对 Kubernetes API 的完全兼容。你可以根据自有的基础设施，例如存储、监控、链路追踪、服务发布以及网络等等一系列组件融合，甚至根据业务场景和自身需求对 Kubernetes 做深度的定制化，例如网易云基于 Kubernetes 的深度定制化实践。

绝杀"斧"：In Kubernetes

云原生这一说法在技术圈已经广为流传，甚至一些同学并不理解什么是云原生，但都知道要朝着云原生的方向发展演进。不管怎样，对于用户而言，改变以往虚拟机的部署和管理方式以及服务的治理策略是必要的。不得不说，All in Kubernetes 是一个趋势，CRD 自 Kubernetes 1.7 版本产生到上周发布的 1.16 版本的 GA，也就是说我们完全有了可以在生产环境扩展 Kubernetes 的能力。

大家如果深入了解 Kubernetes 会发现，Kubernetes 本身就是一个平台，Kubernetes 除了提供了很多的功能：例如它可以简化应用程序的工作流，加快开发速度；用户可以使用 Label 以自己的方式组织管理资源；还可以使用 Annotation 来自定义资源的描述信息，比如为管理工具提供状态检查等。此外，Kubernetes 控制器也是构建在跟开发人员和用户使用的相同的 API 之上，用户还可以编写自己的控制器和调度器，也可以通过各种插件机制扩展系统的功能。

这就是说，我们完全可以在 Kubernetes 里面通过扩展 API 和负载类型完成任何形式和类型的应用负载和管理方法，即使你有复杂的技术栈不可摆脱或者说有复杂的工作流，没问题，你可以根据自己的需要在资源和应用生命周期注入任何外部依赖和逻辑。

这种落地方式其实是借助于 Kubernetes 提供的扩展机制，完全将本地化、复杂化的逻辑转化为 Kubernetes 的设计和管理理念，不仅仅是使用 Kubernetes，而是融入和弱化原生 Kubernetes，最终每个用户都有着自己的一套独一无二的 Kubernetes。你中有我，我中有你。此外，它仍然完全和原生的 Kubernetes 兼容，可以优雅地升级和合并社区的 patch 等等。比较有代表性的是阿里开源的 Openkruise 项目。https://github.com/openkruise/kruise

用户使用 Kubernetes 核心是对工作负载的管理，其实选择 On Kubernetes 的一个很大原因是用户当前的工作负载管理方式与 Kubernetes 的已有工作负载类型不能很好地匹配。CRD 和 Operator 很好地解决了这个问题，让用户可以定制自己的负载。OpenKruise 项目就是这样一个典型的例子， 它是一组控制器，可扩展和补充 Kubernetes 核心控制器的工作负载管理。例如它提供三种工作负载控制器：

• 高级 StatefulSet：默认 StatefulSet 的增强版本，具有额外的功能，例如 inplace-update，pasue 和 MaxUnavailable。
• 
• BroadcastJob：在集群中的所有节点上运行 Pod 以完成的作业。
• 
• SidecarSet：一个控制器，它根据选择器将边车容器注入 Pod 规范，并且能够升级边车容器。
• 

理想的情况下，任何负载都可以做到 All in Kubernetes，甚至 Kubernetes 本身的负载管理，即 kube-on-kube，以及对于有状态服务的管理，例如 Mysql 集群 Operator 等等，你可以在 operatorhub 找到一些非常经典的例子。

总结

虽说不同的落地方式互有差异，但其实都是不同背景下的最好选择，它们都可以做到完全兼容 Kubernetes 的 API，脱离了问题本身，都不能说哪种方式最好。

• Above Kubernetes：如果你是一家初创公司，只想使用 Kubernetes 满足正常的容器管理或者服务部署，没有什么负担，同时人力也不足，没有能力自己维护 Kubernetes；
• On Kubernetes：如果你是一家中型甚至大型公司，有着大量的技术积累和设施，并且有能力和人力改造和开发 Kubernetes 或者原生的 Kubernetes 并不能满足你的需求；
• In Kubernetes：你不满足于单纯使用 Kubernetes 或者说原生的 Kubernetes 不能满足你的需求，你可以从 Above Kubernetes 转变而来；当然，如果痛定思痛，或者想彻底地改造当前的基础设施和应用管理方式，想更加靠近云原生的道路或者想要升级陈旧的机器部署和交付模式，你可以从 On Kubernetes 转变而来，最终 All in Kubernetes。

你的 Kubernetes 落地方式是什么样子呢？

原文链接
本文为云栖社区原创内容，未经允许不得转载。