分析 Kubernetes 技术体系的层级,慎用比较前沿的技术

用户头像
韩超
关注
发布于: 2020 年 05 月 08 日
分析Kubernetes技术体系的层级,慎用比较前沿的技术

Kubernetes作为容器化时代的一个成功标准,构建了一套宏大的技术体系,包含了Cloud中的方方面面。在这个技术体系中,既有成熟的技术,也有比较前沿、实验性的技术。

本文回顾Kubernetes技术的发展历程、展望比较前沿的技术,目标是带领读者区分成熟的技术、前沿的技术,对于比较前沿的技术,根据自己的实际情况来选用——需要的就是最好的。

CNCF的全景图如下所示。



Kubernetes双轮驱动与马斯洛需求层级

对于云时代的R&D工程师、测试工程师、运维工程师、平台研发者等技术人员来说,首先需要明白的概念是:Kubernetes体系技术的发展来自于“双轮驱动”,也就是平台驱动力、应用驱动力。

平台驱动力:从Kubernetes平台级研发的角度出发,属于技术型驱动力,以云原生、标准化为目标,可以对应于CloudNative给出的宏伟技术体系给出的各个部分。

应用驱动力:从使用者的角度出发,属于需求型的驱动力,应用开发者对云的需求较多,一个典型目标就是“尽量少关心分布式系统的细节”。



 如果用马斯洛需求层级来表现云时代的发展,可以整体的技术体系的发展分成四个层次:

  1. 第一个层级:分布式系统的基本功能

  2. 第二个层级:平台方的移植能力、应用方的配套设施

  3. 第三个层级:平台方的扩展点、应用方的可见-控制能力

  4. 第四个层级:平台方的高度统一标准化、应用方的高度综合而方便

 

这四个层级的发展阶段是不一样的,第一、二个层级可以说已经达到了“业界标配”的水平,而第三个层级大部分属于“有收益、非标准的阶段”,第四个层次对于不同的使用者,往往还是“收益不确定的阶段”。

 

在做技术选型、评估技术合理性的时候,要为全流程负责:计划、编码、构建、测试、发布、部署、运维、监控。



第一层次:分布式系统的基本功能

对于任何一个平台,无论是基于Kubernetes的,还是更早之前的,它都要解决分布式系统一个核心的问题:上线-运维等分布式工作,需要尽量简化。

 

在应用驱动力上面,比较朴实而基本的逻辑是:

  • 我们的RD:本质工作写代码的,不要花过多精力在分布式上面;

  • 我们的QA:最好用传统的方法干活,分布式环境相关的工作尽量简化;

  • 我们的OP:分布式系统量级的增加、人力不能线性增加,应该达到“一个羊也是牵、一群羊也是赶”的状态

 

在平台驱动力上面,至少要将打包-发布-部署的全流程贯通,并且具有运行时的调度能力。

第1个重要成果

最基础的机制是Docker所提供的,也是一个比Kubernetes还要早达成的共识,这就是包括编译-拉取-运行三个主要阶段的Docker Image。

Docker Image的逻辑在于从代码变成Code变成仓库里面的Image,再运行仓库里面Image。

Image是分布式系统运行时与开发成果主要接口,当用Image上线的业界共识达成之后,分布式系统就向前走了一大步。



直到9012年,也会有“杠精“认为不用Image上线,可以效率更高。这本质上是将上线的成本,转嫁给了运维成本,可以说是方便了一时,却增加了更长时间的复杂度。

 

第2个重要成果

第2个重要的成果就是Kubernetes比较基础的机制:以Node代表的机器,以Pod代表的容器、以ReplicationController、ReplicaSet代表的无状态分布式机制。



Kubernetes的Pod本意是豆荚,里面每个豆子其实可以视作一个Docker Container,Pod代表了应用的容器、唯一的ID、提供了基本访问、管理机制。Pod里面一般有一个运行的Container,一个Pause的Container,由每个Node的Kubelet来创建。Pod的对于应用的逻辑在于:仅有Docker(cgroup)提供的隔离机制是不够的,还需要调度需要配置设施。



Kubernetes的ReplicationController、ReplicaSet则是分布式的真谛,在它的spec.replicas已经表示了分布式的核心内容,保证有几个副本Pod运行,至于template.spec.containers.resources等参数,则是表示了这里需要资源。多副本运行的拉起,也正是Kubernetes提供的最基本的调度能力。

 

