Pod, węzeł czy klaster: co właściwie przekierowuje sidecar VPN

Sidecar VPN w Podzie Kubernetesa wygląda jak VPN na poziomie hosta z lepszymi manierami, a podobieństwo kończy się na granicy przestrzeni nazw. Kontenery w jednym Podzie dzielą przestrzeń nazw sieci, w tym przestrzeń adresów i portów, więc sidecar instalujący trasy i politykę naprawdę zmienia, dokąd trafiają pakiety aplikacji. Nie zmienia niczego dla pozostałych Podów na węźle i nie dotyka własnego stosu węzła, o ile go tak nie skonfigurujesz. Dobre zrozumienie tej granicy decyduje zarówno o tym, co możesz wdrożyć, jak i o tym, co musisz przetestować. Kolejne sekcje śledzą to od przestrzeni nazw na zewnątrz.

Wspólna przestrzeń nazw, wspólne konsekwencje

Dwa kontenery w Podzie rozmawiają przez loopback i widzą te same interfejsy, i właśnie dlatego wzorzec sidecara w ogóle działa: aplikacja nie musi wiedzieć, że istnieje tunel, bo trasa, na którą trafia, została zainstalowana w przestrzeni nazw, której używa. Ta sama właściwość oznacza, że błędy sidecara są błędami aplikacji. Trasa, która przechwytuje zbyt wiele, albo zmiana DNS wskazująca resolver wewnątrz tunelu, obowiązuje natychmiast dla każdego procesu w tym Podzie. We wspólnej przestrzeni nazw nie ma routingu per kontener, więc sidecara nie można ograniczyć do jednego procesu.

To mechanizm, o którym warto pamiętać podczas przeglądu: promień rażenia to Pod, nie węzeł i nie klaster.

Czego sidecar nie dosięga

Inne Pody zachowują własne przestrzenie nazw i własny routing, więc obciążenie potrzebujące tego samego wyjścia potrzebuje tego samego sidecara albo zamiast tego projektu na poziomie węzła. Ruch węzła także jest poza przestrzenią nazw Poda, a Pody z siecią hosta świadomie całkowicie rezygnują z tej izolacji. Jeśli uruchomisz sidecara z siecią hosta, żeby dotrzeć do czegoś wygodnego, rozszerzyłeś zakres z jednego Poda na cały węzeł i powinieneś powiedzieć to głośno.

Ruch do usług klastra to druga częsta niespodzianka. Szeroka trasa domyślna wewnątrz Poda może przechwycić żądania kierowane do serwera API lub usługi ClusterIP, które potem zawodzą w sposób wyglądający jak zepsuty tunel.

Plan tras: zakresy Poda, usług, węzła i VPN

Zapisz cztery zakresy i sprawdź je pod kątem nakładania, zanim cokolwiek wdrożysz: CIDR Poda, CIDR usług, adresy węzła i cele za VPN. Nakładanie się prywatnych zakresów VPN i własnej przestrzeni klastra nie jest rzadkie, a trasa domyślna jest na to złym rozwiązaniem. Plan tras należy do tego samego repozytorium co manifest, bo następny klaster może przydzielić zupełnie inne zakresy Podów i usług.

DNS jest częścią planu, a nie osobnym zmartwieniem. Sidecar, który przepisuje konfigurację resolwera, może zepsuć odkrywanie usług wewnątrz klastra, podczas gdy zapytania zewnętrzne działają bezbłędnie.

Start i awaria to stany jawne

Działający proces sidecara nie jest polityką wyjścia. Zdecyduj, jaki ruch może płynąć, zanim tunel będzie gotowy, oraz co się stanie, jeśli potem umrze, a następnie wdróż tę decyzję: sonda bramkująca kontener aplikacji, polityka sieciowa domyślnie odmawiająca albo oba te elementy. Bez jednego z nich aplikacja startuje, rozwiązuje nazwy i wysyła ruch poza normalną ścieżkę węzła, podczas gdy tunel wciąż się łączy.

Ta luka jest krótka w zdrowym klastrze i trwała w zepsutym, i dokładnie tę właściwość preferuje atakujący albo przypadkowy wyciek danych.

Połącz kolejność z testem awarii. Zabij sidecara i potwierdź, że aplikacja traci zamierzone wyjście, a nie po cichu wraca do poprzedniego stanu.

Uprawnienia, polityki i testy z kontenera aplikacji

Przyznanie uprawnień potrzebnych do tworzenia interfejsów i zmiany tras to decyzja o przywilejach, a przywilej odpowiedni dla izolowanego Poda nie jest automatycznie odpowiedni na stosie węzła. Korzystaj z mechanizmów polityki sieciowej i bezpieczeństwa obsługiwanych przez klaster i nie zakładaj, że każda implementacja CNI lub polityki traktuje interfejs VPN tak samo; różnice ujawniają się dokładnie w tych przypadkach awarii, na których ci zależy.

Testuj z prawdziwego kontenera aplikacji, świeżymi żądaniami do celu prywatnego, usługi klastra i publicznego internetu. Test z sidecara dowodzi, że tunel działa, a nie że aplikacja dociera do tego, czego potrzebuje.

Udokumentuj założenia sieciowe klastra obok konfiguracji VPN. Przeniesienie obciążenia do innego klastra jest wtedy ćwiczeniem ze sprawdzania planu tras, a nie zmianą obrazu, która po cichu przestaje działać.