| 摘自Tim Boring的《在Go中构建一个协调器》。 这篇文章包括
|
打35%的折扣 在Go中构建一个协调器在manning.com结账时在折扣代码框中输入fccboring。
架构介绍
Kubernetes。Kubernetes。Kubernetes。如果你在过去五年中在科技行业工作或接近科技行业，你至少听说过这个名字。也许你在你的日常工作中使用过它。在这篇文章中，我们将看到建立我们自己的Kubernetes需要什么；编写代码，以更好地了解什么_是_Kubernetes。而Kubernetes是什么，在一般意义上，是一个协调器。
不那么好的日子
让我们回到2002年，认识一下Michelle。米歇尔是她公司的系统管理员，她负责保持她公司的应用程序全天候运行。她是如何做到这一点的呢？
像许多其他系统管理员一样，米歇尔采用了在裸机服务器上部署应用程序的常见策略。图1中可以看到米歇尔的世界的一个简单的草图。每个应用程序通常运行在自己的物理硬件上。更加复杂的是，每个应用程序都有自己的硬件要求，米歇尔必须购买并管理每个应用程序所特有的服务器群。此外，每个应用程序都有自己独特的部署过程和工具。数据库团队通过CD获得新的版本和更新，其过程包括数据库管理员（DBA）将文件从CD复制到中央服务器，然后使用一套自定义的shell脚本将文件推送到数据库服务器，由另一套shell脚本处理安装和更新。米歇尔亲自处理公司财务系统的安装和更新。这个过程包括从互联网上下载软件，至少省去了她处理光盘的麻烦，但财务软件有自己的一套工具来安装和管理更新。其他几个团队正在构建公司的软件产品，而这些团队所构建的应用程序有一套完全不同的工具和程序。
图1.这张图代表了2002年Michelle的世界的一个片断。上图是她的服务器所在的机架的视图。下图是从操作系统的角度来观察这些机器。这两个视图都显示了管理员在物理硬件和操作系统方面所处理的多样性。
如果你在这段时间没有在这个行业工作，没有经历过像米歇尔那样的世界，请认为自己很幸运。那个世界不仅混乱不堪，难以管理，而且还非常浪费。虚拟化在上世纪初到中期出现了。这些工具使像米歇尔这样的系统管理员能够分割他们的物理机群，使每台物理机能够承载几个较小但独立的虚拟机（VM）。每个应用程序不是在自己的专用物理机上运行，而是在一个虚拟机上运行。而且，多个虚拟机可以被装在一台物理机上。尽管虚拟化使像米歇尔这样的人的生活变得更好，但它并不是一颗银弹。
这种情况一直持续到2010年代中期，有两项新技术出现在地平线上。第一个是Docker，它引入了_容器_，一种更轻量级的虚拟化技术，允许运行容器共享操作系统。这时出现的第二个新技术是Kubernetes，一个专注于自动部署和管理容器的协调系统。
什么是协调器？
在一头扎进去写代码之前，让我们先定义一下_协调器_这个术语。协调器是一个为部署、扩展和其他管理容器提供自动化的系统。在这样的系统中，应用程序不再 "裸奔 "在裸机或虚拟化机器上。相反，它们在容器内运行。表1总结了我们所提到的每一种部署和管理模式的不同特点。
过去二十年中使用的三种主要部署和管理模式的比较。
| 传统模式
|
虚拟化
|
调度
| | --- | --- | --- | |
每台机器一个应用
|
每台虚拟机一个应用（每台机器很多）。
|
每个容器一个应用（每台机器很多）。
| |
异质机器类型
|
同质化的机器类型
|
同质化的机器类型
| |
用于应用程序部署、管理、自动化的不同工具
|
部署、管理、自动化工具不同，有些可以重复使用
|
用于部署、管理、自动化的相同工具
|
协调系统的组成部分
一个_协调器_可以自动部署、扩展、管理容器。接下来，让我们来确定实现这些功能的组件及其要求。这些组件可以在图2中看到。它们是
- 任务
- 工作
- 调度器
- 管理者
- 工作者
- 集群
- CLI
任务
_任务_是协调系统中最小的工作单位，通常运行在一个容器中。你可以把它想象成在一台机器上运行的进程。一个任务可以运行一个反向代理的实例，如Nginx；也可以运行一个应用程序的实例，如RESTful API服务器；还可以是一个简单的程序，无休止地循环运行，做一些愚蠢的事情，如ping一个网站并将结果写入数据库。
一个任务应该指定以下内容。
- 它需要多少内存、CPU和磁盘才能有效运行
- 协调器在发生故障时应该做什么，通常称为_重启政策（restart_policy_
- 用于运行该任务的容器镜像的名称
任务定义可以指定其他细节，但这些是核心要求。
任务
_工作_是任务的聚合。它有一个或多个任务，这些任务通常形成一个更大的逻辑分组，以执行一组功能。例如，一项工作可以由一个RESTful API服务器和一个反向代理组成。
一项工作应该在比任务更高的层次上指定细节。
- 构成作业的每个任务
- 工作应该在哪个数据中心运行
- 工作的类型
为了简单起见，我们将不在我们的实现中处理工作。
调度器
调_度器_决定什么机器可以最好地承载作业中定义的任务。它可以作为管理器中的一个独立进程运行，也可以作为一个完全独立的服务。决策过程可以简单到以轮流的方式从一组机器中选择一个节点，也可以复杂到根据一些变量计算分数并选择具有 "最佳 "分数的节点。
调度器应该执行这些功能。
- 确定一组可以运行任务的候选机器。
- 对候选机器从最好到最差进行评分。
- 挑选具有最佳得分的机器。
管理器
_管理器_是协调器的大脑，是用户的主要入口。为了在协调系统中运行任务，用户将其任务提交给管理器。管理器使用调度器，然后找到一台可以运行作业任务的机器。管理器还定期从每个工作者那里收集指标，这些指标被用于调度过程中。
管理者应该做以下工作。
- 接受用户提出的启动和停止任务的请求。
- 将任务安排到工人机上。
- 追踪任务、它们的状态以及它们运行的机器。
工作者
_工作者_提供了协调器的核心部分。它负责运行由经理分配给它的任务。如果一个任务因任何原因失败，它必须尝试重新启动该任务。工作者还提供有关其任务及其整体机器健康状况的指标，供主站轮询。
工作者负责以下工作。
- 作为Docker容器运行任务。
- 接受从管理器中运行的任务。
- 为经理提供相关的统计数据，以便调度任务。
- 追踪其任务及其状态。
集群
_集群_是上述所有组件的逻辑组合。一个协调集群可以从一个单一的物理或虚拟机上运行。更常见的是，集群由多台机器组成，少则五台，多则数千台或更多。
CLI
最后，我们的CLI，即主要的用户界面，应该允许用户。
- 启动和停止任务
- 获取任务的状态
- 查看机器的状态（即工作者）。
- 启动管理器
- 启动工作器
图2.协调系统的组成部分。无论不同的协调器使用什么术语，每个协调器都有一个调度器、一个管理器、一个工作者，它们都对任务进行操作。
所有的协调系统都共享这些相同的基本组件。谷歌的Borg，如图3所示，将管理器称为_BorgMaster_，将工作器称为_Borglet_，但除此之外，还使用了上面定义的相同术语。
图3.谷歌的Borg。底部是一些Borglet，即工作者，它们在容器中运行单个任务。中间是BorgMaster，也就是管理器，它使用调度器将任务放在worker上。
Kubernetes是在谷歌创建的，受到Borg的影响，它把管理器称为_控制平面_，把工作器称为_kubelet_。它把作业和任务的概念卷进了_Kubernetes对象_。最后，Kubernetes保留了_调度器_和_集群_这两个术语的用法。这些组件可以在图4的Kubernetes架构图中看到。
图4.Kubernetes的架构。左边看到的_控制平面_，相当于管理者功能，或者说相当于Borg的BorgMaster。
Hashicorp的Nomad，见于图5，使用更多的基本术语。经理是_服务器_，而工人是_客户端_。虽然图中没有显示，但Nomad使用了我们在这里定义的术语_调度器_、工作、任务_和_集群。
图5.Nomad的架构，虽然看起来比较稀疏，但功能仍与其他协调器类似。
为什么要从头实现一个协调器？
如果像Kubernetes和Nomad这样的协调器已经存在，为什么还要从头开始写一个呢？难道我们不能看一下它们的源代码而得到同样的好处吗？
也许吧。但是，请记住，Kubernetes和Nomad是大型软件项目。两者都包含超过200万行的源代码。虽然不是不可能，但通过在两百万行代码中苦苦挣扎来学习一个系统可能不是最好的方法。
相反，我们要卷起袖子，把我们的手弄脏。
为了确保我们专注于协调器的核心部分而不至于偏离方向，我们将缩小实现的范围。你在本书中编写的协调器是完全有效的。你可以启动和停止作业，并与这些作业进行交互。它不会为生产做好准备。毕竟，我们的目的不是要实现一个取代Kubernetes或Nomad的系统。相反，我们的目的是实现一个最小的系统，让我们更深入地了解像Kubernetes和Nomad这样的生产级系统如何工作。
现在你已经看到了建立你自己的Kubernetes需要什么。如果你想了解更多，可以在曼宁的liveBook平台上查看这本书。
The postComponents of an Orchestratorappeared first onManning.
