Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS)

W przypadku podejścia opartego na kontenerach mikrousług do tworzenia aplikacji składniki aplikacji współpracują ze sobą w celu przetwarzania ich zadań. Platforma Kubernetes udostępnia różne zasoby umożliwiające tę 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.
  • W przypadku bardziej złożonych aplikacji można skonfigurować ruch przychodzący na potrzeby kończenia żądań SSL/TLS lub routingu wielu składników.
  • Ze względów bezpieczeństwa można ograniczyć przepływ ruchu sieciowego do zasobników i węzłów lub między nimi.

W tym artykule przedstawiono podstawowe pojęcia, które zapewniają sieć aplikacjom w usłudze AKS:

Podstawy platformy Kubernetes

Aby umożliwić dostęp do aplikacji lub między składnikami aplikacji, platforma Kubernetes zapewnia 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 zezwolić na bezpośredni dostęp do określonego portu za pośrednictwem adresu IP lub nazwy DNS.
  • Ruch można dystrybuować przy użyciu modułu równoważenia obciążenia.
  • Bardziej złożony routing ruchu aplikacji można również osiągnąć za pomocą kontrolerów ruchu przychodzącego.
  • Bezpieczeństwo i filtrowanie ruchu sieciowego dla zasobników jest możliwe za pomocą zasad sieciowych platformy Kubernetes.

Platforma Azure upraszcza również sieć wirtualną dla klastrów usługi AKS. Podczas tworzenia modułu równoważenia obciążenia 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 są konfigurowane odpowiednie reguły sieciowej grupy zabezpieczeń platformy Azure. W przypadku routingu aplikacji HTTP platforma Azure może również skonfigurować zewnętrzną usługę DNS w miarę konfigurowania nowych tras ruchu przychodzącego.

Usługi

Aby uprościć konfigurację sieci dla obciążeń aplikacji, platforma Kubernetes używa usług do logicznego grupowania zestawu zasobników i zapewnienia łączności sieciowej. Dostępne są następujące typy usług:

  • Adres IP klastra

    Tworzy wewnętrzny adres IP do użycia w klastrze usługi AKS. Dobra dla aplikacji tylko wewnętrznych, które obsługują inne obciążenia w klastrze.

    Diagram showing Cluster IP traffic flow in an AKS cluster

  • NodePort

    Tworzy mapowanie portów w węźle bazowym, które umożliwia uzyskiwanie dostępu do aplikacji bezpośrednio przy użyciu adresu IP i portu węzła.

    Diagram showing NodePort traffic flow in an AKS cluster

  • 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 umożliwić klientom ruch do aplikacji, reguły równoważenia obciążenia są tworzone na żądanych portach.

    Diagram showing Load Balancer traffic flow in an AKS cluster

    Aby uzyskać dodatkową kontrolę i routing ruchu przychodzącego, możesz zamiast tego użyć kontrolera ruchu przychodzącego.

  • Nazwa zewnętrzna

    Tworzy określony wpis DNS, aby ułatwić dostęp do aplikacji.

Adres IP modułów równoważenia obciążenia i usług można przypisać dynamicznie lub 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ć zarówno wewnętrzne , jak 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.

Sieci wirtualne platformy Azure

W usłudze AKS można wdrożyć klaster, który jest oparty na jednym z następujących modeli sieciowych:

  • Sieć Kubenet

    Zasoby sieciowe są zwykle tworzone i konfigurowane podczas wdrażania klastra usługi AKS.

  • Sieć interfejsu 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:

  1. Węzły otrzymują adres IP z podsieci sieci wirtualnej platformy Azure.
  2. Zasobniki odbierają adres IP z logicznie innej przestrzeni adresowej niż podsieć sieci wirtualnej platformy Azure węzłów.
  3. Dzięki skonfigurowaniu translatora adresów sieciowych (NAT) zasobniki mogą uzyskać dostęp do zasobów w sieci wirtualnej platformy Azure.
  4. Źródłowy adres IP ruchu jest tłumaczony na podstawowy adres IP węzła.

