Pod IP, ClusterIP czy wewnętrzny load balancer dla użytkowników VPN

Z VPC CNI Pod może mieć adres z VPC, a użytkownik VPN z właściwą trasą może dotrzeć do niego bezpośrednio. Dzięki temu bezpośredni dostęp do Pod wydaje się najprostszą opcją i rzeczywiście nią jest, dopóki Pod nie zostanie zastąpiony. Adres, który użytkownik pamięta, powinien należeć do aplikacji, a nie do repliki. Porównanie trzech wejść sprowadza się do tego, który obiekt posiada adres i co musi dalej działać, gdy obciążenie się przemieszcza.

Wybieraj najpierw według cyklu życia, a potem według tego, co sieć musi zrobić, aby wejście było osiągalne.

Trzy wejścia, trzy cykle życia

Pod IP należy do Pod: jest przydzielany wraz z nim i zwalniany, gdy się kończy. ClusterIP należy do Service i jest wirtualny, ma sens tylko tam, gdzie istnieje rutowanie usług klastra. Wewnętrzny load balancer należy do zasobu chmury, który kontroler klastra programuje backendami. Te modele własności przewidują awarię, którą otrzymasz: nieaktualny adres, nieosiągalną nazwę lub nieaktualny zestaw backendów.

Zapisz porównanie, zanim wybierzesz. Gdy właściciel i awaria są nazwane, wybór zwykle dokonuje się sam.

Bezpośredni dostęp do Pod: przydatny, tymczasowy

Bezpośredni dostęp jest naprawdę przydatny do kontrolowanej weryfikacji: jeden administrator, jedna krótka sesja, jeden konkretny port. Ale to zła umowa dla użytkowników, ponieważ adres jest szczegółem implementacji, który zmienia się przy każdym wdrożeniu. A zapisanie go w wiki to sposób, w jaki działająca usługa staje się plotką.

Zaprasza to również do szerokich reguł. Uprawnienie jednego administratora do jednego Pod nie jest uprawnieniem do każdego adresu w podsieci węzła i zwykle zapisuje się to drugie.

ClusterIP: ograniczony do klastra z założenia

ClusterIP działa, ponieważ płaszczyzna danych klastra programuje dla niego rutowanie wewnątrz klastra. Z laptopa w VPN adres nic nie znaczy, chyba że coś celowo go ujawni. Nazwa kończąca się na svc.cluster.local należy do DNS klastra, więc skopiowanie jej do klienta z innym resolverem daje nieistniejącą nazwę, a nie błąd rutowania.

ClusterIP pozostaje właściwym wejściem dla wywołujących wewnątrz klastra, w tym innych obciążeń. Po prostu nie jest mechanizmem publikacji dla użytkowników spoza domeny rutowania klastra.

Wewnętrzny load balancer: opublikowana ścieżka

Wewnętrzny load balancer daje stabilny prywatny adres i nazwę, na którą może wskazywać twoja strefa, a kontroler utrzymuje aktualny zestaw backendów, jak opisuje przewodnik EKS po równoważeniu obciążenia. To wejście, które przetrwa zwykłe zastąpienie Pod bez edytowania dokumentu przez kogokolwiek. Kosztuje zasób chmury, konfigurację kontrolera i trasę z VPN, i właśnie te części ludzie nie doceniają.

Używaj modelu kontrolera, który klaster faktycznie uruchamia. Adnotacje napisane dla jednej integracji nie dotyczą innej.

Kto jest adresem źródłowym

Grupy zabezpieczeń widzą źródło, które dociera do ich granicy, a może to być podłączony klient lub przetłumaczony adres, zależnie od ścieżki VPN i równoważenia obciążenia. W węzłach opartych na EC2 zwykłe Pody VPC CNI domyślnie dziedziczą grupy ENI węzła, natomiast obsługiwane konfiguracje mogą dołączać grupy specyficzne dla Pod. Pisz reguły dla udokumentowanej ścieżki, a nie dla domniemanego adresu laptopa.

Trzymaj własny nasłuch i uwierzytelnianie aplikacji jako osobne kontrole. Reguła sieciowa zezwalająca na przepływ nie jest decyzją autoryzacyjną i nie powinna być tak traktowana.

Co przekazać użytkownikom

Daj użytkownikom nazwę usługi, nie adres. Opublikuj nazwę w strefie prywatnej, wskaż na wewnętrzne wejście, a następnie przetestuj, zastępując backendowy Pod, gdy klient trzyma tę samą nazwę otwartą. To ćwiczenie sprawdza właściwość, która ma znaczenie: dotarcie do tej samej aplikacji po rutynowym wdrożeniu.

Trzymaj bezpośredni dostęp do Pod jako udokumentowany wyjątek operacyjny z własnym zakresem, daleko od instrukcji dla użytkowników.