3.5 使用标签和选择器来约束pod调度

迄今为止，我们创建的所有pod都是近乎随机地调度到工作节点上的。正如前一章我们所提到的，这恰恰是在Kubernetes集群中工作的正确方式。由于Kubernetes将集群中的所有节点抽象为一个整体的大型部署平台，因此对于你的pod实际调度到哪个节点而言是无关紧要的。对于每个pod而言，它获得所请求的确切数量的计算资源（CPU、内存等）及其从其他pod的可访问性，完全不受该pod所调度到的节点的影响，所以通常来说没有任何需要指定Kubernetes把pod调度到哪里的需求。

当然，某些情况下，我们希望对将pod调度到何处持一定发言权，你的硬件基础设施并不是同质便是一个很好的例子。如果你的某些工作节点使用机械硬盘，而其他节点使用固态硬盘，那么你可能想将一些pod调度到一组节点，同时将其他pod调度到另一组节点。另外，当需要将执行GPU密集型运算的pod调度到实际提供GPU加速的节点上时，也需要pod调度。

我们不会特别说明pod应该调度到哪个节点上，因为这将会使应用程序与基础架构强耦合，从而违背了Kubernetes对运行在其上的应用程序隐藏实际的基础架构的整个构想。但如果你想对一个pod应该调度到哪里拥有发言权，那就不应该直接指定一个确切的节点，而应该用某种方式描述对节点的需求，使Kubernetes选择一个符合这些需求的节点。这恰恰可以通过节点标签和节点标签选择器完成。

3.5.1 使用标签分类工作节点

如前所述，pod并不是唯一可以附加标签的Kubernetes资源。标签可以附加到任何Kubernetes对象上，包括节点。通常来说，当运维团队向集群添加新节点时，他们将通过附加标签来对节点进行分类，这些标签指定节点提供的硬件类型，或者任何在调度pod时能提供便利的其他信息。

假设我们集群中的一个节点刚添加完成，它包含一个用于通用GPU计算的GPU。我们希望向节点添加标签来展示这个功能特性，可以通过将标签gpu=true添加到其中一个节点来实现（只需从kubectl get nodes返回的列表中选择一个）：

$ kubectl label node gke-kubia gpu=true

现在我们可以在列出节点时使用标签选择器，就像之前操作pod一样，列出只包含标签gpu=true的节点：

$ kubectl get nodes -l gpu=true

与预期相符，此时只有一个节点具有此标签。当然我们还可以尝试列出所有节点，并告知kubectl展示一个显示每个节点的gpu标签值附加列（kubectl get nodes -L gpu）。

3.5.2 将pod调度到特定节点

现在，假设我们想部署一个需要GPU来执行其工作的新pod。为了让调度器只在提供适当GPU的节点中进行选择，我们需要在pod的YAML文件中添加一个节点选择器。使用以下代码清单中的内容创建一个名为kubia-gpu.yaml的文件，然后使用 kubectl create -f kubia-gpu.yaml 命令创建该pod。

代码清单3.4 使用标签选择器将pod调度到特定节点：kubia-gpu.yaml(minikube单节点无法演示)

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    gpu: true

我们只是在spec部分添加了一个nodeSelector字段。当我们创建该pod时，调度器将只在包含标签gpu=true的节点中选择（在我们的例子中，只有一个这样的节点）。

3.5.3 调度到一个特定节点

同样地，我们也可以将pod调度到某个确定的节点，由于每个节点都有一个唯一标签，其中键为 kubernetes.io/hostname，值为该节点的实际主机名，因此我们也可以将pod调度到某个确定的节点。但如果节点处于离线状态，通过hostname标签将nodeSelector设置为特定节点可能会导致pod不可调度。我们绝不应该考虑单个节点，而是应该通过标签选择器考虑符合特定标准的逻辑节点组。

这是一个关于标签和标签选择器是如何工作，以及如何使用它们影响Kubernetes操作的快速演示。当我们在接下来的两章中讨论Replication-Controllers和Service时，标签选择器的重要性和实用性也将变得更加明显。