Kubernetes 大规模使用过的都说简单，没有用过清一色的都是使用复杂、概念晦涩难懂，因此即使是那些具有一定服务器端知识的人也可能会感到困惑。让我在这里尝试一些不同的东西。与其解释一个不熟悉的问题（如何在 Kubernetes 中运行 Web 服务？）和另一个（你只需要一个清单，三个 sidecar 和一堆 gobbledygook），我将尝试揭示 Kubernetes 技术发展趋势。

(资料图)

如果您已经知道如何使用虚拟机运行服务，希望您会发现最终并没有太大区别。如果您对大规模运营服务完全不熟悉，那么跟随技术的发展可能会帮助您了解当代方法。

像往常一样，这篇文章并不全面。相反，它试图总结我的个人经历以及计算机多年来虚拟化是如何形成的。

早在 2010 年，当我刚刚开始我的软件工程师职业生涯时，使用虚拟机（或有时是裸机）部署应用程序非常普遍。

你需要一个临时的 Linux 虚拟机，将 Nginx 或 Apache 反向代理放在它前面，然后在它旁边运行一堆守护进程和 cronjobs。

这样的机器将代表服务的单个实例，打个比方，就类似于一个盒子，而服务本身将只是分布在网络上的一组命名的相同机器。根据您的业务规模，您可能只有几个、几十个、几百个甚至几千个盒子分布在为生产流量提供服务的多个盒子中。

服务的抽象将应用程序的复杂性隐藏在单个入口点之后

通常，机器群的大小将定义配置（安装操作系统和软件包）、扩展（产生相同的盒子）、服务发现（将一组盒子隐藏在一个名称后面）和部署（运送新版本的代码）的方式到盒子）完成了。

如果你是一个只有几个类似宠物的盒子的公司，您可能会发现自己很少半手动地配置新盒子。这通常意味着总线系数低（由于缺乏自动化）、安全状况差（由于缺乏定期补丁更新）以及可能更长的灾难恢复。从好的方面来说，管理成本会非常低，因为不需要扩展，您的部署会很简单（只需几个盒子来交付代码），而且服务发现会很简单（由于相当静态地址池）。

对于拥有大量盒子的公司来说，现实情况会有所不同。大量机器通常会导致更频繁地需要配置新盒子（更多的盒子意味着更多的破损）。你会投资自动化（投资回报率会很高），最终得到许多牛一样的盒子。作为不断重新创建盒子的副产品，您将增加总线因素并改善安全状况（将自动更新和安装补丁）。在它的反面，会存在低效的扩展（由于每日/每年的流量分布不均匀），过于复杂的部署（很难将代码快速交付到许多机器上），以及脆弱的服务发现（您是否尝试过大规模运行consul或zookeeper？）会导致更高的运营成本。

Amazon Elastic Compute Cloud (EC2) 等早期云产品允许更快地启动（和关闭）机器；使用packer制作并使用cloud-init自定义的机器镜像，使配置稍微容易一些；puppet和ansible等自动化工具支持应用基础架构更改并大规模交付新版本的软件。但是，仍有很大的改进空间。

在过去，拥有不同的生产和开发环境是很常见的。这将导致应用程序可能在您安装的 Debian 机器上本地运行，但由于缺少依赖项而无法在生产中的 vanilla CentOS 上启动。相反，在本地安装应用程序的依赖项可能会遇到一些麻烦，但由于资源需求高，为每个服务运行预配置的虚拟机进行开发将是不可行的。

即使在生产中，虚拟机的庞大也是一个问题。每个服务拥有一个虚拟机可能会导致低于最佳资源利用率和/或相当大的存储和计算开销，但是将多个服务放在一个盒子中可能会使它们发生资源抢占冲突。

世界显然需要一个更轻量级的盒子。

容器 - 单个应用程序的盒子

这就是容器的用武之地。就像允许将裸机服务器分割成几台更小（更便宜）的机器的虚拟机一样，容器将一个 Linux 机器分割成数十个甚至数百个独立的环境。

在一个容器中，您可能会觉得您拥有自己的虚拟机，以及您最喜欢的 Linux 发行版。好吧，至少乍一看。从外部看，容器只是在主机操作系统上运行并共享其内核的常规进程。

打包应用程序及其所有依赖项（包括特定版本的操作系统用户空间和库）的能力，将其作为容器镜像发送，并在安装了 Docker（或类似工具）的任何位置的标准化执行环境中运行，极大地提高了工作负载的可重复性.

由于容器边界的轻量级实现，计算开销显著降低，允许单个生产服务器运行可能属于多个（微）服务的数十个不同容器。当然，这可能以降低安全性为代价。

由于不可变和共享的镜像层，镜像存储和分发也变得更加高效。

在某种程度上，容器也改变了供应的方式。使用（粗心编写的）Dockerfiles 和ko和Jib之类的（神奇的）工具，责任极大地转移到了开发人员身上，简化了生产 VM 的要求——从开发人员的角度来看，你只需要一个 Docker-（或更高版本的 OCI-）兼容应用程序的运行时，因此您不会再因为要求安装某个版本的 Linux 或系统包而惹恼您的运维朋友。

最重要的是，容器加速了运行服务的替代方式的开发。现在有 17 种方法可以在 AWS 上运行容器https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/，其中大部分是完全无服务器的，在足够简单的情况下，您可以使用 Lambda 或 Fargate 并从牛一样的盒子中受益！

容器被证明是一个非常方便的开发工具。构建容器镜像也比构建 VM 更简单、更快捷。再加上如何有效分离团队之间职责的老组织问题，导致典型企业的平均服务数量显著增加，每个服务的盒子数量也有类似的增加。

Docker 普及的容器形式实际上具有很强的欺骗性。乍一看，每个服务实例都有一个便宜的专用 VM。但是，如果这样的实例需要sidecar（例如在您的 Web 应用程序前面运行的本地反向代理来终止 TLS 连接或加载秘密和/或预热缓存的守护程序），您会立即感觉到疼痛，这就是容器与虚拟机的本质区别。

Docker 容器被刻意设计为只包含一个应用程序。一个容器——一个 Nginx；一个容器 - 一个 Python Web 服务器；一个容器 - 一个守护进程。容器的生命周期将绑定到该应用程序的生命周期。并且特别不鼓励将像systemd这样的 init 进程作为顶级入口点运行。

因此，要从本文开头的图表重新创建一个 VM-box，您需要拥有三个具有共享网络堆栈的协调容器-box（嗯，至少localhost需要相同）。要运行该服务的两个实例，您需要三个三个一组的六个容器！

从扩展的角度来看，这意味着我们需要一起扩展（和缩减）一些容器。部署也需要同步进行。新版本的 Web 应用程序容器可能会开始使用新的端口号，并与旧版本的反向代理容器不兼容。

我们显然在这里错过了一个抽象，它与容器一样轻量级，但与原始 VM 盒子一样富有表现力。

此外，容器本身也没有提供任何将盒子分组为服务的方法。但他们促成了箱子人数的增加！Docker 竞相用它的 Swarm 产品解决这些问题，但另一个系统赢了……

Kubernetes 设计师显然没有发明新的运行容器的方法，而是决定重新创建良好的旧的基于 VM 的服务架构，但使用容器作为构建块。好吧，至少这是我的看法。

但对我来说，作为以前有 VM 经验的人，一旦我了解了新术语并弄清楚了类似的概念，许多最初的 Kubernetes 想法就会开始看起来很熟悉。

让我们从 Pod 抽象开始。Pod 是您可以在 Kubernetes 中运行的最小的东西。最简单的 Pod 定义如下所示：

apiVersion: v1kind: Podmetadata:  name: nginxspec:  containers:  - name: nginx    image: nginx:1.20.1    ports:    - containerPort: 80

乍一看，上面的清单只是说明要运行什么镜像（以及如何命名）。但是请注意containers属性是一个列表！现在，回到那个nginx + web app例子，在 Kubernetes 中，您可以简单地将反向代理和应用程序本身放在一个盒子中，而不是为 Web 应用程序容器运行额外的 Pod：

apiVersion: v1kind: Podmetadata:  name: foo-instance-1spec:  containers:  - name: nginx            # <-- sidecar container    image: nginx:1.20.1    ports:    - containerPort: 80  - name: app              # <-- main container    image: app:0.3.2

