Historia pytania

Architektury siatki usług ewoluowały od monolitycznych bramek API do rozwiązań opartych na sidecarach, takich jak Istio i Linkerd, aby rozwiązać złożoność komunikacji mikrousług. W miarę jak przedsiębiorstwa przyjmowały strategie wielochmurowe, aby uniknąć uzależnienia od dostawców i zwiększyć odporność, konieczność federacji tych siatek w obrębie heterogenicznych dostawców chmur stała się zasadnicza. Wczesne próby opierały się na scentralizowanych płaszczyznach kontroli lub modelach hub-and-spoke VPN, które wprowadzały nieakceptowalne opóźnienia i pojedyncze punkty awarii dla globalnych aplikacji. Pytanie to syntetyzuje wyzwania napotkane w platformach handlu finansowego i wdrożeniach IoT, wymagających rygorystycznych SLA dotyczących opóźnień oraz zdolności do pracy offline w obliczeniach brzegowych.

Problem

Federacja siatek usług w ramach AWS, Azure i GCP stawia unikalne przeszkody z powodu niekompatybilnych abstrakcji sieciowych, różnych implementacji CNI i zastrzeżonych systemów tożsamości. Ruch między chmurami zazwyczaj przechodzi przez publiczny internet lub kosztowne dedykowane połączenia, wprowadzając zmienne opóźnienia i utratę pakietów, które naruszają wymagania poniżej 50 ms. W przypadku asymetrycznych podziałów sieci — gdzie AWS us-east-1 może osiągnąć GCP europe-west1, ale nie Azure southeast-asia — utrzymanie wzajemnej autoryzacji mTLS staje się niemożliwe, jeśli obciążenia zależą od scentralizowanego dostawcy OIDC. Ponadto efemeryczne węzły brzegowe (takie jak urządzenia 5G MEC lub jednostki pojazdów autonomicznych) nie mają trwałych tożsamości i nie mogą utrzymywać długotrwałych połączeń z centralnymi płaszczyznami kontroli, ale wymagają natychmiastowego włączenia do obszaru bezpieczeństwa bez interwencji ręcznej.

Rozwiązanie

Wdrażanie zdecentralizowanej topologii federacji Istio primary-primary, wykorzystującej SPIFFE/SPIRE do tożsamości obciążeń, niezwiązanej z topologią sieci.

Wdróż regionalne bramy wejściowe w każdej chmurze skonfigurowane jako proxy Envoy z filtrami WASM dla routingu uwzględniającego opóźnienia i równoważenia obciążenia między klastrami. Ustanów tunel WireGuard lub IPsec między regionalnymi bramami, aby szyfrować ruch na poziomie transportu, umożliwiając jednocześnie bezpośrednią komunikację sidecar-to-sidecar dla mTLS na poziomie usługi. Skonfiguruj serwery SPIRE w każdym regionie z federowanymi pakietami zaufania publikowanymi w koszykach S3 z dystrybucją CloudFront, umożliwiając walidację SVID podczas podziałów. Dla węzłów brzegowych wykorzystaj agentów ztunnel siatki ambientowej Istio, którzy bootstrapują się za pomocą konfiguracji hostowanej w S3 i tymczasowych poświadczeń STS, nawiązując wzajemne połączenie TLS z najbliższą regionalną bramą bez potrzeby wymagania stałej łączności z płaszczyzną kontrolną.

Sytuacja z życia

Globalna platforma handlu wysokich częstotliwości wymagała połączenia usług wykonania zamówień w AWS us-east-1 z mikrousługami analizy ryzyka w GCP europe-west1 oraz danymi portfela klientów w Azure southeast-asia. Mandat biznesowy wymagał opóźnienia w obie strony poniżej 50 ms dla wezwań oceny ryzyka między chmurami, aby zapobiec stratom arbitrażowym. Podczas symulowanego cięcia kabla podmorskiego między Ameryką Północną a Europą, istniejący hub VPN IPSec w lokalnym centrum danych firmy stał się wąskim gardłem, zwiększając opóźnienie do 180 ms i powodując przekroczenia czasu TCP, które wstrzymały handel na 12 minut.

Opis problemu

Konstrukcja architektury polegała na scentralizowanej klastry balancerów obciążenia F5 i usług zarządzania domeną Active Directory do autoryzacji, tworząc pojedynczy punkt awarii. Gdy wystąpił podział sieci, obciążenia Azure nie mogły walidować tokenów JWT wobec centralnego serwera AD, co spowodowało kaskadowe awarie autoryzacji. Ponadto nowe węzły obliczeń brzegowych 5G (urządzenia NVIDIA Jetson) musiały dołączyć do siatki, aby lokalnie przetwarzać dane rynkowe, ale standardowy model sidecara Istio przekraczał limit 2 GB RAM sprzętu i wymagał certyfikatów VPN, które zajmowały 45 minut na ręczne przydzielenie.

