Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w Azure Kubernetes Service (AKS)

Ważne

W dniu 31 marca 2028 r. sieć kubenet dla Azure Kubernetes Service (AKS) zostanie wycofana.

Aby uniknąć przerw w działaniu usługi, należyzaktualizować do nakładki Azure Container Networking Interface (CNI)przed tą datą, gdy obciążenia działające na Kubenet dla AKS nie będą już obsługiwane.

Podczas tworzenia klastrów i zarządzania nimi w Azure Kubernetes Service (AKS) zapewniasz łączność sieciową dla węzłów i aplikacji. Te zasoby sieciowe obejmują zakresy adresów IP, moduły równoważenia obciążenia i kontrolery ruchu przychodzącego.

Ten artykuł dotyczący najlepszych rozwiązań koncentruje się na łączności sieciowej i zabezpieczeniach dla operatorów klastra. W tym artykule omówiono sposób wykonywania następujących zadań:

• Wyjaśnij tryb sieciowy Azure Container Networking Interface (CNI) w AKS.
• Zaplanuj wymagane adresowanie IP i łączność.
• Dystrybuuj ruch przy użyciu modułów równoważenia obciążenia, kontrolerów ruchu przychodzącego lub zapory aplikacji internetowej (WAF).
• Bezpieczne łączenie z węzłami klastra.

Wybieranie odpowiedniego modelu sieciowego

Wskazówki dotyczące najlepszych rozwiązań

Użyj sieci Azure CNI w usłudze AKS, aby zintegrować z istniejącymi sieciami wirtualnymi lub sieciami lokalnymi (on-premises). Ten model sieci umożliwia większe rozdzielenie zasobów i kontrolek w środowisku przedsiębiorstwa.

Sieci wirtualne zapewniają podstawową łączność dla węzłów AKS oraz klientów, umożliwiając dostęp do aplikacji. Istnieją dwa różne sposoby wdrażania klastrów usługi AKS w sieciach wirtualnych:

• Sieć Azure CNI: Wdrażana jest w sieci wirtualnej i używa wtyczki Kubernetes Azure CNI. Zasobniki otrzymują indywidualne adresy IP, które mogą być kierowane do innych usług sieciowych lub zasobów lokalnych.

Azure CNI jest prawidłową opcją wdrożeń produkcyjnych.

Sieć CNI

Azure CNI to protokół neutralny dla dostawcy, który umożliwia środowisku uruchomieniowemu kontenera wykonywanie żądań do dostawcy sieci. Przypisuje adresy IP do zasobników i węzłów oraz udostępnia funkcje zarządzania adresami IP (IPAM) podczas nawiązywania połączenia z istniejącymi sieciami wirtualnymi Azure. Każdy węzeł i zasobnik otrzymuje adres IP w wirtualnej sieci Azure. Nie ma potrzeby dodatkowego routingu do komunikowania się z innymi zasobami lub usługami.

W szczególności, Azure CNI sieci na potrzeby produkcji umożliwia rozdzielenie kontroli i zarządzania zasobami. Z perspektywy zabezpieczeń często chcesz, aby różne zespoły zarządzały tymi zasobami i zabezpieczały je. Dzięki sieciom Azure CNI można łączyć się z istniejącymi zasobami Azure, zasobami lokalnymi lub innymi usługami bezpośrednio przez adresy IP przypisane do każdego podu.

W przypadku korzystania z sieci CNI Azure, zasób sieci wirtualnej znajduje się w oddzielnej grupie zasobów od klastra AKS. Przekaż uprawnienia tożsamości klastra AKS do uzyskiwania dostępu do tych zasobów i zarządzania nimi. Tożsamość klastra AKS musi mieć co najmniej uprawnienia współtwórcy sieci dla podsieci w sieci wirtualnej.

Jeśli chcesz zdefiniować rolę niestandardową zamiast korzystać z wbudowanej roli Współautora sieci, wymagane są następujące uprawnienia:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Domyślnie AKS używa zarządzanej tożsamości jako tożsamości klastra. Zamiast tego można użyć pryncypału usługi.

• Aby uzyskać więcej informacji na temat delegowania jednostki usługi AKS, zobacz Delegowanie dostępu do innych zasobów Azure.
• Aby uzyskać więcej informacji na temat tożsamości zarządzanych, zobacz Używanie tożsamości zarządzanych.

