Pojęcia: Wielodostępność w Azure Kubernetes Service (AKS)

Odpowiadając na pytanie „Jak skonfigurować Kubernetes pod kątem wielodostępności?”, architekci muszą najpierw zrozumieć dostępne granice pojęciowe i modele izolacji. Wielodostępność w AKS to praktyka uruchamiania wielu izolowanych obciążeń, należących do różnych zespołów, aplikacji lub klientów, we współdzielonym klastrze Kubernetes. W tym artykule omówiono kluczowe koncepcje i modele architektoniczne dotyczące wielodostępności w usłudze Azure Kubernetes Service (AKS).

Wskazówka

Jakie są trzy modele wielodostępności w usłudze AKS? Wielodzierżawność w usłudze AKS wykorzystuje spektrum izolacji z trzema typowymi modelami: izolacją przestrzeni nazw, izolacją puli węzłów oraz jednym klastrem na dzierżawcę. Izolacja przestrzeni nazw jest najlepszym rozwiązaniem dla zaufanych zespołów wewnętrznych i zapewnia maksymalną efektywność kosztową, izolacja puli węzłów zapewnia lepszą separację obciążeń przy umiarkowanym narzucie, a oddzielny klaster dla każdego dzierżawcy zapewnia najsilniejszą izolację w scenariuszach z niezaufanymi podmiotami lub w środowiskach podlegających ścisłym regulacjom.

Aby uzyskać instrukcje wdrożenia krok po kroku i manifesty YAML, zobacz przewodnik uzupełniający: Najlepsze praktyki dotyczące obsługi wielu dzierżawców w usłudze AKS.

Dlaczego wielodostępność w usłudze AKS?

Wielodostępność umożliwia wielu zespołom, aplikacjom lub klientom współdzielenie jednego klastra Kubernetes. Podstawowym uzasadnieniem dla wielu dzierżaw w usłudze AKS jest efektywność kosztowa i skala operacyjna.

Uruchomienie dedykowanego klastra dla każdej aplikacji lub zespołu powoduje znaczne rozdrobnienie zasobów, bezczynność pojemności obliczeniowej i pomnożenie obciążenia płaszczyzny sterowania. Konsolidując obciążenia w klastrach wielodostępnych, organizacje maksymalizują wykorzystanie zasobów i zmniejszają wydatki na chmurę. Operacyjnie wielodostępność zmniejsza rozmiar floty, co oznacza, że zespoły platformy mają mniej klastrów do stosowania poprawek, uaktualniania, monitorowania i zabezpieczania, co usprawnia zarządzanie cyklem życia.

Jaka jest różnica między miękką a twardą wielodzierżawczością?

Platforma Kubernetes nie jest z natury systemem wielodostępnym. Aby osiągnąć wielodzierżawność, należy zaprojektować model izolacji „miękkiej” lub „twardej” w oparciu o poziom zaufania między dzierżawcami.

Różnica między miękkim i twardym wielodostępem na platformie Kubernetes jest przede wszystkim modelem zaufania i wynikającym z nich wymaganiami izolacji. Miękka wielodzierżawność zakłada zaufanych wewnętrznych dzierżawców i koncentruje się na zapobieganiu przypadkowym zakłóceniom za pomocą logicznych mechanizmów kontroli, takich jak przestrzenie nazw, RBAC i limity przydziału. Twarda wielodostępność zakłada niskie lub zerowe zaufanie między dzierżawami i wymaga silniejszych mechanizmów kontroli izolacji w celu zmniejszenia ryzyka złośliwego dostępu, przenoszenia bocznego i ujawnienia danych.

Model	Poziom zaufania	Goal	Przypadek użycia	Przykładowe scenariusze
Miękka wielodostępność	Wysoka relacja zaufania między dzierżawami wewnętrznymi	Zapobiegaj przypadkowym zakłóceniom, niedoborowi zasobów i konfliktom konfiguracji	Wewnętrzne środowiska platformy, w których zespoły współdzielą infrastrukturę	Wiele zespołów produktów w jednej organizacji współużytkuje klaster usługi AKS na potrzeby tworzenia/testowania i usług wewnętrznych
Twarda wielodzierżawność	Niska lub zerowa relacja zaufania między dzierżawami	Zapobiegaj złośliwym atakom, ruchom bocznym i eksfiltracji danych	Hosting zewnętrznych klientów i obciążenia robocze objęte regulacjami	Dostawca SaaS hostujący obciążenia specyficzne dla poszczególnych klientów, gdzie izolacja tenantów jest wymogiem w zakresie bezpieczeństwa i zgodności

