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 afin de réduire la latence et de 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 la 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

  • Garantir 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 de 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. Il est possible d'optimiser ou d'éviter bon nombre de ces requêtes afin de réduire la latence et la charge sur l'infrastructure DNS. Voici plusieurs méthodes pour optimiser les requêtes de résolution de noms de domaine :

• (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 la résolution DNS côté application. Pour plus d'informations, consultez Utiliser NodeLocal DNSCache.

  • Si vous ne pouvez pas utiliser NodeLocal DNSCache, vous pouvez exploiter le cache intégré du démon de cache de service de noms (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 du fichier resolv.conf , la manière dont vous écrivez les noms de domaine dans un conteneur détermine l'efficacité de la résolution. 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.

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

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

  • Lorsqu'un pod accède à un nom de domaine externe, utilisez un nom de domaine pleinement qualifié (FQDN) se terminant par un point (.) afin d'éviter plusieurs recherches DNS invalides causées par l'ajout de domaines issus 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 sous la forme d'un seul 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 indique au résolveur de 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 durée d'expiration de la persistance de session UDP IPVS dans kube-proxy. Pour plus d'informations, consultez Comment modifier la durée d'expiration de 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 Add-ons 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 Add-ons. 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 davantage de mémoire au démarrage. La limite de mémoire par défaut peut déclencher des problèmes d'épuisement de la mémoire (OOM) dans les clusters à grande échelle. Dans les cas graves, cela peut entraîner un cycle de redémarrage des pods CoreDNS, les empêchant de récupérer. 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 des pods CoreDNS sur le nœud anormal. Ces pods ne peuvent pas être expulsés automatiquement, ce qui provoque des échecs de résolution DNS.

La version minimale recommandée de CoreDNS varie selon 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 intégrés et des règles d'alerte pour CoreDNS. Vous pouvez activer Prometheus et ses fonctionnalités de tableau de bord dans la console ACK. Pour plus d'informations, consultez Surveiller le composant CoreDNS.

Si vous utilisez une instance Prometheus auto-gé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 de noms de domaine CoreDNS et de collecter ses journaux avec Log Service. Pour plus d'informations, consultez Analyser et surveiller les journaux CoreDNS.

Distribution des événements Kubernetes

À partir de 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 le Event Center. Pour plus d'informations sur le plugin k8s_event , consultez k8s_event.

Cette fonctionnalité est activée par défaut dans les nouveaux déploiements 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 stress 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 pouvez 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 GiB pour un pod unique.

• Le QPS de résolution de noms de domaine de CoreDNS est positivement corrélé à sa consommation CPU. Avec NodeLocal DNSCache activé, chaque cœur 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 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 conservativement un ratio de 1:8 entre les pods et les nœuds du cluster. Autrement dit, pour chaque ajout de 8 nœuds de cluster, ajoutez un pod CoreDNS.

Ajuster le nombre de pods CoreDNS

Le nombre de pods CoreDNS détermine directement les ressources de calcul 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 dns-autoscaler suivant. 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

  Exécutez 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 surviennent lors de la mise à l'échelle descendante des 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 méthode pour 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 2Gi, sans limite CPU. Définissez la limite 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 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 appliquent par défaut une politique d'anti-affinité souple au niveau du nœud, ce qui peut conduire au déploiement de tout ou partie des 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 à jour 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 exécutant CoreDNS ne doivent pas avoir leur CPU ou leur mémoire entièrement saturés, car cela affecte les QPS et la latence de réponse de la résolution de noms de domaine. Lorsque les conditions des nœuds de 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 de 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 plugin autopath

Certaines versions antérieures de CoreDNS activaient le plugin 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 Autopath.

1. Exécutez la commande kubectl -n kube-system edit configmap coredns pour ouvrir le fichier de configuration 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 réussi.

Configurer l'arrêt gracieux

lameduck est un mécanisme dans CoreDNS qui 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. lameduck fonctionne comme suit :

• Lorsqu'un processus CoreDNS est sur le point de se terminer, il entre 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 plugin forward

NodeLocal DNSCache utilise TCP pour communiquer avec CoreDNS. CoreDNS communique ensuite avec les serveurs DNS en amont en utilisant le même protocole que la requête entrante. Par conséquent, par défaut, les requêtes des conteneurs métier pour résoudre des noms de domaine hors du cluster passent par NodeLocal DNSCache et CoreDNS, et 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 plugin ready

Les versions de CoreDNS postérieures à la 1.5.0 doivent avoir le plugin ready configuré pour activer les sondes de readiness.

1. Exécutez la commande suivante pour ouvrir le fichier de configuration 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 réussi.

Améliorer les performances avec le plugin multisocket

CoreDNS v1.12.1 a introduit le plugin multisocket. L'activation de ce plugin 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 CPU. Pour une description détaillée du plugin, consultez la documentation communautaire.

Vous devez activer multisocket en utilisant 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 CPU estimée, les limites de ressources CPU et les ressources de cluster disponibles. Par exemple :

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

• Si CoreDNS consomme 8 cœurs au 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.