🥇/etc/resolv.conf pour les pods Kubernetes, option ndots:5, comment cela peut avoir un impact négatif sur les performances des applications

Nous avons récemment lancé Kubernetes 1.9 sur AWS à l'aide de Kops. Hier, alors que nous déployions en douceur un nouveau trafic vers le plus grand de nos clusters Kubernetes, j'ai commencé à remarquer des erreurs inhabituelles de résolution de noms DNS enregistrées par notre application.

Il y a beaucoup de choses à ce sujet sur GitHub a parlé, alors j'ai décidé de le découvrir aussi. En fin de compte, j'ai réalisé que dans notre cas, cela était dû à la charge accrue sur kube-dns и dnsmasq. La chose la plus intéressante et la plus nouvelle pour moi était la raison même de l'augmentation significative du trafic de requêtes DNS. Mon message porte sur cela et sur ce qu'il faut faire.

La résolution DNS à l'intérieur du conteneur - comme dans tout système Linux - est déterminée par le fichier de configuration /etc/resolv.conf. Kubernetes par défaut dnsPolicy это ClusterFirst, ce qui signifie que toute requête DNS sera transmise à dnsmasq, fonctionnant dans un pod kube-dns à l'intérieur du cluster, qui à son tour transmettra la requête à l'application kube-dns, si le nom se termine par un suffixe de cluster, ou, à défaut, vers un serveur DNS de niveau supérieur.

Dossier /etc/resolv.conf à l'intérieur de chaque conteneur, la valeur par défaut ressemblera à ceci :

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Comme vous pouvez le constater, il existe trois directives :

Le serveur de noms est l'IP du service kube-dns
4 domaines de recherche locaux spécifiés search
Il y a une option ndots:5

La partie intéressante de cette configuration est la façon dont les domaines et paramètres de recherche locale ndots:5 s'entendre. Pour comprendre cela, vous devez comprendre comment fonctionne la résolution DNS pour les noms non qualifiés.

Qu'est-ce qu'un nom complet ?

Un nom pleinement qualifié est un nom pour lequel aucune recherche locale ne sera effectuée et le nom sera considéré comme absolu lors de la résolution du nom. Par convention, les logiciels DNS considèrent qu'un nom est pleinement qualifié s'il se termine par un point (.), et non pleinement qualifié dans le cas contraire. C'est google.com. entièrement défini et google.com - non.

Comment est géré un nom non qualifié ?

Lorsqu'une application se connecte à l'hôte distant spécifié dans le nom, la résolution du nom DNS est généralement effectuée à l'aide d'un appel système, par ex. getaddrinfo(). Mais si le nom n'est pas qualifié (ne se termine pas par .), je me demande si l'appel système tentera d'abord de résoudre le nom en tant que nom absolu, ou passera d'abord par les domaines de recherche locaux ? Cela dépend de l'option ndots.

Du manuel resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

Cela signifie que si pour ndots étant donné une valeur de 5 et que le nom contient moins de 5 points, l'appel système tentera de le résoudre de manière séquentielle, en parcourant d'abord tous les domaines de recherche locaux et, en cas d'échec, en le résolvant finalement en tant que nom absolu.

Pourquoi même `ndots:5` cela pourrait-il avoir un impact négatif sur les performances des applications ?

Comme vous pouvez l'imaginer, si votre application utilise beaucoup de trafic externe, pour chaque connexion TCP établie (ou plus précisément, pour chaque nom résolu), elle émettra 5 requêtes DNS avant que le nom ne soit correctement résolu, car il passera d'abord par 4 domaine de recherche local, et à la fin émettra une demande de résolution de nom absolue.

Le graphique suivant montre le trafic total sur nos 3 modules kube-dns avant et après le remplacement des quelques noms d'hôtes configurés dans notre application par des noms pleinement qualifiés.

Le diagramme suivant montre la latence de l'application avant et après le remplacement de plusieurs noms d'hôtes configurés dans notre application par des noms complets (la ligne bleue verticale représente le déploiement) :

Solution n°1 – Utilisez des noms complets

Si vous disposez de quelques noms externes statiques (c'est-à-dire définis dans la configuration de l'application) auxquels vous créez un grand nombre de connexions, la solution la plus simple consiste peut-être à les remplacer par des noms pleinement qualifiés en les ajoutant simplement. à la fin.

Il ne s’agit pas d’une solution définitive, mais elle permet d’améliorer rapidement, même si ce n’est pas propre, la situation. Nous avons appliqué ce correctif pour résoudre notre problème, dont les résultats ont été montrés dans les captures d'écran ci-dessus.

Solution n°2 – personnalisation `ndots` в `dnsConfig`

Dans Kubernetes 1.9, une fonctionnalité est apparue en mode alpha (version bêta v1.10), ce qui permet de mieux contrôler les paramètres DNS via la propriété pod dans dnsConfig. Entre autres choses, il permet de configurer la valeur ndots pour un pod spécifique, c'est-à-dire

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

sources

Lisez également d'autres articles sur notre blog:

Source: habr.com

/etc/resolv.conf pour les pods Kubernetes, option ndots:5, comment cela peut avoir un impact négatif sur les performances des applications