Gdy każdy węzeł i pod otrzymuje własny adres IP, zaplanuj zakresy adresów dla podsieci AKS. Należy pamiętać o następujących kryteriach:

• Podsieć musi być wystarczająco duża, aby zapewnić adresy IP dla każdego wdrożonego węzła, zasobnika i zasobu sieciowego.
  • W przypadku sieci Azure CNI każdy uruchomiony węzeł ma domyślne limity liczby podów.
• Unikaj używania zakresów adresów IP, które nakładają się na istniejące zasoby sieciowe.
  • Należy zezwolić na łączność z sieciami lokalnymi lub połączonymi sieciami partnerskimi w środowisku Azure.
• Aby obsłużyć zdarzenia zwiększenia skali lub uaktualnienia klastra, w przypisanej podsieci muszą być dostępne dodatkowe adresy IP.
  • Ta dodatkowa przestrzeń adresowa jest szczególnie ważna, jeśli używasz kontenerów Windows Server, ponieważ te pule węzłów wymagają uaktualnienia w celu zastosowania najnowszych poprawek zabezpieczeń. Aby uzyskać więcej informacji na temat węzłów Windows Server, zobacz Zaktualizuj pulę węzłów w usłudze AKS.

Aby obliczyć wymagany adres IP, zobacz Konfigurowanie sieci Azure CNI w usłudze AKS.

Podczas tworzenia klastra z siecią Azure CNI należy określić inne zakresy adresów klastra, takie jak adres mostka platformy Docker, adres IP usługi DNS i zakres adresów usługi. Ogólnie rzecz biorąc, upewnij się, że te zakresy adresów nie nakładają się na siebie ani żadnych sieci skojarzonych z klastrem, w tym żadnych sieci wirtualnych, podsieci, lokalnych i równorzędnych sieci.

Aby uzyskać szczegółowe informacje dotyczące limitów i rozmiaru tych zakresów adresów, zobacz Konfigurowanie sieci CNI Azure w usłudze AKS.

Dystrybuowanie ruchu przychodzącego

Wskazówki dotyczące najlepszych rozwiązań

Aby dystrybuować ruch HTTP lub HTTPS do aplikacji, użyj zasobów wejściowych i kontrolerów. W porównaniu z równoważnikiem obciążenia Azure, kontrolery wejściowe zapewniają dodatkowe funkcje i mogą być zarządzane jako natywne zasoby Kubernetes.

Chociaż moduł równoważenia obciążenia Azure może dystrybuować ruch klientów do aplikacji w klastrze usługi AKS, ma ograniczone możliwości zrozumienia tego ruchu. Zasób modułu równoważenia obciążenia działa w warstwie 4 i dystrybuuje ruch na podstawie protokołu lub portów.

Większość aplikacji internetowych korzystających z protokołu HTTP lub HTTPS powinna używać zasobów przychodzących i kontrolerów platformy Kubernetes, które działają w warstwie 7. Ingress może dystrybuować ruch na podstawie adresu URL aplikacji i obsługiwać zakończenie połączeń TLS/SSL. System Ingress zmniejsza również liczbę ujawnianych i mapowanych adresów IP.

W przypadku równoważnika obciążenia każda aplikacja zazwyczaj potrzebuje publicznego adresu IP przypisanego i zamapowanego na usługę w klastrze AKS. Za pomocą zasobu ruchu przychodzącego pojedynczy adres IP może dystrybuować ruch do wielu aplikacji.

Istnieją dwa składniki wejścia.

1. Zasób wejściowy
2. Kontroler wejściowy

Zasób wejściowy

Zasób ingress jest manifestem YAML kind: Ingress. Definiuje hosta, certyfikaty i reguły kierowania ruchu do usług działających w klastrze AKS.

Poniższy przykładowy manifest YAML dystrybuuje ruch dla myapp.com do jednej z dwóch usług, blogservice lub storeservice oraz kieruje klienta do jednej usługi lub drugiej na podstawie adresu URL, do którego uzyskuje dostęp.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Kontroler wejściowy

Kontroler wejścia to demon, który działa na węźle AKS i obserwuje żądania przychodzące. Ruch jest następnie dystrybuowany na podstawie reguł zdefiniowanych w zasobie ruchu przychodzącego. Chociaż najczęstszy kontroler wejściowy jest oparty na NGINX, usługa AKS nie ogranicza cię do określonego kontrolera. Możesz użyć Application Gateway for Containers, Contour, HAProxy, Traefik itp.