Węzły używają wtyczki kubenet Kubernetes. Oto co możesz zrobić:

  • Zezwalaj platformie Azure na tworzenie i konfigurowanie sieci wirtualnych dla Ciebie lub
  • Wybierz wdrożenie klastra usługi AKS w istniejącej podsieci sieci wirtualnej.

Pamiętaj, że 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 dla zasobników do użycia.

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. Bez planowania 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.

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, który jest zewnętrzny do sieci wirtualnej, nadal do podstawowego adresu IP węzła.

Węzły używają wtyczki Azure CNI Kubernetes.

Diagram showing two nodes with bridges connecting each to a single Azure VNet

Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi Azure CNI dla klastra usługi AKS.

Porównanie modeli sieciowych

Zarówno platforma kubenet, jak i usługa Azure CNI zapewniają łączność sieciową dla klastrów usługi AKS. Jednak każda z nich ma zalety i wady. Na wysokim poziomie mają zastosowanie następujące kwestie:

  • kubenet
    • Oszczędza przestrzeń adresów IP.
    • Używa wewnętrznego lub zewnętrznego modułu równoważenia obciążenia 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ść z siecią wirtualną i mogą być dostępne bezpośrednio za pośrednictwem ich prywatnego adresu IP z połączonych sieci.
    • Wymaga więcej przestrzeni adresów IP.

Istnieją następujące różnice w zachowaniu między platformą kubenet i usługą Azure CNI:

Możliwość Kubenet Azure CNI
Wdrażanie klastra w istniejącej lub nowej sieci wirtualnej Obsługiwane — ręczne stosowanie tras zdefiniowanych przez użytkownika Obsługiwane
Łączność zasobnika 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
Łączność zasobnika z maszyną wirtualną; Maszyna wirtualna w równorzędnej sieci wirtualnej Działa po zainicjowaniu przez zasobnik Działa na oba sposoby
Dostęp lokalny przy użyciu sieci VPN lub usługi Express Route Działa po zainicjowaniu przez zasobnik Działa na oba sposoby
Dostęp do zasobów zabezpieczonych przez punkty końcowe usługi 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
Domyślna usługa Azure DNS i strefy prywatne Obsługiwane Obsługiwane
Obsługa pul węzłów Windows Nieobsługiwane Obsługiwane

Jeśli chodzi o system DNS, zarówno kubenet, jak i azure CNI wtyczki DNS 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.

Zakres obsługi między modelami sieciowymi

Niezależnie od używanego modelu sieciowego, 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 obsługi 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 wie o rzeczywistych aplikacjach 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 przychodzącego adresu URL.

Diagram showing Ingress traffic flow in an AKS cluster

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 A są tworzone w strefie DNS specyficznej dla klastra.

Aby uzyskać więcej informacji, zobacz Wdrażanie routingu aplikacji HTTP.

kontroler ruchu przychodzącego Application Gateway (AGIC)

Dzięki dodaniu kontrolera ruchu przychodzącego (AGIC) Application Gateway klienci usługi AKS korzystają z natywnego modułu równoważenia obciążenia Application Gateway na poziomie 7 platformy Azure, aby uwidocznić oprogramowanie w chmurze w Internecie. AGIC monitoruje klaster Kubernetes hosta i stale aktualizuje Application Gateway, ujawniając wybrane usługi w Internecie.

Aby dowiedzieć się więcej na temat dodatku AGIC dla usługi AKS, zobacz Co to jest kontroler ruchu przychodzącego 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 PROTOKÓŁ 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 zachowywania ź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 zachowywania ź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 TLS może być używane z innymi usługami, takimi jak typ modułu równoważenia obciążenia .

Grupy zabezpieczeń sieci

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. Wystarczy zdefiniować wymagane porty i przekazywanie w ramach manifestów usługi Kubernetes Service. Pozwól platformie Azure utworzyć lub zaktualizować odpowiednie reguły.

Możesz również użyć zasad sieciowych, aby automatycznie zastosować reguły filtrowania ruchu do zasobników.

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, takie jak:

  • 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 kubernetes dostępna w usłudze AKS, która umożliwia sterowanie przepływem ruchu między zasobnikami. Zezwalasz na ruch do zasobnika lub go odrzucasz 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: