ProHoster > Blogs > Administrācija > /etc/resolv.conf Kubernetes podiem, ndots:5 opcija, kā tas var negatīvi ietekmēt lietojumprogrammu veiktspēju

/etc/resolv.conf Kubernetes podiem, ndots:5 opcija, kā tas var negatīvi ietekmēt lietojumprogrammu veiktspēju

/etc/resolv.conf Kubernetes podiem, ndots:5 opcija, kā tas var negatīvi ietekmēt lietojumprogrammu veiktspēju

Mēs nesen palaižām Kubernetes 1.9 AWS, izmantojot Kops. Vakar, nevainojami ieviešot jaunu trafiku lielākajiem mūsu Kubernetes klasteriem, es sāku pamanīt neparastas DNS nosaukuma izšķirtspējas kļūdas, ko reģistrējusi mūsu lietojumprogramma.

GitHub par to ir diezgan daudz runāja, tāpēc arī es nolēmu to izdomāt. Beigās sapratu, ka mūsu gadījumā to izraisa palielinātā slodze kube-dns и dnsmasq. Pats interesantākais un jaunums man bija iemesls ievērojamam DNS pieprasījumu trafika pieaugumam. Mans ieraksts ir par to un ko ar to darīt.

DNS izšķirtspēju konteinera iekšpusē - tāpat kā jebkurā Linux sistēmā - nosaka konfigurācijas fails /etc/resolv.conf. Noklusējuma Kubernetes dnsPolicy šis ClusterFirst, kas nozīmē, ka jebkurš DNS pieprasījums tiks pārsūtīts uz dnsmasq, darbojas podā kube-dns klasterī, kas savukārt pārsūtīs pieprasījumu lietojumprogrammai kube-dns, ja nosaukums beidzas ar klastera sufiksu, vai, pretējā gadījumā, uz augstāka līmeņa DNS serveri.

fails /etc/resolv.conf katrā konteinerā pēc noklusējuma izskatīsies šādi:

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

Kā redzat, ir trīs direktīvas:

  1. Nosaukuma serveris ir pakalpojuma IP kube-dns
  2. Norādīti 4 vietējās meklēšanas domēni search
  3. Ir iespēja ndots:5

Interesantā šīs konfigurācijas daļa ir vietējās meklēšanas domēni un iestatījumi ndots:5 sanāk kopā. Lai to saprastu, jums ir jāsaprot, kā darbojas DNS atrisināšana nekvalificētiem nosaukumiem.

Kas ir pilns vārds?

Pilnībā kvalificēts nosaukums ir nosaukums, kuram netiks veikta vietēja uzmeklēšana, un nosaukums tiks uzskatīts par absolūtu nosaukuma noteikšanas laikā. Pēc vienošanās DNS programmatūra uzskata nosaukumu par pilnībā kvalificētu, ja tas beidzas ar punktu (.), un citādi nav pilnībā kvalificēts. Tas ir google.com. pilnībā definēts un google.com - Nē.

Kā tiek apstrādāts nekvalificēts vārds?

Kad lietojumprogramma izveido savienojumu ar nosaukumā norādīto attālo resursdatoru, DNS nosaukuma atrisināšana parasti tiek veikta, izmantojot sistēmas zvanu, piemēram, getaddrinfo(). Bet, ja nosaukums ir nekvalificēts (nebeidzas ar .), es domāju, vai sistēmas izsaukums vispirms mēģinās atrisināt nosaukumu kā absolūtu nosaukumu vai vispirms iziet cauri vietējās meklēšanas domēniem? Tas ir atkarīgs no opcijas ndots.

No rokasgrāmatas resolv.conf:

ndots:n

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

Tas nozīmē, ka, ja par ndots Ja vērtība ir 5 un nosaukumā ir mazāk par 5 punktiem, sistēmas izsaukums mēģinās to atrisināt secīgi, vispirms šķērsojot visus lokālās meklēšanas domēnus un, ja tas neizdosies, galu galā atrisinot to kā absolūtu nosaukumu.

Kāpēc tā ndots:5 vai tas varētu negatīvi ietekmēt lietojumprogrammas veiktspēju?

Kā jūs varat iedomāties, ja jūsu lietojumprogramma izmanto daudz ārējās trafika, katram izveidotajam TCP savienojumam (vai, precīzāk, katram atrisinātajam nosaukumam), tā izdos 5 DNS vaicājumus, pirms nosaukums tiks pareizi atrisināts, jo vispirms tiks veikts. 4 vietējās meklēšanas domēns, un beigās izdos absolūtu vārda izšķirtspējas pieprasījumu.

Tālāk esošajā diagrammā ir parādīta mūsu 3 kube-dns moduļu kopējā trafika pirms un pēc dažu mūsu lietojumprogrammā konfigurēto saimniekdatoru nosaukumu pārslēgšanas uz pilnībā kvalificētiem.

/etc/resolv.conf Kubernetes podiem, ndots:5 opcija, kā tas var negatīvi ietekmēt lietojumprogrammu veiktspēju

Šajā diagrammā parādīts lietojumprogrammas latentums pirms un pēc tam, kad mēs pārslēdzām vairākus mūsu lietojumprogrammā konfigurētos saimniekdatoru nosaukumus uz pilniem nosaukumiem (vertikālā zilā līnija ir izvietošana):

/etc/resolv.conf Kubernetes podiem, ndots:5 opcija, kā tas var negatīvi ietekmēt lietojumprogrammu veiktspēju

1. risinājums — izmantojiet pilnībā kvalificētus nosaukumus

Ja jums ir maz statisku ārējo nosaukumu (t.i., definēti lietojumprogrammas konfigurācijā), kuriem izveidojat lielu skaitu savienojumu, iespējams, vienkāršākais risinājums ir pārslēgt tos uz pilnībā kvalificētiem, vienkārši pievienojot tos. beigās.

Tas nav galīgs risinājums, taču palīdz ātri, lai arī ne tīri, uzlabot situāciju. Mēs izmantojām šo ielāpu, lai atrisinātu problēmu, kuras rezultāti tika parādīti iepriekš redzamajos ekrānuzņēmumos.

Risinājums #2 - pielāgošana ndots в dnsConfig

Operētājsistēmā Kubernetes 1.9 funkcionalitāte parādījās alfa režīmā (beta versija v1.10), kas ļauj labāk kontrolēt DNS parametrus, izmantojot pod rekvizītu dnsConfig. Cita starpā tas ļauj konfigurēt vērtību ndots konkrētam podam, t.i.

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

avoti

Lasiet arī citus rakstus mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru