Container Service for Kubernetes:Best practices for DNS in Kubernetes clusters

Les bonnes pratiques DNS couvrent les aspects client et serveur :

• Côté client, réduisez la latence de résolution en optimisant les requêtes de noms de domaine. Limitez les anomalies de résolution grâce à des images de conteneur appropriées, des systèmes d'exploitation de nœuds adaptés et NodeLocal DNSCache.

  • Optimiser les requêtes de résolution de noms de domaine

  • Comprendre la configuration DNS dans les conteneurs

  • Éviter les délais d'expiration intermittents de résolution DNS causés par des défauts IPVS

  • Utiliser NodeLocal DNSCache

  • Utiliser une version adaptée de CoreDNS

• Côté serveur CoreDNS, surveillez l'état d'exécution afin de détecter les anomalies DNS et d'en identifier la cause racine. Améliorez la haute disponibilité de CoreDNS et son débit de requêtes par seconde (QPS) en ajustant les paramètres de déploiement.

  • Surveiller l'état d'exécution de CoreDNS

    • Métriques de surveillance

    • Journaux opérationnels

    • Transmission des événements Kubernetes

  • Garantir la haute disponibilité de CoreDNS

    • Évaluer la pression sur le composant complémentaire CoreDNS

    • Ajuster le nombre de pods CoreDNS

    • Ajuster les spécifications des pods CoreDNS

    • Planifier les pods CoreDNS

  • Optimiser la configuration de CoreDNS

    • Désactiver les paramètres d'affinité du service kube-dns

    • Désactiver le plugin Autopath

    • Configurer l'arrêt progressif de CoreDNS

    • Définir le protocole par défaut du plugin Forward pour communiquer avec les serveurs DNS VPC en amont

    • Configurer le plugin de sonde de disponibilité Ready

La résolution DNS figure parmi les activités réseau les plus fréquentes dans Kubernetes. Vous pouvez optimiser ou éviter de nombreuses requêtes :

• (Recommandé) Utilisez des pools de connexions. Si une application conteneurisée accède fréquemment à un autre service, mettez en cache les connexions en amont dans la mémoire afin d'éviter la résolution DNS et l'établissement TCP lors de chaque accès.

• Recourez au polling asynchrone ou long pour obtenir l'adresse IP associée à un nom de domaine DNS.

• Activez la mise en cache DNS :

  • (Recommandé) Si votre application ne peut pas utiliser de pools de connexions, mettez en cache les résultats de résolution DNS côté application ou utilisez NodeLocal DNSCache.

  • Si NodeLocal DNSCache n'est pas disponible, mettez en cache les requêtes DNS à l'intérieur du conteneur avec Name Service Cache Daemon (NSCD). Consultez Utiliser NSCD dans les clusters Kubernetes.

• Optimisez le fichier resolv.conf : les paramètres ndots et search influencent l'efficacité de la résolution selon la syntaxe des noms de domaine dans les configurations de conteneur. Reportez-vous à Configuration de la politique DNS et résolution de noms de domaine pour plus de détails sur ndots et search.

• Optimisez la configuration des noms de domaine afin de minimiser les tentatives de résolution et de réduire le temps de traitement :

  • Pour accéder à un Service dans le même namespace, utilisez <service-name>, où service-name correspond au nom du Service.

  • Pour accéder à un Service entre namespaces, utilisez <service-name>.<namespace-name>, où namespace-name désigne le namespace du Service.

  • Pour les domaines externes, employez des noms de domaine pleinement qualifiés (FQDN). Ajoutez un point final (.) pour indiquer une adresse absolue et éviter toute concaténation invalide avec les domaines search. Par exemple, préférez www.aliyun.com. à www.aliyun.com.

    • Dans les clusters version 1.33 ou ultérieure, définissez le domaine de recherche sur un simple "." (voir 125883) pour obtenir un effet similaire :

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
        searches:
        - .
        - default.svc.cluster.local  ## Replace "default" with your namespace name
        - svc.cluster.local
        - cluster.local

      Après application de cette configuration, le fichier /etc/resolv.conf du pod se présente comme suit :

      search . default.svc.cluster.local svc.cluster.local cluster.local
      nameserver 192.168.0.10

      Un "." placé en premier domaine de recherche traite toutes les requêtes de domaine comme des FQDN et les résout directement sans tentatives de recherche inutiles.

      Important

      Définissez dnsPolicy sur None pour que cette configuration prenne effet.

      Exemple complet de charge de travail

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: nginx
        name: nginx
        namespace: default
      spec:
        progressDeadlineSeconds: 600
        replicas: 3
        revisionHistoryLimit: 10
        selector:
          matchLabels:
            app: nginx
        strategy:
          rollingUpdate:
            maxSurge: 25%
            maxUnavailable: 25%
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
              imagePullPolicy: Always
              name: nginx
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: None
            dnsConfig:
              nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

