关于Kubernetes的一些零碎想法

关于Kubernetes的一些零碎想法

容器集群管理系统与容器编排系统

很多使用Kubernetes的企业可能没有认识到Kubernetes最重要的特点。许多企业将其视为一种容器集群管理系统（container management system），只使用其管理容器的能力。然而，这种看法是大错特错的。如果只是想管理容器，Mesos可能在这方面甚至比Kubernetes做得更好。甚至只需将OpenStack的driver从虚拟机换成容器，就可以实现管理容器，而无需进行任何更改。甚至自行开发一个容器管理系统，也比引入Kubernetes来得简单，因为引入Kubernetes无疑增加了整个系统的复杂度。

实际上，Kubernetes在某种程度上甚至是借鉴了Mesos的设计，而Mesos本身则是借鉴了Google的Borg。相较之下，Yarn则是雅虎推出的半吊子产品，其集群资源管理和分布式计算框架之间的层次划分并不十分明确，对容器和GPU的支持直到2018年才开始，并且它并不支持镜像部署。这一切源于Yarn诞生较早，大约在2005年左右，当时还没有计算存储分离和不可变基础设施等概念。

Kubernetes作为容器编排系统

Kubernetes的创始人并不是将其描述为容器集群管理系统，而是称其为容器编排系统（container orchestration system）。在我接触Kubernetes之前，我曾参与IaaS虚拟机集群管理系统的开发，并接触过像Yarn这样的大数据计算任务集群管理系统。我在大学实习时还涉足了Hadoop相关工作，当时只是简单地编写HiveQL，主要是做数仓方面的工作，对于Yarn的设计并不了解。但后来我自学了Yarn，认为Yarn是较好的资源管理和调度系统。

然而，当我逐渐熟悉Kubernetes时，我第一反应并不是容器、镜像、集群资源管理和调度等方面，这些方面实际上Mesos做得更出色且更早（kubelet很多代码还是参考自Mesos）。真正让Kubernetes出色的地方在于其开放式API，自定义资源的能力，控制器模式和原生的调度和编排功能。这使得我相信统一基础设施是有可能实现的！在我看来，Yarn（或者Mesos）实际上只是一个普通的集群资源管理系统。虽然大家都说没有银弹，就像编程语言一样，没有绝对的银弹，但我认 为Kubernetes是分布式时代最接近银弹的一枚。

我曾在单机上实现过一些多进程的Pipeline小程序，发现Kubernetes中的Pod其实就是在集群之上抽象出来的进程。你不需要关注集群中的物理节点，你只需要关注如何创建、监听和编排这些Pod，就像以前在单机上写的编排程序一样。这是我对Kubernetes思想的第一个理解，它抽象出了基本概念和接口，就像操作系统的基本概念和系统调用一样，而操作系统的接口几乎三十年来都没有变化，这正是它设计的先进之处。

在分布式系统中，有一个不可回避的话题，即在多台机器上运行代码，而不是在单个机器上。因此，所有的分布式系统都需要一个简单的接口来实现这个功能。无论是无状态应用，有状态应用，只要你的服务涉及到多台实例，你都会面对运维、部署、发布、弹性，而这恰恰是Kubernetes给出的统一标准答案，Kubernetes现在也正在的成为了事实的标准。

Yarn看到Kubernetes攻占了微服务的地盘后，甚至试图进军AI和大数据的领域。因此，在2019年左右，Yarn开始支持Docker容器和镜像。需要注意的是，Yarn中的NodeManager虽然通过分配Container的形式来为应用分配资源，但之前的Container只是Yarn中的一种资源抽象，并不是Docker，而是直接使用Cgroup隔离，启动JVM虚拟机进程，并没有镜像这些概念。很可惜，Yarn只强调资源分配和隔离，而不强调不可变基础设施，并且确实已经老态龙钟；因此，之前的Yarn无法在一个集群中运行不同版本的MapReduce或Spark。而在Kubernetes上，每一个Spark App就是一个小型集群（从最简单的Deployment集群到有状态的StatefulSet集群，再到更加复杂的大型分布式应用集群），且这些App可以采用不同的镜像版本，而Kubernetes恰恰就特别擅长和适合用来维护管理一个个小型应用集群。Kubernetes抽象程度大于Yarn，这就是为什么Yarn可以运行在Kubernetes上而不能反过来。

云原生调度和资源管理

目前大多数分布式计算框架（如Spark和MapReduce）都具有自己的集群资源管理和调度功能。在Kubernetes出现之前，大多数企业要么自行开发这些功能，要么选择使用Yarn和Mesos。然而，Yarn和Mesos并不属于云原生调度。

个人而言，我更偏爱全面采用Kubernetes的做法，而不是采用二层甚至三层的调度。将Kubernetes视为IaaS仅用于机器分配，然后部署Yarn或Mesos，由它们自行管理集群，我认为这种做法非常鸡肋，完全没有摆脱传统的IaaS思维，实际上你只是提供了一台机器，完全可以不使用Kubernetes这么复杂的系统来实现容器交付。这样的问题在于，每个Yarn集群只能看到自己的资源视角，并不知道整个基础设施的资源情况，而Yarn本身对MapReduce App的调度，就没有全局资源视角。

如果去掉中间层的Yarn和Mesos，让Kubernetes直接调度Spark、MapReduce App，其实就会轻松很多，所谓中间商赚差价，过多的中间层也会消耗过多的人力和资源。不过这主要不是技术问题，而是风险、人力、时间、成本和部门问题。

面向终态和控制器模式

Kubernetes中到处都是控制器模式和面向终态的设计。对大多数公司来说（除了Google之外），这是一种非常激进的设计，以至于许多公司要么不使用它，要么不敢使用它。当然，Kubernetes的这种声明式设计并非独创，许多编程语言和框架都支持声明式编程。

Kubernetes的控制器模式和面向终态的代码我很少写，这类代码对程序员的能力要求确实很高。编写控制器最重要的是对差异的控制和理解，需要非常严密的逻辑。这是因为这些代码不是过程式的，它们是面向终态的代码。许多人可能不理解这之间的差异，我自己开始也不是很理解，毕竟我的水平有限。虽然说表面上看，控制器很容易写，主要原因在于面临的场景还不够复杂。

举个例子，编程语言中经常会涉及两个概念：Imperative（命令式）和Declarative（声明式）。Imperative描述如何执行（How），而Declarative描述的是要执行什么（What）。 这两个概念不仅存在于编程语言中，目前的AI框架如TensorFlow和MXNet等都支持声明式编程。如果您有使用过这些框架的经验，就会知道，编写代码后，它的执行并不是按顺序一行一行开始执行的，而是将代码翻译成计算图来执行。从某种意义上说，SQL也是一种声明式语言。

因此，大家常说Kubernetes的API是声明式的，这是什么意思呢？

这并不是说Kubernetes的API使用了非HTTP/RPC的协议，而是指它的API是声明式的。它只描述结果和终态，而不描述过程。过程交给谁了？交给Kubernetes中的控制器模式了。与前面提到的编程语言和AI框架类比，就是您编写的YAML文件被Kubernetes解析后，会以控制器模式的形式生效。举个例子，如果您的Deployment需要5个Pod，那么Kubernetes就会像一个机器人一样，始终保持5个Pod的状态。如果您将Pod数量更改为7，Kubernetes会自动调整到7个Pod。一切都按照您的指示执行。

实际上，声明式编程只是人们迈向智能化的重要一步，而不是表示没有代码。它只是将复杂性交给平台和框架处理，Kubernetes的控制器模式和面向终态的设计，则是彻底解放运维，朝着自动化和智能化的方向迈进。这对于一个平台的能力保障要求就比较高。本质上这是一种能力的转移，当机器有能力帮助你实现的时候，你就可以解放双手去做更多更高级的事情。

不可变基础设施

不可变基础设施是什么意思？

镜像让不可变成为可能，镜像使得一次编译，到处运行成为可能。镜像让发布部署变得非常方便。在传统基于虚拟机的IaaS架构中，CI/CD流程可能是通过包部署的，即代码构建后，将其下载到要发布的机器上（虚拟机或裸金属物理机），然后进行部署运行。

然而，基于Kubernetes的基础设施可以在CI/CD流程中首先将代码打包成镜像（如Docker镜像），然后使用Kubernetes的资源（如Deployment）来更新镜像，进行滚动更新以实现部署。如果您的服务有状态，自定义控制器还可以实现精细化的部署控制。

应用交付模型

现在大家都吹嘘以应用为中心的云原生概念，其目标是推进应用交付。请注意，这是应用交付，而不是容器交付。这可能是一场困难的旅程，因为从交付机器到交付应用，研发和运维人员需要进行心智的升级。为什么我说这是心智升级？我们传统的研发人员都习惯于将应用视为机器，无论他们当前使用的是容器、虚拟机还是物理机，他们的脑海中总是有机器的概念。在开发、测试和部署应用时，他们总是需要机器。

实际上，更抽象地说，我们不需要机器。开发人员在开发时，只需要一个代码编辑器，测试时只需要控制台输出日志和调试代码，部署服务只是需要将代码和环境批量复制，运行时只需可观测性指标（logging、tracing、metric），运维和弹性扩容只需要系统自动根据算法参数调整。您可能会发现，实际上不需要机器的概念。就像消费者购买个人电脑时不是为了机器本身，而是为了使用上面的软件应用一样。开发者购买服务器是为了更快、更灵活、更便捷的调试、部署和运行服务。

然而，由于许多基础设施在这方面尚未完善，如果此时完全摈弃机器的概念，只是让开发人员描述他们的需求以交付一个应用程序，那么当应用出现问题时，开发人员将无从下手。这也是Serverless目前推进较为困难的地方。

Serverless是当前最前卫的应用交付方式，其实也没有太多统一答案，该模式最大的好处是利好创业公司，特别是规模体量不大的早期创业者，围绕Serverless交付应用的创业公司不胜枚举，目标就是为开发者提供非常方便的开发、部署体验，都在不同层次上和方向（微服务、AI、大数据）进一步简化服务开发、部署、弹性、运维能力，解放开发者。

比如以Google CloudRun 为代表的Serverless模型，是一种既没有放弃镜像概念，也结合了Serverless按量计费，随时弹性的优点的Serverless交付模型。国内也有模仿者，比如 阿里云Serverless Kubernetes、腾讯云华为云超级虚拟节点等，一些创业公司搞的Serverless部署开发，都属于这类服务。这是一种在Kubernetes之上往前衍生的一小步Serverless。这种模式​更灵活也更能够被开发者接受。

另一个更高阶段的Serverless就是我们熟悉的云函数，Serverless Function，开发者只需要编写函数，事件驱动的方式触发函数调用，就可以完成某些功能模块。这个应用交付模型就更加激进，其实云函数不会完全替代容器镜像交付，它只能算一个场景补充，主要原因在于，大量的应用编写并不是云函数能够完全覆盖的，所谓越是高级，必然失去灵活性，就是这个道理。

本文由 mdnice 多平台发布