Il n'y a pas si longtemps, nous avons déployé Kubernetes 1.9 sur AWS avec Kops. Hier, lors d'un déploiement progressif de nouveau trafic sur l'un de nos plus grands clusters Kubernetes, j'ai commencé à remarquer des erreurs étranges de résolution de noms DNS, enregistrées par notre application.
Cela a été discuté pendant longtemps sur GitHub kube-dns . La cause la plus intéressante et nouvelle pour moi a été l'augmentation significative du trafic des requêtes DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire. et dnsmasqLa résolution DNS à l'intérieur du conteneur — comme dans tout système Linux — est déterminée par un fichier de configuration.
Par défaut, Kubernetes /etc/resolv.confutilise la stratégie dnsPolicy c'est ClusterFirst, ce qui signifie que toute requête DNS sera redirigée vers dnsmasq, exécuté dans un pod . La cause la plus intéressante et nouvelle pour moi a été l'augmentation significative du trafic des requêtes DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire. à l'intérieur du cluster, qui, à son tour, redirigera la requête vers l'application . La cause la plus intéressante et nouvelle pour moi a été l'augmentation significative du trafic des requêtes DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire., si le nom se termine par le suffixe du cluster, ou, sinon, vers un serveur DNS de niveau supérieur.
Le fichier /etc/resolv.conf La configuration par défaut à l'intérieur de chaque conteneur ressemblera à ceci :
nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
eu-west-1.compute.internal
options ndots:5Comme vous pouvez le constater, il y a trois directives :
- Le serveur de noms est l'IP du service
. La cause la plus intéressante et nouvelle pour moi a été l'augmentation significative du trafic des requêtes DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire. - Quatre domaines de recherche locaux sont spécifiés
search - Il y a l'option
ndots:5
Une partie intéressante de cette configuration est la manière dont les domaines de recherche locaux et les paramètres ndots:5 coexistent. Pour comprendre cela, il faut examiner comment fonctionne la résolution DNS pour les noms incomplets.
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 des noms. Par convention, le logiciel DNS considère qu'un nom est pleinement qualifié s'il se termine par un point (.), et pas pleinement qualifié sinon. En d'autres termes, google.com. c'est pleinement qualifié et google.com ne l'est pas.
Comment un nom incomplet est-il traité ?
Lorsque l'application se connecte à un hôte distant désigné par le nom, la résolution des noms DNS est généralement effectuée à l'aide d'un appel système tel que getaddrinfo(). En revanche, si le nom est incomplet (ne se termine pas par .), il est intéressant de se demander si l'appel système tentera d'abord de résoudre le nom comme absolu, ou passera d'abord par les domaines de recherche locaux. Cela dépend de l'option ndots.
selon le manuel de resolv.conf:
ndots:n
définit le seuil pour le nombre de points qui doivent apparaître dans le nom avant qu'une requête absolue initiale soit effectuée. La valeur par défaut de n est 1, ce qui signifie que si le nom contient des points, il sera d'abord testé comme un nom absolu avant que des éléments de la liste de recherche ne soient ajoutés.Cela signifie que si ndots la valeur 5 est définie et que le nom contient moins de 5 points, l'appel système essaiera de le résoudre séquentiellement, d'abord en parcourant tous les domaines de recherche locaux, et, en cas d'échec, finira par le résoudre comme un nom absolu.
Pourquoi ndots:5 peut avoir un impact négatif sur la performance de l'application ?
Comme vous le comprenez, si votre application utilise beaucoup de trafic externe, pour chaque connexion TCP établie (ou, plus précisément, pour chaque nom résolu), elle générera 5 requêtes DNS avant que le nom soit correctement résolu, car elle passera d'abord par 4 domaines de recherche locaux, et finira par émettre une requête pour résoudre le nom absolu.
Le graphique suivant montre le trafic total sur nos 3 modules kube-dns avant et après que nous ayons basculé plusieurs noms d'hôtes configurés dans notre application vers des noms complètement qualifiés.
Le graphique suivant montre la latence de l'application avant et après que nous ayons basculé plusieurs noms d'hôtes configurés dans notre application vers des noms complets (la ligne bleue verticale représente le déploiement) :
Solution #1 — utiliser des noms complètement qualifiés
Si vous avez peu de noms externes statiques (c.-à-d. définis dans la configuration de l'application) pour lesquels vous établissez un grand nombre de connexions, la solution la plus simple pourrait être de les basculer vers des noms complètement qualifiés, en ajoutant simplement. à la fin.
Ce n'est pas une solution définitive, mais cela aide à améliorer rapidement, même si ce n'est pas proprement, la situation. Ce patch que nous avons appliqué pour résoudre notre problème, dont les résultats ont été montrés sur les captures d'écran ci-dessus.
Solution #2 — personnalisation ndots dans dnsConfig
Dans Kubernetes 1.9, une fonctionnalité en mode alpha est apparue (version bêta v1.10) qui permet un meilleur contrôle des paramètres DNS via la propriété du pod dans dnsConfig. Parmi d'autres, elle permet de configurer la valeur ndots pour un pod spécifique, c.-à-d.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Sources
Lisez aussi d'autres articles sur notre blog :
Source : habr.com
