Kubernetes应用之道:让Kubernetes落地的“三板斧”
发布于 19 天前 作者 yan 60 次浏览

前言

出身豪门、大厂背书的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版本的窘境,这无疑会给开发和运维带来很多麻烦,所以这也不是一般的小公司能够走得通的道路,需要一定的研发和技术能力。比较典型的是美团点评的HULK 2.0、京东的JDOS 2.0以及阿里巴巴的Sigma。

在这种高阶的玩法中,没有标准的套路,只有符合自己的方案。例如美团点评结合自己已有的设施在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项目。用户使用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落地方式是什么样子呢?

文章经授权发布,作者:王国梁 ;

原文:https://zhuanlan.zhihu.com/p/82666719

END

Kubernetes  CKA线下班


Kubernetes  线上直播班

回到顶部