分布式系统马斯洛需求的第一个层次,简单来说就是:应用方只需要建立RC、RS等无状态的Workload,指定image,平台用其在一些Node创建pod,调度Pod运行、确保Pod的数目。

 

第二层次:平台方的移植能力、应用方的配套设施

当Cloud的马斯洛需求层级向第二层延伸的时候,平台方、应用方各自产生了一些诉求,



从应用方的角度,新的需求在于应用并非是一个单体的东西,而是有着“服务化“的诉求,需要有多服务、服务调用问题;还有一些服务是并非简单的RS、RC等无状态服务,它们有着特殊的生命周期。

 

从平台方的角度,增加自身的生存能力很重要,因此Kubernetes的CRI、CNI、CSI等移植层的接口应运而生。



应用方的配套设施



作为应用方,一个典型的需求就是:服务化建设。这个工作涉及到Kubernetes一些机制的重新利用,比如Service、Load Balance、DNS……



这些机制本身是Kubernetes的提供的,却又不是基础-核心功能,但又是应用需要标准依赖的。至于应用如何用这些机制,其实也存在着变数。

 

Kubernetes的Service演进过程也是比较复杂的,它本身与kube-proxy的代理转发模式有关,也提供后端的ClusterIP、NodePort、loadbalance和Ingress四种模式,还有一种Headless Service变种情况。它解决的问题比较明确:如何表示一个分布式服务。



一个Kubernetes的Service主要用于对外提供服务,如下面图所示。





 应用开发者遇到的另外一个问题就是“特殊生命周期的程序“,它们不同于RC、RS或者Deployment等无状态、等待外部调用的服务。

Kubernetes提供一个概念是Workload Controllers:

  • Jobs、CrobJob:用于单次、多次运行的机制

  • DaemonSet:保持单Node只有一个特性

  • StatefulSets:用于有状态服务保持序列

这些组件其实是对应用层一些生命周期特殊的程序提供机制,本身也属于高度的抽象实现。

平台方的移植能力

 

作为Kubernetes平台的生存能力也在这个层级得到了进展,这里面也就是它的移植层。

  • CRI(Container Runtime Interface):容器运行时接口

  • CNI(Container Network Interface):容器网络接口

  • CSI(Container Storage Interface):容器存储接口



下面图表示了Kubernetes与移植层的关系。



CRI本身是一个Docker单一实现的封装,而CNI所表示了抽象网络、CSI表示抽象存储,其实也就是提供了Kubernetes运行于不同地方的能力。从更大的层面来说,网络、存储是各种Cloud平台的重度依赖,它们的虚拟化也可以从软件做到硬件,下层实现的”可移植化“,显然也是比较重要的。

 

在云时代的第二个需求层级,平台方、应用方的技术走向关联性不强,但二者殊途同归:提升了Kubernetes的使用场景

 

第三层级:平台方的扩展点、应用方的可见-控制能力

随着Cloud技术的发展,马斯洛需求向第三层次演进,这也是应用方、平台方的一个新的契合点——平台的可扩展性

 

  • 从应用方的角度,第三层级属于较高级人员的需求,而第一层级属于较低级人员的需求。虽然Cloud的大目标是“尽量简单”,但高级的人员依然希望“看到并控制“平台的运行,这两点也并不矛盾。

  • 从平台方角度,并不能将Kubernetes所有的能力都当成的“上下层不可预约的鸿沟“,而是需要让上层也能做一些事情,Kubernetes的扩展点也去越来越重要了。



下面的图表示了Kubernetes的扩展点。



Kubernetes的扩展点有些属于移植层,有些并不常用,以下三个需要关注:

  • 自定义资源CRD(3):提供了不属于系统提供,但可以封装成标准形式的能力;

  • 调度器scheduler(4)、控制器Controllers(5):通过监听api-server来可以进行管理扩展。

通过以上扩展点,其实类似RC、RS之类的机制,完全可以在Kubernetes的核心代码以外来实现。当Kubernetes发展到这个阶段,它已经可称之为技术平台,RC、RS及调度器、控制器等也并非底层机制,而是预置实现。