Kontrolery Ingress muszą być przypisane na węźle Linux. Wskaż uruchomienie zasobu na węźle bazującym na systemie Linux, przy pomocy selektora węzłów w manifeście YAML lub wdrożeniu wykresu Helm. Aby uzyskać więcej informacji, zobacz Używanie selektorów węzłów do kontrolowania, gdzie zasobniki są umieszczane w usłudze AKS.

Ingress z dodatkiem routingu aplikacji

Dodatek do routingu aplikacji jest zalecanym sposobem konfigurowania kontrolera Ingress w usłudze AKS. Dodatek routingu aplikacji jest w pełni zarządzanym kontrolerem ruchu przychodzącego dla Azure Kubernetes Service (AKS), który zapewnia następujące funkcje:

• Łatwa konfiguracja zarządzanych kontrolerów Ingress NGINX opartych na Kubernetesowym kontrolerze Ingress NGINX.

• Integracja z Azure DNS do zarządzania strefami publicznymi i prywatnymi.

• Zakończenie sesji SSL z certyfikatami przechowywanymi w Azure Key Vault.

Aby uzyskać więcej informacji na temat dodatku routingu aplikacji, zobacz Zarządzany Ingress NGINX z dodatkiem routingu aplikacji.

Zabezpieczanie ruchu za pomocą zapory aplikacji internetowej (WAF)

Wskazówki dotyczące najlepszych rozwiązań

Aby skanować ruch przychodzący pod kątem potencjalnych ataków, użyj zapory aplikacji internetowej (WAF), takiej jak zapora aplikacji internetowej Barracuda dla zapory aplikacji internetowej Azure lub Azure Application Gateway for Containers. Te bardziej zaawansowane zasoby sieciowe mogą również kierować ruch poza tylko połączenia HTTP i HTTPS lub podstawowe zakończenie protokołu TLS.

Zazwyczaj kontroler wejścia jest zasobem Kubernetes w klastrze AKS, który dystrybuuje ruch do usług i aplikacji. Kontroler działa jako usługa działająca w tle w węźle usługi AKS i korzysta z niektórych zasobów węzła, takich jak CPU, pamięć i przepustowość sieci. W większych środowiskach warto rozważyć następujące kwestie:

• Odciążaj trasowanie tego ruchu lub zakończenie sesji TLS do zasobu sieciowego spoza klastra AKS.
• Skanuj ruch przychodzący pod kątem potencjalnych ataków.

Dla dodatkowej warstwy zabezpieczeń zapora aplikacji internetowej filtruje ruch przychodzący. Dzięki zestawowi reguł program Open Web Application Security Project (OWASP) obserwuje ataki, takie jak zatrucie skryptami między witrynami lub zatruciem plików cookie. Azure Application Gateway for Containers jest zaporą aplikacji internetowej zintegrowaną z klastrami AKS, zapewniającą te funkcje zabezpieczeń przed dotarciem ruchu do klastra i aplikacji AKS.

Ponieważ inne rozwiązania innych firm również wykonują te funkcje, możesz nadal korzystać z istniejących inwestycji lub wiedzy w preferowanym produkcie.

Moduł równoważenia obciążenia lub zasoby wejściowe są stale uruchamiane w klastrze usługi AKS i poprawiają dystrybucję ruchu. Azure Application Gateway dla kontenerów można zarządzać centralnie jako kontroler ruchu przychodzącego z definicją zasobu. Aby rozpocząć, utwórz usługę Application Gateway dla kontenerów.

Sterowanie przepływem ruchu przy użyciu zasad sieciowych

Wskazówki dotyczące najlepszych rozwiązań

Użyj zasad sieciowych, aby zezwolić na ruch do podów lub go zablokować. Domyślnie cały ruch jest dozwolony między podami w klastrze. Aby zwiększyć bezpieczeństwo, zdefiniuj reguły ograniczające komunikację podu.

Polityki sieciowe to funkcja platformy Kubernetes dostępna w usłudze AKS, która umożliwia zarządzanie przepływem ruchu między podami. Zezwalasz na ruch do poda lub go blokujesz na podstawie ustawień, takich jak przypisane etykiety, przestrzeń nazw lub port. Zasady sieci to natywny dla chmury sposób kontrolowania przepływu ruchu dla podów. Ponieważ zasobniki są tworzone dynamicznie w klastrze usługi AKS, wymagane zasady sieciowe można zastosować automatycznie.

Aby użyć zasad sieciowych w usłudze AKS, funkcję można włączyć podczas tworzenia klastra lub w istniejącym klastrze usługi AKS. Jeśli planujesz używać zasad sieciowych, upewnij się, że funkcja jest włączona w klastrze usługi AKS.

Uwaga

Zasady sieci mogą być używane dla węzłów i zasobników opartych na systemie Linux lub Windows w usłudze AKS.

Tworzysz zasady sieciowe jako zasób Kubernetes przy użyciu manifestu YAML. Zasady są stosowane do zdefiniowanych kapsuł, a reguły dotyczące ruchu przychodzącego lub wychodzącego definiują przepływ ruchu.

W poniższym przykładzie zastosowano zasady sieciowe do zasobników z etykietą app: backend. Reguła wejścia zezwala tylko na ruch z podów z etykietą app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Aby rozpocząć korzystanie z zasad, przeczytaj Zabezpieczanie ruchu między zasobnikami za pomocą zasad sieciowych w Azure Kubernetes Service (AKS).

Optymalizowanie rozwiązania DNS za pomocą LocalDNS

Wskazówki dotyczące najlepszych rozwiązań

Włącz usługę LocalDNS w pulach węzłów usługi AKS, aby zwiększyć wydajność, niezawodność i zmniejszyć obciążenie scentralizowanych zasobników CoreDNS.

Rozpoznawanie nazw DNS ma kluczowe znaczenie dla komunikacji między usługami w środowisku Kubernetes. Domyślnie wszystkie zapytania DNS z zasobników są wysyłane do scentralizowanych zasobników CoreDNS, co może stać się wąskim gardłem na dużą skalę. Usługa AKS oferuje LocalDNS, wdrażając serwer proxy DNS jako usługę systemd na każdym węźle. Ten serwer proxy obsługuje zapytania DNS lokalnie, zmniejszając przeskoki sieciowe i opóźnienie rozpoznawania.

LocalDNS również eliminuje conntrack wpisy tabeli dla ruchu DNS, uniemożliwiając conntrack wyczerpanie tabel i warunki wyścigu, które mogą powodować utracone połączenia. Połączenia z lokalnej pamięci podręcznej do CoreDNS są uaktualniane do protokołu TCP, co umożliwia równoważenie połączeń i szybsze czyszczenie wpisów śledzenia.

W przypadku obciążeń wymagających wysokiej dostępności DNS usługa LocalDNS obsługuje obsługę nieaktualnych odpowiedzi buforowanych przez konfigurowalny czas trwania, gdy nadrzędny system DNS jest niedostępny. Ta funkcja pomaga zachować łączność podu i niezawodność usługi podczas tymczasowych awarii DNS.

Aby uzyskać więcej informacji na temat architektury i możliwości localDNS, zobacz Rozpoznawanie nazw DNS w usłudze AKS. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Konfigurowanie lokalnych sieciDNS.

Bezpieczne nawiązywanie połączenia z węzłami za pośrednictwem serwera bastionowego

Wskazówki dotyczące najlepszych rozwiązań

Nie udostępniaj łączności zdalnej z węzłami AKS. Utwórz hosta bastionu lub serwer przesiadkowy w sieci wirtualnej do zarządzania. Użyj hosta bastionu, aby bezpiecznie przekierować ruch do twojego klastra AKS, podczas zadań zdalnego zarządzania.

Większość operacji w usłudze AKS można wykonać przy użyciu narzędzi do zarządzania Azure lub serwera interfejsu API Kubernetes. Węzły usługi AKS są dostępne tylko w sieci prywatnej i nie są połączone z publicznym Internetem. Aby nawiązać połączenie z węzłami i zapewnić konserwację oraz wsparcie, pokieruj połączenia za pośrednictwem hosta bastionu lub serwera przesiadkowego. Sprawdź, czy ten host znajduje się w oddzielnej, bezpiecznie połączonej sieci wirtualnej zarządzania w stosunku do sieci wirtualnej klastra AKS.

Należy również zabezpieczyć sieć zarządzania dla hosta bastionu. Użyj bramy Azure ExpressRoute lub VPN aby nawiązać połączenie z siecią lokalną i kontrolować dostęp przy użyciu sieciowych grup zabezpieczeń.

Następne kroki

Ten artykuł koncentruje się na łączności sieciowej i zabezpieczeniach. Aby uzyskać więcej informacji na temat podstaw sieci na platformie Kubernetes, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS)