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

关注

发布于: 2020 年 05 月 08 日

Kubernetes作为容器化时代的一个成功标准，构建了一套宏大的技术体系，包含了Cloud中的方方面面。在这个技术体系中，既有成熟的技术，也有比较前沿、实验性的技术。
本文回顾Kubernetes技术的发展历程、展望比较前沿的技术，目标是带领读者区分成熟的技术、前沿的技术，对于比较前沿的技术，根据自己的实际情况来选用——需要的就是最好的。
CNCF的全景图如下所示。
﻿
Kubernetes双轮驱动与马斯洛需求层级对于云时代的R&D工程师、测试工程师、运维工程师、平台研发者等技术人员来说，首先需要明白的概念是：Kubernetes体系技术的发展来自于“双轮驱动”，也就是平台驱动力、应用驱动力。
平台驱动力：从Kubernetes平台级研发的角度出发，属于技术型驱动力，以云原生、标准化为目标，可以对应于CloudNative给出的宏伟技术体系给出的各个部分。
应用驱动力：从使用者的角度出发，属于需求型的驱动力，应用开发者对云的需求较多，一个典型目标就是“尽量少关心分布式系统的细节”。
﻿
 如果用马斯洛需求层级来表现云时代的发展，可以整体的技术体系的发展分成四个层次：
第一个层级：分布式系统的基本功能
第二个层级：平台方的移植能力、应用方的配套设施
第三个层级：平台方的扩展点、应用方的可见-控制能力
第四个层级：平台方的高度统一标准化、应用方的高度综合而方便
 
这四个层级的发展阶段是不一样的，第一、二个层级可以说已经达到了“业界标配”的水平，而第三个层级大部分属于“有收益、非标准的阶段”，第四个层次对于不同的使用者，往往还是“收益不确定的阶段”。
 
在做技术选型、评估技术合理性的时候，要为全流程负责：计划、编码、构建、测试、发布、部署、运维、监控。
﻿
第一层次：分布式系统的基本功能对于任何一个平台，无论是基于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相关技术方案，依然可以秉承一个原则：适合的就是好的。