Container Service for Kubernetes:Implementar distribuição de pods por zona e agendamento de afinidade para nós virtuais

Contexto

O Kubernetes oferece três primitivas de agendamento para posicionamento de pods no nível de zona:

Para consultar a documentação do Kubernetes sobre essas APIs, acesse Restrições de distribuição de topologia de pod, Atribuição de pods a nós, Afinidade de nó, Afinidade de pod e maxSkew.

Pré-requisitos

Antes de começar, verifique se:

• Existe um cluster ACK Serverless Pro que atende aos seguintes requisitos:

  • Versão 1,22 ou posterior do Kubernetes

  • Versão 2.10.0 ou posterior do componente ACK Virtual Node

  • Versão 5,9 ou posterior do componente kube-scheduler, com o recurso de agendamento de pods baseado em nó virtual ativado (consulte Ativar a política de agendamento de pods baseada em nó virtual para um cluster ACK)

• Várias zonas (vSwitches) estão configuradas no eci-profile para permitir o agendamento de pods em múltiplas zonas (consulte Configurar um eci-profile)

• O parâmetro nodeAffinity, podAffinity ou topologySpreadConstraints está configurado para os pods que você deseja agendar, ou os pods correspondem a uma política de recursos existente

Para agendar pods em nós virtuais baseados em ARM, adicione tolerâncias às contaminações do nó virtual no campo tolerations da especificação do pod.

Observações de uso

• Defina topologyKey como topology.kubernetes.io/zone.

• As anotações a seguir desativam os recursos de distribuição de zona e afinidade:

  Anotação	Efeito
  k8s.aliyun.com/eci-schedule-strategy: "VSwitchOrdered"	Ativa uma estratégia de agendamento multizona que segue uma ordem especificada de vSwitch
  k8s.aliyun.com/eci-fail-strategy: "fail-fast"	Define a política de tratamento de falhas do pod como fail-fast

Distribuir pods baseados em ECI entre zonas e configurar afinidades

Os exemplos a seguir utilizam um cluster ACK Serverless Pro executando o Kubernetes 1,22.

topologySpreadConstraints:
  - maxSkew: <integer>
    minDomains: <integer>               # Optional. Beta in Kubernetes 1.25 and later.
    topologyKey: <string>
    whenUnsatisfiable: <string>
    labelSelector: <object>
    matchLabelKeys: <list>              # Optional. Beta in Kubernetes 1.27 and later.
    nodeAffinityPolicy: [Honor|Ignore]  # Optional. Beta in Kubernetes 1.26 and later.
    nodeTaintsPolicy: [Honor|Ignore]    # Optional. Beta in Kubernetes 1.26 and later.

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:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: with-pod-topology-spread
      containers:
      - name: with-pod-topology-spread
        image: registry.k8s.io/pause:2.0
        resources:
          requests:
            cpu: "1"
            memory: "256Mi"

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
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

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:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - cn-beijing-a
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

Distribuição estrita de topologia de pods ECI

Por padrão, o kube-scheduler tenta distribuir os pods uniformemente entre as zonas, mas a criação de pods baseados em ECI pode falhar em algumas delas. Quando isso ocorre, a contagem de pods na zona com falha permanece em zero, o que pode violar a restrição maxSkew. O diagrama a seguir ilustra o resultado do agendamento com maxSkew: 1. Para mais informações sobre maxSkew, consulte maxSkew.

Se a criação de pods falhar na Zona B e na Zona C, dois pods executarão na Zona A e nenhum nas outras zonas, violando a restrição maxSkew: 1.

O ACK Serverless Pro oferece suporte à distribuição estrita de topologia de pods ECI para evitar esse cenário. Quando ativado, o kube-scheduler agenda primeiro um pod para cada zona e mantém os pods pendentes até que os pods agendados sejam criados com sucesso, conforme mostrado abaixo.

Mesmo após a criação do Pod A1, os pods pendentes permanecem retidos. Se o Pod B1 ou o Pod C1 falhar, agendar mais pods para a Zona A violaria o maxSkew. Somente após a criação do Pod B1 o kube-scheduler prossegue com o agendamento de um pod para a Zona C. Os pods sombreados em verde foram criados com sucesso.

Para desativar a distribuição estrita de topologia, defina whenUnsatisfiable como ScheduleAnyway. Para mais detalhes, consulte Definição de restrição de distribuição.Definição de Restrição de Distribuição