监控典型是一个典型的属于马斯洛需求第三层次的工作,在传统的方式中,监控实现方式常常需要“侵入“,这其实与云原生的理念违和。

 

一个现实的情况很明显,虽然Prometheus体系是按照比较云原生,比较吻合Kubernetes里面模式来架构的,但实际的应用中,往往标准化没有如此重要。

 



实际情况则是,Prometheus等监控体系并不需要按照非常标准化的方式来部署,它的核心价值在于实用性,而不是标准化。



这里面的原因也很简单,对于应用方来说,并不关心Observability-Analysis体系与Kubernetes关系是否标准,因为它们都属于系统层。

 

Kubernetes技术生态要有扩展能力,这正是云的需求第三层级,这点显然有收益;但扩展方式是否“标准“,却是未必。公有云、私有云的不同部署模式,也决定了”标准化“的重要程度。

 

第四层次:平台方的高度统一标准化、应用方的高度综合而方便

从更长远的角度,应当看到Cloud发展的星辰大海,也有一些美好的愿景……

平台方希望高度统一标准化的平台,应用方希望高度综合方便的平台,一些很新颖、也很不标准化的技术点包括:Service Mesh、CI/CD、等综合性的技术,比如Database、Queue、Steaming等模块@Kubernetes上。



Service Mesh(服务网格)对于应用的微服务建设、开发-测试-运维的效率提升,有着重要的意义。Istio及其衍生的Sidecar方案,也非常有代表性,但它们并非一定就是Service Mesh的唯一方案、最终方案。



CI/CD(持续集成、持续交付)是生产流程中的强需求,却不是由单一技术能解决的,这方面方案也不仅仅是技术,也与环境、流程大有关系。

下面图代表了CI/CD在研发流程中所影响的环节。



特别需要说明的一点就是在CNCF的全景图当中,官方认证的Service Mesh、CI/CD全局方案并未出现——LINKERD只是个网络代理。

 

 Kubernetes在发展过程中,也衍生一个新的方向:Database等分布式组件,也可以跑在Kubernetes上面,而它们原本的运行方式,类似于小平台。在Kubernetes运行显然是可以实现的,而Kubernetes也为此提供了Operator框架。MySql、Kafka、Spark都可以运行Kubernetes在上面,并且用Operator管理这些有状态服务。



把这些成熟的分布式软件搬到Kubernetes上面,业界并未形成完全统一的方案。大方向的正确与实际的收益是两回事。

从技术发展的角度来说,统一环境不能提高标准化程度,理论上还能提高资源利用率,但这种技术方案可能只在某些场景有收益,而非所有场景都有收益。

 

结语:适合的就是好的

 

Kubernetes仍在快速的发展过程中,本文通过需求层级来描述了技术的成熟度。

 

从技术选型的角度来说,对于一、二层的成熟技术,跟从既成事实的标准即可;对于第三、四层的技术,有些其实比较前沿,需要一分为二来看待。

 

可以从几个角度思考问题:

  • 标准化重要,还是极限优化重要?

  • 目标系统是大型,中型,还是小型?

  • 实际的生产中,开发、部署、运维的工作比例是多大?

  • 对于某个技术,“有你,跟没你,有什么区别?

 

 总之,在Cloud时代中看Kubernetes相关技术方案,依然可以秉承一个原则:适合的就是好的

用户头像

韩超

关注

还未添加个人签名 2017.10.20 加入

还未添加个人简介

评论 (8 条评论)

发布
用户头像
非常棒,云时代,kubernetes 让人又爱又恨。
2020 年 05 月 09 日 21:09
回复
用户头像
超哥修复下CloudNative和ServiceMesh,第一张图哈~
2020 年 05 月 09 日 18:13
回复
多谢了
2020 年 05 月 09 日 19:47
回复
用户头像
感谢分享,文章我推荐到InfoQ官网首页了。
2020 年 05 月 09 日 09:13
回复
用户头像
深度好文
2020 年 05 月 09 日 08:12
回复
用户头像
挺实用的!
2020 年 05 月 08 日 22:52
回复
用户头像
抢沙发,超哥牛逼666
2020 年 05 月 08 日 21:48
回复
没有更多了
分析Kubernetes技术体系的层级,慎用比较前沿的技术