Kubernetes 如何重塑虚拟机

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

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

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

如何使用虚拟机部署服务

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

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

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

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

使用虚拟机部署服务带来的挑战

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

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

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

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

Docker 容器解决了什么问题

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

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

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

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

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

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