{"id":37372,"date":"2019-10-31T22:17:16","date_gmt":"2019-10-31T19:17:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya\/"},"modified":"2019-10-31T22:17:16","modified_gmt":"2019-10-31T19:17:16","slug":"etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","title":{"rendered":"\/etc\/resolv.conf \u0434\u043b\u044f Kubernetes pods, \u043e\u043f\u0446\u0438\u044f ndots:5, \u043a\u0430\u043a \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\/etc\/resolv.conf<\/p>\n

<\/p>\n

Il n'y a pas si longtemps, nous avons d\u00e9ploy\u00e9 Kubernetes 1.9 sur AWS avec Kops. Hier, lors d'un d\u00e9ploiement progressif de nouveau trafic sur l'un de nos plus grands clusters Kubernetes, j'ai commenc\u00e9 \u00e0 remarquer des erreurs \u00e9tranges de r\u00e9solution de noms DNS, enregistr\u00e9es par notre application.<\/p>\n

<\/a><\/noindex><\/p>\n

Cela a \u00e9t\u00e9 discut\u00e9 pendant longtemps sur GitHub , donc j'ai d\u00e9cid\u00e9 d'investiguer \u00e9galement. En fin de compte, j'ai compris que dans notre cas, cela \u00e9tait d\u00fb \u00e0 une surcharge \u00e9lev\u00e9e sur<\/a><\/noindex>kube-dns . La cause la plus int\u00e9ressante et nouvelle pour moi a \u00e9t\u00e9 l'augmentation significative du trafic des requ\u00eates DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire.<\/code> et dnsmasq<\/code>La r\u00e9solution DNS \u00e0 l'int\u00e9rieur du conteneur \u2014 comme dans tout syst\u00e8me Linux \u2014 est d\u00e9termin\u00e9e par un fichier de configuration.<\/p>\n

<\/p>\n

Par d\u00e9faut, Kubernetes \/etc\/resolv.conf<\/code>utilise la strat\u00e9gie dnsPolicy<\/code> c'est ClusterFirst<\/code>, ce qui signifie que toute requ\u00eate DNS sera redirig\u00e9e vers dnsmasq<\/code>, ex\u00e9cut\u00e9 dans un pod . La cause la plus int\u00e9ressante et nouvelle pour moi a \u00e9t\u00e9 l'augmentation significative du trafic des requ\u00eates DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire.<\/code> \u00e0 l'int\u00e9rieur du cluster, qui, \u00e0 son tour, redirigera la requ\u00eate vers l'application . La cause la plus int\u00e9ressante et nouvelle pour moi a \u00e9t\u00e9 l'augmentation significative du trafic des requ\u00eates DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire.<\/code>, si le nom se termine par le suffixe du cluster, ou, sinon, vers un serveur DNS de niveau sup\u00e9rieur.<\/p>\n

<\/p>\n

Le fichier \/etc\/resolv.conf<\/code> La configuration par d\u00e9faut \u00e0 l'int\u00e9rieur de chaque conteneur ressemblera \u00e0 ceci :<\/p>\n

<\/p>\n

nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/code><\/pre>\n
<\/p>\n
Comme vous pouvez le constater, il y a trois directives :<\/p>\n
<\/p>\n
    \n
  1. Le serveur de noms est l'IP du service . La cause la plus int\u00e9ressante et nouvelle pour moi a \u00e9t\u00e9 l'augmentation significative du trafic des requ\u00eates DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire.<\/code><\/li>\n
  2. Quatre domaines de recherche locaux sont sp\u00e9cifi\u00e9s search<\/code><\/li>\n
  3. Il y a l'option ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Une partie int\u00e9ressante de cette configuration est la mani\u00e8re dont les domaines de recherche locaux et les param\u00e8tres ndots:5<\/code> coexistent. Pour comprendre cela, il faut examiner comment fonctionne la r\u00e9solution DNS pour les noms incomplets.<\/p>\n
    <\/p>\n
    Qu'est-ce qu'un nom complet ?<\/h3>\n
    <\/p>\n
    Un nom pleinement qualifi\u00e9 est un nom pour lequel aucune recherche locale ne sera effectu\u00e9e, et le nom sera consid\u00e9r\u00e9 comme absolu lors de la r\u00e9solution des noms. Par convention, le logiciel DNS consid\u00e8re qu'un nom est pleinement qualifi\u00e9 s'il se termine par un point (.), et pas pleinement qualifi\u00e9 sinon. En d'autres termes, google.com.<\/code> c'est pleinement qualifi\u00e9 et google.com<\/code> ne l'est pas. <\/p>\n
    <\/p>\n
    Comment un nom incomplet est-il trait\u00e9 ?<\/h3>\n
    <\/p>\n
    Lorsque l'application se connecte \u00e0 un h\u00f4te distant d\u00e9sign\u00e9 par le nom, la r\u00e9solution des noms DNS est g\u00e9n\u00e9ralement effectu\u00e9e \u00e0 l'aide d'un appel syst\u00e8me tel que getaddrinfo()<\/code>. En revanche, si le nom est incomplet (ne se termine pas par .), il est int\u00e9ressant de se demander si l'appel syst\u00e8me tentera d'abord de r\u00e9soudre le nom comme absolu, ou passera d'abord par les domaines de recherche locaux. Cela d\u00e9pend de l'option ndots<\/code>.<\/p>\n
    <\/p>\n
    selon le manuel de resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nd\u00e9finit le seuil pour le nombre de points qui doivent appara\u00eetre dans le nom avant qu'une requ\u00eate absolue initiale soit effectu\u00e9e. La valeur par d\u00e9faut de n est 1, ce qui signifie que si le nom contient des points, il sera d'abord test\u00e9 comme un nom absolu avant que des \u00e9l\u00e9ments de la liste de recherche ne soient ajout\u00e9s.<\/code><\/pre>\n
    <\/p>\n
    Cela signifie que si ndots<\/code> la valeur 5 est d\u00e9finie et que le nom contient moins de 5 points, l'appel syst\u00e8me essaiera de le r\u00e9soudre s\u00e9quentiellement, d'abord en parcourant tous les domaines de recherche locaux, et, en cas d'\u00e9chec, finira par le r\u00e9soudre comme un nom absolu.<\/p>\n
    <\/p>\n
    Pourquoi ndots:5<\/code> peut avoir un impact n\u00e9gatif sur la performance de l'application ?<\/h3>\n
    <\/p>\n
    Comme vous le comprenez, si votre application utilise beaucoup de trafic externe, pour chaque connexion TCP \u00e9tablie (ou, plus pr\u00e9cis\u00e9ment, pour chaque nom r\u00e9solu), elle g\u00e9n\u00e9rera 5 requ\u00eates DNS avant que le nom soit correctement r\u00e9solu, car elle passera d'abord par 4 domaines de recherche locaux, et finira par \u00e9mettre une requ\u00eate pour r\u00e9soudre le nom absolu.<\/p>\n
    <\/p>\n
    Le graphique suivant montre le trafic total sur nos 3 modules kube-dns avant et apr\u00e8s que nous ayons bascul\u00e9 plusieurs noms d'h\u00f4tes configur\u00e9s dans notre application vers des noms compl\u00e8tement qualifi\u00e9s.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Le graphique suivant montre la latence de l'application avant et apr\u00e8s que nous ayons bascul\u00e9 plusieurs noms d'h\u00f4tes configur\u00e9s dans notre application vers des noms complets (la ligne bleue verticale repr\u00e9sente le d\u00e9ploiement) :<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Solution #1 \u2014 utiliser des noms compl\u00e8tement qualifi\u00e9s<\/h3>\n
    <\/p>\n
    Si vous avez peu de noms externes statiques (c.-\u00e0-d. d\u00e9finis dans la configuration de l'application) pour lesquels vous \u00e9tablissez un grand nombre de connexions, la solution la plus simple pourrait \u00eatre de les basculer vers des noms compl\u00e8tement qualifi\u00e9s, en ajoutant simplement. \u00e0 la fin.<\/p>\n
    <\/p>\n
    Ce n'est pas une solution d\u00e9finitive, mais cela aide \u00e0 am\u00e9liorer rapidement, m\u00eame si ce n'est pas proprement, la situation. Ce patch que nous avons appliqu\u00e9 pour r\u00e9soudre notre probl\u00e8me, dont les r\u00e9sultats ont \u00e9t\u00e9 montr\u00e9s sur les captures d'\u00e9cran ci-dessus.<\/p>\n
    <\/p>\n
    Solution #2 \u2014 personnalisation ndots<\/code> dans dnsConfig<\/code><\/h3>\n
    <\/p>\n
    Dans Kubernetes 1.9, une fonctionnalit\u00e9 en mode alpha est apparue (version b\u00eata v1.10) qui permet un meilleur contr\u00f4le des param\u00e8tres DNS via la propri\u00e9t\u00e9 du pod dans dnsConfig<\/code>. Parmi d'autres, elle permet de configurer la valeur ndots<\/code> pour un pod sp\u00e9cifique, c.-\u00e0-d.<\/p>\n
    <\/p>\n
    apiVersion: v1\nkind: Pod\nmetadata:\n  namespace: default\n  name: dns-example\nspec:\n  containers:\n    - name: test\n      image: nginx\n  dnsConfig:\n    options:\n      - name: ndots\n        value: \"1\"<\/code><\/pre>\n
    <\/p>\n
    Sources<\/h3>\n
    <\/p>\n