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 platformy Kubernetes
Aby zezwolić na dostęp do aplikacji lub między składnikami aplikacji, platforma Kubernetes udostępnia warstwę abstrakcji sieci wirtualnej. Węzły kubernetes łączą się z siecią wirtualną, zapewniając łączność przychodzącą i wychodzącą dla zasobników. Składnik kube-proxy jest uruchamiany w każdym węźle, aby zapewnić te funkcje sieciowe.
Na platformie Kubernetes:
- Usługi logicznie grupować zasobniki, aby umożliwić bezpośredni dostęp do określonego portu za pośrednictwem adresu IP lub nazwy DNS.
- ServiceTypes umożliwiają określenie, jakiego rodzaju usługi chcesz użyć.
- Ruch można dystrybuować przy użyciu modułu równoważenia obciążenia.
- Routing ruchu aplikacji warstwy 7 można również osiągnąć za pomocą kontrolerów ruchu przychodzącego.
- Możesz kontrolować ruch wychodzący (wychodzący) dla węzłów klastra.
- Zabezpieczenia i filtrowanie ruchu sieciowego dla zasobników jest możliwe za pomocą zasad sieciowych.
Platforma Azure upraszcza również sieć wirtualną dla klastrów usługi AKS. Podczas tworzenia modułu równoważenia obciążenia Platformy Kubernetes należy również utworzyć i skonfigurować bazowy zasób modułu równoważenia obciążenia platformy Azure. Podczas otwierania portów sieciowych do zasobników konfigurowane są odpowiednie reguły sieciowej grupy zabezpieczeń platformy Azure. W przypadku routingu aplikacji HTTP platforma Azure może również skonfigurować zewnętrzny system DNS jako nowe trasy ruchu przychodzącego.
Usługi
Platforma Kubernetes używa usług do logicznego grupowania zestawu zasobników i zapewniania łączności z siecią. Upraszcza to konfigurację sieci na potrzeby obciążeń aplikacji. Możesz określić typ usługi Kubernetes ServiceType , aby określić odpowiedni rodzaj usługi, na przykład jeśli chcesz uwidocznić usługę na zewnętrzny adres IP, który znajduje się poza klastrem. Aby uzyskać więcej informacji, zobacz dokumentację platformy Kubernetes dotyczącą usług publikowania (ServiceTypes).
Dostępne są następujące typy usług:
ClusterIP
KlasterIP tworzy wewnętrzny adres IP do użycia w klastrze usługi AKS. Ta usługa jest dobra dla aplikacji tylko wewnętrznych, które obsługują inne obciążenia w klastrze. Jest to wartość domyślna używana, jeśli nie określisz jawnie typu usługi.
NodePort
NodePort tworzy mapowanie portów w węźle bazowym, które umożliwia dostęp do aplikacji bezpośrednio przy użyciu adresu IP węzła i portu.
LoadBalancer
Usługa LoadBalancer tworzy zasób modułu równoważenia obciążenia platformy Azure, konfiguruje zewnętrzny adres IP i łączy żądane zasobniki z pulą zaplecza modułu równoważenia obciążenia. Aby zezwolić klientom na dostęp do aplikacji, reguły równoważenia obciążenia są tworzone na żądanych portach.
W przypadku równoważenia obciążenia HTTP ruchu przychodzącego innym rozwiązaniem jest użycie kontrolera ruchu przychodzącego.
Nazwa zewnętrzna
Tworzy określony wpis DNS w celu ułatwienia dostępu do aplikacji.
Moduły równoważenia obciążenia i adres IP usług mogą być przypisywane dynamicznie lub można określić istniejący statyczny adres IP. Można przypisać zarówno wewnętrzne, jak i zewnętrzne statyczne adresy IP. Istniejące statyczne adresy IP są często powiązane z wpisem DNS.
Można tworzyć wewnętrzne i zewnętrzne moduły równoważenia obciążenia. Wewnętrzne moduły równoważenia obciążenia mają przypisany tylko prywatny adres IP, więc nie można uzyskać do nich dostępu z Internetu.
Dowiedz się więcej o usługach w dokumentacji platformy Kubernetes.
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.
W przeciwieństwie do rozwiązania kubenet ruch do punktów końcowych w tej samej sieci wirtualnej nie jest translatorem adresów sieciowych do podstawowego adresu 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, która odpowiada wyzwaniom związanym ze skalowalnością i planowaniem wynikających z przypisywania adresów IP sieci wirtualnej do zasobników. Pozwala to osiągnąć, przypisując prywatne adresy IP CIDR do zasobników, które są oddzielone od sieci wirtualnej i mogą być ponownie używane w wielu klastrach. Ponadto nakładka usługi Azure CNI 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ę 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. Korzystając z programów eBPF i bardziej wydajnej struktury obiektów interfejsu API, usługa Azure CNI obsługiwana przez cilium może być skalowana poza limity 250 węzłów /20 000 zasobników usługi Azure Network Policy Manager.
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 firmy 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.
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 |
| 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 | Brak obsługi kontrolera ruchu przychodzącego usługi Application Gateway (AGIC) | Te same ograniczenia w przypadku korzystania z trybu nakładki |
| Obsługa pul węzłów systemu Windows | Nieobsługiwane | Obsługiwane | Obsługiwane | Dostępne tylko dla systemu Linux, a nie dla systemu Windows. |
Jeśli chodzi o system DNS, zarówno wtyczki kubenet, jak i Azure CNI, są oferowane przez CoreDNS, wdrożenie uruchomione w usłudze AKS z własnym skalowaniem automatycznym. Aby uzyskać więcej informacji na temat usługi CoreDNS na platformie Kubernetes, zobacz Dostosowywanie usługi DNS. Domyślnie usługa CoreDNS jest skonfigurowana do przekazywania nieznanych domen do funkcji DNS usługi Azure Virtual Network, w której wdrożono klaster usługi AKS. W związku z tym usługi Azure DNS i Strefy prywatne będą działać dla zasobników działających w usłudze AKS.
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ć. 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.
Tworzenie zasobu ruchu przychodzącego
W usłudze AKS można utworzyć zasób ruchu przychodzącego przy użyciu serwera NGINX, podobnego narzędzia lub funkcji routingu aplikacji HTTP usługi AKS. Po włączeniu routingu aplikacji HTTP dla klastra usługi AKS platforma Azure tworzy kontroler ruchu przychodzącego i zewnętrzny kontroler DNS . W miarę tworzenia nowych zasobów ruchu przychodzącego na platformie Kubernetes wymagane rekordy DNS są tworzone w strefie DNS A specyficznej dla klastra.
Aby uzyskać więcej informacji, zobacz Wdrażanie routingu aplikacji HTTP.
Kontroler ruchu przychodzącego usługi Application Gateway (AGIC)
Za pomocą dodatku Kontrolera ruchu przychodzącego usługi Application Gateway (AGIC) możesz użyć natywnego modułu równoważenia obciążenia usługi Application Gateway platformy Azure na poziomie 7, aby uwidocznić oprogramowanie w chmurze w Internecie. Narzędzie AGIC działa jako zasobnik w klastrze usługi AKS. Korzysta z zasobów ruchu przychodzącego platformy Kubernetes i konwertuje je na konfigurację usługi Application Gateway, która umożliwia bramie równoważenie obciążenia ruchu do zasobników Kubernetes.
Aby dowiedzieć się więcej na temat dodatku AGIC dla usługi AKS, zobacz Co to jest kontroler ruchu przychodzącego usługi Application Gateway?.
Kończenie żądań protokołu SSL/TLS
Kończenie żądań SSL/TLS to kolejna typowa funkcja ruchu przychodzącego. W przypadku dużych aplikacji internetowych, do których uzyskuje się dostęp za pośrednictwem protokołu HTTPS, zasób ruchu przychodzącego obsługuje zakończenie protokołu TLS, a nie w samej aplikacji. Aby zapewnić automatyczne generowanie i konfigurację certyfikatów TLS, można skonfigurować zasób ruchu przychodzącego do używania dostawców, takich jak "Let's Encrypt".
Aby uzyskać więcej informacji na temat konfigurowania kontrolera ruchu przychodzącego NGINX za pomocą funkcji Let's Encrypt, zobacz Ruch przychodzący i TLS.
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: