Container Service for Kubernetes:Déployer un CoreDNS non géré stable et performant

Évaluer la pression DNS

Avant d'ajuster le nombre de réplicas, évaluez la pression DNS. Des outils tels que DNSPerf permettent de mesurer la charge DNS.

Si vous ne pouvez pas mesurer directement la pression DNS, suivez ces recommandations :

• Exécutez au moins 2 pods CoreDNS avec des limites de ressources d'au moins 1 cœur et 1 Go de mémoire.

• Les QPS de résolution DNS évoluent linéairement avec la consommation CPU. Avec NodeLocal DNSCache, chaque cœur CPU gère plus de 10 000 requêtes par seconde (QPS). Les besoins en QPS varient considérablement selon les charges de travail ; surveillez donc l'utilisation maximale du CPU de chaque pod CoreDNS. Si un pod dépasse un cœur pendant les heures de pointe, augmentez le nombre de réplicas.

• En l'absence de données de charge, commencez avec 1 pod pour 8 nœuds comme référence de base.

Une fois que vous connaissez le nombre cible de réplicas, utilisez l'ajustement automatique (recommandé) ou mettez à l'échelle manuellement.

Configurer l'ajustement automatique (recommandé)

Le composant cluster-proportional-autoscaler ajuste les réplicas CoreDNS en fonction de la taille du cluster. Contrairement au HPA, il ne s'appuie pas sur les métriques CPU et n'effectue pas de réductions perturbatrices. Le ratio par défaut est de 1 pod pour 8 nœuds.

Formule de calcul du nombre de réplicas : replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)). Les paramètres min et max limitent le nombre entre 2 et 100.

Déployez l'autoscaler :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: dns-autoscaler
spec:
  selector:
    matchLabels:
      k8s-app: dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: dns-autoscaler
    spec:
      serviceAccountName: admin
      containers:
      - name: autoscaler
        image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
        resources:
          requests:
            cpu: "200m"
            memory: "150Mi"
        command:
        - /cluster-proportional-autoscaler
        - --namespace=kube-system
        - --configmap=dns-autoscaler
        - --nodelabels=type!=virtual-kubelet
        - --target=Deployment/coredns
        - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
        - --logtostderr=true
        - --v=9

Mettre à l'échelle manuellement

Pour définir un nombre spécifique de réplicas :

kubectl scale --replicas=<target> deployment/coredns -n kube-system # Replace <target> with the target number of pods.

Créer un pool de nœuds dédié

Lors de la création du pool de nœuds, respectez les consignes suivantes :

• CoreDNS sollicite intensivement le réseau, mais peu le calcul. Utilisez des instances optimisées pour le réseau, avec une taille recommandée de 4 cœurs et 8 Go de mémoire.

• Le pool de nœuds doit comporter au moins 2 nœuds, car CoreDNS exécute 2 pods par défaut.

• Ajoutez une taint et un libellé pour empêcher l'exécution d'autres pods sur ces nœuds. Par exemple, utilisez system-addon: system-addon comme paire clé-valeur de taint et comme libellé, avec Effect défini sur NoSchedule .

Consultez la section Créer et gérer des pools de nœuds .

Planifier les pods CoreDNS sur le pool de nœuds

1. Sur la page Add-ons , recherchez la carte CoreDNS et cliquez sur Configuration .

2. Dans la section NodeSelector , ajoutez le libellé du pool de nœuds dédié.

   Ne supprimez pas les libellés NodeSelector existants.

3. Dans la section Tolerations , ajoutez une tolérance correspondant à la taint du pool de nœuds.

   Ajoutez une entrée de tolérance dans Tolerations : définissez effect sur NoSchedule , key sur system-addon , operator sur Equal et value sur system-addon .

4. Cliquez sur OK , puis vérifiez que les pods CoreDNS s'exécutent sur les nœuds dédiés :

   kubectl -n kube-system get pod -o wide --show-labels | grep coredns

Anti-affinité de pod

CoreDNS utilise une règle d'anti-affinité requiredDuringSchedulingIgnoredDuringExecution pour empêcher deux pods CoreDNS de partager un nœud. Cela nécessite au moins 2 nœuds disposant de ressources suffisantes, à l'exclusion :

• k8s.aliyun.com: true — nœuds avec la mise à l'échelle automatique des nœuds activée

• type: virtual-kubelet — nœuds virtuels

• alibabacloud.com/lingjun-worker: true — nœuds Lingjun

La configuration d'affinité par défaut est la suivante :

      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              # virtual nodes have this label
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
              # lingjun worker nodes have this label
              - key: alibabacloud.com/lingjun-worker
                operator: NotIn
                values:
                - "true"
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              # autoscaled nodes have this label
              - key: k8s.aliyun.com
                operator: NotIn
                values:
                - "true"
            weight: 100
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: k8s-app
                operator: In
                values:
                - kube-dns
            topologyKey: kubernetes.io/hostname

Planification consciente de la topologie

Par défaut, CoreDNS utilise la planification consciente de la topologie pour répartir les pods entre les zones. Le paramètre whenUnsatisfiable: DoNotSchedule applique cette règle : les pods ne seront pas planifiés si la condition d'équilibre des zones ne peut pas être satisfaite.

Pour que cela fonctionne de manière fiable :

• Votre cluster doit disposer de nœuds dans au moins 2 zones différentes, chacune contenant au moins 1 nœud avec suffisamment de ressources pour CoreDNS.

• Tous les nœuds doivent posséder le libellé topology.kubernetes.io/zone (appliqué par défaut). Des libellés manquants ou incohérents entraînent des échecs de planification ou une répartition inégale.

• Mettez à jour votre cluster vers la version v1.27 ou ultérieure et CoreDNS vers la version v1.12.1.3 ou ultérieure. Les versions antérieures du cluster ne prennent pas en charge matchLabelKeys ; ainsi, une mise à jour progressive de CoreDNS peut aboutir à une répartition inégale des pods entre les zones, voire laisser certaines zones non couvertes. Consultez la configuration matchLabelKeys décrite ci-dessous.

Les versions de CoreDNS antérieures à la v1.12.1.3 utilisent cette contrainte de répartition topologique :

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

CoreDNS v1.12.1.3 et versions ultérieures corrige ce problème grâce à matchLabelKeys (Kubernetes v1.27+) :

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  matchLabelKeys:
  - pod-template-hash
  nodeTaintsPolicy: Honor
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

L'ajout de matchLabelKeys: [pod-template-hash] limite la contrainte au ReplicaSet actuel, de sorte que les mises à jour progressives répartissent les pods uniformément entre les zones.