Dlaczego wirtualne mosty opóźniają aplikacje kontenerowe na serwerze domowym?

Wirtualny most może opóźnić aplikację kontenera na serwerze domowym, ponieważ pakiet nie podróżuje już bezpośrednio między fizycznym interfejsem a gniazdem aplikacji. Może przechodzić przez wirtualną parę Ethernet, most programowy, haki routingu i zapory, translację adresów oraz drugą przestrzeń nazw, zanim kontener go odbierze. Każdy krok jest niewielki, ale ścieżka staje się mierzalna, gdy żądania są krótkie, częste lub planowanie CPU jest już napięte.

To nie oznacza, że sieć mostu jest z natury wolna. Sprawny most często dodaje mniej opóźnienia niż DNS, TLS, pamięć masowa czy praca aplikacji. Pytanie brzmi, czy most wnosi zwykły narzut na pakiet, czy ujawnia błędną konfigurację — taką jak problem z MTU, conntrack, filtrowaniem lub zagnieżdżoną wirtualizacją — która zamienia niewielki koszt w wyraźne opóźnienie.

Krótka odpowiedź techniczna

Most Linuksa to przełącznik programowy. Przegląd mostu Red Hat opisuje go jako moduł jądra, który przekazuje pakiety między podłączonymi interfejsami, w tym wirtualnymi interfejsami połączonymi z przestrzeniami nazw sieci. Ramka kontenera wymaga więc dodatkowych decyzji o przekazywaniu, których proces korzystający ze stosu sieciowego hosta może uniknąć.

Most to tylko jedna część trasy. Opublikowane porty kontenera mogą również wywoływać translację docelową przy wejściu i translację źródłową przy wyjściu, podczas gdy reguły zapory i śledzenia połączeń kontrolują przepływ. Połączona praca wykorzystuje cykle CPU, dostęp do pamięci podręcznej i kolejki; pod obciążeniem te krótkie operacje mogą czekać za innymi pakietami i wydłużać opóźnienie końcowe.

Co się dzieje, gdy żądanie przechodzi przez wirtualny most?

Pakiet wchodzi do przestrzeni nazw kontenera

Większość kontenerów z mostem ma jeden koniec wirtualnej pary Ethernet wewnątrz swojej przestrzeni nazw sieci, a partner na hoście. Dla aplikacji interfejs po stronie kontenera zachowuje się jak normalna karta sieciowa. Na hoście partner jest podłączony do mostu, więc odebrana ramka przekracza granicę przestrzeni nazw, zanim dotrze do gniazda TCP kontenera.

To przekazanie nie jest fizycznym retransmisją, ale nadal przesuwa pakiet przez etapy sieciowe jądra i konteksty planowania. Małe odpowiedzi sieciowe sprawiają, że ta stała praca jest bardziej widoczna niż długie transfery: jeśli sama aplikacja potrzebuje tylko ułamka milisekundy, inny ułamek spędzony przed i po niej może znacząco zmienić procentowy udział.

Most wybiera i przekazuje ramkę

Most uczy się, które adresy MAC pojawiają się za jego portami i używa tych informacji do wyboru portu wyjściowego. Dokumentacja sterownika mostu Dockera opisuje sieć mostową jako programowy most łączący kontenery na jednym hoście. Ten projekt zapewnia przydatną izolację i łączność między usługami, ale wprowadza warstwę przekazywania.

Ruch nieznany unicast, broadcast i multicast może być obsługiwany inaczej niż nauczona ramka unicast. Zajęty host może mieć też kilka mostów, wiele wirtualnych portów lub zagnieżdżone wirtualne przełączniki. Problem rzadko dotyczy jednego sprawdzenia w izolacji; to liczba etapów i kolejek, które musi pokonać żądanie i jego odpowiedź.

Filtrowanie, NAT i śledzenie połączeń dodają stan

Publikowanie portu kontenera zwykle tworzy reguły zapory i NAT, które tłumaczą adres i port hosta na kontener. Dokumentacja filtrowania pakietów Dockera wyjaśnia, że tworzy reguły zapory dla sieci mostowych i używa maskaradowania do dostępu zewnętrznego. Nowy przepływ może więc wymagać oceny reguł i utworzenia stanu połączenia, zanim pakiety podążą ustaloną ścieżką.

Duże zestawy reguł, wysoka rotacja połączeń lub prawie pełna tabela conntrack zwiększają to obciążenie. Serwery proxy mogą dodać kolejny etap między kontenerami, więc jedno żądanie przeglądarki może wejść przez opublikowany port, przejść do proxy, a następnie ponownie do aplikacji. Odpowiedź powtarza tę trasę w odwrotnym kierunku.

Normalne obciążenie mostu a rzeczywisty problem z opóźnieniem

Pierwszym testem jest proporcjonalność. Jeśli żądania przez most i sieć hosta różnią się nieznacznie i konsekwentnie, a przepustowość pozostaje zbliżona, różnica może być oczekiwanym kosztem izolacji i translacji. Jeśli opóźnienie skacze o dziesiątki lub setki milisekund, pobieranie się załamuje lub tylko niektóre rozmiary ładunku zawodzą, samo sprawdzenie mostu nie jest wystarczającym wyjaśnieniem.

Raport społeczności Docker ilustruje, dlaczego to rozróżnienie ma znaczenie: użytkownik zauważył, że pobieranie przez mostek stało się dramatycznie wolniejsze, podczas gdy opóźnienie wysyłania było podobne, a dochodzenie rozważało MTU i otaczającą ścieżkę Hyper-V, zamiast traktować ekstremalną utratę jako normalne obciążenie mostka. Ostateczne zachowanie zmieniło się po ponownym uruchomieniu szerszego środowiska hosta.

Mierz warstwami. Porównaj adres IP z nazwą hosta, port kontenera z bezpośrednim adresem przestrzeni nazw aplikacji, tryb mostka z trybem hosta oraz trywialny statyczny punkt końcowy z rzeczywistą aplikacją. Przewodnik ZimaSpace dotyczący oddzielania opóźnienia DNS od czasu odpowiedzi aplikacji pomaga zapobiec obwinianiu mostka za wolne pierwsze wyszukiwanie.

Dlaczego ścieżki Host, macvlan lub ipvlan mogą wydawać się szybsze

Sieć hosta pozwala procesowi kontenera na współdzielenie przestrzeni nazw sieci hosta. Ta ścieżka omija mostek kontenera, publikowanie portów oraz związany z tym skok NAT. Aktualny przewodnik porównujący mostek i tryb hosta podsumowuje tryb hosta jako mający brak wirtualnego mostka lub mapowania portów, dlatego jest to przydatna baza diagnostyczna.

macvlan i ipvlan stosują różne podejścia: mogą dać kontenerom tożsamości dostępne w LAN bez konwencjonalnej ścieżki z opublikowanym portem. Mogą usunąć translację lub zmniejszyć przetwarzanie mostu, ale wprowadzają własne ograniczenia dotyczące dostępności hosta, przełączania, zarządzania adresami i kompatybilności. Krótsza ścieżka pakietu nie oznacza automatycznie prostszego modelu operacyjnego.

Ważny wniosek pochodzi z testu A/B na tym samym hoście, aplikacji, kliencie, protokole i ładunku. Jeśli tryb hosta ledwo zmienia opóźnienie, most nie jest dominującym wąskim gardłem. Jeśli zmienia wynik wyraźnie, przechwytywanie i liczniki powinny wskazać, czy usunięty koszt to NAT, filtrowanie, conntrack, obsługa MTU czy po prostu kolejna przeciążona warstwa wirtualna.

Korzyści i koszty stojące za opóźnieniem

Izolacja i polityka usług to prawdziwe korzyści

Sieci mostowe dają kontenerom oddzielne adresy i przestrzenie nazw, pozwalają wielu aplikacjom wiązać ten sam port wewnętrzny i eksponują tylko porty wybrane przez operatora. Wspierają też odkrywanie nazw usług w sieciach definiowanych przez użytkownika. To są korzyści operacyjne i bezpieczeństwa, a nie przypadkowe obciążenie.

Praktyczna dyskusja o Dockerze wskazuje, że tryb hosta może powodować konflikty portów między wieloma usługami, podczas gdy przestrzenie nazw mostu pozwalają każdemu kontenerowi używać własnych portów za proxy odwrotnym. Usunięcie mostu może wymienić mierzalną mikrooptymalizację na trudniejszą wdrożenie.

Dodatkowy stan tworzy więcej powierzchni awarii

Kosztem jest to, że każda dodana granica musi zgadzać się co do adresów, tras, MTU, sum kontrolnych i polityki zapory. Serwer domowy uruchamiający kontenery wewnątrz maszyny wirtualnej może nałożyć most kontenera na most VM, a następnie na fizyczną sieć LAN. Każda warstwa może być poprawna sama w sobie, podczas gdy połączona ścieżka ujawnia niezgodność.

Stan wymaga również pojemności. Śledzenie połączeń, tabele sąsiadów, kolejki i przetwarzanie softirq CPU mogą stać się punktami krytycznymi podczas skoków obciążenia. Most, który działa normalnie przy dziesięciu przepływach, może wydawać się wolny przy tysiącach, nie dlatego, że jego podstawowy projekt nagle się zmienił, ale dlatego, że jeden współdzielony zasób przekroczył próg.

Praktyczne rozwiązania, które naprawdę mają znaczenie

Zacznij od dowodów czasowych. Użyj powtarzanych żądań HTTP, aby oddzielić zachowanie zimne i ciepłe, a następnie tymczasowo porównaj tryb mostu i hosta na niekrytycznej instancji testowej. Zapisuj medianę i wysokie percentyle opóźnienia, nie pojedynczy wynik. Porównaj też statyczny punkt końcowy ze stroną opartą na bazie danych, aby czas sieci nie był mylony z pracą aplikacji.

Śledź faktyczną ścieżkę. Sprawdź sieć kontenera, parę veth, członkostwo w moście, trasy, opublikowane porty i liczniki zapory. Przechwytuj pakiety na interfejsie fizycznym, moście i interfejsie po stronie kontenera, jeśli to możliwe. Powtarzające się retransmisje, długie przerwy lub pakiet pojawiający się po jednej stronie, a nie po drugiej, zawężają etap, na którym występuje błąd.

Zmniejsz przypadkową złożoność przed zmianą trybu sieci. Umieść ściśle powiązane usługi na tym samym definiowanym przez użytkownika moście, unikaj niepotrzebnych opublikowanych portów między kontenerami, utrzymuj reguły zapory celowe i sprawdzaj wykorzystanie conntrack. Dopasuj MTU na interfejsach fizycznych, VM, tunelu, moście i kontenerze, gdy enkapsulacja zmniejsza użyteczny ładunek.

Wybierz host, macvlan lub ipvlan dopiero po pomiarach uzasadniających kompromis. Tryb hosta może pasować do usługi wrażliwej na opóźnienia z kontrolowanymi portami; most może pozostać lepszym domyślnym rozwiązaniem dla izolacji wielu aplikacji. Celem nie jest usunięcie każdego etapu jądra — chodzi o usunięcie etapu, który dowody pokazują jako opóźniający obciążenie.

Kiedy powinieneś się martwić?

Mała, stabilna różnica, która nie wpływa na interakcję ani przepustowość, to zwykle koszt projektu, a nie wada. Martw się, gdy opóźnienie zmienia się wraz z obciążeniem, tylko jeden kierunek zwalnia, niektóre rozmiary pakietów zawodzą, conntrack zbliża się do pojemności lub przechwytywanie pakietów pokazuje utratę między interfejsami wirtualnymi. Te wzorce wskazują na ograniczoną lub niespójną ścieżkę.

Zbadaj także sytuację, gdy aplikacja działa szybko przez bezpośredni adres kontenera, ale wolno przez opublikowany port hosta. To porównanie skuteczniej izoluje warstwy translacji, filtrowania i proxy niż przełączanie każdego kontenera na tryb hosta. Zachowaj warunki testu, aby trafienie w pamięć podręczną DNS lub ciepła sesja TLS nie zniekształciły wyniku.

Wirtualne mosty opóźniają aplikacje kontenerowe, dodając przydatne etapy przekazywania, izolacji i polityki. W zdrowym serwerze domowym ten koszt powinien być ograniczony. Gdy opóźnienie jest duże, traktuj most jako mapę punktów kontrolnych: zmierz każdą granicę, znajdź etap, na którym znikają czas lub pakiety, i zmień projekt sieci tylko wtedy, gdy dowody wskazują, że to on jest wąskim gardłem.