Spektrum izolacji

Wielodostępność w usłudze AKS nie jest wyborem binarnym; istnieje w spektrum. W miarę przechodzenia przez spektrum izolacja zwiększa się, ale w związku z tym zwiększa się złożoność operacyjna i koszty. To spektrum stanowi podstawę organizacyjną projektowania klastra wielodzierżawnego:

• Izolacja przestrzeni nazw (logiczna): Tenanty współdzielą te same pule węzłów i płaszczyznę sterowania, ale są logicznie odseparowane za pomocą przestrzeni nazw Kubernetes. To jest podstawa miękkiej współdzierżawy.
• Izolacja puli węzłów (obliczenia fizyczne): Dzierżawcy współużytkują płaszczyznę sterowania, ale mają przypisane dedykowane węzły robocze. Poprawia to separację obciążeń i ogranicza efekt „hałaśliwego sąsiada”, ale nie zapewnia pełnej izolacji dzierżawcy, ponieważ komponenty płaszczyzny sterowania i komponenty na poziomie klastra są nadal współdzielone.
• Oddzielny klaster dla każdego dzierżawcy (pełna izolacja fizyczna): dzierżawcy są całkowicie odizolowani i mają własną płaszczyznę sterowania oraz płaszczyznę danych usługi AKS. To najbardziej skrajna forma ścisłej wielodzierżawności, która w praktyce omija współdzielenie na poziomie Kubernetes na rzecz izolacji na poziomie platformy Azure.

Podstawowe elementy AKS dla wielodostępności

Usługa AKS udostępnia zestaw natywnych i zintegrowanych z platformą Azure mechanizmów umożliwiających egzekwowanie spektrum izolacji.

• Microsoft Entra ID: zapewnia scentralizowane zarządzanie tożsamościami i dostępem na potrzeby uwierzytelniania użytkowników i zautomatyzowanych systemów w interfejsie API platformy Kubernetes.
• Azure RBAC: mapuje tożsamości Microsoft Entra ID na uprawnienia Kubernetes, zapewniając, że dzierżawcy mogą uzyskiwać dostęp wyłącznie do zasobów, do których są uprawnieni.
• Zarządzane przestrzenie nazw: Zapewnia logiczne granice w klastrze, aby grupować zasoby dzierżawców, stosować limity przydziału i określać zakres dostępu.
• Azure Policy/ Gatekeeper: wymusza scentralizowane reguły zgodności i ładu w klastrze, aby zapobiec wdrażaniu niezabezpieczonych lub nieautoryzowanych konfiguracji dzierżawców.
• Azure CNI: zapewnia natywną integrację z siecią wirtualną dla AKS i obsługuje segmentację ruchu dzierżawców za pomocą zasad sieciowych. Zachowanie adresu IP zasobnika zależy od wybranego trybu CNI (na przykład Overlay lub Pod Subnet).
• Azure Container Networking Services (ACNS) Cilium L7: zapewnia wysoką wydajność, zasady sieciowe oparte na technologii eBPF oraz filtrowanie ruchu w warstwie 7, aby ściśle izolować ruch sieciowy dzierżawców.
• Tożsamość obciążenia: umożliwia poszczególnym podom bezpieczne uwierzytelnianie do zewnętrznych usług platformy Azure przy użyciu tożsamości federacyjnej, eliminując współdzielone wpisy tajne między dzierżawcami.

Mapowanie warstw izolacji między płaszczyznami

Aby zbudować bezpieczną architekturę wielodostępną, musisz zastosować podstawowe mechanizmy AKS w trzech odrębnych warstwach środowiska klastra.

