Container Service for Kubernetes:DNS resolution and caching policies

Applications basées sur l'hôte (non conteneurisées)

Les applications s'exécutant directement sur des instances Elastic Compute Service (ECS) utilisent le fichier /etc/resolv.conf de l'hôte, qui pointe vers les serveurs DNS du Virtual Private Cloud (VPC).

Pods conteneurisés standard (dnsPolicy: ClusterFirst)

Par défaut, les pods utilisent la politique ClusterFirst. Toutes les requêtes DNS sont envoyées au service CoreDNS au sein du cluster.

Pods avec NodeLocal DNSCache activé

Lorsque NodeLocal DNSCache est actif, les pods envoient leurs requêtes à un agent de mise en cache local situé sur le même nœud. Cette approche offre deux avantages :

• Réduction de la latence : les requêtes DNS sont résolues localement, évitant ainsi le saut réseau vers CoreDNS.

• Protection de la table conntrack : les requêtes utilisent l'agent local sans créer d'entrées conntrack, ce qui réduit les conflits conntrack et empêche l'épuisement de la table conntrack par le trafic DNS UDP.

Côté client

Le résolveur glibc interprète ces paramètres du fichier /etc/resolv.conf. Voici une configuration représentative pour un pod utilisant la politique ClusterFirst :

nameserver 10.x.x.x          # CoreDNS ClusterIP
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5 timeout:5 attempts:2

Valeurs par défaut selon les environnements de déploiement :

^①^ Le paramètre attempts s'applique uniquement lorsque le serveur renvoie SERVFAIL, NOTIMP ou REFUSED, ou renvoie NOERROR sans résultat. Consultez les détails des requêtes du paramètre Attempts.

^②^ Les serveurs DNS VPC (100.100.2.136 et 100.100.2.138) sont les serveurs DNS par défaut sur les instances ECS. Ils résolvent les noms de domaine PrivateZone et autoritatifs.

^③^ L'adresse IP ClusterIP de CoreDNS correspond à l'IP du service kube-dns dans le namespace kube-system. Elle résout les noms de service internes et transfère les requêtes PrivateZone et autoritatives.

^④^ NodeLocal DNSCache écoute sur l'adresse 169.254.20.10 sur chaque nœud lorsque le module complémentaire est déployé.

Consultez la page resolv.conf pour obtenir des informations supplémentaires sur les options du fichier /etc/resolv.conf .

Résolveurs non standards

Les valeurs par défaut glibc ci-dessus s'appliquent uniquement lorsque le conteneur utilise glibc. Deux exceptions courantes existent :

• Alpine (musl libc) : la bibliothèque intégrée musl d'Alpine remplace glibc et se comporte différemment (voir musl libc) :

  • Ne prend pas en charge les options single-request et single-request-reopen dans le fichier /etc/resolv.conf.

  • Alpine 3.3 et versions antérieures ne prennent pas en charge le paramètre search ni les domaines de recherche, ce qui perturbe la découverte de services.

  • Les requêtes simultanées vers plusieurs serveurs DNS rendent les optimisations de NodeLocal DNSCache inefficaces.

  • Les requêtes A et AAAA simultanées sur le même socket déclenchent des conditions de concurrence conntrack sur les noyaux plus anciens, entraînant des pertes de paquets intermittentes.

• Langages avec résolveurs intégrés (Go, Node.js) : ces environnements d'exécution contournent souvent le fichier /etc/resolv.conf et effectuent la résolution différemment du résolveur système.

Serveurs DNS intra-cluster

Par défaut, CoreDNS lit son amont à partir du fichier /etc/resolv.conf de l'ECS et transfère les requêtes DNS avec le plugin intégré forward. NodeLocal DNSCache exécute une instance CoreDNS embarquée avec la même configuration de transfert.

Paramètres du plugin forward (référence complète) :

Côté client

La mise en cache côté client varie selon l'image du conteneur et l'application.

Serveurs DNS intra-cluster

Paramètres de cache pour CoreDNS et NodeLocal DNSCache dans ACK :

Améliorer la tolérance aux pannes

Avec la politique dnsPolicy: Default, le conteneur hérite des paramètres du serveur DNS VPC depuis le fichier /etc/resolv.conf de l'ECS, mais pas des options rotate, single-request-reopen, timeout:2 et attempts:3. Sans ces options, les fluctuations réseau peuvent provoquer des échecs DNS intermittents.

Configuration héritée :

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # The dnsPolicy value in the Pod YAML is Default.
  dnsPolicy: Default

# The /etc/resolv.conf file in the container at this time.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Ajoutez le champ dnsConfig pour restaurer les options de tolérance aux pannes manquantes :

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # The dnsPolicy value in the pod YAML is Default.
  dnsPolicy: Default
  # Add the following fault tolerance configuration.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After modification, redeploy the pod. The options parameter is added to /etc/resolv.conf in the container.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3

Haute disponibilité avec serve_stale

L'option serve_stale permet à CoreDNS de renvoyer des entrées de cache expirées lorsque les serveurs DNS amont sont injoignables, empêchant ainsi les échecs de résolution lors de pannes transitoires.

L'option serve_stale est activée par défaut dans CoreDNS Unmanaged Edition v1.12.1 et versions ultérieures. Consultez la RFC-8767 .

Format de configuration

serve_stale [DURATION] [REFRESH_MODE]

• DURATION : durée pendant laquelle les entrées expirées restent servables après leur expiration. Valeur par défaut : 1h. Les entrées expirées depuis plus longtemps sans actualisation réussie ne sont plus servies.

• REFRESH_MODE : contrôle la manière dont CoreDNS gère les entrées expirées :

  • verify : vérifie d'abord l'accessibilité de l'amont, renvoie l'entrée actualisée si disponible, ou revient à l'entrée expirée. Latence plus élevée pour les réponses obsolètes, mais évite de servir des données périmées lorsque des données fraîches existent.

  • immediate : renvoie immédiatement l'entrée expirée et actualise depuis l'amont en arrière-plan. Plus rapide, mais peut servir des données obsolètes.

Exemple

Configuration par défaut dans CoreDNS Unmanaged Edition v1.12.1.2 et versions ultérieures :

cache 30 {
  ...
  serve_stale 30s verify
}

cache 30 {
  ...
  serve_stale 1h immediate
}