转载

调度器之 Kubernetes

【编者的话】本文作者向大家简单阐述了Kubernetes的组成和设计，以及相对于单体调度器的改进。

、

在上一篇文章中，我介绍了调度的概念，并且调研了2个基础单块(basic monolithic)调度器：fleet和swarm。总结一下：调度器负责项集群的节点发布任务。然而，基础单体调度器，由于设计问题，在性能和吞吐量上都受限。

本文，我们将介绍Kubernetes相对于基础单块设计的改进。

Kubernetes介绍

Kubernetes 一个用来管理集群间Linux容器的工具。

Kubernetes来自Google，拥有轻量及支持大规模扩展的特点。在设计上，它是高度解耦的，可以被划分为2个组件：控制位面和工作节点服务。控制位面，负责向节点分配容器和管理集群配置。工作节点服务，运行于集群中的单个机器上，负责管理本地容器。

在Kubernetes中，存在 pod 的概念。它是位于同一位置的容器群，就如同鲸鱼的pod，或者是豌豆的pod(tips：pod来源于DC Network，常指在逻辑上对于节点的划分，通常分布于同一区域)。在同一pod中的容器共享相同的命名空间。它被用于服务发现和分离。

Kubernetes的每个节点都需要专用的子网——或者覆盖网络 (overlay network)。这样，每个pod便能够得到一个在集群中独一无二的IP。这一点可以通过在Flannel，OpenVSwitch，Calico，或Weave集群上部署Kubernetes实现。更多关于Kubernetes网络的内容，请看这个文档。

让我们深入讨论这些细节。

核心概念

PODS

pod 是Kubernetes的基本单位。一个pod就是一堆容器，它们位于同一主机并且共享相同的 Linux命名空间集合。

当一个pod部署完毕，Kubernetes会启动一个容器，它会锁住pod中真实容器需要的资源和命名空间。这就是所谓的 暂停容器 。

Pod可以支持纵向应用栈。比如，一个后端和前端紧耦合的应用可以位于同一pod。

在单个工作节点中，pod是能够容错的，但是在集群中则不然。该特性可以通过 --restart=on-failure 参数进行启用。然后，当pod故障时，它就会自动重启了。但是如果一整个节点宕机，该节点上的pod并不会被重新调度到另一个节点。

Pod并不是被设计用来在多节点间扩展，或者在节点故障后正常运行。因此，我们需要一个备份控制器。

备份控制器

备份控制器负责扩展，更新和重调度pod。它保证在任何时点，运行的pod数量和配置中指定的备份数量一致。备份控制器通过终止或启动pod来实现其与备份数量的一致。

命名空间

命名空间是一种分离pod的方式。来自不同命名空间的2个pod不能参与服务发现。由此，我们便可以在同一集群中创建多个环境。如果我们希望，便可靠此提供应用级的隔离。

服务

一个服务充当一组相关pod的联系点。它会根据配置将流量路由到所有相关的pod。

服务让你可以改动pod组而无需担心单个pod的可用性。你并不需要直接访问pod，只需要访问服务即可。服务将会按照round-robin算法将流量路由到所有匹配到相应标签的pod。

服务也有助于服务发现。当一个pod在某个命名空间中被创建，相同命名空间中的每个服务的主机和端口号会通过环境变量提供。

例如：在 deis 命名空间，我可以使用 db 这个名字创建一个服务。每个在此命名空间中创建的pod，随后便会持有 DB_SERVICE_HOST 和 DB_SERVICE_PORT 环境变量集。

守护进程集

守护进程集确保特定的pod正在集群中的每个节点(或一组节点)上运行。这个和fleet的全局单元很像。当一个额外的节点被添加到集群时，Kubernetes会将需要的pod添加到该节点。如果集群的节点数减少时，那些节点上的pod就会被回收。

任务(JOBS)

任务和pod类似，但任务一定会终止。这对批处理工作负载相当有用。

在Kubernetes v1 API中，任务和守护进程集是不可用的。如果可以，请将Kubernetes切换到1.2。否则，你需要在自行开启API扩展，具体的方法是，在API服务器启动时，加上 --runtime-config=extensions/v1beta1/daemonsets=true 或在运行 kube-up.sh 脚本前 export ENABLE_DAEMONSETS=true 。