Container Service for Kubernetes:Spread ECI pods across zones and configure affinity scheduling

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un cluster ACK managé Pro répondant aux exigences suivantes :

  • Version de Kubernetes 1.22 ou ultérieure

  • Composant ACK Virtual Node version 2.10.0 ou ultérieure

  • Composant kube-scheduler version 5.9 ou ultérieure, avec la politique de planification des pods basée sur les nœuds virtuels activée

• Plusieurs zones (vSwitch) configurées dans le profil eci-profile afin que les pods puissent être planifiés entre les zones

• Les champs nodeAffinity, podAffinity ou topologySpreadConstraints définis dans la spécification de votre pod, ou une ResourcePolicy configurée pour le pod

Notes d'utilisation

• Définissez topologyKey sur topology.kubernetes.io/zone.

• Le comportement de planification décrit dans cette rubrique ne s'applique pas lorsque :

  • L'annotation k8s.aliyun.com/eci-schedule-strategy: "VSwitchOrdered" est définie sur le pod (la planification multi-zones suit alors un ordre fixe de vSwitch).

  • L'annotation k8s.aliyun.com/eci-fail-strategy: "fail-fast" est définie sur le pod.

Choisir une approche

Deux mécanismes Kubernetes répondent à des objectifs différents :

Les deux exemples ci-dessous utilisent les mêmes champs requis par ECI : une tolération pour virtual-kubelet.io/provider et une affinité de nœud preferredDuringSchedulingIgnoredDuringExecution qui privilégie les nœuds Elastic Compute Service (ECS) par rapport aux nœuds virtuels. Seule la règle de répartition ou d'affinité change.

Exemple 1 : Répartir les pods uniformément entre les zones

Cet exemple crée un Deployment avec 10 réplicas répartis uniformément entre toutes les zones disponibles.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-pod-topology-spread
  labels:
    app: with-pod-topology-spread
spec:
  replicas: 10
  selector:
    matchLabels:
      app: with-pod-topology-spread
  template:
    metadata:
      labels:
        app: with-pod-topology-spread
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: with-pod-topology-spread
      tolerations:
        - key: "virtual-kubelet.io/provider"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
      - name: with-pod-topology-spread
        image: registry.k8s.io/pause:2.0
        resources:
          requests:
            cpu: "1"
            memory: "256Mi"

kubectl get po -lapp=with-pod-topology-spread \
  -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName \
  --no-headers | grep -v "<none>"

kubectl get po -lapp=with-pod-topology-spread \
  -o custom-columns=NODE:.spec.nodeName \
  --no-headers | grep -v "<none>" \
  | xargs -I {} kubectl get no {} -o json \
  | jq '.metadata.labels["topology.kubernetes.io/zone"]' \
  | sort | uniq -c

Exemple 2 : Déployer des pods dans une zone spécifique

Cet exemple crée un Deployment avec 3 réplicas qui doivent tous se trouver dans la même zone. Utilisez ce modèle lorsque la faible latence entre les pods est plus importante que la répartition entre les zones.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-affinity
  labels:
    app: with-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: with-affinity
  template:
    metadata:
      labels:
        app: with-affinity
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - with-affinity
            topologyKey: topology.kubernetes.io/zone
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      tolerations:
        - key: "virtual-kubelet.io/provider"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchExpressions:
    - key: topology.kubernetes.io/zone
      operator: In
      values:
      - cn-beijing-a

kubectl get po -lapp=with-affinity \
  -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName \
  --no-headers | grep -v "<none>"

kubectl get po -lapp=with-affinity \
  -o custom-columns=NODE:.spec.nodeName \
  --no-headers | grep -v "<none>" \
  | xargs -I {} kubectl get no {} -o json \
  | jq '.metadata.labels["topology.kubernetes.io/zone"]' \
  | sort | uniq -c

Répartition topologique stricte des pods ECI

Par défaut, kube-scheduler vise une distribution uniforme entre les zones, mais ne bloque pas le placement des pods lorsque la création ECI échoue dans certaines zones. Cela peut violer silencieusement la contrainte maxSkew.

Par exemple, avec maxSkew: 1 et trois zones (A, B, C), kube-scheduler déploie uniformément les pods d'une charge de travail entre toutes les zones. Si la création ECI échoue dans les zones B et C, les pods ne s'exécutent que dans la zone A, ce qui viole la contrainte spécifiée par maxSkew.

Activez la répartition topologique stricte des pods ECI pour garantir le respect de la contrainte. Avec le mode strict activé, kube-scheduler assigne d'abord un pod à chaque zone et retient les pods en attente jusqu'à ce que les pods planifiés soient créés. La figure ci-dessous montre l'état initial : un pod assigné à chaque zone, tous les autres étant en attente.

Même après la création du pod A1, kube-scheduler ne planifie pas le pod suivant, car si la zone B ou C échouait, la contrainte serait violée. Ce n'est qu'après la création du pod B1 que kube-scheduler planifie un pod dans la zone C. Les pods ombrés en vert indiquent les pods créés.

Pour désactiver la répartition stricte et permettre à kube-scheduler de planifier des pods indépendamment de la satisfaction des contraintes, définissez whenUnsatisfiable: ScheduleAnyway. Pour plus de détails sur les paramètres, consultez la section Définition de la contrainte de répartition.