Kiedy DNS kontenera staje się wąskim gardłem serwera domowego?

Lauren Pan

IceWhale author

Lauren Pan jest założycielem ZimaSpace i architektem stojącym za uznaną serią ZimaBoard. Łącząc wzornictwo przemysłowe z inżynierią wbudowaną, Lauren założył ZimaSpace z jasną misją: demokratyzacji osobistej chmury obliczeniowej. Wierzy, że sprzęt powinien być zarówno "hakerski", jak i piękny—niwelując przepaść między serwerami klasy przemysłowej a gadżetami konsumenckimi. Obecnie kieruje zespołem inżynierów tworzących narzędzia, które dają twórcom pełną kontrolę nad ich cyfrowym życiem.

When Does Container DNS Become a Home Server Bottleneck?

DNS w kontenerach staje się wąskim gardłem serwera domowego, gdy opóźnienie w wyszukiwaniu, mnożenie zapytań lub awaria resolvera zajmuje więcej czasu niż samo lokalne żądanie usługi.

Kontenery często rozwiązują nazwy usług przez wbudowany serwer proxy DNS, zanim zapytania dotrą do hosta lub resolvera nadrzędnego. Ta dodatkowa ścieżka jest zazwyczaj szybka. Staje się widoczna, gdy aplikacje otwierają wiele krótkich połączeń, domeny wyszukiwania generują nieudane warianty, pamięć podręczna jest słaba lub jeden lokalny resolver obsługuje każdy kontener i urządzenie w domu.

Kontener dodaje ścieżkę resolvera do wykrywania usług

W sieci zdefiniowanej przez użytkownika wbudowany resolver może mapować nazwy i aliasy kontenerów, a następnie przekazywać nieznane nazwy dalej. Przewodnik po wbudowanym DNS Docker opisuje tę decyzję między lokalnym a przekazywanym zapytaniem. Projekt pozwala na przemieszczanie się usług bez twardo zakodowanych adresów IP, ale także sprawia, że rozwiązywanie nazw jest częścią każdego niebuforowanego nawiązania połączenia.

Host i kontener mogą więc pokazywać różne wyniki. Host może zapytać bezpośrednio swojego resolvera, podczas gdy kontener przechodzi przez proxy runtime, most i odziedziczone ustawienia resolvera. Testowanie tylko hosta może nie wykryć wolnej warstwy.

Domeny wyszukiwania mogą zamienić jedną nazwę na kilka zapytań

Krótka nazwa, taka jak database, może być testowana z jednym lub kilkoma sufiksami wyszukiwania, zanim resolver spróbuje jej jako nazwy absolutnej. Reguła ndots wpływa na ten porządek. Nieprawidłowe lub zbyt szerokie ustawienia wyszukiwania mogą generować kilka negatywnych zapytań na każdy udany wynik.

Przewodnik Netdata dotyczący rozwiązywania problemów z DNS w kontenerach wskazuje ndots i domeny wyszukiwania jako przyczyny wolnych startów i blokujących zapytań. To ryzyko zależne od konfiguracji, a nie powód, by wymuszać jedną wartość ndots w każdym środowisku.

Stan DNS	Efekt zapytania	Widoczny objaw	Przydatny pomiar
Wolne wbudowane przekazywanie	Opóźnienie przed odpowiedzią nadrzędną	Kontener wolny, host szybki	Porównaj dig z hosta i kontenera
Rozszerzenie sufiksu wyszukiwania	Wiele negatywnych zapytań na nazwę	Krótki nazwy zatrzymują się okresowo	Zarejestruj nazwy i liczbę zapytań
Brak skutecznej pamięci podręcznej	Powtarzające się zapytania do nadrzędnego resolvera	Wysoki ruch resolvera	Wskaźnik trafień w cache i liczba zapytań
Utrata UDP lub fallback	Ponowne próby lub zapytanie TCP	Skoki opóźnień o rozmiarze timeoutu	Ponowne próby, obcięcia i czas odpowiedzi

Krótkotrwałe połączenia mnożą koszt wyszukiwania

Aplikacja, która ponownie używa połączenia z bazą danych lub HTTP, rozwiązuje nazwę rzadziej. Kontroler stanu, worker lub klient z kiepskim poolingiem może tworzyć nowe połączenie dla każdego zadania. Nawet umiarkowane opóźnienie DNS wtedy wielokrotnie pojawia się na ścieżce krytycznej.

Prawdziwy przypadek DNS kontener kontra host pokazuje wielosekundowe wyszukiwania w kontenerze, podczas gdy zapytania hosta pozostawały szybkie. Oddzielny raport o opóźnieniach w wbudowanym DNS odnotowuje ten sam kontrast diagnostyczny, co czyni go użytecznym pierwszym podziałem przed obwinianiem aplikacji.

Pamięć podręczna pomaga tylko w ramach TTL i zakresu

Pamięć podręczna DNS przechowuje odpowiedź do wygaśnięcia czasu życia (TTL), zmniejszając liczbę zapytań i opóźnienie startu. Wyjaśnienie pamięci podręcznej DNS opisuje, jak buforowane odpowiedzi zmniejszają obciążenie sieci, ale środowiska uruchomieniowe kontenerów, aplikacje i lokalne resolvery mogą mieć różne zachowania cache.

Pamięć podręczna nie jest uniwersalnym lekarstwem. Bardzo krótkie TTL, często zmieniające się rekordy usług, negatywne wyszukiwania i zachowanie resolvera na poziomie procesu mogą utrzymywać wysoką liczbę zapytań. Nieudana lub przeciążona lokalna pamięć podręczna staje się też współdzielonym zależnym elementem dla każdej usługi, która na nią wskazuje.

DNS jest wąskim gardłem tylko przed rozpoczęciem połączenia

Mierz czas wyszukiwania oddzielnie od nawiązywania połączenia TCP, negocjacji TLS, pierwszego bajtu i odpowiedzi aplikacji. Jeśli rozwiązywanie nazw jest szybkie, ale żądanie wolne, zmiana resolvera nie naprawi usługi. Jeśli dostęp do surowego IP jest szybki, a dostęp nazwany się zatrzymuje, sprawdź ścieżkę resolvera kontenera i sekwencję zapytań.

Analiza opóźnień DNS w serwerze domowym ustala tę granicę czasową. Jej wyjaśnienie opóźnień wirtualnych mostów pomaga oddzielić DNS od ścieżki pakietów następującej po rozwiązywaniu nazw.

FAQ

Dlaczego DNS jest szybki na hoście, ale wolny w kontenerze?

Kontener może używać wbudowanego resolvera, innych domen wyszukiwania, odziedziczonych serwerów DNS lub oddzielnej przestrzeni nazw sieci. Porównaj pliki resolvera i mierzone zapytania z obu lokalizacji.

Czy kontenery powinny używać publicznego DNS do lokalnych nazw usług?

Nie. Publiczne resolvery nie znają prywatnych aliasów kontenerów. Używaj wykrywania usług runtime lub autorytatywnego lokalnego resolvera z niezawodnym przekazywaniem dla nazw zewnętrznych.

Czy pamięć podręczna DNS może zepsuć wykrywanie usług w kontenerach?

Przestarzałe odpowiedzi mogą opóźnić rozpoznanie zmienionego adresu usługi do wygaśnięcia TTL. Polityka cache musi wyważać redukcję zapytań z szybkością zmian środowiska.