标签上的Kubernetes AntiAffinity-通过Node-Labels传播副本

Question

我们有3个ESXi主机，每个主机2个Kubernetes工人。所有节点都标记有“ esxhost：esxN”，我想在这些主机上散布副本。它很容易将副本散布在工作线程上，在一台主机上没有相同的服务，但是我想散布在ESXi主机上，即使两名工作人员死亡，也要拥有HA，因为ESXi主机死了。

我该如何管理？尝试了一些选择，但没有成功。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: someNS
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:    
      containers:
        - name: demo-mos-node
          image: registry.docker.dev...../demo:2.1.2
          ports:
            - containerPort: 80
          env:
            - name: CONFIG
              value: "https://config.git.dev....."

Answer 1

正如@iliefa所说，您应该使用pod反亲和力，但是必须定义2个亲和力术语。第一个将阻止（软或硬）pod在同一节点上的分布，第二个将阻止（软或硬）pod在相同可用性区域中的分布（您将其称为ESXi主机）。也许您可以使用built in labes，或更具体地说-failure-domain.beta.kubernetes.io/zone。另一个选择是根据可用区域为节点添加标签。这是我的意思的示例：

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: <define-importance-here>
        podAffinityTerm:
          topologyKey: kubernetes.io/hostname
          labelSelector:
            matchLabels:
              <insert-your-pod-labels-here>
      - weight: <define-importance-here>
        podAffinityTerm:
          topologyKey: failure-domain.beta.kubernetes.io/zone
          labelSelector:
            matchLabels:
              <insert-your-pod-labels-here>

您施加的权重将定义每个反亲和力规则与另一个规则相比的重要性。

Answer 2

您可以定义反亲和力规则。这些用于使豆荚彼此远离。有2个变体：

• soft（preferredDuringSchedulingIgnoredDuringExecution）

• hard（DuringSchedulingIgnoredDuringExecution必需）

如果指定硬变体，则如果该节点上已经有一个Pod，则该Pod不会被调度到该节点。

如果指定软变体，则如果该节点已经在运行具有标签为“ app”和值为“ demo”的标签的容器，则该容器不希望被调度到该节点上。

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - demo
          topologyKey: "kubernetes.io/hostname"
此外，如果要在主节点上安排播客，则必须删除主节点的默认污点：
 kubectl get nodes 

 kubectl describe node master_node_name

 kubectl taint nodes master_node_name key:NoSchedule-
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity