Container Service for Kubernetes:DNS best practices

Les bonnes pratiques DNS couvrent les optimisations côté client et côté serveur :

• Côté client, vous pouvez optimiser les requêtes de résolution de noms de domaine pour réduire la latence et minimiser les échecs de résolution en utilisant des images de conteneur appropriées, des systèmes d'exploitation de nœud adaptés et NodeLocal DNSCache.

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

  • Comprendre les configurations 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, vous pouvez identifier les anomalies DNS et localiser rapidement leurs causes racines en surveillant l'état opérationnel de CoreDNS. Vous pouvez également ajuster le déploiement de CoreDNS pour améliorer la haute disponibilité et le débit en requêtes par seconde (QPS).

  • Surveiller l'état opérationnel de CoreDNS

    • Métriques

    • Journaux

    • Distribution des événements Kubernetes

  • Assurer la haute disponibilité de CoreDNS

    • Évaluer la pression sur le composant CoreDNS

    • Ajuster le nombre de pods CoreDNS

    • Ajuster les spécifications des pods CoreDNS

    • Planifier les pods CoreDNS

  • Optimiser les configurations CoreDNS

    • Désactiver l'affinité de session pour le service kube-dns

    • Désactiver le plugin autopath

    • Configurer l'arrêt gracieux pour CoreDNS

    • Configurer le protocole par défaut pour le plugin forward et les serveurs DNS VPC en amont

    • Configurer le plugin ready pour les sondes de readiness

La résolution DNS est l'une des opérations réseau les plus fréquentes dans un cluster Kubernetes. Beaucoup de ces requêtes peuvent être optimisées ou évitées pour réduire la latence et la charge sur l'infrastructure DNS. Vous pouvez optimiser les requêtes de résolution de noms de domaine de plusieurs façons :

• (Recommandé) Utilisez des pools de connexions : lorsqu'une application conteneurisée interroge fréquemment un autre service, utilisez un pool de connexions pour mettre en cache les connexions actives vers les services en amont en mémoire. Cela élimine la surcharge liée à la résolution DNS et aux handshakes TCP pour chaque requête.

• Utilisez un mode asynchrone ou de polling long pour obtenir les adresses IP associées à un nom de domaine.

• Utilisez la mise en cache DNS :

  • (Recommandé) Si votre application ne peut pas être modifiée pour utiliser un pool de connexions, envisagez de mettre en cache les résultats de résolution DNS côté application. Pour plus d'informations, consultez Utiliser NodeLocal DNSCache.

  • Si vous ne pouvez pas utiliser NodeLocal DNSCache, vous pouvez utiliser le cache intégré du Name Service Cache Daemon (NSCD) dans vos conteneurs. Pour plus d'informations, consultez Utiliser NSCD dans les clusters Kubernetes.

• Optimisez le fichier resolv.conf : en raison des mécanismes des paramètres ndots et search dans le fichier resolv.conf, la manière dont vous écrivez les noms de domaine dans un conteneur détermine l'efficacité de la résolution de noms. Pour plus d'informations sur les mécanismes des paramètres ndots et search, consultez Configuration de la politique DNS et résolution de noms de domaine.

• Optimisez les configurations de noms de domaine : lorsqu'une application dans un conteneur accède à un nom de domaine, configurez-la comme suit pour minimiser les tentatives de résolution et réduire la latence de résolution.

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

  • Pour accéder à un service dans un namespace différent depuis un pod, utilisez <service-name>.<namespace-name>, où namespace-name est le namespace où réside le service.

  • Lorsqu'un pod accède à un nom de domaine externe, utilisez un nom de domaine entièrement qualifié (FQDN), qui se termine par un point (.), pour éviter plusieurs recherches DNS invalides causées par l'ajout de domaines de la liste search. Par exemple, pour accéder à www.aliyun.com, utilisez son FQDN www.aliyun.com..

    • Dans les clusters exécutant Kubernetes 1.22 ou une version ultérieure, vous pouvez configurer le domaine de recherche comme un simple point (.) pour obtenir un effet similaire (voir Issue 125883) :

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace with the actual ClusterIP of your CoreDNS Service.
        searches:
        - .
        - default.svc.cluster.local  ## Note: Replace default with the actual namespace.
        - svc.cluster.local
        - cluster.local

      Après avoir appliqué la configuration précédente, le fichier /etc/resolv.conf dans le pod est configuré comme suit :

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

      Le premier domaine de recherche est « . », ce qui amène le résolveur à traiter le domaine cible comme un FQDN. Le résolveur tente d'abord de résoudre le nom de domaine tel quel, en ignorant les expansions inutiles des domaines de recherche.

      Important

      Vous devez définir dnsPolicy sur None pour que la configuration précédente 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 with the actual ClusterIP of your CoreDNS Service.
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

Vous pouvez utiliser l'une des méthodes suivantes pour atténuer l'impact du défaut IPVS :

• Utilisez NodeLocal DNSCache. Pour plus d'informations, consultez Utiliser NodeLocal DNSCache.

• Modifiez la période de délai d'expiration pour la persistance de session UDP IPVS dans kube-proxy. Pour plus d'informations, consultez Comment modifier la période de délai d'expiration pour la persistance de session UDP IPVS dans kube-proxy ?.

CoreDNS offre une bonne rétrocompatibilité avec les versions de Kubernetes. Maintenez CoreDNS à jour vers la dernière version stable. La page Modules complémentaires de la console ACK vous permet d'installer, de mettre à niveau et de configurer CoreDNS. Vérifiez l'état du composant CoreDNS sur la page Modules complémentaires. Si une mise à niveau est disponible, planifiez-la pendant les heures creuses.

• Pour plus d'informations sur la mise à niveau de CoreDNS, consultez Mise à niveau automatique pour CoreDNS non managé.

• Pour les notes de publication de CoreDNS, consultez CoreDNS.

Les versions de CoreDNS antérieures à la v1.7.0 présentent plusieurs risques potentiels, notamment :

• Lorsque la connectivité entre CoreDNS et le serveur API est anormale, par exemple en raison de redémarrages, de migrations ou de fluctuations réseau du serveur API, CoreDNS peut redémarrer car il ne parvient pas à écrire les journaux d'erreurs. Pour plus d'informations, consultez Set klog's logtostderr flag.

• CoreDNS consomme de la mémoire supplémentaire au démarrage. La limite de mémoire par défaut peut déclencher des problèmes de manque de mémoire (OOM) dans les clusters à grande échelle. Dans les cas graves, cela peut entraîner une boucle de redémarrage des pods CoreDNS et empêcher leur récupération. Pour plus d'informations, consultez CoreDNS uses a lot memory during initialization phase.

• CoreDNS présente plusieurs problèmes pouvant affecter la résolution des noms de domaine des services headless et des noms de domaine externes au cluster. Pour plus d'informations, consultez plugin/kubernetes: handle tombstones in default processor et Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• Si un nœud de cluster devient anormal, la politique de tolérance par défaut dans certaines versions antérieures de CoreDNS peut entraîner la planification de pods CoreDNS sur le nœud anormal. Ces pods ne peuvent pas être expulsés automatiquement, ce qui entraîne des échecs de résolution DNS.

La version minimale recommandée de CoreDNS varie en fonction de la version Kubernetes du cluster.

Métriques

CoreDNS expose des métriques de santé, y compris les résultats de résolution, via une interface Prometheus standard. Cela permet de détecter les anomalies sur le serveur CoreDNS et même sur les serveurs DNS en amont.

Managed Service for Prometheus fournit des tableaux de bord de surveillance des métriques et des règles d'alerte intégrés pour CoreDNS. Vous pouvez activer Prometheus et ses fonctionnalités de tableau de bord dans la console ACK. Pour plus d'informations, consultez la rubrique Surveiller le composant CoreDNS.

Si vous utilisez une instance Prometheus autogérée pour surveiller votre cluster Kubernetes, vous pouvez observer les métriques pertinentes dans Prometheus et configurer des alertes pour les indicateurs clés. Pour plus d'informations, consultez la documentation officielle de CoreDNS pour Prometheus.

Journaux

En cas d'anomalie DNS, les journaux CoreDNS peuvent vous aider à diagnostiquer rapidement la cause racine. Nous vous recommandons d'activer la journalisation de la résolution des noms de domaine CoreDNS et de collecter ses journaux avec Log Service. Pour plus d'informations, consultez la rubrique Analyser et surveiller les journaux CoreDNS.

Distribution des événements Kubernetes

À partir de la version CoreDNS v1.9.3.6-32932850-aliyun, vous pouvez activer le plugin k8s_event pour distribuer les journaux CoreDNS critiques en tant qu'événements Kubernetes vers l'Event Center. Pour plus d'informations sur le k8s_event plugin, consultez k8s_event.

Cette fonctionnalité est activée par défaut lors des nouveaux déploiements de CoreDNS. Si vous effectuez une mise à niveau depuis une version antérieure vers CoreDNS v1.9.3.6-32932850-aliyun ou ultérieure, vous devez modifier manuellement le fichier de configuration pour l'activer.

1. Exécutez la commande suivante pour ouvrir 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
           }
           // Start of addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, and warning statuses.
           }
           // End of addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // ... (remaining content omitted)
       }

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

Évaluer la pression sur le composant CoreDNS

Vous pouvez effectuer un test de charge DNS dans le cluster pour évaluer la pression sur le composant. De nombreux outils open source, notamment DNSPerf, peuvent vous y aider. Si vous ne parvenez pas à évaluer avec précision la pression DNS dans votre cluster, suivez ces recommandations.

• Définissez toujours le nombre de pods CoreDNS à au moins 2, avec une limite de ressources d'au moins 1 cœur et 1 Go pour un seul pod.

• Le débit QPS (requêtes par seconde) de résolution des noms de domaine de CoreDNS est positivement corrélé à sa consommation de CPU. Avec NodeLocal DNSCache activé, chaque cœur de CPU peut prendre en charge plus de 10 000 QPS. La demande en QPS pour les requêtes de noms de domaine varie considérablement selon les types de services. Vous pouvez observer l'utilisation maximale du CPU de chaque pod CoreDNS. Si un pod utilise plus d'un cœur de CPU pendant les heures de pointe, nous vous recommandons d'augmenter le nombre de réplicas CoreDNS. Si vous ne pouvez pas déterminer l'utilisation maximale du CPU, vous pouvez utiliser de manière conservatrice un ratio de 1:8 entre les pods et les nœuds du cluster. Autrement dit, pour chaque groupe de 8 nœuds de cluster ajoutés, ajoutez un pod CoreDNS.

Ajuster le nombre de pods CoreDNS

Le nombre de pods CoreDNS détermine directement les ressources informatiques que CoreDNS peut utiliser. Vous pouvez ajuster le nombre de pods CoreDNS en fonction de votre évaluation.

• Ajustement automatique basé sur la politique recommandée

  Vous pouvez déployer le composant suivant dns-autoscaler. Il ajuste automatiquement le nombre de pods CoreDNS en temps réel selon la politique recommandée (un ratio de 1:8 entre les pods et les nœuds du cluster). Le nombre de pods est calculé à l'aide de la formule suivante : replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)), et est limité par les paramètres 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

• Ajustement manuel

  Vous pouvez exécuter la commande suivante pour ajuster manuellement le nombre de pods CoreDNS.

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

• N'utilisez pas la mise à l'échelle automatique des charges de travail

  Bien que les fonctionnalités de mise à l'échelle automatique des charges de travail telles que Horizontal Pod Autoscaler (HPA) et CronHPA puissent également ajuster automatiquement le nombre de pods, elles effectuent des opérations de mise à l'échelle fréquentes. En raison des exceptions de résolution qui se produisent lors de la réduction du nombre de pods, n'utilisez pas la mise à l'échelle automatique des charges de travail pour contrôler le nombre de pods CoreDNS.

Ajuster les spécifications des pods CoreDNS

Une autre façon d'ajuster les ressources CoreDNS consiste à modifier les spécifications des pods. Dans un cluster managé ACK Pro, la limite de mémoire par défaut pour les pods CoreDNS est de 2Gi, sans limite de CPU. Définissez la limite de CPU à 4096m, avec un minimum de 1024m. Vous pouvez ajuster la configuration des pods CoreDNS dans la console.

Planifier les pods CoreDNS

Nous vous recommandons de déployer les pods CoreDNS sur différentes zones de disponibilité et différents nœuds de cluster afin d'éviter les pannes liées à un seul nœud ou à une seule zone de disponibilité. Les versions du composant CoreDNS antérieures à la v1.8.4.3 disposent d'une politique d'anti-affinité souple par défaut au niveau du nœud, ce qui peut entraîner le déploiement de certains ou de tous les pods sur le même nœud si les ressources sont insuffisantes. Si cela se produit, supprimez les pods pour déclencher une replanification ou mettez à niveau le composant vers la dernière version. Les versions du composant CoreDNS antérieures à la v1.8 ne sont plus maintenues et doivent être mises à niveau dès que possible.

Les nœuds de cluster sur lesquels CoreDNS s'exécute ne doivent pas avoir leur CPU ou leur mémoire entièrement utilisés, car cela affecte le débit QPS et la latence de réponse de la résolution des noms de domaine. Lorsque les conditions des nœuds du cluster le permettent, envisagez d'utiliser des paramètres personnalisés pour planifier CoreDNS sur des nœuds de cluster dédiés afin de fournir un service de résolution de noms de domaine stable.

Les configurations CoreDNS par défaut déployées avec les versions antérieures des clusters Kubernetes peuvent présenter certains risques. Vérifiez et optimisez-les comme suit :

• Désactiver l'affinité de session pour le service kube-dns

• Désactiver le plugin autopath

• Configurer l'arrêt gracieux pour CoreDNS

• Configurer le protocole par défaut pour le plugin forward et les serveurs DNS VPC en amont

• Configurer le plugin ready pour les sondes de readiness

Désactiver l'affinité de session pour kube-dns

Désactiver le plug-in autopath

Certaines versions antérieures de CoreDNS activaient le plug-in autopath, ce qui peut provoquer des erreurs de résolution dans certains cas limites. Vérifiez s'il est activé et modifiez le fichier de configuration pour le désactiver. Pour plus d'informations, consultez la rubrique Autopath.

1. Exécutez la commande kubectl -n kube-system edit configmap coredns pour ouvrir le fichier de configuration de CoreDNS.

2. Supprimez la ligne autopath @kubernetes et enregistrez le fichier.

3. Vérifiez l'état opérationnel et les journaux des pods CoreDNS. Si les journaux contiennent le mot reload, la modification a été effectuée avec succès.

Configurer l'arrêt gracieux

Le mécanisme lameduck de CoreDNS permet un arrêt gracieux. Il garantit que lorsque CoreDNS doit s'arrêter ou redémarrer, les requêtes en cours sont traitées jusqu'à leur achèvement sans interruption brutale. Le fonctionnement de lameduck est le suivant :

• Lorsqu'un processus CoreDNS est sur le point de se terminer, 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'à ce qu'elles soient toutes terminées ou que le délai d'expiration lameduck soit dépassé.

Configurer le protocole par défaut pour le plug-in forward

NodeLocal DNSCache utilise TCP pour communiquer avec CoreDNS. CoreDNS communique ensuite avec les serveurs DNS amont en utilisant le même protocole que la requête entrante. Par conséquent, par défaut, les requêtes émises par les conteneurs métier pour résoudre des noms de domaine externes au cluster transitent par NodeLocal DNSCache et CoreDNS, puis atteignent finalement les serveurs DNS VPC (par défaut, 100.100.2.136 et 100.100.2.138 sur les instances ECS) via TCP.

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

Configurer le plug-in ready

Les versions de CoreDNS ultérieures à la 1.5.0 doivent avoir le plug-in ready configuré pour activer les sondes de readiness.

1. Exécutez la commande suivante pour ouvrir le fichier de configuration de CoreDNS.

   kubectl -n kube-system edit configmap/coredns

2. Vérifiez si le fichier contient la ligne ready. Si ce n'est pas le cas, ajoutez la ligne ready, appuyez sur Échap, saisissez :wq!, puis appuyez sur Entrée pour enregistrer le fichier de configuration modifié et quitter le mode édition.

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # If this line does not exist, add it. Make sure that the indentation is consistent 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 opérationnel et les journaux des pods CoreDNS. Si les journaux contiennent le mot reload, la modification a été effectuée avec succès.

Améliorer les performances avec le plug-in multisocket

CoreDNS v1.12.1 a introduit le plug-in multisocket. L'activation de ce plug-in permet à CoreDNS d'utiliser plusieurs sockets pour écouter sur le même port, améliorant ainsi les performances de CoreDNS dans les scénarios à forte utilisation du CPU. Pour une description détaillée du plug-in, consultez la documentation communautaire.

Vous devez activer multisocket à l'aide de la 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.

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

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

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

Pour déterminer la configuration optimale, nous vous recommandons de tester les QPS et la charge avec différents paramètres.

Si vous ne spécifiez pas NUM_SOCKETS, la valeur par défaut est GOMAXPROCS, qui est égale à la limite CPU du pod CoreDNS. Si la limite CPU du pod n'est pas définie, la valeur est égale au nombre de cœurs CPU du nœud sur lequel le pod s'exécute.