🥇/etc/resolv.conf per a pods de Kubernetes, opció ndots:5, com això pot afectar negativament el rendiment de l'aplicació

Recentment hem llançat Kubernetes 1.9 a AWS amb Kops. Ahir, mentre distribuïa el trànsit nou sense problemes al més gran dels nostres clústers de Kubernetes, vaig començar a notar errors inusuals de resolució de noms DNS registrats per la nostra aplicació.

Hi ha moltes coses sobre això a GitHub va parlar, així que vaig decidir esbrinar-ho també. Al final, em vaig adonar que en el nostre cas això és causat per l'augment de la càrrega kube-dns и dnsmasq. El més interessant i nou per a mi va ser el motiu de l'augment significatiu del trànsit de sol·licituds de DNS. La meva publicació tracta sobre això i què fer-hi.

La resolució DNS dins del contenidor, com en qualsevol sistema Linux, ve determinada pel fitxer de configuració /etc/resolv.conf. Kubernetes predeterminat dnsPolicy aquest ClusterFirst, el que significa que qualsevol sol·licitud de DNS es reenviarà a dnsmasq, corrent en una beina kube-dns dins del clúster, que al seu torn reenviarà la sol·licitud a l'aplicació kube-dns, si el nom acaba amb un sufix de clúster o, en cas contrari, a un servidor DNS de nivell superior.

expedient /etc/resolv.conf dins de cada contenidor, el valor predeterminat serà així:

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

Com podeu veure, hi ha tres directives:

El servidor de noms és la IP del servei kube-dns
4 dominis de cerca local especificats search
Hi ha una opció ndots:5

La part interessant d'aquesta configuració és com els dominis de cerca locals i la configuració ndots:5 portar-se junts. Per entendre-ho, heu d'entendre com funciona la resolució DNS per a noms no qualificats.

Què és un nom complet?

Un nom totalment qualificat és un nom pel qual no es realitzarà cap cerca local i el nom es considerarà absolut durant la resolució de noms. Per convenció, el programari DNS considera que un nom està totalment qualificat si acaba amb un punt (.), i no està totalment qualificat en cas contrari. Això és google.com. totalment definit i google.com - No.

Com es gestiona un nom no qualificat?

Quan una aplicació es connecta a l'amfitrió remot especificat al nom, la resolució de noms DNS normalment es fa mitjançant una trucada al sistema, p. getaddrinfo(). Però si el nom no està qualificat (no acaba amb .), em pregunto si la trucada del sistema intentarà resoldre primer el nom com a nom absolut o passarà primer pels dominis de cerca locals? Depèn de l'opció ndots.

Del manual resolv.conf:

ndots:n

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

Això vol dir que si per ndots donat un valor de 5 i el nom conté menys de 5 punts, la trucada del sistema intentarà resoldre'l de manera seqüencial, primer travessant tots els dominis de cerca locals i, si no té èxit, finalment resoldrà com a nom absolut.

Per la qual `ndots:5` podria afectar negativament el rendiment de l'aplicació?

Com podeu imaginar, si la vostra aplicació utilitza molt trànsit extern, per cada connexió TCP establerta (o més exactament, per cada nom resolt), emetrà 5 consultes DNS abans que el nom es resolgui correctament, perquè primer passarà per 4 domini de cerca local i, al final, emetrà una sol·licitud de resolució de nom absoluta.

El gràfic següent mostra el trànsit total dels nostres 3 mòduls kube-dns abans i després de canviar els pocs noms d'amfitrió configurats a la nostra aplicació per uns de totalment qualificats.

El diagrama següent mostra la latència de l'aplicació abans i després de canviar diversos noms d'amfitrió configurats a la nostra aplicació a noms complets (la línia blava vertical és el desplegament):

Solució núm. 1: utilitzeu noms totalment qualificats

Si teniu pocs noms externs estàtics (és a dir, definits a la configuració de l'aplicació) als quals creeu un gran nombre de connexions, potser la solució més senzilla és canviar-los per altres de totalment qualificats simplement afegint-los. al final.

Aquesta no és una solució definitiva, però ajuda a millorar la situació ràpidament, encara que no de manera neta. Hem aplicat aquest pegat per resoldre el nostre problema, els resultats del qual es van mostrar a les captures de pantalla anteriors.

Solució núm. 2: personalització `ndots` в `dnsConfig`

A Kubernetes 1.9, la funcionalitat va aparèixer en mode alfa (versió beta v1.10), que us permet controlar millor els paràmetres DNS mitjançant la propietat del pod a dnsConfig. Entre altres coses, permet configurar el valor ndots per a una beina específica, és a dir.

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

Fonts

Llegiu també altres articles al nostre blog:

Font: www.habr.com

/etc/resolv.conf per a pods de Kubernetes, opció ndots:5, com això pot afectar negativament el rendiment de l'aplicació