共计 3335 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章主要讲解了“Kubernetes 容器调度怎么使用”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“Kubernetes 容器调度怎么使用”吧！
节点调度
根据原生的 Kubernetes 行为，默认情况下，Rancher 2.0 工作负载中的 pod 将分布在可调度且具有足够可用容量的节点（主机）上。但就像 1.6 版本一样，Rancher 2.0 也有助于：
在特定节点上运行所有 pod
使用标签进行节点调度
以下是 1.6 UI 中的调度方式。Rancher 允许您在特定主机上运行所有容器，指定硬 / 软主机标签，或在部署服务时使用亲和性/反亲和性规则。
以下是 Rancher 2.0 中对应的节点调度 UI，它在部署工作负载时提供相同的功能。
Rancher 使用底层的原生 Kubernetes 构造来指定节点的亲和性 / 反亲和性。
下面的示例中我们将来看看如何使用节点调度选项来调度工作负载 pod，然后看看 Kubernetes YAML 规范和 Rancher 1.6 Docker Compose 配置的对比。
示例：在特定节点上运行所有 Pod
在部署工作负载（导航到 Cluster Project Workloads）时，可以将工作负载中的所有 pod 调度到特定节点。
在这里，我使用特定节点上的 nginx 镜像部署 scale = 2 的工作负载。
如果某节点有足够的计算资源可用，Rancher 将选择该节点；如果使用 hostPort，则不会发生端口冲突。如果该工作负载使用与另一个工作负载冲突的 nodePort 来对外暴露，那么部署是可以成功创建的，但它不会创建 nodePort 服务。如此一来，工作负载则完全不会暴露了。
在“工作负载 /Workload”选项卡上，您可以按节点列出工作负载。在此，我可以看到我的 Nginx 工作负载的两个 pod 都安排在指定的节点上了：
Kubernetes pod 规范中的调度规则如下所示：
示例：主机标签的亲和性 / 反亲和性 **
我在 Rancher 2.0 集群中向 node1 添加了标签 foo = bar，以测试基于标签的节点调度规则。
主机标签亲和性：硬
下图展示了如何在 Rancher 2.0 UI 中指定主机标签的亲和性规则。硬亲和性规则意味着所选主机必须满足所有调度规则。如果找不到此类主机，则工作负载将无法部署。
在 PodSpec YAML 中，此规则将转换为字段 nodeAffinity。另外请注意，我已经包含了 Rancher 1.6 docker-compose.yml 以使用标签实现相同的调度行为。
主机标签亲和性：软
如果您是 Rancher 1.6 用户，那么您一定知道软亲和性规则意味着调度程序会尝试按规则部署应用程序，但即使有主机不满足规则也可以成功部署。以下是如何在 Rancher 2.0 UI 中指定此规则：
pod 的相应 YAML 规范如下所示：
主机标签反亲和性
除了 key = value 主机标签匹配规则外，Kubernetes 调度结构还支持以下运算符：
因此，要实现反亲和性，可以使用运算符 NotIn 和 DoesNotExist 作为节点标签。
使用容器标签进行调度
Rancher 1.6 中的这一功能允许您将容器调度到具有特定标签的容器的主机。要在 Rancher 2.0 上执行此操作，请使用 Kubernetes inter-pod 亲和和反亲和功能：
Kubernetes 允许您根据 pod 标签而不是节点标签来约束 pod 可以被调度到哪些节点。
Rancher 1.6 中最常用的调度功能之一是使用容器上的标签对服务本身进行反亲和。要在 Rancher 2.0 中复制此行为，我们可以在 Kubernetes YAML 规范中使用 pod 反亲和构造。例如，可以考虑使用 Nginx Web 工作负载。要确保此工作负载中的 pod 不在同一主机上，您可以使用 podAntiAffinity 构造，如下所示。通过使用标签指定 podAntiAffinity，我们可以确保每个 Nginx 副本不在单个节点上共存。
使用 Rancher CLI，可以将此工作负载部署到 Kubernetes 集群上。请注意，上面的部署指定了三个副本，并且我在 Kubernetes 集群中有三个可调度节点。
由于指定了 podAntiAffinity，因此三个 pod 最终位于不同的节点上。为了进一步检查 podAntiAffinity 的应用方式，我可以将部署扩展到四个 pod。请注意，由于调度程序无法找到满足 podAntiAffinityrule 的另一个节点，因此无法调度第四个 pod。
基于资源的调度
在 Rancher 1.6 中创建服务时，可以在 UI 的“安全 / 主机”选项卡中指定内存预留和 mCPU 预留。Cattle 会将服务的容器安排到具有足够可用计算资源的主机上。
在 Rancher 2.0 中，您可以使用 pod 容器规范下的 resources.requests.memory 和 resources.requests.cpu 指定工作负载 pod 所需的内存和 CPU 资源。
指定这些资源请求时，Kubernetes 调度程序会将 pod 分配给具有足够容量的节点。
仅给主机调度特定服务
Rancher 1.6 能够在主机上指定容器标签，从而只将特定容器调度给它。
要在 Rancher 2.0 中实现此目的，可以在 pod 规范中使用相应的 Kubernetes 的“添加节点 taints（如主机标签）并使用容差”的功能：
全局服务
在 Rancher 1.6 中，全局服务是指在环境中的每个主机上部署容器的服务：
如果服务的标签为 io.rancher.scheduler.global：true，则 Rancher 1.6 调度程序将在环境中的每个主机上调度服务容器。如文档中所述，如果将新主机添加到环境中，并且主机满足全局服务的主机要求，则 Rancher 将自动启动该服务。
下面的示例是 Rancher 1.6 中的全局服务示例。请注意，只需放置所需标签就足以使服务全局化。
我们如何使用 Kubernetes 在 Rancher 2.0 中部署全局服务？
为此，Rancher 为用户的工作负载部署了 Kubernetes DaemonSet 对象。DaemonSet 的功能与 Rancher 1.6 全局服务完全相同。Kubernetes 调度程序将在集群的每个节点上部署一个 pod，并且随着新节点的添加，调度程序将在它们上启动新的 pod，前提是它们与工作负载的调度要求相匹配。
此外，在 2.0 中，您还可以将 DaemonSet 限制为部署到具有特定标签的节点
使用 Rancher 2.0 UI 部署 DaemonSet
如果您是 Rancher 1.6 用户，要使用 UI 将全局服务迁移到 Rancher 2.0，请导航到 Cluster Project Workloads 视图。部署工作负载时，您可以选择以下工作负载类型：
这就是上面的 DaemonSetworkload 相应的 Kubernetes YAML 规范：
从 Docker Compose 到 Kubernetes YAML
要使用 Compose 配置将 Rancher 1.6 全局服务迁移到 Rancher 2.0，请按照下列步骤操作。
您可以使用 Kompose 工具将 docker-compose.yml 文件从 Rancher 1.6 转换为 Kubernetes YAML，然后使用 Kubernetes 集群中的 Kubectl 客户端工具或 Rancher CLI 部署应用程序。
回头想想上面提到的 docker-compose.yml 规范，其中的 Nginx 服务就是全局服务。如下是使用 Kompose 将其转换为 Kubernetes YAML 的方法：
下面开始针对您的 Kubernetes 集群配置 Rancher CLI，并部署生成的 * -daemonset.yaml 文件。
如上所示，我的 Kubernetes 集群有两个可以调度工作负载的工作节点，并且部署 global-daemonset.yaml 为 Daemonset 启动了两个 pod，每个节点上有一个 pod。
感谢各位的阅读，以上就是“Kubernetes 容器调度怎么使用”的内容了，经过本文的学习后，相信大家对 Kubernetes 容器调度怎么使用这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
