Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS)
W przypadku opartego na kontenerach podejścia mikrousług do tworzenia aplikacji składniki aplikacji współpracują ze sobą w celu przetwarzania zadań. Platforma Kubernetes udostępnia różne zasoby umożliwiające współpracę:
- Możesz łączyć się z aplikacjami i uwidaczniać je wewnętrznie lub zewnętrznie.
- Aplikacje o wysokiej dostępności można tworzyć, równoważąc obciążenie aplikacji.
- Aby zwiększyć bezpieczeństwo, można ograniczyć przepływ ruchu sieciowego do zasobników i węzłów lub między nimi.
- Można skonfigurować ruch przychodzący na potrzeby kończenia żądań SSL/TLS lub routingu wielu składników dla bardziej złożonych aplikacji.
W tym artykule przedstawiono podstawowe pojęcia, które zapewniają sieć aplikacjom w usłudze AKS:
Podstawy sieci platformy Kubernetes
Platforma Kubernetes wykorzystuje warstwę sieci wirtualnej do zarządzania dostępem w aplikacjach i między aplikacjami lub ich składnikami:
Węzły kubernetes i sieć wirtualna: węzły Kubernetes są połączone z siecią wirtualną. Ta konfiguracja umożliwia zasobnikom (podstawowym jednostkom wdrażania na platformie Kubernetes) łączność przychodzącą i wychodzącą.
Składnik kube-proxy: serwer kube-proxy działa w każdym węźle i jest odpowiedzialny za zapewnienie niezbędnych funkcji sieciowych.
Dotyczy określonych funkcji platformy Kubernetes:
- Moduł równoważenia obciążenia: moduł równoważenia obciążenia umożliwia równomierne dystrybuowanie ruchu sieciowego między różnymi zasobami.
- Kontrolery ruchu przychodzącego: ułatwiają one routing warstwy 7, który jest niezbędny do kierowania ruchem aplikacji.
- Kontrola ruchu wychodzącego: platforma Kubernetes umożliwia zarządzanie ruchem wychodzącym z węzłów klastra i sterowanie nim.
- Zasady sieciowe: te zasady umożliwiają środki zabezpieczeń i filtrowanie ruchu sieciowego w zasobnikach.
W kontekście platformy Azure:
- Platforma Azure usprawnia sieć wirtualną dla klastrów usługi AKS (Azure Kubernetes Service).
- Tworzenie modułu równoważenia obciążenia Kubernetes na platformie Azure jednocześnie konfiguruje odpowiedni zasób modułu równoważenia obciążenia platformy Azure.
- Podczas otwierania portów sieciowych do zasobników platforma Azure automatycznie konfiguruje niezbędne reguły sieciowej grupy zabezpieczeń.
- Platforma Azure może również zarządzać zewnętrznymi konfiguracjami DNS na potrzeby routingu aplikacji HTTP w miarę ustanawiania nowych tras ruchu przychodzącego.
Sieci wirtualne platformy Azure
W usłudze AKS można wdrożyć klaster, który używa jednego z następujących modeli sieciowych:
Sieć Kubenet
Zasoby sieciowe są zwykle tworzone i konfigurowane jako klaster usługi AKS jest wdrażany.
Sieć usługi Azure Container Networking Interface (CNI)
klaster usługi AKS jest połączony z istniejącymi zasobami i konfiguracjami sieci wirtualnej.
Sieć Kubenet (podstawowa)
Opcja sieci kubenet jest domyślną konfiguracją tworzenia klastra usługi AKS. Za pomocą rozwiązania kubenet:
- Węzły otrzymują adres IP z podsieci sieci wirtualnej platformy Azure.
- Zasobniki odbierają adres IP z logicznie innej przestrzeni adresowej niż podsieć sieci wirtualnej platformy Azure węzłów.
- Dzięki skonfigurowaniu translatora adresów sieciowych (NAT) zasobniki mogą uzyskać dostęp do zasobów w sieci wirtualnej platformy Azure.
- Źródłowy adres IP ruchu jest tłumaczony na podstawowy adres IP węzła.
Węzły używają wtyczki kubenet Kubernetes. Możesz zezwolić platformie Azure na tworzenie i konfigurowanie sieci wirtualnych lub wdrożenie klastra usługi AKS w istniejącej podsieci sieci wirtualnej.
Tylko węzły otrzymują routingowy adres IP. Zasobniki używają translatora adresów sieciowych do komunikowania się z innymi zasobami spoza klastra usługi AKS. Takie podejście zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby zasobniki były używane.
Uwaga
Chociaż rozwiązanie kubenet jest domyślną opcją sieciową dla klastra usługi AKS w celu utworzenia sieci wirtualnej i podsieci, nie jest zalecane w przypadku wdrożeń produkcyjnych. W przypadku większości wdrożeń produkcyjnych należy zaplanować sieć azure CNI i używać jej ze względu na lepszą skalowalność i wydajność.
Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci kubenet dla klastra usługi AKS.
Sieć usługi Azure CNI (zaawansowana)
W sieci Azure CNI każdy zasobnik uzyskuje adres IP z podsieci i jest dostępny bezpośrednio. Te adresy IP muszą być planowane z wyprzedzeniem i unikatowe w przestrzeni sieciowej. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby zasobników, które obsługuje. Równoważna liczba adresów IP na węzeł jest następnie zarezerwowana z góry. Takie podejście może prowadzić do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji, dlatego ważne jest, aby prawidłowo zaplanować. Aby uniknąć tych wyzwań związanych z planowaniem, można włączyć funkcję sieci CNI platformy Azure na potrzeby dynamicznej alokacji adresów IP i rozszerzonej obsługi podsieci.
Uwaga
Ze względu na ograniczenia platformy Kubernetes nazwa grupy zasobów, nazwa sieci wirtualnej i nazwa podsieci muszą zawierać 63 znaki lub mniej.
W przeciwieństwie do rozwiązania kubenet ruch do punktów końcowych w tej samej sieci wirtualnej nie jest tłumaczony na podstawowy adres IP węzła. Adres źródłowy ruchu wewnątrz sieci wirtualnej to adres IP zasobnika. Ruch zewnętrzny do sieci wirtualnej nadal jest kierowany do podstawowego adresu IP węzła.
Węzły używają wtyczki Azure CNI Kubernetes.
Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi Azure CNI dla klastra usługi AKS.
Sieć nakładki usługi Azure CNI
Nakładka CNI platformy Azure reprezentuje ewolucję interfejsu CNI platformy Azure, zajmując się skalowalnością i planowaniem wyzwań wynikających z przypisywania adresów IP sieci wirtualnej do zasobników. Nakładka CNI platformy Azure przypisuje prywatne adresy IP CIDR do zasobników. Prywatne adresy IP są oddzielone od sieci wirtualnej i mogą być ponownie używane w wielu klastrach. Nakładka CNI platformy Azure może być skalowana poza limit 400 węzłów wymuszony w klastrach Kubenet. Nakładka CNI platformy Azure jest zalecaną opcją dla większości klastrów.
Usługa Azure CNI obsługiwana przez Cilium
Usługa Azure CNI obsługiwana przez cilium używa cilium w celu zapewnienia sieci o wysokiej wydajności, możliwości obserwowania i wymuszania zasad sieciowych. Integruje się ona natywnie z nakładką usługi Azure CNI na potrzeby skalowalnego zarządzania adresami IP (IPAM).
Ponadto funkcja Cilium domyślnie wymusza zasady sieciowe bez konieczności używania oddzielnego aparatu zasad sieciowych. Usługa Azure CNI obsługiwana przez narzędzie Cilium może być skalowana poza limity 250 węzłów /20 K zasobnika usługi Azure Network Policy Manager przy użyciu programów eBPF i bardziej wydajnej struktury obiektów interfejsu API.
Usługa Azure CNI obsługiwana przez cilium jest zalecaną opcją dla klastrów wymagających wymuszania zasad sieciowych.
Stosowanie własnej usługi CNI
Istnieje możliwość zainstalowania w usłudze AKS sieci CNI innej niż Microsoft przy użyciu funkcji Bring your own CNI .
Porównanie modeli sieciowych
Zarówno platforma kubenet, jak i usługa Azure CNI zapewniają łączność sieciową dla klastrów usługi AKS. Jednak istnieją zalety i wady każdej z nich. Na wysokim poziomie mają zastosowanie następujące zagadnienia:
kubenet
- Oszczędza przestrzeń adresów IP.
- Używa wewnętrznych lub zewnętrznych modułów równoważenia obciążenia platformy Kubernetes, aby uzyskać dostęp do zasobników spoza klastra.
- Ręcznie zarządzasz trasami zdefiniowanymi przez użytkownika i zarządzasz nimi.
- Maksymalnie 400 węzłów na klaster.
Azure CNI
- Zasobniki uzyskują pełną łączność sieci wirtualnej i mogą być dostępne bezpośrednio za pośrednictwem ich prywatnego adresu IP z połączonych sieci.
- Wymaga więcej przestrzeni adresowej IP.
| Model sieci | Kiedy używać |
|---|---|
| Kubenet | • Konwersacja przestrzeni adresów IP jest priorytetem. • Prosta konfiguracja. • Mniej niż 400 węzłów na klaster. • Wewnętrzne lub zewnętrzne moduły równoważenia obciążenia platformy Kubernetes są wystarczające do dotarcia do zasobników spoza klastra. • Ręczne zarządzanie trasami zdefiniowanymi przez użytkownika i zarządzanie nimi jest dopuszczalne. |
| Azure CNI | • Pełna łączność sieci wirtualnej jest wymagana dla zasobników. • Potrzebne są zaawansowane funkcje usługi AKS (takie jak węzły wirtualne). • Dostępna jest wystarczająca przestrzeń adresowa IP. • Wymagane jest połączenie zasobnika z zasobnikami i zasobnikami z maszyną wirtualną. • Zasoby zewnętrzne muszą bezpośrednio docierać do zasobników. • Wymagane są zasady sieciowe usługi AKS. |
| Nakładka Azure CNI | • Brak adresów IP jest problemem. • Skalowanie do 1000 węzłów i 250 zasobników na węzeł jest wystarczające. • Dodatkowy przeskok dla łączności zasobnika jest akceptowalny. • Prostsza konfiguracja sieci. • Wymagania dotyczące ruchu wychodzącego usługi AKS można spełnić. |
Istnieją następujące różnice między rozwiązaniem kubenet i usługą Azure CNI:
| Możliwość | Kubenet | Azure CNI | Nakładka Azure CNI | Usługa Azure CNI obsługiwana przez Cilium |
|---|---|---|---|---|
| Wdrażanie klastra w istniejącej lub nowej sieci wirtualnej | Obsługiwane — ręczne stosowanie tras zdefiniowanych przez użytkownika | Obsługiwane | Obsługiwane | Obsługiwane |
| Łączność zasobnika | Obsługiwane | Obsługiwane | Obsługiwane | Obsługiwane |
| Łączność zasobnika z maszyną wirtualną; Maszyna wirtualna w tej samej sieci wirtualnej | Działa po zainicjowaniu przez zasobnik | Działa na oba sposoby | Działa po zainicjowaniu przez zasobnik | Działa po zainicjowaniu przez zasobnik |
| Łączność zasobnika z maszyną wirtualną; Maszyna wirtualna w równorzędnej sieci wirtualnej | Działa po zainicjowaniu przez zasobnik | Działa na oba sposoby | Działa po zainicjowaniu przez zasobnik | Działa po zainicjowaniu przez zasobnik |
| Dostęp lokalny przy użyciu sieci VPN lub usługi Express Route | Działa po zainicjowaniu przez zasobnik | Działa na oba sposoby | Działa po zainicjowaniu przez zasobnik | Działa po zainicjowaniu przez zasobnik |
| Dostęp do zasobów zabezpieczonych przez punkty końcowe usługi | Obsługiwane | Obsługiwane | Obsługiwane | |
| Uwidaczniaj usługi Kubernetes przy użyciu usługi równoważenia obciążenia, usługi App Gateway lub kontrolera ruchu przychodzącego | Obsługiwane | Obsługiwane | Obsługiwane | Te same ograniczenia w przypadku korzystania z trybu nakładki |
| Obsługa pul węzłów systemu Windows | Nieobsługiwany | Obsługiwane | Obsługiwane | Dostępne tylko dla systemu Linux, a nie dla systemu Windows. |
| Domyślne strefy DNS i prywatne platformy Azure | Obsługiwane | Obsługiwane | Obsługiwane |
Aby uzyskać więcej informacji na temat usług Azure CNI i kubenet oraz w celu określenia, która opcja jest najlepsza dla Ciebie, zobacz Konfigurowanie sieci usługi Azure CNI w usłudze AKS i Korzystanie z sieci kubenet w usłudze AKS.
Zakres obsługi między modelami sieciowymi
Niezależnie od używanego modelu sieci, zarówno kubenet, jak i azure CNI można wdrożyć w jeden z następujących sposobów:
- Platforma Azure może automatycznie tworzyć i konfigurować zasoby sieci wirtualnej podczas tworzenia klastra usługi AKS.
- Możesz ręcznie utworzyć i skonfigurować zasoby sieci wirtualnej oraz dołączyć je do tych zasobów podczas tworzenia klastra usługi AKS.
Chociaż funkcje, takie jak punkty końcowe usługi lub trasy zdefiniowane przez użytkownika, są obsługiwane zarówno w przypadku platformy Kubenet, jak i usługi Azure CNI, zasady pomocy technicznej usługi AKS definiują, jakie zmiany można wprowadzić. Na przykład:
- Jeśli ręcznie utworzysz zasoby sieci wirtualnej dla klastra usługi AKS, będziesz obsługiwana podczas konfigurowania własnych tras zdefiniowanych przez użytkownika lub punktów końcowych usługi.
- Jeśli platforma Azure automatycznie tworzy zasoby sieci wirtualnej dla klastra usługi AKS, nie można ręcznie zmienić tych zasobów zarządzanych przez usługę AKS w celu skonfigurowania własnych tras zdefiniowanych przez użytkownika lub punktów końcowych usługi.
Kontrolery ruchu przychodzącego
Podczas tworzenia usługi typu LoadBalancer należy również utworzyć bazowy zasób modułu równoważenia obciążenia platformy Azure. Moduł równoważenia obciążenia jest skonfigurowany do dystrybucji ruchu do zasobników w usłudze na danym porcie.
Moduł LoadBalancer działa tylko w warstwie 4. W warstwie 4 usługa nie zna rzeczywistych aplikacji i nie może jeszcze bardziej rozważyć routingu.
Kontrolery ruchu przychodzącego działają w warstwie 7 i mogą używać bardziej inteligentnych reguł do dystrybucji ruchu aplikacji. Kontrolery ruchu przychodzącego zwykle kierują ruch HTTP do różnych aplikacji na podstawie adresu URL ruchu przychodzącego.
Porównanie opcji ruchu przychodzącego
W poniższej tabeli wymieniono różnice funkcji między różnymi opcjami kontrolera ruchu przychodzącego:
| Funkcja | Dodatek routingu aplikacji | Usługa Application Gateway dla kontenerów | Siatka usług oparta na usłudze Azure Service Mesh/Istio |
|---|---|---|---|
| Ruch przychodzący/kontroler bramy | Kontroler ruchu przychodzącego NGINX | aplikacja systemu Azure Gateway for Containers | Brama ruchu przychodzącego Istio |
| API | Interfejs API ruchu przychodzącego | Interfejs API ruchu przychodzącego i interfejs API bramy | Interfejs API bramy |
| Hosting | W klastrze | Hostowana na platformie Azure | W klastrze |
| Skalowanie | Skalowanie automatyczne | Skalowanie automatyczne | Skalowanie automatyczne |
| Równoważenie obciążenia | Wewnętrzne/zewnętrzne | Zewnętrzne | Wewnętrzne/zewnętrzne |
| Kończenie żądań SSL | W klastrze | Tak: odciążanie i protokół E2E SSL | W klastrze |
| Mtls | Nie dotyczy | Tak do zaplecza | Nie dotyczy |
| Statyczny adres IP | Nie dotyczy | Nazwa FQDN | Nie dotyczy |
| Usługa Azure Key Vault przechowywała certyfikaty SSL | Tak | Tak | Nie dotyczy |
| Integracja usługi Azure DNS z zarządzaniem strefami DNS | Tak | Tak | Nie dotyczy |
W poniższej tabeli wymieniono różne scenariusze, w których można użyć każdego kontrolera ruchu przychodzącego:
| Opcja ruchu przychodzącego | Kiedy używać |
|---|---|
| Zarządzany serwer NGINX — dodatek routingu aplikacji | • Hostowane w klastrze, dostosowywalne i skalowalne kontrolery ruchu przychodzącego NGINX. • Podstawowe możliwości równoważenia obciążenia i routingu. • Konfiguracja wewnętrznego i zewnętrznego modułu równoważenia obciążenia. • Konfiguracja statycznego adresu IP. • Integracja z usługą Azure Key Vault na potrzeby zarządzania certyfikatami. • Integracja ze strefami usługi Azure DNS na potrzeby zarządzania publicznym i prywatnym systemem DNS. • Obsługuje interfejs API ruchu przychodzącego. |
| Usługa Application Gateway dla kontenerów | • Brama ruchu przychodzącego hostowana na platformie Azure. • Elastyczne strategie wdrażania zarządzane przez kontroler lub przynieść własną usługę Application Gateway for Containers. • Zaawansowane funkcje zarządzania ruchem, takie jak automatyczne ponawianie prób, odporność strefy dostępności, wzajemne uwierzytelnianie (mTLS) na cel zaplecza, dzielenie ruchu / ważone działanie okrężne i skalowanie automatyczne. • Integracja z usługą Azure Key Vault na potrzeby zarządzania certyfikatami. • Integracja ze strefami usługi Azure DNS na potrzeby zarządzania publicznym i prywatnym systemem DNS. • Obsługuje interfejsy API ruchu przychodzącego i bramy. |
| Brama ruchu przychodzącego Istio | • Na podstawie envoy, w przypadku korzystania z istio dla siatki usług. • Zaawansowane funkcje zarządzania ruchem, takie jak ograniczanie szybkości i przerywanie obwodów. • Obsługa biblioteki mTLS • Obsługuje interfejs API bramy. |
Tworzenie zasobu ruchu przychodzącego
Dodatek routingu aplikacji jest zalecanym sposobem konfigurowania kontrolera ruchu przychodzącego w usłudze AKS. Dodatek routingu aplikacji to w pełni zarządzany kontroler ruchu przychodzącego dla usługi Azure Kubernetes Service (AKS), który udostępnia następujące funkcje:
Łatwa konfiguracja zarządzanych kontrolerów ruchu przychodzącego NGINX na podstawie kontrolera ruchu przychodzącego NGINX Platformy Kubernetes.
Integracja z usługą Azure DNS na potrzeby zarządzania strefami publicznymi i prywatnymi.
Kończenie żądań SSL z certyfikatami przechowywanymi w usłudze Azure Key Vault.
Aby uzyskać więcej informacji na temat dodatku routingu aplikacji, zobacz Managed NGINX ingress with the application routing add-on (Zarządzana ruch przychodzący NGINX z dodatkiem routingu aplikacji).
Zachowywanie źródłowego adresu IP klienta
Skonfiguruj kontroler ruchu przychodzącego, aby zachować źródłowy adres IP klienta na żądaniach do kontenerów w klastrze usługi AKS. Gdy kontroler ruchu przychodzącego kieruje żądanie klienta do kontenera w klastrze usługi AKS, oryginalny źródłowy adres IP tego żądania jest niedostępny dla kontenera docelowego. Po włączeniu zachowania źródłowego adresu IP klienta źródłowy adres IP klienta jest dostępny w nagłówku żądania w obszarze X-Forwarded-For.
Jeśli używasz zachowania źródłowego adresu IP klienta na kontrolerze ruchu przychodzącego, nie możesz użyć przekazywania protokołu TLS. Zachowywanie źródłowego adresu IP klienta i przekazywanie protokołu TLS może być używane z innymi usługami, takimi jak typ modułu LoadBalancer .
Aby dowiedzieć się więcej na temat zachowywania źródłowego adresu IP klienta, zobacz Jak działa zachowywanie źródłowego adresu IP klienta dla usług LoadBalancer w usłudze AKS.
Kontrolowanie ruchu wychodzącego (wychodzącego)
Klastry AKS są wdrażane w sieci wirtualnej i mają zależności wychodzące od usług spoza tej sieci wirtualnej. Te zależności wychodzące są prawie całkowicie zdefiniowane z w pełni kwalifikowanymi nazwami domen (FQDN). Domyślnie klastry usługi AKS mają nieograniczony dostęp do Internetu wychodzący (wychodzący), co umożliwia uruchamianie węzłów i usług w celu uzyskania dostępu do zasobów zewnętrznych zgodnie z potrzebami. W razie potrzeby można ograniczyć ruch wychodzący.
Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze AKS.
Sieciowe grupy zabezpieczeń
Sieciowa grupa zabezpieczeń filtruje ruch dla maszyn wirtualnych, takich jak węzły usługi AKS. Podczas tworzenia usług, takich jak LoadBalancer, platforma Azure automatycznie konfiguruje wszelkie niezbędne reguły sieciowej grupy zabezpieczeń.
Nie trzeba ręcznie konfigurować reguł sieciowej grupy zabezpieczeń w celu filtrowania ruchu dla zasobników w klastrze usługi AKS. W ramach manifestów usługi Kubernetes Service można zdefiniować wymagane porty i przekazywanie oraz umożliwić platformie Azure tworzenie lub aktualizowanie odpowiednich reguł.
Zasady sieciowe umożliwiają również automatyczne stosowanie reguł filtrowania ruchu do zasobników.
Aby uzyskać więcej informacji, zobacz Jak sieciowe grupy zabezpieczeń filtrować ruch sieciowy.
Zasady sieciowe
Domyślnie wszystkie zasobniki w klastrze usługi AKS mogą wysyłać i odbierać ruch bez ograniczeń. Aby zwiększyć bezpieczeństwo, zdefiniuj reguły kontrolujące przepływ ruchu, na przykład:
- Aplikacje zaplecza są widoczne tylko dla wymaganych usług frontonu.
- Składniki bazy danych są dostępne tylko dla warstw aplikacji, które się z nimi łączą.
Zasady sieciowe to funkcja platformy Kubernetes dostępna w usłudze AKS, która umożliwia sterowanie przepływem ruchu między zasobnikami. Możesz zezwolić na ruch do zasobnika lub go zablokować na podstawie ustawień, takich jak przypisane etykiety, przestrzeń nazw lub port ruchu. Chociaż sieciowe grupy zabezpieczeń są lepsze dla węzłów usługi AKS, zasady sieciowe są bardziej odpowiednie, natywnym dla chmury sposobem kontrolowania przepływu ruchu dla zasobników. Ponieważ zasobniki są tworzone dynamicznie w klastrze usługi AKS, wymagane zasady sieciowe można stosować automatycznie.
Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze Azure Kubernetes Service (AKS).
Następne kroki
Aby rozpocząć pracę z siecią usługi AKS, utwórz i skonfiguruj klaster usługi AKS przy użyciu własnych zakresów adresów IP przy użyciu rozwiązania kubenet lub azure CNI.
Aby uzyskać informacje o skojarzonych najlepszych rozwiązaniach, zobacz Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w usłudze AKS.
Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły: