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

 Kubernetes 社区成员与项目维护者原文标题《Kubernetes 应用之道：让 Kubernetes落地的“三板斧”》，首发于知乎专栏：进击的云计算原文地址：https://zhuanlan.zhihu.com/p/82666719

出身豪门、大厂背书的 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 落地方式是什么样子呢？

---

本文做者：王国梁

阅读原文

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