如果现在让你选择一个容器管理平台,相信应该没人会错过Kubernetes,尤其对于没有任何技术负担的用户,选择Kubernetes无疑是最明智的一个选择。
Above Kubernetes,这种落地方式很好理解,就是你把原生的、标准的、无任何接触和侵入改动的社区版本的Kubernetes拿来,直接部署运行起来即可,完全在Kubernetes之上构建自己的应用,通过标准的Kubernetes API来访问集群。你可以完全跟着社区升级演进你的Kubernetes,保持与社区同步,完全借助于社区的力量维护你的Kubernetes。这种落地方式无疑是最理想的,你不必考虑与社区和业界的主流脱离,同时也降低了管理和运维的成本。
Building a Cloud Native Architecture with Kubernetes followed 12 factor app
如上图,你可以安装标准的主流的云原生体系来落地Kubernetes,可以拥抱社区的一整套完整的架构方案,并且足以满足你的需求。
高阶"斧":On Kubernetes
能够使用原生的Kubernetes集群诚然非常好,但是有些场景并不一定走得通。大家都知道,Kubernetes的概念和设计其实是很超前的,谷歌的软件开发和应用部署理念虽然好,但业界大部分的企业还是陈旧的技术理念和更复杂的场景,对于一些又技术积淀的企业用户而言,想要一下子抛弃当前的应用管理和部署方式改为原生的Kubernetes的应用部署和管理方式,确实有些吃不消。那对于这些用户而言,肯定不能看着别人吃肉自己啃窝窝头。
On Kubernetes的落地形态其实是一种妥协和中间过程,一方面很难一下子抛弃已有的基础设施,例如服务治理、监控、网络拓扑等等,只能在原生的Kubernetes基础上做一些本地化改造使得Kubernetes能够满足当前的应用管理方式,例如抛弃kube-proxy使用扁平化的内网环境、通过富容器的方式包装一些监控和代理组件等等。
这种落地方式一方面能够做少了改动就吃到这波技术红利,一方面可以探索属于自己的云原生的道路,内部技术栈也可以朝着云原生的方向发展演进,不至于在这波潮流中落后太多,而且可以根据自己的场景做定制化的Kubernetes开发,甚至比社区的Kubernetes走的更远或者解决一些社区没有解决的问题。有得必有失,虽然可以在借助于Kubernetes的设计理念和管理能力,但是同时由于本地化的改造不能完全与社区版本的Kubernetes兼容,升级就会比较麻烦,每次升级不得不重新打patch,还会出现同时维护多个Kubernetes版本的窘境,这无疑会给开发和运维带来很多麻烦,所以这也不是一般的小公司能够走得通的道路,需要一定的研发和技术能力。比较典型的是 、 以及 。
On Kubernetes:如果你是一家中型甚至大型公司,有着大量的技术积累和设施,并且有能力和人力改造和开发Kubernetes或者原生的Kubernetes并不能满足你的需求
In Kubernetes:你不满足于单纯使用Kubernetes或者说原生的Kubernetes不能满足你的需求,你可以从Above Kubernetes转变而来;当然,如果痛定思痛,或者想彻底地改造当前的基础设施和应用管理方式,想更加靠近云原生的道路或者想要升级陈旧的机器部署和交付模式,你可以从On Kubernetes转变而来,最终All in Kubernetes