🥇/etc/resolv.conf dla podów Kubernetes, opcja ndots:5, jak to może negatywnie wpłynąć na wydajność aplikacji

Nie tak dawno uruchomiliśmy Kubernetes 1.9 na AWS za pomocą Kops. Wczoraj, podczas płynnego wprowadzania nowego ruchu na największym z naszych klastrów Kubernetes, zacząłem zauważać nietypowe błędy rozwiązywania nazw DNS rejestrowane przez naszą aplikację.

Na GitHubie o tym mówiono przez dość długi czas więc postanowiłem to zrozumieć. Ostatecznie zrozumiałem, że w naszym przypadku było to spowodowane zwiększonym obciążeniem. Najciekawszym i nowym dla mnie był sam powód znaczącego wzrostu ruchu zapytań DNS. O tym i o tym, co z tym zrobić, jest mój post. Modyfikacja podNetwork i dnsmasqRozwiązywanie DNS wewnątrz kontenera — podobnie jak w każdym systemie Linux — definiowane jest przez plik konfiguracyjny

. Domyślnie Kubernetes /etc/resolv.confClusterFirst dnsPolicy to , co oznacza, że każde zapytanie DNS zostanie przekierowane na, uruchomiony w podzie dnsmasqwewnątrz klastra, który z kolei przekieruje zapytanie do aplikacji Modyfikacja podNetwork , jeśli nazwa kończy się sufiksem klastra, lub, w przeciwnym razie, do serwera DNS wyższego poziomu. Modyfikacja podNetworkWewnątrz każdego kontenera domyślnie będzie to wyglądało tak:

Plik /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5

Jak można zauważyć, są tu trzy dyrektywy:

Serwer nazw — to IP usługi

Podano 4 lokalne domeny wyszukiwania Modyfikacja podNetwork
Jest opcja search
ndots:5 Ciekawą częścią tej konfiguracji jest to, jak lokalne domeny wyszukiwania i ustawienia

funkcjonują razem. Aby to zrozumieć, należy zrozumieć, jak działa rozwiązywanie DNS dla niepełnych nazw. Ciekawą częścią tej konfiguracji jest to, jak lokalne domeny wyszukiwania i ustawienia Czym jest pełna nazwa?

Pełna nazwa to taka, dla której nie będzie wykonywane lokalne wyszukiwanie i nazwa będzie uważana za absolutną podczas rozwiązywania nazw. Zgodnie z umową oprogramowanie DNS uznaje nazwę za pełni określoną, jeśli kończy się kropką (.), a za niepełni określoną w przeciwnym razie. To znaczy

pełni określona, a google.com. — nie. google.com Jak przetwarzana jest niepełna nazwa?

Gdy aplikacja łączy się z zdalnym hostem wskazanym w nazwie, rozwiązywanie nazw DNS zazwyczaj odbywa się za pomocą wywołania systemowego, takiego jak

getaddrinfo() . A co, jeśli nazwa jest niepełna (nie kończy się na .), to ciekawe, czy wywołanie systemowe najpierw spróbuje rozwiązać nazwę jako absolutną, czy najpierw przejdzie przez lokalne domeny wyszukiwania? To zależy od opcjiZ podręcznika do ndots.

Из мануала по resolv.conf:

ndots:n

ustawia próg liczby kropek, które muszą wystąpić w nazwie, zanim zostanie dokonane początkowe absolutne zapytanie. Domyślna wartość dla n wynosi 1, co oznacza, że jeżeli w nazwie znajdują się jakiekolwiek kropki, nazwa zostanie najpierw wypróbowana jako absolutna nazwa, zanim zostaną do niej dodane jakiekolwiek elementy listy wyszukiwania.

Oznacza to, że jeśli ndots ustawiono wartość 5, a nazwa zawiera mniej niż 5 kropek, wywołanie systemowe spróbuje rozwiązać ją kolejno, najpierw przeszukując wszystkie lokalne domeny wyszukiwania, a w przypadku niepowodzenia, ostatecznie rozwiąże ją jako absolutną nazwę.

Dlaczego `Ciekawą częścią tej konfiguracji jest to, jak lokalne domeny wyszukiwania i ustawienia` może negatywnie wpływać na wydajność aplikacji?

Jak rozumiesz, jeśli twoja aplikacja korzysta z dużego ruchu zewnętrznego, dla każdego nawiązanego połączenia TCP (lub, precyzyjniej, dla każdej rozwiązywanej nazwy) wygeneruje 5 zapytań DNS, zanim nazwa zostanie prawidłowo rozwiązana, ponieważ najpierw przejdzie przez 4 lokalne domeny wyszukiwania, a na końcu wyda zapytanie o rozwiązanie absolutnej nazwy.

Na poniższym wykresie przedstawiony jest skumulowany ruch na naszych 3 modułach kube-dns przed i po tym, jak przełączyliśmy kilka nazw hostów skonfigurowanych w naszej aplikacji na w pełni określone.

Na poniższym wykresie pokazana jest opóźnienie aplikacji przed i po tym, jak przełączyliśmy kilka nazw hostów skonfigurowanych w naszej aplikacji na w pełni określone (pionowa niebieska linia to wdrożenie):

Rozwiązanie #1 — użycie w pełni określonych nazw

Jeśli masz mało statycznych zewnętrznych nazw (tzn. zdefiniowanych w konfiguracji aplikacji), do których nawiązujesz dużą liczbę połączeń, być może najprostszym rozwiązaniem będzie ich przełączenie na w pełni określone, po prostu dodając. na końcu.

To nie jest ostateczne rozwiązanie, ale pomaga szybko, choć nie w czysty sposób, poprawić sytuację. Ta poprawka została zastosowana do rozwiązania naszego problemu, a wyniki zostały pokazane na zrzutach ekranu powyżej.

Rozwiązanie #2 — dostosowanie `ndots` do `dnsConfig`

W Kubernetes 1.9 w trybie alfa pojawiła się funkcjonalność (beta w v1.10), która pozwala lepiej kontrolować parametry DNS przez właściwość podu w dnsConfig. Między innymi pozwala dostosować wartość ndots dla konkretnego podu, tj.

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

Źródła

Przeczytaj również inne artykuły na naszym blogu:

Źródło: habr.com

/etc/resolv.conf для Kubernetes pods, опция ndots:5, как это может негативно сказаться на производительности приложения