Sidecar VPN potrzebuje reguły startu i reguły awarii

Pod uruchamia kontener tunelu przed aplikacją i pierwsze żądania się udają, co jest dokładnie tym przypadkiem, który ukrywa problem. Kolejność naprawia jeden wyścig i nie mówi nic o ruchu, który aplikacja rozpoczyna cztery godziny później, po awarii tunelu. To dwie osobne decyzje. Zwykle projektuje się tylko jedną z nich.

Kolejność ogranicza tylko pierwsze żądanie

Kubernetes obsługuje cykl życia sidecara zbudowany z restartowalnych kontenerów init. W tym modelu sonda startowa może wstrzymać następny krok inicjalizacji, dopóki tunel nie zgłosi gotowości. To prawdziwe usprawnienie i warto je stosować świadomie, zamiast dodawać sleep do skryptu punktu wejścia. Brama jest tylko tak dobra, jak warunek, który sprawdza.

Poza tym modelem semantyka kolejności należy do używanego środowiska uruchomieniowego lub systemu zależności i nie muszą się one zgadzać. Wdrożenie skopiowane z innej platformy może wyglądać, jakby czekało na tunel, bo aplikacja przypadkiem startuje wolno. To nie ta sama gwarancja i zawodzi pod obciążeniem.

Powiedz, co obserwuje brama: istnieje proces, istnieje interfejs, handshake został ukończony. Każde z tych stwierdzeń jest słabsze niż „ścieżka danych do miejsc docelowych, których potrzebuje ten pod, działa”.

Wymuszaj ścieżkę danych, zamiast ją zakładać

Sonda to sprawdzenie w jednej chwili, a firewall to właściwość obowiązująca między chwilami. Jeśli wymaganiem jest, aby ruch aplikacji nigdy nie wychodził poza tunel, trzeba to wyrazić we współdzielonej przestrzeni nazw sieci jako regułę akceptuj-albo-odrzuć. Kolejność uruchamiania kontenerów nie może nieść tego wymagania. Tylko reguła może.

Kontenery w jednym podzie współdzielą tę przestrzeń nazw, więc punktem egzekwowania jest sama przestrzeń nazw. Cokolwiek napiszesz, musi pozostawić dostępne własne połączenie zewnętrzne tunelu, ponieważ jego blokowanie w celu ochrony aplikacji przecina ścieżkę, której aplikacja potrzebuje.

Zdecyduj jawnie politykę awarii: czy ruch aplikacji ma się całkowicie zatrzymać, gdy tunel jest niezdrowy, czy ma trwać dalej i zostać oznaczony jako niechroniony? Oba podejścia są obronne i żadne z nich nie jest tym, co dostajesz, uruchamiając kontenery w określonej kolejności.

Przetestuj ruch, o którym nie wspomniałeś

Wykonaj nowe żądanie podczas kontrolowanej awarii tunelu i zobacz, czy wychodzi. Następnie powtórz sprawdzenie dla ścieżek, których test adresu wyjścia nigdy nie dotyka: rozwiązywanie DNS wewnątrz klastra, cele IPv6 i usługi osiągane przez adresy wewnętrzne klastra, a nie przez publiczny internet. To ścieżki, które po śmierci tunelu po cichu działają dalej.

Strona adresu wyjścia dowodzi, że jedno żądanie poszło tam, gdzie się spodziewałeś w tej chwili. Nie potrafi zinwentaryzować innych ścieżek, a luka między tym, co przetestowałeś, a tym, do czego pod może dotrzeć, jest miejscem, gdzie żyją ciekawe awarie.

Powtórz test po restarcie sidecara, a nie tylko po czystym starcie. Zrestartowany kontener tunelu może pozostawić przestrzeń nazw z trasami i polityką w stanie pośrednim.

Zapisz rekord wdrożenia

Trzy fakty należą do notatek wdrożeniowych: test gotowości i to, co obserwuje, działanie naprawcze, gdy ten test zawodzi, oraz reguła egzekwowania rządząca ruchem wychodzącym. Dokumentacja kontenerów sidecar obejmuje mechanikę cyklu życia i pozostawia tę decyzję polityczną tobie. Ten podział jest prawidłowy i dlatego polityka zwykle brakuje.

Kontrola stanu brana za ochronę to najdroższy rodzaj zielonego wskaźnika, ponieważ powstrzymuje ludzi od zadawania pytań. Nazwanie jej dokładnie w dokumentacji kosztuje jedno zdanie i temu zapobiega.

Na koniec przetestuj ścieżkę odzyskiwania raz, gdy aplikacja działa. Projekt, który wymaga odtworzenia poda, aby przywrócić ruch wychodzący, jest decyzją i powinien być twoją, a nie odkrytą.