Samolot	Description	Zastosowane podstawowe elementy usługi AKS
Płaszczyzna sterowania	Zabezpieczanie dostępu do serwera interfejsu API Kubernetes i granic logicznych.	Microsoft Entra ID, Azure RBAC, zarządzane przestrzenie nazw
Płaszczyzna danych	Zabezpieczanie ruchu sieciowego, wykonywania obliczeń i granic na poziomie węzła.	Azure CNI, ACNS Cilium L7, Pule węzłów
Warstwa zasobów	Zarządzanie zużyciem zasobów obliczeniowych, dostępem zewnętrznym i zgodnością konfiguracji.	Azure Policy, tożsamość obciążenia

Który model izolacji należy wybrać?

Użyj poniższej macierzy, aby określić, który punkt w spektrum izolacji najlepiej odpowiada wymaganiom organizacji.

Model izolacji	Poziom zabezpieczeń	Efektywność kosztowa	Złożoność operacyjna	Najlepsze dopasowanie do
Przestrzeń nazw dla każdego dzierżawcy	Niski do średniego (logiczny)	Wysoka (maksymalna liczba współużytkowania)	Niski (jeden klaster do zarządzania)	Zespoły wewnętrzne, środowiska deweloperskie/testowe, miękki model współdzielenia przez wielu dzierżawców.
Pula węzłów dla każdego dzierżawcy	Wysoka (izolowane obliczenia)	Średni (wspólna płaszczyzna sterowania)	Średni (Zarządzanie skażeniami i tolerancjami)	Obciążenia wewnętrzne i zewnętrzne, które wymagają silniejszej izolacji zasobów obliczeniowych przy współdzieleniu płaszczyzny sterowania; nie jest to idealne rozwiązanie dla modelu dzierżawy zero-trust w nieprzyjaznym środowisku.
Klaster na tenant	Najwyższy (Fizyczny)	Niski (duży narzut)	Wysoki (wymagane zarządzanie flotą)	Wroga wielodostępność, zewnętrzni klienci korporacyjni, zero zaufania.

Kiedy należy używać każdego modelu

• Stosuj model namespace-per-tenant, gdy dzierżawcy są wewnętrzni lub zaufani, priorytetem jest efektywność kosztowa, a mechanizmy logicznej izolacji są wystarczające.
• Używaj puli węzłów dla każdej dzierżawy, gdy potrzebujesz silniejszej izolacji zasobów obliczeniowych i mniejszego wpływu zakłóceń powodowanych przez innych dzierżawców, a jednocześnie nadal współdzielisz jedną płaszczyznę sterowania AKS.
• Użyj oddzielnego klastra dla każdego dzierżawcy, gdy dzierżawcy nie są zaufani, wymogi regulacyjne są rygorystyczne lub model ryzyka wymaga minimalnej współdzielonej infrastruktury.

Następne kroki

Teraz, gdy rozumiesz modele koncepcyjne i podstawowe elementy wielodzierżawności, przejdź do przewodnika po implementacji, aby zastosować te koncepcje do swojego klastra.

• Najlepsze praktyki dotyczące wielodostępności w usłudze AKS

Sedno sprawy

• Wielodostępność w usłudze Azure Kubernetes Service (AKS) polega na uruchamianiu wielu izolowanych obciążeń poszczególnych dzierżawców we współdzielonej infrastrukturze Kubernetes w celu obniżenia kosztów i uproszczenia zarządzania.
• Model z oddzielną przestrzenią nazw dla każdego dzierżawcy jest najbardziej opłacalny kosztowo w przypadku zaufanych wewnętrznych obciążeń roboczych, ponieważ maksymalizuje współdzielenie infrastruktury przy jednoczesnym zachowaniu logicznych granic.
• Oddzielna pula węzłów dla każdego dzierżawcy poprawia separację zasobów obliczeniowych i ogranicza problem „hałaśliwego sąsiada”, ale nadal współdzieli płaszczyznę sterowania AKS oraz inne komponenty na poziomie klastra.
• Oddzielny klaster dla każdego dzierżawcy zapewnia najsilniejszą izolację dzierżawców w środowiskach zero trust i scenariuszach podlegających ścisłym regulacjom, ale wiąże się z wyższymi kosztami i większym narzutem operacyjnym.