Rozwiązanie A: Natywne łączenie tranzytowe w chmurze z centralnym zarządzaniem polityką

Podejście to wykorzystuje łączenie AWS Transit Gateway z Azure Virtual WAN i GCP Cloud Interconnect, aby stworzyć pełną sieć mesh. Cały ruch między chmurami przechodzi przez scentralizowane klastry zapór sieciowych zarządzanych przez urządzenia Palo Alto lub Fortinet, zapewniając znajomy obszar bezpieczeństwa. Konfiguracja opiera się na propagacji tras BGP, aby utrzymać łączność, gdy regiony chmurowe są rozbudowywane lub zmniejszane.

Zalety: Natywna integracja zapewnia wysoką przepustowość do 100 Gbps i scentralizowaną widoczność dla audytów zgodności za pomocą natywnych narzędzi chmurowych lub kontrolerów Aviatrix. Podejście to wymaga minimalnych zmian w istniejących pracach inżynieryjnych dotyczących sieci, znanych ze szkieletów MPLS.
Wady: Koszty wyjścia danych przekraczają 0,09 USD za GB dla ruchu między chmurami, co prowadzi do prognozowanych miesięcznych faktur przekraczających 500 tys. USD przy wolumenach platformy handlowej. Architektura wprowadza wąskie gardła w klastrach zapór, które dodają 80-120 ms opóźnienia, łamiąc wymagania poniżej 50 ms. Nie oferuje żadnej wykonalnej ścieżki włączenia dla efemerycznych węzłów brzegowych, które nie mają statycznych adresów IP ani możliwości łączenia z BGP.

**Rozwiązanie B: Cilium siatka klastra z dataplane eBPF **

Ta architektura wdraża Cilium we wszystkich klastrach Kubernetes, wykorzystując eBPF do równoważenia obciążenia na poziomie jądra i szyfrowania WireGuard. Cilium ClusterMesh umożliwia odkrywanie usług w wielu regionach poprzez synchronizację Kubernetes Endpoints w klastrach etcd w każdej chmurze. Dataplane omija całkowicie iptables, redukując obciążenie przetwarzania do poziomów poniżej milisekundy i zapewniając observability za pomocą Hubble bez sidecarów.

Zalety: eBPF zapewnia wyjątkową wydajność przy minimalnym obciążeniu CPU i eliminuje potrzebę sidecarów Envoy dla ruchu warstwy 4. Rozwiązanie oferuje doskonałe bezpieczeństwo dzięki przejrzystemu szyfrowaniu i precyzyjnym politykom sieciowym.
Wady: Cilium wymaga jednorodnych konfiguracji CNI, które są niekompatybilne z trybem nakładki Azure CNI i istniejącymi implementacjami polityki Calico. Łączenie BGP między granicami chmur wymaga skomplikowanej koordynacji z zespołami sieciowymi w chmurze i brakuje mu szczegółowego routingu na poziomie metod gRPC, niezbędnego dla protokołów handlowych. Wsparcie dla węzłów brzegowych pozostaje ograniczone, ponieważ Cilium zakłada trwałe tożsamości węzłów Kubernetes, które nie są odpowiednie dla urządzeń często uruchamiających się na nowo.

Rozwiązanie C: Zdecentralizowana federacja Istio z SPIFFE i siatką ambientową

Przyjmij federację Istio primary-primary, gdzie każda chmura utrzymuje własną płaszczyznę kontroli istiod, synchronizowaną za pomocą potoków GitOps przy użyciu Flux lub ArgoCD. Wdróż SPIRE do atestacji obciążeń, przechowując federowane pakiety zaufania w koszykach S3 z cachowaniem na krawędzi CloudFront dla odporności na podziały. Użyj agentów ztunnel siatki ambientowej Istio na węzłach brzegowych zamiast sidecarów, aby oszczędzać zasoby. Regionalne bramy ustanawiają tunele WireGuard między chmurami, umożliwiając składania sidecarów Envoy komunikację bezpośrednią bez konieczności holowania przez centra.

Zalety: Sidecary Envoy umożliwiają zaawansowane zarządzanie ruchem, w tym routing gRPC, przerywanie obwodów i polityki ponowienia, niezbędne dla protokołów finansowych. Tożsamości SPIFFE buforowane lokalnie przetrwają podziały sieci, ponieważ SVID są walidowane na podstawie publikowanych pakietów S3, a nie z żywych serwerów. Ztunnel zużywa tylko 50 MB RAM na węzeł w porównaniu do 100 MB na pod, pozwalając urządzeniom NVIDIA Jetson w pełni uczestniczyć.
Wady: Złożoność operacyjna znacznie wzrasta, ponieważ zespoły muszą zarządzać trzema niezależnymi płaszczyznami kontroli i upewnić się o zgodności wersji CRD w klastrach EKS, AKS i GKE. Początkowy bootstrap wymaga starannej konfiguracji ról IAM dla dostępu do S3 między chmurami.

Wybrane rozwiązanie i uzasadnienie

Rozwiązanie C zostało wybrane, ponieważ unikalnie spełniało rygorystyczne wymagania dotyczące opóźnień poniżej 50 ms dzięki bezpośredniej komunikacji sidecar-to-sidecar Envoy poprzez tunele WireGuard. Utrzymało gwarancje bezpieczeństwa zerowego zaufania podczas podziałów dzięki tożsamości opartej na SPIFFE, która nie polega na scentralizowanych dostawcach OIDC. Architektura pomieściła węzły brzegowe z ograniczonymi zasobami za pomocą ambientowej siatki ztunnel, podczas gdy rozwiązania A i B zawiodły w przypadku kosztów, opóźnień lub ograniczeń węzłów brzegowych.

Wynik

Po wdrożeniu, opóźnienia między chmurami ustabilizowały się na poziomie 38 ms P99, dobrze w ramach SLA 50 ms. Podczas następnego nieplanowanego podziału między AWS a Azure, system utrzymał 94% przepustowości transakcji, wykorzystując zbuforowane SVID i przestarzałe, ale bezpieczne zasady routingu. Czas dzierżawy węzłów brzegowych spadł z 45 minut do 90 sekund dzięki zautomatyzowanym skryptom bootstrapującym w S3. Miesięczne koszty sieciowe zmniejszyły się o 60% w porównaniu do prognozowanych kosztów łączenia Transit Gateway, oszczędzając około 300 tys. USD miesięcznie.

Co często pomijają kandydaci

Pytanie: Jak SPIRE zapobiega podszywaniu się obciążeń roboczych, gdy regionalny serwer SPIRE jest niedostępny podczas podziału sieci?

Odpowiedź: Agenci SPIRE uruchamiający się na każdym węźle utrzymują lokalne bufory certyfikatów X.509 SVID oraz pakietów zaufania kluczy publicznych. Gdy obciążenie próbuje nawiązać mTLS, druga strona weryfikuje SVID względem lokalnie buforowanego pakietu zamiast pytania do żywego serwera, co zapewnia pomyślność autoryzacji podczas podziałów. SVID mają krótkie TTL (zazwyczaj 5 minut) oraz wiążą się z określonym kluczem prywatnym obciążenia, zapobiegając atakom przechwytywania, nawet jeśli atakujący przechwyci buforowany certyfikat. Nowe obciążenia przystępujące podczas podziału są atestowane przez lokalnego agenta, wykorzystując atestatorów na poziomie węzła, takich jak dokumenty tożsamości instancji AWS IAM lub certyfikaty TPM EK, które nie wymagają łączności między chmurami.

Pytanie: Dlaczego ambientowa siatka Istio redukuje zużycie zasobów dla efemerycznych węzłów brzegowych w porównaniu do tradycyjnej iniekcji sidecar?

Odpowiedź: Tradycyjny Istio wdraża kontener sidecar Envoy w każdym podzie aplikacji, zużywając około 100 MB RAM i 0,5 vCPU na instancję, co wyczerpuje zasoby ograniczonych urządzeń brzegowych, takich jak NVIDIA Jetson. Siatka ambientowa wdraża ztunnel jako DaemonSet na samym węźle, dzieląc zakończenie mTLS i routing warstwy 4 między wszystkimi podami na tym hoście, skutecznie redukując obciążenie na pod do bliskiego zera. Ztunnel wykorzystuje eBPF do wydajnego przekierowywania pakietów na poziomie jądra, unikając kosztów związanych z przechodzeniem przez iptables. Dla efemerycznych węzłów brzegowych, które często dołączają do siatki i opuszczają ją, ztunnel utrzymuje pojedynczą trwałą pulę połączeń do regionalnej bramy, eliminując burzliwe nawiązywanie połączeń i skoki pamięci związane z setkami indywidualnych sidecarów uruchamiających się jednocześnie.

Pytanie: Jak zapobiegasz dryfowi konfiguracji między niezależnymi płaszczyznami kontroli Istio w federacji multi-cloud?

Odpowiedź: Wdrażaj potok GitOps za pomocą Flux lub ArgoCD, który traktuje manekiny VirtualService i AuthorizationPolicy jako pojedyncze źródło prawdy przechowywane w federowanym repozytorium Git. Każda regionalna płaszczyzna kontroli pobiera konfiguracje z tego repozytorium, które jest replikowane w chmurach za pomocą replikacji międzyregionowej AWS CodeCommit lub Geo GitLab. Używaj webhooków przyjęć OPA (Open Policy Agent), aby odrzucić lokalne modyfikacje, które różnią się od stanu repozytorium. Regularnie wykonuj narzędzia analizy konfiguracji Istio w potokach CI/CD, aby wykrywać różnice wersji CRD między klastrami EKS, AKS i GKE przed wdrożeniem, zapewniając surową zgodność.