Atténuez l'impact des défauts IPVS en appliquant l'une des méthodes suivantes :

• Utiliser NodeLocal DNSCache.

• Modifiez le délai d'expiration de persistance de session UDP IPVS dans kube-proxy. Consultez Comment modifier le délai d'expiration de persistance de session UDP IPVS dans kube-proxy ?.

CoreDNS assure une bonne compatibilité ascendante entre les différentes versions de Kubernetes. Maintenez CoreDNS à une version récente et stable. La page Gestion des composants de la console ACK offre des fonctionnalités d'installation, de mise à niveau et de configuration. Surveillez l'état des composants et mettez à niveau CoreDNS pendant les heures creuses lorsqu'une mise à jour est disponible.

• Consultez Mise à niveau automatique pour CoreDNS non managé pour les instructions de mise à niveau.

• Reportez-vous aux notes de version de CoreDNS.

Les versions de CoreDNS antérieures à v1.7.0 présentent des risques connus, notamment :

• Si la connectivité entre CoreDNS et le serveur API tombe en panne lors d'un redémarrage du serveur API, d'une migration ou d'une instabilité réseau, CoreDNS peut redémarrer car il ne parvient pas à écrire les journaux d'erreurs. Consultez Set klog's logtostderr flag.

• CoreDNS consomme davantage de mémoire au démarrage. La limite de mémoire par défaut peut déclencher des problèmes de mémoire insuffisante (OOM) dans les grands clusters, provoquant des redémarrages répétés des pods CoreDNS sans récupération possible. Consultez CoreDNS uses a lot of memory during initialization phase.

• CoreDNS comporte des problèmes connus affectant les domaines Headless Service et la résolution de domaines externes. Consultez plugin/kubernetes: handle tombstones in default processor et Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• En cas de défaillance d'un nœud, les anciennes versions de CoreDNS peuvent déployer des pods sur ce nœud anormal en raison des politiques de tolérance par défaut. Ces pods risquent de ne pas être expulsés automatiquement, ce qui entraîne des échecs de résolution de domaines.

La version minimale recommandée de CoreDNS dépend de la version du cluster Kubernetes :

Métriques de surveillance

CoreDNS expose des métriques de santé, telles que les résultats de résolution, via une interface Prometheus standard afin de faciliter la détection d'anomalies dans CoreDNS ou sur les serveurs DNS en amont.

Prometheus pour ACK intègre des métriques de surveillance CoreDNS natives ainsi que des règles d'alerte. Activez Prometheus et Dashboard dans la console Container Service for Kubernetes. Consultez Surveillance du composant CoreDNS.

Si vous utilisez une instance Prometheus auto-gérée, observez les métriques pertinentes et configurez des alertes pour les plus critiques. Reportez-vous à la documentation officielle Prometheus de CoreDNS.

Journaux opérationnels

Exploitez les journaux CoreDNS pour diagnostiquer la cause racine lors d'anomalies DNS. Activez les journaux de résolution de domaines ainsi que la collecte de journaux SLS. Consultez Analyser et surveiller les journaux CoreDNS.

Transmission des événements Kubernetes

À partir de CoreDNS v1.9.3.6-32932850-aliyun, activez le plugin k8s_event pour transmettre les journaux critiques de CoreDNS sous forme d'événements Kubernetes vers Event Hub. Consultez la documentation du plugin k8s_event.

Cette fonctionnalité est activée par défaut sur les nouvelles instances CoreDNS. Lors d'une mise à niveau depuis une version ancienne, modifiez manuellement le fichier de configuration pour l'activer.

1. Ouvrez le fichier de configuration CoreDNS :

   kubectl -n kube-system edit configmap/coredns

2. Ajoutez les plugins kubeAPI et k8s_event.

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
           // Begin addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, or warning levels.
           }
           // End addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // Omitted below.
       }

3. Vérifiez l'état et les journaux des pods CoreDNS. Si les journaux contiennent le mot reload, la modification a réussi.

Évaluer la pression sur le composant complémentaire CoreDNS

Exécutez des tests de charge DNS pour évaluer la pression exercée sur le composant complémentaire CoreDNS. Des outils open source tels que DNSPerf peuvent vous y aider. Si vous ne parvenez pas à évaluer précisément la pression DNS, suivez ces recommandations :

• Déployez au moins deux pods CoreDNS, chacun disposant de limites de ressources d'au moins 1 cœur CPU et 1 Go de mémoire.

• La capacité QPS de CoreDNS est corrélée à l'utilisation CPU. Avec NodeLocal DNSCache, chaque cœur CPU prend en charge plus de 10 000 QPS. Le trafic DNS lié aux charges de travail métier varie considérablement. Surveillez l'utilisation CPU maximale par pod CoreDNS et augmentez le nombre de réplicas lorsque l'utilisation dépasse un cœur en période de pointe. Si la charge maximale est inconnue, déployez un pod CoreDNS pour huit nœuds de cluster comme mesure conservatrice.

Ajuster le nombre de pods CoreDNS

Le nombre de pods CoreDNS détermine directement les ressources de calcul disponibles. Ajustez-le en fonction de votre évaluation.

• Ajustement automatique du nombre de pods selon les politiques recommandées

  Déployez le dns-autoscaler suivant. Il ajuste le nombre de pods CoreDNS en temps réel selon un ratio d'un pod pour huit nœuds de cluster. Nombre de réplicas : replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)), contraint par les limites max et min.

  dns-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

• Ajustements manuels

  Ajustez manuellement le nombre de pods CoreDNS :

  kubectl scale --replicas={target} deployment/coredns -n kube-system # Replace {target} with the desired pod count

• Évitez la mise à l'échelle automatique des charges de travail

  Les mécanismes de mise à l'échelle automatique des charges de travail tels que HPA (Horizontal Pod Autoscaling) ou CronHPA déclenchent des opérations de mise à l'échelle fréquentes. En raison des anomalies de résolution survenant lors de la réduction des pods, n'utilisez pas la mise à l'échelle automatique des charges de travail pour les pods CoreDNS.

Ajuster les spécifications des pods CoreDNS

Modifiez les spécifications des pods pour ajuster les ressources CoreDNS. Dans les clusters managés ACK Pro, les pods CoreDNS ont une limite de mémoire par défaut de 2Gi et aucune limite CPU. Définissez la limite CPU à 4096 m, avec un minimum de 1024 m. Ajustez la configuration des pods CoreDNS dans la console.

Planifier les pods CoreDNS

Répartissez les pods CoreDNS sur plusieurs zones et nœuds afin d'éviter les pannes liées à un nœud ou une zone unique. Les versions de CoreDNS antérieures à v1.8.4.3 utilisent par défaut une anti-affinité de nœud faible, ce qui peut placer tous les pods sur le même nœud lorsque les ressources sont insuffisantes. Supprimez les pods pour déclencher une nouvelle planification ou mettez à niveau vers la dernière version du composant. Les versions de CoreDNS antérieures à v1.8 ne sont plus maintenues. Procédez à la mise à niveau dès que possible.

Évitez de déployer CoreDNS sur des nœuds dont le CPU ou la mémoire sont saturés, car cela affecte le QPS DNS et la latence de réponse. Utilisez des paramètres personnalisés pour planifier CoreDNS sur des nœuds dédiés afin de garantir une résolution stable des noms de domaine.

Les configurations CoreDNS par défaut issues d'anciennes versions de Kubernetes peuvent présenter des risques. Vérifiez-les et optimisez-les comme suit :

• Désactiver les paramètres d'affinité du service kube-dns

• Désactiver le plugin Autopath

• Configurer l'arrêt progressif de CoreDNS

• Définir le protocole par défaut du plugin Forward pour communiquer avec les serveurs DNS VPC en amont

• Configurer le plugin de sonde de disponibilité Ready

Désactiver les paramètres d'affinité du service kube-dns

Désactiver le plugin Autopath

Certaines anciennes versions de CoreDNS ont le plugin Autopath activé, ce qui peut produire des résultats de résolution incorrects dans des scénarios extrêmes. Vérifiez si le plugin est activé et désactivez-le en modifiant le fichier de configuration. Consultez Autopath.

1. Ouvrez le fichier de configuration CoreDNS avec kubectl -n kube-system edit configmap coredns.

2. Supprimez la ligne autopath @kubernetes et enregistrez la modification.

3. Vérifiez l'état et les journaux des pods CoreDNS. Si les journaux contiennent le mot reload, la modification a réussi.

Configurer l'arrêt progressif de CoreDNS

Le mécanisme lameduck de CoreDNS permet un arrêt progressif. Lorsque CoreDNS s'arrête ou redémarre, les requêtes en cours se terminent normalement au lieu d'être interrompues brutalement. Le mécanisme lameduck fonctionne comme suit :

• Lorsque CoreDNS s'arrête, il passe en mode Lameduck.

• En mode lameduck, CoreDNS cesse d'accepter de nouvelles requêtes mais continue de traiter les requêtes existantes jusqu'à leur achèvement ou l'expiration du délai lameduck.

Définir le protocole par défaut du plugin Forward pour communiquer avec les serveurs DNS VPC en amont

NodeLocal DNSCache communique avec CoreDNS via TCP. CoreDNS utilise le même protocole que les requêtes entrantes lorsqu'il communique avec les serveurs DNS en amont. Par défaut, les requêtes de résolution de domaines externes provenant des conteneurs d'application transitent par NodeLocal DNSCache et CoreDNS, puis atteignent les serveurs DNS VPC (100.100.2.136 et 100.100.2.138) via TCP.

# Before modification
forward . /etc/resolv.conf
# After modification
forward . /etc/resolv.conf {
  prefer_udp
}

Configurer le plugin de sonde de disponibilité Ready

Les versions de CoreDNS postérieures à 1.5.0 nécessitent le plugin ready pour activer les sondes de disponibilité.

1. Ouvrez le fichier de configuration CoreDNS :

   kubectl -n kube-system edit configmap/coredns

2. Vérifiez la présence de la ligne ready. Si elle est absente, ajoutez ready. Appuyez sur Échap, tapez :wq!, puis appuyez sur Entrée pour enregistrer la modification et quitter.

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # Add this line if missing, ensuring consistent indentation with Kubernetes.
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. Vérifiez l'état et les journaux des pods CoreDNS. Si les journaux contiennent le mot reload, la modification a réussi.

Configurer le plugin multisocket pour améliorer les performances de résolution CoreDNS

CoreDNS v1.12.1 a introduit le plugin multisocket. Lorsqu'il est activé, CoreDNS utilise plusieurs sockets pour écouter sur le même port, ce qui améliore les performances dans les scénarios à forte utilisation CPU. Consultez la documentation communautaire.

Activez multisocket dans le ConfigMap coredns :

.:53 {
        ...
        prometheus :9153
        multisocket [NUM_SOCKETS]
        forward . /etc/resolv.conf
        ...
}

NUM_SOCKETS spécifie le nombre de sockets écoutant sur le même port.

Alignez NUM_SOCKETS sur l'utilisation CPU estimée, les limites de ressources CPU et les ressources disponibles du cluster. Par exemple :

• Si CoreDNS consomme 4 cœurs en période de pointe et que 8 cœurs sont disponibles, définissez NUM_SOCKETS sur 2.

• Si CoreDNS consomme 8 cœurs en période de pointe et que 64 cœurs sont disponibles, définissez NUM_SOCKETS sur 8.

Testez différents paramètres et mesurez le QPS ainsi que la charge afin de déterminer la configuration optimale.

Si vous ne spécifiez pas NUM_SOCKETS, CoreDNS utilise GOMAXPROCS par défaut, ce qui correspond à la limite CPU du pod CoreDNS ou au nombre de cœurs CPU du nœud lorsqu'aucune limite n'est définie.