然而，Pod 不仅仅是一组容器。Pod 中容器之间的隔离边界被削弱。就像在 VM 上运行的常规进程一样，Pod 中的容器可以通过localhost或使用传统的 IPC 方式自由通信。同时，每个容器仍然有一个独立的根文件系统，以保持打包应用程序及其依赖项的好处。对我来说，这看起来像是在尝试同时利用 VM 和容器世界的最佳部分：

现在，当我们得到新的盒子时，我们如何运行多个它们来组成一个服务？换句话说，如何在 Kubernetes 中进行扩展和部署？

事实证明，它非常简单，至少在基本场景中是这样。Kubernetes 引入了一个方便的抽象，称为 Deployment。最小的 Deployment 定义由名称和 Pod 模板组成，但指定所需的 Pod 副本数量也很常见：

apiVersion: apps/v1kind: Deploymentmetadata:  name: foo-deployment-1  labels:    app: foospec:  replicas: 10  selector:    matchLabels:      app: foo  template:    metadata:      labels:        app: foo    spec:      <...Pod definition comes here>

Kubernetes 的伟大之处在于，作为开发人员，您并不关心服务器（或 Kubernetes 术语中的节点）。您根据 Pod 组进行思考和操作，它们会自动调动（和重新分布）到集群节点：

这使得 Kubernetes 更像是一种无服务器技术。但同时，Pod 的外观和行为与过去熟悉的 VM 非常相似（除了您不需要管理它们），因此您可以在熟悉的抽象中设计和推理您的应用程序：

Kubernetes Service - 一组命名的 Pod。

Kubernetes 设计人员肯定知道，仅仅创建 N 个盒子的副本并将其称为服务是不够的。客户端应该能够使用单个（可能是逻辑的）名称访问服务，并且服务发现系统应该能够将该名称转换为特定的 IP 地址（类似于我们理解的负载均衡器，服务于特定的实例） ）。

过去，您需要一个单独的（并且要求非常高的）解决方案。但是，Kubernetes 内置了这个功能，而且默认实现还不错！它还可以使用Linkerd或Istio等服务网格进行扩展，使其更加强大。

将一组 Pod 转换为服务唯一需要做的就是创建一个 Service 对象（不是真正的创建服务，只是一个网络层面的抽象）。

下面是一个简单的 Kubernetes Service 定义的样子：

apiVersion: v1kind: Servicemetadata:  name: foospec:  selector:    app: foo  ports:    - protocol: TCP      port: 80

上面的清单允许app=foo使用defaultDNS 名称（如foo.default.svc.cluster.local. 而且这一切都没有在集群中安装任何额外的软件！

请注意 Service 定义在任何地方都没有提到 Deployment。就像 Deployment 本身一样，它根据 Pod 和标签运行，这使它非常强大！例如，Kubernetes 中良好的蓝/绿或金丝雀部署可以通过让两个 Deployment 对象在单个 Service 选择具有公共标签的 Pod 后运行不同版本的应用程序镜像来实现：

现在，最有趣的部分 - 你注意到 Kubernetes 服务与我们旧的基于 VM 的服务没有什么区别了吗？

那么，Kubernetes 是不是就像 VM 一样，但更简单？嗯，是的，但也不是。因为他跟虚拟机存在本质上的差别，套用Kelsey Hightower的话，我们应该区分驾驶汽车的复杂性和修理汽车的复杂性。我们中的许多人会开车，但很少有人擅长修理发动机。幸运的是，有专门的商店！这同样适用于 Kubernetes。

使用 EKS 或 GKE 等托管 Kubernetes 产品运行服务确实很相似，但比使用 VM 简单得多。但如果你必须维护 Kubernetes 集群背后的实际服务器，那就完全不同了……，所以仅仅使用 Kubernetes 和维护 Kubernetes 是两码事。

为了改善在 VM 上运行服务的体验，容器改变了我们打包软件的方式，大大降低了对服务器配置的要求，并启用了替代方法来部署我们的工作负载。但就其本身而言，容器并没有成为大规模运行服务的解决方案。顶部仍然需要额外的编排层。

Kubernetes 作为容器原生编排系统之一，使用容器作为基本构建块重新创建了过去熟悉的架构模式。Kubernetes 还通过提供用于扩展、部署和服务发现的内置方法来解决传统方案的痛点。