Container Compute Service:DNS resolution policies and caching policies

Chaînes de résolution DNS

Les diagrammes suivants illustrent la chaîne de résolution DNS pour deux scénarios.

Applications non conteneurisées sur des instances Elastic Compute Service (ECS)

Par exemple, une application nommée App s'exécute sur une instance ECS, comme l'illustre la figure suivante.

Applications conteneurisées dans des pods avec la politique DNS ClusterFirst

Par exemple, une application nommée App s'exécute dans un pod au sein d'un cluster Kubernetes, comme l'illustre la figure suivante.

Politiques de résolution

Côté client

Les requêtes DNS provenant des pods transitent par les interfaces fournies par glibc. Le fichier /etc/resolv.conf détermine le mode de résolution DNS de glibc. Le tableau suivant répertorie les paramètres configurables et leurs valeurs par défaut selon les environnements.

Le tableau suivant décrit le comportement de routage des requêtes pour chaque politique DNS.

① Le paramètre attempts s'applique uniquement lorsque le serveur retourne SERVFAIL, NOTIMP ou REFUSED, ou lorsqu'un code NOERROR est retourné sans résultat de résolution. Pour plus de détails, consultez Présentation du paramètre attempts.

② Les serveurs DNS du VPC constituent les serveurs de noms par défaut pour les instances ECS dans le Virtual Private Cloud (VPC). Leurs adresses IP sont 100.100.2.136 et 100.100.2.138. Ils résolvent les noms de domaine autoritaires ainsi que les domaines ajoutés à Alibaba Cloud DNS PrivateZone.

③ L'IP du cluster CoreDNS correspond à l'adresse IP du Service kube-dns dans le namespace kube-system. Ce service transfère les requêtes DNS à CoreDNS pour les noms de domaine internes, les domaines autoritaires et les domaines ajoutés à Alibaba Cloud DNS PrivateZone.

Environnements non standard

La configuration DNS côté client décrite ci-dessus s'applique aux environnements utilisant glibc. Les environnements suivants présentent un comportement différent.

Alpine Linux (musl libc)

Alpine Linux remplace glibc par musl libc, ce qui introduit plusieurs différences en matière de résolution DNS :

• Les options single-request et single-request-reopen ne sont pas prises en charge dans /etc/resolv.conf.

• Alpine 3.3 et les versions antérieures ne prennent pas en charge le paramètre search pour les domaines de recherche, ce qui entraîne l'échec de la découverte de services.

• musl libc envoie parallèlement des requêtes à tous les serveurs de noms définis dans /etc/resolv.conf, empêchant ainsi NodeLocal DNSCache d'optimiser la résolution DNS.

• musl libc transmet simultanément les requêtes A et AAAA sur le même socket. Sur les anciennes versions du noyau, cela provoque une perte de paquets au niveau du port conntrack.

Pour plus d'informations, consultez Différences fonctionnelles entre musl libc et glibc.

Golang et Node.js

Les applications développées avec Golang ou Node.js peuvent utiliser un résolveur DNS intégré plutôt que glibc. Cela peut entraîner des différences significatives dans le comportement de résolution DNS. Vérifiez l'implémentation de la résolution DNS de votre application si vous observez un comportement inattendu.

Serveurs DNS internes du cluster

Par défaut, CoreDNS hérite du fichier /etc/resolv.conf de l'instance ECS qui l'héberge. CoreDNS utilise ensuite le plugin intégré forward pour transmettre les requêtes DNS en amont.

Le tableau suivant répertorie les paramètres du plugin forward ainsi que leurs valeurs par défaut. Pour la référence complète, consultez forward.

Politiques de mise en cache

Côté client

La politique de mise en cache DNS côté client dépend de la configuration du conteneur et de l'application. Configurez la mise en cache côté client selon vos besoins.

Serveurs DNS internes du cluster

CoreDNS utilise le plugin cache pour mettre en cache les résultats de résolution DNS. Le tableau suivant répertorie les paramètres du plugin cache et leurs valeurs par défaut dans ACS.

Optimisation de la résolution DNS

Modifiez le fichier YAML du pod ou la ConfigMap CoreDNS pour ajuster le comportement de résolution DNS.

Utilisation directe des serveurs DNS du VPC

Définissez dnsPolicy: Default pour contourner CoreDNS et résoudre les noms de domaine directement via les serveurs DNS du VPC. Le pod hérite alors des paramètres DNS de l'instance ECS qui l'héberge.

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default

# The /etc/resolv.conf file in the pod.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Amélioration de la tolérance aux pannes pour les pods Default

Lorsque dnsPolicy: Default est défini, le fichier /etc/resolv.conf du pod omet les options rotate, single-request-reopen, timeout:2 et attempts:3 présentes par défaut sur les instances ECS. En l'absence de ces options, la résolution DNS risque davantage d'échouer lors d'instabilités réseau.

Ajoutez ces options via dnsConfig afin de reproduire le comportement des instances ECS :

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default
  # Add the following options.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After adding the options, redeploy the pod to apply the changes.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3