时间戳

首页 > 解决方案 > 节点选择器或污点具有更高的优先级？

kubernetes - 节点选择器或污点具有更高的优先级？

问题描述

我们有一个 aks 集群，目前有一个系统节点池和 2 个用户节点池（usnp1&usnp2）。我们目前有多个应用程序 pod 跨用户节点池运行。

因此，现在我们需要运行我们现有的应用程序 pod 之一，以专门拥有一个单独的节点池和命名空间。例如，我们的应用程序 myapp 当前在命名空间“all-app-ns”中运行，该命名空间的节点选择器设置为“usnp1”，并且在同一个池中，我们还有其他应用程序 pod。因此需要将 myapp pod 和所有相关组件完全移动到专门针对“myapp-ns”的新命名空间，并且它应该只分配给“myapp-pool”

  1. myapp-pool”不应分配除 myapp 之外的任何其他 pod。此处哪个选项更优先 - 带有 pod 或 taints 的节点选择器？我读到 nodeselector 将强制调度程序“应该分配”到特定节点，其中 taint 会做“可以分配”.. 所以 nodeselector 会是更好的选择吗？

  2. 由于 myapp 部署和 pod 当前已经在“all-app-ns”中运行，是否将它们移动到新命名空间“myapp-ns”，这些是否会删除命名空间 -all-app-ns”中现有的 myapp pod？有停机时间吗？目前我们使用 helm chart 进行了部署，helmstate 会删除旧的 pod 并创建新的 pod，是否会发生停机？

标签： kuberneteskubectlazure-akskubernetes-pod

解决方案

  1. ...所以 nodeselector 会是一个更好的选择吗？

您可以使用 nodeSelector，也可以使用 nodeAffinity。这只是配置问题。nodeSelector 严格定义 Pod 与 eg

nodeSelector:
   usnp1: "true"

只能部署到带有标签的节点usnp1=true。但是您可以在 Pod 配置中定义与 nodeAffinity 相同的内容，例如

kind: Pod
metadata:
  name: <your-pod-name>
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: usnp1
            operator: In
            values:
            - "true"

这些配置是相同的。

  1. ...并且任何停机时间会发生吗？

如果我清楚地理解，您需要将myapp pods当前部署的移动all-app-ns到myapp-ns. 因此，在这种情况下，如果您在案例中部署到不同的命名空间，则不会取消部署myapp-ns其中的 pod 。all-app-ns我想，因为如果你还没有切换，helm install你需要定义选项。因此，要取消部署，您必须. 应用程序的可用性取决于您的 DNS 记录，因此如果您需要公开应用程序，您可能需要配置它们。--namespacekubectl set-contexthelm uninstall <RELEASE> --namespace=all-app-ns

在下面回答您的问题：

所以对于第1点。如果我们有任何未定义任何节点选择器的 pod，那么就有机会将这些 pod 分配给这个 cae 中的新节点池，对吗？这里的目的是不允许新的节点池拥有除 myapp pod 之外的任何其他 pod。taint 是否会比 nodeelctor 或称为“podnodeselector”的准入控制器有帮助？

使用nodeAffinity上述配置进行myapppod 配置。

将标签添加到myapppod 配置中，例如

  template:
    metadata:
      labels:
        usnp1: myapp

对于您不想在该节点上安排的任何其他 pod，或者最好说不与具有标签usnp1: myapp创建podAntiAffinity配置的 pod 一起安排，例如

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: usnp1
            operator: In
            values:
            - myapp
        topologyKey: "kubernetes.io/hostname"

看看https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

无论如何，这也不是 100% 的解决方案，因为 pod 的调度是具有许多规则的复杂算法，这些规则是得分加权的。您可以在 schedulerds 日志中看到分数和权重。

看看https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

同样对于第 2 点，我们将使用修改后的清单进行 helm 升级，并从管道中更改命名空间，在这种情况下，helm statefile 是否在此处起到删除旧 pod 的作用？

对此，我不知道 helm 中的一项功能，您可以从一个命名空间并行取消部署并部署到第二个命名空间。因为如果我清楚地了解所应用的部署状态helm install是每个命名空间。因此，要部署/取消部署，您需要始终定义--namespace您是否尚未启用。这可能意味着您在部署相同的 helm chart 时不能干扰命名空间状态。

但我没有太多的掌舵经验。

推荐阅读