作者 | ContainerLabs 译者 | Luga Lee 策划 | Luga Lee
Hello folks，今天为大家分享一个由 ContainerLabs 出品的关于 Kubernetes Scheduler 的文章。
(资料图)
在 Kubernetes 中，Pod 是最小的可部署工作负载单元。所以显而易见的问题：
“Pod 应该部署在哪里？”
当然，答案是：Pod 始终在 Node 内执行。
但是…… 有这么多 Node 节点 ，我们应该将这个 Pod 部署到哪个 Node ？？？
大家好，我是 “Kubernetes Scheduler” ～
让我们用简单的场景打个比方来剖析一下 Kubernetes Scheduler 的工作原理以及选择 Node 的方式。
假设我们有一家“社交餐厅”，里面有几张桌子，每张桌子周围有几个座位，有很多顾客和酒店服务员。“社交餐厅”意味着不同的顾客群可以坐在同一张桌子旁，如果有足够的座位并且满足所有条件。
桌子 = Node 节点（VM 或物理机）座位 = VM 上的资源可用性服务员= Kube-Scheduler客户组 = Pod组内单个客户 = Container
1、Resource requirements and availability - 资源需求和可用性
1、一个 *Customer-Group 进入餐厅并提出一个简单的座位请求。服务员分析客户组的需求并查看他们需要多少个座位。然后，他查看所有可用的桌子，过滤无法“安排”的桌子，并为他们分配（绑定）满足他们座位要求的桌子。 *
2、这是基本的调度类型——Kube 调度程序不断监视 API Server 以查看是否有任何未调度的 Pod，查看 Pod 内每个容器的资源需求。
3、请记住，容器是那些在规范中有资源需求的容器，而不是 Pod 本身。
在下面的示例中，我们对所部署的 Pod 的 CPU 和内存进行了资源定义。要求是 500 milli CPU 和 128 MiB 内存。
apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - name: nginx image: nginx:1.7.9 resources: requests: memory: "128Mi" cpu: "500m"
现在让我们看一下其中一个 Node（餐厅餐桌）以确保它们有足够的容量。我们运行以下命令：
kubectl describe nodes
2、Node Selector - 节点选择器
另一个 *Customer-Group 来到餐厅，要求坐在任何“蓝色”的桌子上。服务员查看他的库存并找到所有带有蓝色标签的表并将客户组分配给适当的桌子*
在这种情况下，Pod 有一个指定的 nodeSelector（键值对），它请求部署 Pod 到与键值对匹配的任何 Node 节点上。
新的 YAML 文件如下所示：
apiVersion: v1kind: Podmetadata: name: nginx-bluespec: containers: - name: nginx image: nginx:1.7.9 nodeSelector: color: blue
为了查询我的所有 Node 以检查我们是否有标签 “blue” ，我们运行以下命令进行查看：
kubectl get nodes --show-labels
从列表中我们可以看到 “worker-2” 的标签为 color=blue。Kubernetes 也为我们提供了几个内置标签。
棒极了 ！如果您现在部署它，调度程序会自动将其分配给正确的节点。我们可以通过运行以下命令来确认这一点。
kubectl get pod -o wide
请注意，如果您没有带有适当标签的 Node 节点，则部署将处于挂起状态。
3、 Node affinity and anti-affinity -节点亲和与反亲和
节点亲和性和反亲和性很像节点选择器，但它通过支持表达语言和软/硬偏好而不只是硬性要求为您提供更大的灵活性。
让我们说另一个 *Customer-Group 进入餐厅。他们更喜欢放在任何“海景”的桌子上，但这不是必需的。服务员查看他的库存并找到所有标签为“海洋”的桌子并将客户组分配给适当的桌子*
在此示例中，Pod 定义了一个 nodeAffinity，它表明我们更喜欢与键值对匹配的“节点”-> view : ocean（我们通过下面的 matchExpressions 来做到这一点）
这里有两个选项：
preferredDuringSchedulingIgnoredDuringExecution: 这意味着匹配条件的节点将是首选，但不保证何时分配到节点。
IgnoredDuringExecution- 如果在调度 Pod 后删除或更改节点的标签，则不会删除 Pod。换句话说，affinity 选择仅在调度 Pod 时起作用，而在执行时不起作用
requiredDuringSchedulingIgnoredDuringExecution: 表示选择节点时需要符合条件的节点。IgnoredDuringExecution 和以前一样。
apiVersion: v1kind: Podmetadata: name: nginx-oceanviewspec: containers: - name: nginx image: nginx:1.7.9 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: view operator: In values: - ocean
这种情况下的运算符也可以是其他值，例如 In、NotIn、Exists、DoesNotExist、Gt、Lt。NotInDoesNotExist 会产生相反的效果 nodeAntiAffinity。
4、 Pod affinity and anti-affinity -Pod 亲和与反亲和
另一个素食主义者女孩团伙*顾客团体来到餐厅。他们有一项要求，即不得将其放置在任何包含已经被肉食者占据的座位的桌子上。他们有点挑剔——他们还想坐在已经有男孩子坐的桌子上。换句话说，他们对肉食者没有亲和力，但对男孩有亲和力。 *
让我们来看一个真实世界的场景，您有一组 Redis 缓存和 Web 服务器部署。以下是条件：
您希望将 redis-cache Pod 部署得尽可能靠近 web-servers Pod (podAffinity)您不希望同一节点中有两个 redis-cache Pod (podAntiAffinity)您不想在同一个节点中部署两个网络服务器 Pod (podAntiAffiinity)您希望这些规则适用于节点范围。（拓扑）
以下是 redis-cache 部署 YAML :
apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: selector: matchLabels: apptype: redis-cache replicas: 3 template: metadata: labels: apptype: redis-cache spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: apptype operator: In values: - redis-cache topologyKey: "kubernetes.io/hostname" containers: - name: redis-server image: redis:3.2-alpine
在上面的示例中，您看到 redis-cache 标签 (apptype=redis-cache) 被添加到作为此部署的一部分部署的每个 Pod。
描述 podAntiAffinity 为没有两个 redis-cache Pod 部署在同一台服务器内。这是由内置拓扑 “kubernetes.io/hostname” 定义的，这意味着它是一个 Node 。如果需要，这也可以扩展到区域或任何其他合法密钥。
现在，让我们看一下 Web 服务器部署 YAML 文件：
apiVersion: apps/v1kind: Deploymentmetadata: name: web-serverspec: selector: matchLabels: apptype: web-server replicas: 3 template: metadata: labels: apptype: web-server spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: apptype operator: In values: - web-server topologyKey: "kubernetes.io/hostname" podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: apptype operator: In values: - redis-cache topologyKey: "kubernetes.io/hostname" containers: - name: web-app image: nginx:1.12-alpine
在上面的示例中，您看到 Web 服务器标签 (apptype=web-server) 被添加到作为此部署的一部分部署的每个 Pod：
podAntiAffinity 被描述为没有两个网络服务器 Pod 部署在同一台服务器内。这是由
内置的 topologyKey 定义的，"kubernetes.io/hostname" 这意味着它是一个 Node。如果需要，这也可以扩展到区域或任何其他合法密钥。
podAffinity 被描述为将 Web 服务器 Pod 部署为尽可能靠近 redis 缓存。
一旦你部署了这个 - 我们就得到了我们的目标 - 3 个网络服务器和 3 个 redis 缓存服务器 - 每个节点上都有一个副本！
5、 Taint and Tolerations -污点和容忍
这一次，餐厅周围的一张桌子被花生溢出的灾难“污染”了。所以他们说不会在这张桌子上安排新的 *Customer-Groups 以避免过敏反应。所以任何新的客户组都被放置在除了这个受污染的桌子之外的所有其他桌子上。*
到目前为止，我们一直在从 Pod 的角度来看调度。但是，如果 Node 的另一方决定不再安排新的 Pod 怎么办？这就是污点进来的地方。一旦你污染了一个 Node，你将有两个选择：
1、NoSchedule - 这意味着一旦它被污染，就不应该在这个 Node 上安排新的 Pod。*除非他们有容忍度
2、NoExecute - 现有的 Pod 一旦被污染，就会从 Node 中逐出。*除非他们有容忍度（我们将在一分钟内讨论容忍度）
那么我们如何污染节点呢？
kubectl taint nodes mytaintkey=mytaintvalue:NoSchedule
一旦我们有了这个设置，Node 节点现在就被以下键值对 (mytaintkey=mytaintvalue) 污染了。因此无法安排新的 Pod。
但是如果你想从 Node 中驱逐现有的 Pod 怎么办？
kubectl taint nodes mytaintkey=mytaintvalue:NoExecute
这将从当前 Node 中驱逐所有的 Pod，并将它们移动至另一个可用的 Node 节点上。
但过了一会儿，一个客户组走过来说 - “哦，那很好。我们对花生过敏有“容忍度”**。所以请继续并将我们放在“受污染”的桌子上”。Kube 调度程序验证它们的容忍度并将它们放入受污染的表中
现在，如果 Pod 对 Node 指定的污点键值具有容忍度，则此 Pod 将免除污点，并在必要时放置在 Node 上。
apiVersion: v1kind: Podmetadata: name: web-serverspec: containers: - name: web-app image: nginx:1.12-alpine tolerations: - key: "mytaintkey" operator: "Equal" value: "mytaintvalue" effect: "NoExecute"
Adiós !
- EOF -
关键词：
Node.js
云数据库
Redis
Kubernetes
