Edytuj

Udostępnij za pośrednictwem

Zagadnienia dotyczące wielodostępności w usłudze Azure Kubernetes Service (AKS)

Azure
Azure Kubernetes Service (AKS)

azure Kubernetes Service (AKS) upraszcza wdrażanie zarządzanego klastra Kubernetes na platformie Azure, odciążając obciążenie operacyjne platformy Azure w chmurze. Ponieważ usługa AKS jest hostowaną usługą Kubernetes, platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji i konserwacja oraz płaszczyzna sterowania.

Klastry usługi AKS mogą być współużytkowane przez wiele dzierżaw w różnych scenariuszach i sposobach. W niektórych przypadkach różne aplikacje mogą działać w tym samym klastrze. W innych przypadkach wiele wystąpień tej samej aplikacji może działać w tym samym klastrze udostępnionym, po jednym dla każdej dzierżawy. Termin wielodostępności często opisuje wszystkie te typy udostępniania. Platforma Kubernetes nie ma najwyższej klasy koncepcji użytkowników końcowych ani dzierżaw. Mimo to udostępnia kilka funkcji ułatwia zarządzanie różnymi wymaganiami dotyczącymi dzierżawy.

W tym artykule opisano niektóre funkcje usługi AKS, których można używać podczas tworzenia systemów wielodostępnych. Aby uzyskać ogólne wskazówki i najlepsze rozwiązania dotyczące wielodostępności platformy Kubernetes, zobacz multi-tenancy w dokumentacji platformy Kubernetes.

Typy wielodostępności

Pierwszym krokiem do określenia sposobu udostępniania klastra usługi AKS w wielu dzierżawach jest ocena wzorców i narzędzi, które są dostępne do użycia. Ogólnie rzecz biorąc, wielodostępność w klastrach Kubernetes należy do dwóch głównych kategorii, ale wiele odmian jest nadal możliwe. W dokumentacji platformy Kubernetes opisano dwa typowe przypadki użycia dla wielu zespołów i wielu klientów.

Wiele zespołów

Typową formą wielodostępności jest udostępnianie klastra między wieloma zespołami w organizacji. Każdy zespół może wdrażać, monitorować i obsługiwać co najmniej jedno rozwiązanie. Te obciążenia często muszą komunikować się ze sobą i z innymi aplikacjami wewnętrznymi lub zewnętrznymi znajdującymi się w tym samym klastrze lub na innych platformach hostingu.

Ponadto te obciążenia muszą komunikować się z usługami, takimi jak relacyjna baza danych, repozytorium NoSQL lub system obsługi komunikatów, które są hostowane w tym samym klastrze lub działają jako usługi jako usługa (PaaS) na platformie Azure.

W tym scenariuszu członkowie zespołów często mają bezpośredni dostęp do zasobów kubernetes za pośrednictwem narzędzi, takich jak kubectl. Lub członkowie mają pośredni dostęp za pośrednictwem kontrolerów GitOps, takich jak Flux i Argo CDlub za pośrednictwem innych typów narzędzi automatyzacji wydania.

Aby uzyskać więcej informacji na temat tego scenariusza, zobacz Wiele zespołów w dokumentacji platformy Kubernetes.

Wielu klientów

Inna typowa forma wielodostępności często obejmuje dostawcę oprogramowania jako usługi (SaaS). Lub dostawca usług uruchamia wiele wystąpień obciążenia, które są uważane za oddzielne dzierżawy dla swoich klientów. W tym scenariuszu klienci nie mają bezpośredniego dostępu do klastra usługi AKS, ale mają tylko dostęp do aplikacji. Ponadto nie wiedzą nawet, że aplikacja działa na platformie Kubernetes. Optymalizacja kosztów jest często krytycznym problemem. Dostawcy usług używają zasad platformy Kubernetes, takich jak limity przydziałów zasobów i zasad sieciowych, aby upewnić się, że obciążenia są silnie odizolowane od siebie.

Aby uzyskać więcej informacji na temat tego scenariusza, zobacz Wielu klientów w dokumentacji platformy Kubernetes.

Modele izolacji

Zgodnie z dokumentacją platformy Kubernetes, wielodostępny klaster Kubernetes jest współużytkowany przez wielu użytkowników i obciążenia, które są często określane jako dzierżawy. Ta definicja obejmuje klastry Kubernetes, które różne zespoły lub działy współużytkowały w organizacji. Zawiera również klastry, które dla poszczególnych klientów wystąpień udziału aplikacji SaaS.

Wielodostępność klastra jest alternatywą dla zarządzania wieloma dedykowanymi klastrami z jedną dzierżawą. Operatorzy wielodostępnego klastra Kubernetes muszą odizolować dzierżawy od siebie. Ta izolacja minimalizuje szkody, które naruszone lub złośliwe dzierżawy mogą wykonać w klastrze i w innych dzierżawach.

Gdy kilku użytkowników lub zespołów współużytkuje ten sam klaster z stałą liczbą węzłów, jeden zespół może używać więcej niż równy udział zasobów. Administratorzy mogą użyć przydziałów zasobów, aby rozwiązać ten problem.

Na podstawie poziomu zabezpieczeń, który zapewnia izolacja, można odróżnić od miękkiej i twardej wielodostępności.

  • Elastyczne wielodostępność jest odpowiednie w ramach jednego przedsiębiorstwa, w którym dzierżawy są różnymi zespołami lub działami, które ufają sobie nawzajem. W tym scenariuszu izolacja ma na celu zagwarantowanie integralności obciążenia, organizowanie zasobów klastra w różnych grupach użytkowników wewnętrznych i obronę przed możliwymi atakami zabezpieczeń.
  • Hard multitenancy opisuje scenariusze, w których heterogeniczne dzierżawy nie ufają sobie nawzajem, często z perspektywy zabezpieczeń i udostępniania zasobów.

Podczas planowania tworzenia wielodostępnego klastra usługi AKS należy wziąć pod uwagę warstwy izolacji zasobów i wielodostępności, które kubernetes zapewnia, w tym:

  • Klaster
  • Namespace
  • Pula węzłów lub węzeł
  • Strączek
  • Kontener

Ponadto należy wziąć pod uwagę wpływ zabezpieczeń na udostępnianie różnych zasobów między wieloma dzierżawami. Można na przykład zmniejszyć liczbę maszyn potrzebnych w klastrze, planując zasobniki z różnych dzierżaw w tym samym węźle. Z drugiej strony może być konieczne uniemożliwienie sortowania określonych obciążeń. Na przykład możesz nie zezwalać na uruchamianie niezaufanego kodu spoza organizacji w tym samym węźle co kontenery, które przetwarzają poufne informacje.

Chociaż platforma Kubernetes nie może zagwarantować doskonałej bezpiecznej izolacji między dzierżawami, oferuje funkcje, które mogą być wystarczające dla konkretnych przypadków użycia. Najlepszym rozwiązaniem jest oddzielenie każdej dzierżawy i jej zasobów Kubernetes do przestrzeni nazw. Następnie można użyć kontroli dostępu opartej na rolach (RBAC) kubernetes i zasad sieci w celu wymuszenia izolacji dzierżawy. Na przykład na poniższym diagramie przedstawiono typowy model dostawcy SaaS, który hostuje wiele wystąpień tej samej aplikacji w tym samym klastrze— jeden dla każdej dzierżawy. Każda aplikacja znajduje się w oddzielnej przestrzeni nazw.

Diagram przedstawiający model dostawcy SaaS hostujący wiele wystąpień tej samej aplikacji w tym samym klastrze.

Istnieje kilka sposobów projektowania i tworzenia wielodostępnych rozwiązań za pomocą usługi AKS. Każda z tych metod zawiera własny zestaw kompromisów, w zakresie wdrażania infrastruktury, topologii sieci i zabezpieczeń. Te metody wpływają na poziom izolacji, nakład pracy implementacji, złożoność operacyjną i koszt. Możesz zastosować izolację dzierżawy w płaszczyznach kontroli i danych w zależności od wymagań.

Izolacja płaszczyzny sterowania

Jeśli masz izolację na poziomie płaszczyzny sterowania, gwarantujesz, że różne dzierżawy nie będą miały dostępu do zasobów innych osób, takich jak zasobniki i usługi. Ponadto nie mogą one wpływać na wydajność aplikacji innych dzierżaw. Aby uzyskać więcej informacji, zobacz izolacja płaszczyzny sterowania w dokumentacji platformy Kubernetes. Najlepszym sposobem zaimplementowania izolacji na poziomie płaszczyzny sterowania jest rozdzielenie obciążenia poszczególnych dzierżawców i zasobów Platformy Kubernetes na oddzielną przestrzeń nazw.

Zgodnie z dokumentacją platformy Kubernetesprzestrzeni nazw jest abstrakcją używaną do obsługi izolacji grup zasobów w ramach jednego klastra. Przestrzenie nazw umożliwiają izolowanie obciążeń dzierżawy współużytkujących klaster Kubernetes.

  • Przestrzenie nazw umożliwiają istnienie odrębnych obciążeń dzierżawy we własnym wirtualnym obszarze roboczym bez ryzyka wpływu na siebie pracy. Oddzielne zespoły w organizacji mogą używać przestrzeni nazw, aby odizolować swoje projekty od siebie, ponieważ mogą używać tych samych nazw zasobów w różnych przestrzeniach nazw bez ryzyka nakładania się nazw.
  • role RBAC i powiązania ról są zasobami o zakresie przestrzeni nazw, których zespoły mogą używać do ograniczania użytkowników i procesów dzierżawy w celu uzyskania dostępu do zasobów i usług tylko w ich przestrzeniach nazw. Różne zespoły mogą definiować role w celu grupowania list uprawnień lub możliwości w ramach jednej nazwy. Następnie przypisują te role do kont użytkowników i kont usług, aby upewnić się, że tylko autoryzowane tożsamości mają dostęp do zasobów w danej przestrzeni nazw.
  • przydziały zasobów dla procesora CPU i pamięci są obiektami przestrzeni nazw. Zespoły mogą ich używać w celu zapewnienia, że obciążenia, które współużytkują ten sam klaster, są silnie odizolowane od zużycia zasobów systemowych. Ta metoda może zapewnić, że każda aplikacja dzierżawy uruchomiona w oddzielnej przestrzeni nazw ma zasoby, których potrzebuje do uruchomienia, i uniknąć hałaśliwych problemów z sąsiadami, co może mieć wpływ na inne aplikacje dzierżawy, które współużytkowują ten sam klaster.
  • zasady sieci są obiektami przestrzeni nazw, które zespoły mogą przyjąć, aby wymusić, który ruch sieciowy jest dozwolony dla danej aplikacji dzierżawy. Za pomocą zasad sieci można segregować różne obciążenia, które współużytkują ten sam klaster z perspektywy sieci.
  • Aplikacje zespołowe uruchamiane w różnych przestrzeniach nazw mogą używać różnych kont usług do uzyskiwania dostępu do zasobów w tym samym klastrze, aplikacjach zewnętrznych lub usługach zarządzanych.
  • Użyj przestrzeni nazw, aby zwiększyć wydajność na poziomie płaszczyzny sterowania. Jeśli obciążenia w udostępnionym klastrze są zorganizowane w wiele przestrzeni nazw, interfejs API Kubernetes ma mniej elementów do wyszukania podczas uruchamiania operacji. Ta organizacja może zmniejszyć opóźnienie wywołań względem serwera interfejsu API i zwiększyć przepływność płaszczyzny sterowania.

Aby uzyskać więcej informacji na temat izolacji na poziomie przestrzeni nazw, zobacz następujące zasoby w dokumentacji platformy Kubernetes:

Izolacja płaszczyzny danych

Izolacja płaszczyzny danych gwarantuje, że zasobniki i obciążenia różnych dzierżaw są wystarczająco odizolowane od siebie. Aby uzyskać więcej informacji, zobacz Izolacja płaszczyzny danych w dokumentacji platformy Kubernetes.

Izolacja sieci

W przypadku uruchamiania nowoczesnych aplikacji opartych na mikrousługach na platformie Kubernetes często chcesz kontrolować, które składniki mogą komunikować się ze sobą. Domyślnie wszystkie zasobniki w klastrze usługi AKS mogą wysyłać i odbierać ruch bez ograniczeń, w tym inne aplikacje, które współdzielą ten sam klaster. Aby zwiększyć bezpieczeństwo, można zdefiniować reguły sieci w celu kontrolowania przepływu ruchu. Zasady sieciowe to specyfikacja platformy Kubernetes, która definiuje zasady dostępu do komunikacji między zasobnikami. Można użyć zasad sieciowych do segregowania komunikacji między aplikacjami dzierżawcy, które współużytkują ten sam klaster.

Usługa AKS udostępnia dwa sposoby implementowania zasad sieci:

  • Platforma Azure ma swoją implementację zasad sieciowych, nazywanych zasadami sieci platformy Azure.
  • zasady sieci Calico to rozwiązanie sieci open source i zabezpieczeń sieci założone przez Tigera.

Obie implementacje używają tabel iptable systemu Linux do wymuszania określonych zasad. Zasady sieciowe są tłumaczone na zestawy dozwolonych i niedozwolonych par IP. Te pary są następnie programowane jako reguły filtru iptables. Zasady sieci platformy Azure można używać tylko z klastrami usługi AKS skonfigurowanymi za pomocą wtyczki sieci Azure CNI. Jednak zasady sieci Calico obsługują zarówno azure CNI, jak i kubenet. Aby uzyskać więcej informacji, zobacz Bezpieczny ruch między zasobnikami przy użyciu zasad sieciowych w usłudze Azure Kubernetes Service.

Aby uzyskać więcej informacji, zobacz Izolacja sieci w dokumentacji platformy Kubernetes.

Izolacja magazynu

Platforma Azure udostępnia bogaty zestaw zarządzanych repozytoriów danych PaaS, takich jak azure SQL Database i azure Cosmos DBoraz inne usługi magazynu, których można używać jako woluminów trwałych dla obciążeń. Aplikacje dzierżawy działające w udostępnionym klastrze usługi AKS mogą współużytkować bazę danych lub magazyn plikówlub mogą używać dedykowanego repozytorium danych i zasobu magazynu. Aby uzyskać więcej informacji na temat różnych strategii i podejść do zarządzania danymi w scenariuszu wielodostępnym, zobacz Podejścia architektury do przechowywania i danych w wielodostępnych rozwiązaniach.

Obciążenia uruchamiane w usłudze AKS mogą również używać woluminów trwałych do przechowywania danych. Na platformie Azure możesz utworzyć woluminy trwałe jako zasoby platformy Kubernetes obsługiwane przez usługę Azure Storage. Możesz ręcznie utworzyć woluminy danych i przypisać je bezpośrednio do zasobników lub automatycznie utworzyć je za pomocą usługi AKS przy użyciu trwałych oświadczeń woluminów. Usługa AKS udostępnia wbudowane klasy magazynu do tworzenia trwałych woluminów, które usług Azure Disks, Azure Filesi obsługą usługi Azure NetApp Files. Aby uzyskać więcej informacji, zobacz opcje usługi Storage dla aplikacji w usłudze AKS. Ze względów bezpieczeństwa i odporności należy unikać używania magazynu lokalnego w węzłach agenta za pośrednictwem emptyDir i hostPath.

Gdy wbudowane klasy magazynu usługi AKS nie są odpowiednie dla co najmniej jednej dzierżawy, można utworzyć niestandardowe klasy magazynu w celu spełnienia wymagań różnych dzierżaw. Te wymagania obejmują rozmiar woluminu, jednostkę SKU magazynu, umowę dotyczącą poziomu usług (SLA), zasady tworzenia kopii zapasowych i warstwę cenową.

Można na przykład skonfigurować niestandardową klasę magazynu dla każdej dzierżawy. Następnie można go użyć do zastosowania tagów do dowolnego trwałego woluminu utworzonego w przestrzeni nazw, aby pobierać z nich opłaty. Aby uzyskać więcej informacji, zobacz Używanie tagów platformy Azure w usłudze AKS.

Aby uzyskać więcej informacji, zobacz izolacji usługi Storage w dokumentacji platformy Kubernetes.

Izolacja węzła

Obciążenia dzierżawy można skonfigurować tak, aby działały na oddzielnych węzłach agenta, aby uniknąć hałaśliwych problemów sąsiadów i zmniejszyć ryzyko ujawnienia informacji. W usłudze AKS można utworzyć oddzielny klaster lub tylko dedykowaną pulę węzłów dla dzierżaw, które mają ścisłe wymagania dotyczące izolacji, zabezpieczeń, zgodności z przepisami i wydajności.

Można użyć defektów, tolerancji, etykiet węzłów , selektorów węzłów i koligacji węzłów, aby ograniczyć zasobniki dzierżawy do uruchamiania tylko w określonym zestawie węzłów lub pul węzłów.

Ogólnie rzecz biorąc, usługa AKS zapewnia izolację obciążeń na różnych poziomach, w tym:

  • Na poziomie jądra, uruchamiając obciążenia dzierżawy w lekkich maszynach wirtualnych na udostępnionych węzłach agenta i przy użyciu Zasobnik piaskownicy na podstawie kontenerów kata kata.
  • Na poziomie fizycznym przez hostowanie aplikacji dzierżawy w dedykowanych klastrach lub pulach węzłów.
  • Na poziomie sprzętu, uruchamiając obciążenia dzierżawy na dedykowanych hostach platformy Azure, które gwarantują, że maszyny wirtualne węzła agenta uruchamiają dedykowane maszyny fizyczne. Izolacja sprzętowa zapewnia, że żadne inne maszyny wirtualne nie są umieszczane na dedykowanych hostach, co zapewnia dodatkową warstwę izolacji dla obciążeń dzierżawy.

Te techniki można połączyć. Można na przykład uruchamiać klastry i pule węzłów dla poszczególnych dzierżaw w dedykowanej grupy hostów platformy Azure w celu osiągnięcia segregacji obciążeń i izolacji fizycznej na poziomie sprzętu. Można również utworzyć pule węzłów współużytkowanych lub dla poszczególnych dzierżaw, które obsługują federal information process Standard (FIPS), poufnych maszyn wirtualnychlub szyfrowania opartego na hoście.

Izolacja węzłów umożliwia łatwe kojarzenie i obciążanie kosztem zestawu węzłów lub puli węzłów w jednej dzierżawie. Jest to ściśle związane z modelem dzierżawy, który został przyjęty przez Rozwiązanie.

Aby uzyskać więcej informacji, zobacz izolacja węzła w dokumentacji platformy Kubernetes.

Modele dzierżawy

Usługa AKS udostępnia więcej typów modeli izolacji węzłów i dzierżawy.

Zautomatyzowane wdrożenia z jedną dzierżawą

W zautomatyzowanym modelu wdrażania z jedną dzierżawą wdrażasz dedykowany zestaw zasobów dla każdej dzierżawy, jak pokazano w tym przykładzie:

Diagram przedstawiający trzy dzierżawy, z których każda ma oddzielne wdrożenia.

Każde obciążenie dzierżawy jest uruchamiane w dedykowanym klastrze usługi AKS i uzyskuje dostęp do odrębnego zestawu zasobów platformy Azure. Zazwyczaj wielodostępne rozwiązania, które są kompilowane przy użyciu tego modelu, umożliwiają szerokie wykorzystanie infrastruktury jako kodu (IaC). Na przykład Bicep usługi Azure Resource Manager, narzędzia Terraformlub interfejsów API REST usługi Azure Resource Manager pomóc zainicjować i koordynować wdrażanie zasobów dedykowanych na żądanie. Możesz użyć tego podejścia, jeśli musisz aprowizować całkowicie oddzielną infrastrukturę dla każdego z klientów. Podczas planowania wdrożenia rozważ użycie wzorca sygnatur wdrażania .

korzyści :

  • Kluczową zaletą tego podejścia jest to, że serwer interfejsu API każdego klastra usługi AKS dzierżawy jest oddzielny. Takie podejście gwarantuje pełną izolację między dzierżawami z poziomu zabezpieczeń, sieci i zużycia zasobów. Osoba atakująca, która zarządza uzyskaniem kontroli nad kontenerem, ma dostęp tylko do kontenerów i zainstalowanych woluminów należących do jednej dzierżawy. Model dzierżawy pełnej izolacji ma kluczowe znaczenie dla niektórych klientów z wysokim obciążeniem w zakresie zgodności z przepisami.
  • Dzierżawy są mało prawdopodobne, aby wpływać na wydajność systemu, więc uniknąć hałaśliwych problemów sąsiadów. Ta kwestia obejmuje ruch z serwerem interfejsu API. Serwer interfejsu API jest współużytkowany, krytyczny składnik w dowolnym klastrze Kubernetes. Kontrolery niestandardowe, które generują nieuregulowany, duży ruch na serwerze interfejsu API, mogą powodować niestabilność klastra. Ta niestabilność prowadzi do błędów żądań, przekroczenia limitu czasu i ponawiania prób interfejsu API. Użyj funkcji sla czasu pracy, aby skalować w poziomie płaszczyznę sterowania klastra usługi AKS w celu zaspokojenia zapotrzebowania na ruch. Mimo to aprowizowanie dedykowanego klastra może być lepszym rozwiązaniem dla tych klientów z silnymi wymaganiami w zakresie izolacji obciążeń.
  • Aktualizacje i zmiany można wdrażać stopniowo w różnych dzierżawach, co zmniejsza prawdopodobieństwo awarii całego systemu. Koszty platformy Azure można łatwo pobierać z powrotem do dzierżaw, ponieważ każdy zasób jest używany przez jedną dzierżawę.

ryzyko :

  • Efektywność kosztowa jest niska, ponieważ każda dzierżawa korzysta z dedykowanego zestawu zasobów.
  • Ciągła konserwacja może być czasochłonna, ponieważ należy powtórzyć działania konserwacyjne w wielu klastrach usługi AKS, po jednym dla każdej dzierżawy. Rozważ zautomatyzowanie procesów operacyjnych i stopniowe stosowanie zmian w środowiskach. Inne operacje obejmujące wiele wdrożeń, takie jak raportowanie i analiza w całym majątku, mogą być również przydatne. Upewnij się, że planujesz wykonywanie zapytań dotyczących danych w wielu wdrożeniach i manipulowanie nimi.

Wdrożenia w pełni wielodostępne

We w pełni wielodostępnym wdrożeniu pojedyncza aplikacja obsługuje żądania wszystkich dzierżaw, a wszystkie zasoby platformy Azure są współużytkowane, w tym klaster usługi AKS. W tym kontekście masz tylko jedną infrastrukturę do wdrażania, monitorowania i konserwacji. Wszystkie dzierżawy używają zasobu, jak pokazano na poniższym diagramie:

Diagram przedstawiający trzy dzierżawy, które korzystają z pojedynczego wdrożenia udostępnionego.

Benefits:

  • Ten model jest atrakcyjny ze względu na niższy koszt działania rozwiązania z udostępnionymi składnikami. W przypadku korzystania z tego modelu dzierżawy może być konieczne wdrożenie większego klastra usługi AKS i wdrożenie wyższej jednostki SKU dla dowolnego udostępnionego repozytorium danych. Te zmiany pomagają utrzymać ruch generowany przez wszystkie zasoby dzierżawy, takie jak repozytoria danych.

ryzyka:

  • W tym kontekście pojedyncza aplikacja obsługuje wszystkie żądania dzierżaw. Należy zaprojektować i wdrożyć środki zabezpieczeń, aby uniemożliwić dzierżawcom zalewanie aplikacji wywołaniami. Te wywołania mogą spowalniać cały system i wpływać na wszystkie dzierżawy.
  • Jeśli profil ruchu jest wysoce zmienny, należy skonfigurować narzędzie do automatycznego skalowania klastra usługi AKS, aby zmieniać liczbę zasobników i węzłów agenta. Skonfiguruj konfigurację na podstawie użycia zasobów systemowych, takich jak procesor CPU i pamięć. Alternatywnie można skalować w poziomie i skalować liczbę zasobników i węzłów klastra na podstawie metryk niestandardowych. Można na przykład użyć liczby oczekujących żądań lub metryk zewnętrznego systemu obsługi komunikatów, który używa opartych na platformie Kubernetes autoskalowania opartego na zdarzeniach (KEDA).
  • Upewnij się, że rozdzielisz dane dla każdej dzierżawy i zaimplementujesz zabezpieczenia, aby uniknąć wycieku danych między różnymi dzierżawami.
  • Upewnij się, że śledzić i kojarzyć koszty platformy Azure z poszczególnymi dzierżawami na podstawie rzeczywistego użycia. Rozwiązania innych firm, takie jak kubecost, mogą pomóc w obliczaniu i dzieleniu kosztów w różnych zespołach i dzierżawach.
  • Konserwacja może być prostsza w przypadku pojedynczego wdrożenia, ponieważ trzeba zaktualizować tylko jeden zestaw zasobów platformy Azure i obsługiwać jedną aplikację. Może to być jednak bardziej ryzykowne, ponieważ wszelkie zmiany w infrastrukturze lub składnikach aplikacji mogą mieć wpływ na całą bazę klientów.
  • Należy również rozważyć ograniczenia skalowania. Częściej osiągasz limity skalowania zasobów platformy Azure, gdy masz udostępniony zestaw zasobów. Aby uniknąć osiągnięcia limitu przydziału zasobów, możesz dystrybuować dzierżawy w wielu subskrypcjach platformy Azure.

Wdrożenia partycjonowane w poziomie

Alternatywnie możesz rozważyć partycjonowanie w poziomie wielodostępną aplikację Kubernetes. Takie podejście udostępnia niektóre składniki rozwiązania we wszystkich dzierżawach i wdraża dedykowane zasoby dla poszczególnych dzierżaw. Można na przykład utworzyć pojedynczą wielodostępną aplikację Kubernetes, a następnie utworzyć poszczególne bazy danych, po jednym dla każdej dzierżawy, jak pokazano na poniższej ilustracji:

Diagram przedstawiający trzy dzierżawy. Każda z nich używa dedykowanej bazy danych i jednej udostępnionej aplikacji Kubernetes.

korzyści :

  • Wdrożenia partycjonowane w poziomie mogą pomóc w ograniczeniu hałaśliwych problemów z sąsiadami. Rozważ to podejście, jeśli określisz, że większość obciążenia ruchu w aplikacji Kubernetes wynika z określonych składników, które można wdrożyć oddzielnie dla każdej dzierżawy. Na przykład bazy danych mogą pochłaniać większość obciążenia systemu, ponieważ obciążenie zapytania jest wysokie. Jeśli jedna dzierżawa wysyła dużą liczbę żądań do rozwiązania, wydajność bazy danych może mieć negatywny wpływ, ale bazy danych innych dzierżaw i udostępnione składniki, takie jak warstwa aplikacji, pozostają bez wpływu.

ryzyko :

  • W przypadku wdrożenia partycjonowanego w poziomie nadal należy wziąć pod uwagę automatyczne wdrażanie składników i zarządzanie nimi, zwłaszcza składniki używane przez jedną dzierżawę.
  • Ten model może nie zapewniać wymaganego poziomu izolacji dla klientów, którzy nie mogą udostępniać zasobów innym dzierżawcom ze względów wewnętrznych lub zgodności.

Wdrożenia partycjonowane w pionie

Możesz skorzystać z zalet modeli z jedną dzierżawą i w pełni wielodostępnymi przy użyciu modelu hybrydowego, który w pionie dzieli dzierżawy na wiele klastrów usługi AKS lub pul węzłów. Takie podejście zapewnia następujące korzyści w porównaniu z poprzednimi dwoma modelami dzierżawy:

  • Można użyć kombinacji wdrożeń jednodostępnych i wielodostępnych. Na przykład większość klientów może współużytkować klaster usługi AKS i bazę danych w infrastrukturze wielodostępnej. Można również wdrożyć infrastrukturę z jedną dzierżawą dla tych klientów, którzy wymagają wyższej wydajności i izolacji.
  • Dzierżawy można wdrażać w wielu regionalnych klastrach usługi AKS, potencjalnie z różnymi konfiguracjami. Ta technika jest najbardziej skuteczna, gdy dzierżawy są rozmieszczone w różnych lokalizacjach geograficznych.

Można zaimplementować różne odmiany tego modelu dzierżawy. Na przykład możesz zaoferować rozwiązanie wielodostępne z różnymi warstwami funkcjonalności po różnych kosztach. Model cen może zapewnić wiele jednostek SKU, z których każda zapewnia przyrostowy poziom wydajności i izolacji pod względem udostępniania zasobów, wydajności, sieci i segregacji danych. Rozważ następujące warstwy:

  • Warstwa podstawowa: żądania dzierżawy są obsługiwane przez pojedynczą wielodostępną aplikację Kubernetes udostępnioną innym dzierżawcom. Dane są przechowywane w co najmniej jednej bazie danych, którą współużytkuje wszystkie dzierżawy w warstwie Podstawowa.
  • Warstwa Standardowa: żądania dzierżawy są obsługiwane przez dedykowaną aplikację Kubernetes działającą w oddzielnej przestrzeni nazw, która zapewnia granice izolacji pod względem zabezpieczeń, sieci i zużycia zasobów. Wszystkie aplikacje dzierżaw, po jednym dla każdej dzierżawy, współdzielą ten sam klaster usługi AKS i pulę węzłów z innymi klientami w warstwie Standardowa.
  • Warstwa Premium: aplikacja dzierżawy działa w dedykowanej puli węzłów lub klastrze usługi AKS, aby zagwarantować wyższą umowę SLA, lepszą wydajność i wyższy stopień izolacji. Ta warstwa może zapewnić elastyczny model kosztów na podstawie liczby i jednostki SKU węzłów agenta hostujących aplikację dzierżawy. Można użyć piaskownicy zasobnika jako alternatywne rozwiązanie dla dedykowanych klastrów lub pul węzłów w celu odizolowania odrębnych obciążeń dzierżawy.

Na poniższym diagramie przedstawiono scenariusz, w którym dzierżawy A i B działają w udostępnionym klastrze usługi AKS, natomiast dzierżawa C działa w oddzielnym klastrze usługi AKS.

Diagram przedstawiający trzy dzierżawy. Dzierżawy A i B współużytkuje klaster usługi AKS. Dzierżawa C ma dedykowany klaster AKS.

Na poniższym diagramie przedstawiono scenariusz, w którym dzierżawy A i B działają w tej samej puli węzłów, podczas gdy dzierżawa C działa w dedykowanej puli węzłów.

Diagram przedstawiający trzy dzierżawy. Dzierżawy A i B współużytkuje pulę węzłów. Dzierżawa C ma dedykowaną pulę węzłów.

Ten model może również oferować różne umowy SLA dla różnych warstw. Na przykład warstwa podstawowa może oferować czas pracy 99,9%, warstwa Standardowa może oferować czas pracy 99,95%, a warstwa Premium może oferować czas pracy 99,99% czasu pracy. Wyższą umowę SLA można zaimplementować przy użyciu usług i funkcji, które umożliwiają uzyskanie wyższych celów dostępności.

korzyści :

  • Ponieważ nadal udostępniasz infrastrukturę, nadal możesz uzyskać niektóre korzyści związane z kosztami współużytkowania wdrożeń wielodostępnych. Można wdrażać klastry i pule węzłów współużytkowane przez wiele aplikacji dzierżawy w warstwie podstawowej i warstwie Standardowa, które używają tańszego rozmiaru maszyny wirtualnej dla węzłów agenta. Takie podejście gwarantuje lepszą gęstość i oszczędności kosztów. W przypadku klientów w warstwie Premium można wdrażać klastry usługi AKS i pule węzłów o większym rozmiarze maszyny wirtualnej oraz maksymalną liczbę replik zasobników i węzłów w wyższej cenie.
  • Usługi systemowe, takie jak CoreDNS, Konnectivitylub kontroler ruchu przychodzącego usługi Azure Application Gateway, można uruchamiać w dedykowanej puli węzłów trybu systemu. Można użyć defektów, tolerancji, etykiet węzłów , selektorów węzłów i koligacji węzłów do uruchamiania aplikacji dzierżawy w co najmniej jednej puli węzłów trybu użytkownika.
  • Do uruchamiania zasobów udostępnionych można użyć , tolerancji, etykiet węzłów , selektorów węzłów i koligacji węzłów . Na przykład można mieć kontroler ruchu przychodzącego lub system obsługi komunikatów w dedykowanej puli węzłów, która ma określony rozmiar maszyny wirtualnej, ustawienia skalowania automatycznego i obsługę stref dostępności.

ryzyko :

  • Aby obsługiwać wdrożenia wielodostępne i jednodostępne, należy zaprojektować aplikację Kubernetes.
  • Jeśli planujesz zezwolić na migrację między infrastrukturami, należy rozważyć sposób migrowania klientów z wdrożenia wielodostępnego do własnego wdrożenia z jedną dzierżawą.
  • Potrzebujesz spójnej strategii i jednego okienka szkła lub jednego punktu widzenia, aby monitorować więcej klastrów usługi AKS i zarządzać nimi.

Skalowanie automatyczne

Aby nadążyć za zapotrzebowaniem na ruch generowany przez aplikacje dzierżawy, możesz włączyć narzędzie do automatycznego skalowania klastra w celu skalowania węzłów agenta usługi AKS. Skalowanie automatyczne ułatwia systemom reagowanie w następujących okolicznościach:

  • Obciążenie ruchem zwiększa się w określonych godzinach pracy lub okresach roku.
  • Dzierżawa lub udostępnione duże obciążenia są wdrażane w klastrze.
  • Węzły agenta stają się niedostępne z powodu awarii strefy dostępności.

Po włączeniu skalowania automatycznego dla puli węzłów należy określić minimalną i maksymalną liczbę węzłów na podstawie oczekiwanych rozmiarów obciążeń. Konfigurując maksymalną liczbę węzłów, można zapewnić wystarczającą ilość miejsca dla wszystkich zasobników dzierżawy w klastrze, niezależnie od przestrzeni nazw, w której działają.

Gdy ruch wzrasta, skalowanie automatyczne klastra dodaje nowe węzły agenta, aby zapobiec przejściu zasobników do stanu oczekiwania z powodu niedoborów zasobów, takich jak procesor CPU i pamięć.

Po zmniejszeniu obciążenia skalowanie automatyczne klastra zmniejsza liczbę węzłów agenta w puli węzłów na podstawie określonych granic, co pomaga zmniejszyć koszty operacyjne.

Automatyczne skalowanie zasobników umożliwia automatyczne skalowanie zasobników na podstawie zapotrzebowania na zasoby. HorizontalPodAutoscaler automatycznie skaluje liczbę replik zasobników na podstawie użycia procesora CPU lub pamięci lub metryk niestandardowych. Korzystając z KEDA, można zwiększyć skalowanie dowolnego kontenera na platformie Kubernetes na podstawie liczby zdarzeń z systemów zewnętrznych, takich jak usługi Azure Event Hubs lub usługi Azure Service Bus, z których korzystają aplikacje dzierżawy.

Pionowe narzędzie do automatycznego skalowania zasobników (VPA) umożliwia wydajne zarządzanie zasobami dla zasobników. Dzięki dostosowaniu procesora CPU i pamięci przydzielonej zasobnikom usługa VPA pomaga zmniejszyć liczbę węzłów wymaganych do uruchamiania aplikacji dzierżawy. Posiadanie mniejszej liczby węzłów zmniejsza całkowity koszt posiadania i pomaga uniknąć hałaśliwych problemów z sąsiadami.

Przypisz grupy rezerwacji pojemności do pul węzłów, aby zapewnić lepszą alokację zasobów i izolację dla różnych dzierżaw.

Konserwacja

Aby zmniejszyć ryzyko przestojów, które mogą mieć wpływ na aplikacje dzierżawcze podczas uaktualniania klastra lub puli węzłów, zaplanuj usługę AKS planowanej konserwacji poza godzinami szczytu. Zaplanuj tygodniowe okna obsługi, aby zaktualizować płaszczyznę sterowania klastrów usługi AKS, które uruchamiają aplikacje dzierżawy i pule węzłów, aby zminimalizować wpływ obciążenia. W klastrze można zaplanować co najmniej jednotygodniowe okna obsługi, określając zakres dnia lub godziny w określonym dniu. Wszystkie operacje konserwacji są wykonywane w zaplanowanych oknach.

Bezpieczeństwo

W poniższych sekcjach opisano najlepsze rozwiązania w zakresie zabezpieczeń dla rozwiązań wielodostępnych za pomocą usługi AKS.

Dostęp do klastra

W przypadku udostępniania klastra usługi AKS między wieloma zespołami w organizacji należy zaimplementować zasadę najniższych uprawnień, aby odizolować różne dzierżawy od siebie. W szczególności należy upewnić się, że użytkownicy mają dostęp tylko do przestrzeni nazw i zasobów platformy Kubernetes podczas korzystania z narzędzi takich jak kubectl, Helm, Fluxlub Argo CD.

Aby uzyskać więcej informacji na temat uwierzytelniania i autoryzacji w usłudze AKS, zobacz następujące artykuły:

Tożsamość obciążenia

Jeśli hostujesz wiele aplikacji dzierżawy w jednym klastrze usługi AKS, a każda aplikacja znajduje się w oddzielnej przestrzeni nazw, każde obciążenie powinno używać innego konta usługi Kubernetes i poświadczeń w celu uzyskania dostępu do podrzędnych usług platformy Azure. Konta usług są jednym z podstawowych typów użytkowników na platformie Kubernetes. Interfejs API platformy Kubernetes przechowuje konta usług i zarządza nimi. Poświadczenia konta usługi są przechowywane jako wpisy tajne platformy Kubernetes, więc autoryzowane zasobniki mogą używać ich do komunikowania się z serwerem interfejsu API. Większość żądań interfejsu API zapewnia token uwierzytelniania dla konta usługi lub normalnego konta użytkownika.

Obciążenia dzierżawy wdrażane w klastrach usługi AKS mogą używać poświadczeń aplikacji Firmy Microsoft Entra do uzyskiwania dostępu do zasobów chronionych przez identyfikator firmy Microsoft, takich jak Azure Key Vault i Microsoft Graph. identyfikator obciążenia entra firmy Microsoft dla platformy Kubernetes integruje się z natywnymi możliwościami platformy Kubernetes w celu federacji z dowolnymi zewnętrznymi dostawcami tożsamości.

Piaskownica zasobnika

Usługa AKS zawiera mechanizm o nazwie Zasobnik piaskownicy, który zapewnia granicę izolacji między aplikacją kontenera a udostępnionym jądrem i zasobami obliczeniowymi hosta kontenera, takimi jak procesor CPU, pamięć i sieć. Piaskownica zasobnika uzupełnia inne środki zabezpieczeń lub mechanizmy kontroli ochrony danych, aby ułatwić obciążenia dzierżawcom zabezpieczanie poufnych informacji i spełnianie wymagań dotyczących zgodności z przepisami, branży lub ładu, takich jak Payment Card Industry Data Security Standard (PCI DSS), Międzynarodowa Organizacja Standaryzacji (ISO) 27001 i Health Insurance Portability and Accountability Act (HIPAA).

Wdrażając aplikacje w oddzielnych klastrach lub pulach węzłów, można silnie odizolować obciążenia dzierżawy różnych zespołów lub klientów. Korzystanie z wielu klastrów i pul węzłów może być odpowiednie dla wymagań izolacji wielu organizacji i rozwiązań SaaS, ale istnieją scenariusze, w których pojedynczy klaster z udostępnionymi pulami węzłów maszyn wirtualnych jest bardziej wydajny. Na przykład można użyć pojedynczego klastra w przypadku uruchamiania niezaufanych i zaufanych zasobników w tym samym węźle lub kolokacji zestawów daemonSets i uprzywilejowanych kontenerów w tym samym węźle w celu szybszej komunikacji lokalnej i grupowania funkcjonalnego. zasobnik piaskownicy może pomóc w silnym odizolowaniu aplikacji dzierżawy w tych samych węzłach klastra bez konieczności uruchamiania tych obciążeń w oddzielnych klastrach lub pulach węzłów. Inne metody wymagają ponownego skompilowania kodu lub wystąpienia innych problemów ze zgodnością, ale piaskownica zasobnika w usłudze AKS może uruchamiać dowolny kontener niezmodyfikowany wewnątrz rozszerzonej granicy maszyny wirtualnej zabezpieczeń.

Piaskownica zasobnika w usłudze AKS jest oparta na kontenerach kata uruchamianych na hoście kontenerów systemu Linux platformy Azure dla usługi AKS w celu zapewnienia izolacji wymuszonej sprzętowo. Kontenery Kata w usłudze AKS są oparte na funkcji hypervisor platformy Azure ze wzmocnionym zabezpieczeniami. Zapewnia izolację na zasobnik za pomocą zagnieżdżonej, lekkiej maszyny wirtualnej Kata, która korzysta z zasobów z nadrzędnego węzła maszyny wirtualnej. W tym modelu każdy zasobnik Kata otrzymuje własne jądro w zagnieżdżonej maszynie wirtualnej gościa Kata. Ten model umożliwia umieszczenie wielu kontenerów Kata na jednej maszynie wirtualnej gościa podczas kontynuowania uruchamiania kontenerów na nadrzędnej maszynie wirtualnej. Ten model zapewnia silną granicę izolacji w udostępnionym klastrze usługi AKS.

Aby uzyskać więcej informacji, zobacz:

Dedykowany host platformy Azure

usługi Azure Dedicated Host to usługa, która zapewnia serwery fizyczne dedykowane dla jednej subskrypcji platformy Azure i zapewniają izolację sprzętową na poziomie serwera fizycznego. Te dedykowane hosty można aprowizować w regionie, strefie dostępności i domenie błędów. Maszyny wirtualne można umieszczać bezpośrednio na hostach aprowizowania.

Korzystanie z usługi Azure Dedicated Host z usługą AKS ma kilka korzyści, w tym:

  • Izolacja sprzętowa zapewnia, że żadne inne maszyny wirtualne nie są umieszczane na dedykowanych hostach, co zapewnia dodatkową warstwę izolacji dla obciążeń dzierżawy. Dedykowane hosty są wdrażane w tych samych centrach danych i współużytkują tę samą sieć i podstawową infrastrukturę magazynu co inne hosty nieizolowane.

  • Usługa Azure Dedicated Host zapewnia kontrolę nad zdarzeniami konserwacji inicjowanych przez platformę Azure. Możesz wybrać okno obsługi, aby zmniejszyć wpływ na usługi i zapewnić dostępność i prywatność obciążeń dzierżawy.

Usługa Azure Dedicated Host może pomóc dostawcom SaaS zapewnić, że aplikacje dzierżawy spełniają wymagania dotyczące zgodności z przepisami, branżą i ładem w celu zabezpieczenia poufnych informacji. Aby uzyskać więcej informacji, zobacz Dodawanie dedykowanego hosta platformy Azure do klastra usługi AKS.

Karpenter

Karpenter to projekt zarządzania cyklem życia węzłów typu open source utworzony dla platformy Kubernetes. Dodanie Narzędzia Karpenter do klastra Kubernetes może zwiększyć wydajność i koszty uruchamiania obciążeń w tym klastrze. Karpenter patrzy na zasobniki, które harmonogram Kubernetes oznacza jako nieplanowalne. Dynamicznie aprowizuje również węzły, które mogą spełniać wymagania zasobnika i zarządza nimi.

Karpenter zapewnia szczegółową kontrolę nad aprowizowaniem węzłów i umieszczaniem obciążeń w klastrze zarządzanym. Ta kontrola poprawia wielodostępność, optymalizując alokację zasobów, zapewniając izolację między aplikacjami każdej dzierżawy i zmniejszając koszty operacyjne. Podczas tworzenia wielodostępnego rozwiązania w usłudze AKS firma Karpenter zapewnia przydatne możliwości ułatwiające zarządzanie różnymi wymaganiami aplikacji w celu obsługi różnych dzierżaw. Na przykład aplikacje niektórych dzierżawców mogą być potrzebne do uruchamiania w pulach węzłów zoptymalizowanych pod kątem procesora GPU, a inne do uruchamiania w pulach węzłów zoptymalizowanych pod kątem pamięci. Jeśli aplikacja wymaga małego opóźnienia magazynu, możesz użyć Narzędzia Karpenter, aby wskazać, że zasobnik wymaga węzła uruchomionego w określonej strefie dostępności, aby można było przenieść magazyn i warstwę aplikacji.

Usługa AKS umożliwia automatyczne aprowizowanie węzłów w klastrach usługi AKS za pośrednictwem Narzędzia Karpenter. Większość użytkowników powinna używać trybu automatycznego aprowizacji węzłów, aby włączyć Oprogramowanie Karpenter jako zarządzany dodatek. Aby uzyskać więcej informacji, zobacz Node autoprovisioning. Jeśli potrzebujesz bardziej zaawansowanego dostosowywania, możesz wybrać własnego hosta Karpenter. Aby uzyskać więcej informacji, zobacz dostawca AKS Karpenter.

Poufne maszyny wirtualne

Aby dodać co najmniej jedną pulę węzłów do klastra usługi AKS, można użyć poufnych maszyn wirtualnych, aby spełnić wymagania dotyczące ścisłej izolacji, prywatności i zabezpieczeń dzierżawców. poufne maszyny wirtualne używają zaufanego środowiska wykonawczegoopartego na sprzęcie. amd Secure Encrypted Virtualization — bezpieczne zagnieżdżone stronicowanie (SEV-SNP) poufne maszyny wirtualne odmawiają funkcji hypervisor i innego kodu zarządzania hostem dostępu do pamięci i stanu maszyny wirtualnej, co dodaje warstwę ochrony i dogłębnej ochrony przed dostępem operatora. Aby uzyskać więcej informacji, zobacz Używanie poufnych maszyn wirtualnych w klastrze usługi AKS.

Federal Information Process Standards (FIPS)

FIPS 140-3 to amerykański standard rządowy, który definiuje minimalne wymagania dotyczące zabezpieczeń modułów kryptograficznych w produktach i systemach technologii informatycznych. Włączając zgodność ze standardem FIPS dla pul węzłów usługi AKS, można zwiększyć izolację, prywatność i bezpieczeństwo obciążeń dzierżawy. zgodności ze standardem FIPS zapewnia użycie zweryfikowanych modułów kryptograficznych na potrzeby szyfrowania, tworzenia skrótów i innych operacji związanych z zabezpieczeniami. W przypadku pul węzłów usługi AKS z obsługą standardu FIPS można spełnić wymagania dotyczące zgodności z przepisami i branży, stosując niezawodne algorytmy kryptograficzne i mechanizmy. Platforma Azure zawiera dokumentację dotyczącą włączania pul węzłów fiPS dla usługi AKS, co umożliwia wzmocnienie stanu zabezpieczeń wielodostępnych środowisk usługi AKS. Aby uzyskać więcej informacji, zobacz Enable FIPS for AKS node pools (Włączanie protokołu FIPS dla pul węzłów usługi AKS).

Używanie własnych kluczy (BYOK) z dyskami platformy Azure

Usługa Azure Storage szyfruje wszystkie dane na koncie magazynu magazynowanych, w tym dyski systemu operacyjnego i danych klastra usługi AKS. Domyślnie dane są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. Aby uzyskać większą kontrolę nad kluczami szyfrowania, możesz podać klucze zarządzane przez klienta do użycia do szyfrowania w pozostałych dyskach systemu operacyjnego i danych klastrów usługi AKS. Aby uzyskać więcej informacji, zobacz:

Szyfrowanie oparte na hoście

szyfrowanie oparte na hoście w usłudze AKS dodatkowo zwiększa izolację obciążeń dzierżawy, prywatność i zabezpieczenia. Po włączeniu szyfrowania opartego na hoście usługa AKS szyfruje dane magazynowane na podstawowych maszynach hosta, co pomaga zapewnić ochronę poufnych informacji dzierżawy przed nieautoryzowanym dostępem. Dyski tymczasowe i efemeryczne dyski systemu operacyjnego są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez platformę po włączeniu kompleksowego szyfrowania.

W usłudze AKS dyski systemu operacyjnego i danych domyślnie używają szyfrowania po stronie serwera z kluczami zarządzanymi przez platformę. Pamięci podręczne dla tych dysków są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez platformę. Możesz określić własny klucz szyfrowania klucza w celu zaszyfrowania klucza ochrony danych przy użyciu szyfrowania kopert, znanego również jako opakowujące. Pamięć podręczna dla dysków systemu operacyjnego i danych jest również szyfrowana za pośrednictwem określonego BYOK.

Szyfrowanie oparte na hoście dodaje warstwę zabezpieczeń dla środowisk wielodostępnych. Dane każdej dzierżawy w pamięci podręcznej dysku systemu operacyjnego i danych są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez klienta lub zarządzanych przez platformę, w zależności od wybranego typu szyfrowania dysku. Aby uzyskać więcej informacji, zobacz:

Sieci

W poniższych sekcjach opisano najlepsze rozwiązania dotyczące sieci dla rozwiązań wielodostępnych za pomocą usługi AKS.

Ograniczanie dostępu sieciowego do serwera interfejsu API

Na platformie Kubernetes serwer interfejsu API odbiera żądania wykonania akcji w klastrze, takich jak tworzenie zasobów lub skalowanie liczby węzłów. Gdy udostępniasz klaster usługi AKS wielu zespołom w organizacji, chroń dostęp do płaszczyzny sterowania przy użyciu jednego z następujących rozwiązań.

Prywatne klastry usługi AKS

Korzystając z prywatnego klastra usługi AKS, możesz upewnić się, że ruch sieciowy między serwerem interfejsu API a pulami węzłów pozostaje w sieci wirtualnej. W prywatnym klastrze usługi AKS płaszczyzna sterowania lub serwer interfejsu API ma wewnętrzny adres IP dostępny tylko za pośrednictwem prywatnego punktu końcowego platformy Azure, który znajduje się w tej samej sieci wirtualnej klastra usługi AKS. Podobnie każda maszyna wirtualna w tej samej sieci wirtualnej może prywatnie komunikować się z płaszczyzną sterowania za pośrednictwem prywatnego punktu końcowego. Aby uzyskać więcej informacji, zobacz Tworzenie prywatnego klastra usługi AKS.

Autoryzowane zakresy adresów IP

Drugą opcją poprawy zabezpieczeń klastra i zminimalizowania ataków jest użycie autoryzowanych zakresów adresów IP. Takie podejście ogranicza dostęp do płaszczyzny sterowania publicznego klastra usługi AKS do dobrze znanej listy adresów IP i zakresów routingu Inter-Domain bezklasowego (CIDR). W przypadku korzystania z autoryzowanych adresów IP są one nadal udostępniane publicznie, ale dostęp jest ograniczony do zestawu zakresów. Aby uzyskać więcej informacji, zobacz Bezpieczny dostęp do serwera interfejsu API przy użyciu autoryzowanych zakresów adresów IP w usłudze AKS.

usługi Azure Private Link to składnik infrastruktury, który umożliwia aplikacjom prywatne łączenie się z usługą za pośrednictwem prywatnego punktu końcowego platformy Azure azure zdefiniowanego w sieci wirtualnej i połączonego z konfiguracją adresu IP frontonu wystąpienia usługi Azure Load Balancer. Dzięki usługi Private Linkdostawcy usług mogą bezpiecznie udostępniać swoje usługi dzierżawcom, które mogą łączyć się z platformy Azure lub lokalnie bez ryzyka eksfiltracji danych.

Możesz użyć integracji usługi Private Link, aby zapewnić dzierżawcom łączność prywatną z obciążeniami hostowanymi przez usługę AKS w bezpieczny sposób bez konieczności uwidaczniania publicznego punktu końcowego w publicznym Internecie.

Aby uzyskać więcej informacji na temat sposobu konfigurowania usługi Private Link dla wielodostępnego rozwiązania hostowanego na platformie Azure, zobacz Multitenancy i Private Link.

Odwrotne serwery proxy

odwrotny serwer proxy to moduł równoważenia obciążenia i brama interfejsu API, która jest zwykle używana przed aplikacjami dzierżawy do zabezpieczania, filtrowania i wysyłania żądań przychodzących. Popularne odwrotne serwery proxy obsługują funkcje, takie jak równoważenie obciążenia, kończenie żądań SSL i routing warstwy 7. Odwrotne serwery proxy są zwykle implementowane w celu zwiększenia bezpieczeństwa, wydajności i niezawodności. Popularne odwrotne serwery proxy dla platformy Kubernetes obejmują następujące implementacje:

W przypadku używania zwrotnego serwera proxy hostowanego przez usługę AKS w celu zabezpieczania i obsługi żądań przychodzących do wielu aplikacji dzierżawy należy wziąć pod uwagę następujące zalecenia:

  • Hostowanie zwrotnego serwera proxy w dedykowanej puli węzłów skonfigurowanej do używania rozmiaru maszyny wirtualnej z przepustowością sieci o wysokiej przepustowości i przyspieszonej sieci włączone.
  • Skonfiguruj pulę węzłów, która hostuje zwrotny serwer proxy na potrzeby skalowania automatycznego.
  • Aby uniknąć zwiększonego opóźnienia i przekroczenia limitu czasu dla aplikacji dzierżawy, zdefiniuj zasady skalowania automatycznego, aby liczba zasobników kontrolera ruchu przychodzącego mogła być natychmiast rozszerzana i zmniejszana w celu dopasowania ich do wahań ruchu.
  • Rozważ podzielenie ruchu przychodzącego do aplikacji dzierżawy w wielu wystąpieniach kontrolera ruchu przychodzącego, aby zwiększyć skalowalność i poziom segregacji.

W przypadku korzystania z kontrolera ruchu przychodzącego usługi Azure Application Gateway (AGIC)należy rozważyć wdrożenie następujących najlepszych rozwiązań:

  • Skonfiguruj bramy aplikacji używane przez kontroler ruchu przychodzącego do skalowania automatycznego. Po włączeniu skalowania automatycznego brama aplikacji i zapora aplikacji internetowej (WAF) w wersji 2 są skalowane w poziomie lub w poziomie na podstawie wymagań dotyczących ruchu aplikacji. Ten tryb zapewnia lepszą elastyczność aplikacji i eliminuje konieczność odgadnięcia rozmiaru bramy aplikacji lub liczby wystąpień. Ten tryb pomaga również zaoszczędzić na kosztach, nie wymagając, aby brama działała w szczytowej pojemności dla oczekiwanego maksymalnego obciążenia ruchu. Musisz określić minimalną (i opcjonalnie maksymalną) liczbę wystąpień.
  • Rozważ wdrożenie wielu wystąpień AGIC, z których każda jest skojarzona z oddzielną bramą aplikacji , gdy liczba aplikacji dzierżawy przekracza maksymalną liczbę witryn . Zakładając, że każda aplikacja dzierżawy działa w dedykowanej przestrzeni nazw, użyj obsługi wielu przestrzeni nazw, aby rozpowszechnić aplikacje dzierżawy w większej liczbie wystąpień AGIC.

Integracja z usługą Azure Front Door

usługa Azure Front Door to globalny moduł równoważenia obciążenia warstwy 7 i nowoczesna sieć dostarczania zawartości w chmurze (CDN) firmy Microsoft, która zapewnia szybki, niezawodny i bezpieczny dostęp między użytkownikami i aplikacjami internetowymi na całym świecie. Usługa Azure Front Door obsługuje funkcje, takie jak przyspieszanie żądań, kończenie żądań SSL, buforowanie odpowiedzi, zapora aplikacji internetowych na brzegu, routing oparty na adresach URL, ponowne zapisywanie i przekierowania, których można używać podczas uwidaczniania wielodostępnych aplikacji usługi AKS w publicznym Internecie.

Na przykład możesz użyć aplikacji wielodostępnej hostowanej przez usługę AKS do obsługi wszystkich żądań klientów. W tym kontekście możesz użyć usługi Azure Front Door do zarządzania wieloma domenami niestandardowymi— po jednym dla każdej dzierżawy. Połączenia SSL można zakończyć na brzegu sieci i kierować cały ruch do aplikacji wielodostępnej hostowanej przez usługę AKS, która jest skonfigurowana przy użyciu jednej nazwy hosta.

Diagram przedstawiający sposób nawiązywania połączenia z usługami Azure Front Door i AKS.

Usługę Azure Front Door można skonfigurować tak, aby zmodyfikować nagłówek hosta żądania pochodzenia, aby był zgodny z nazwą domeny aplikacji zaplecza. Oryginalny nagłówek Host wysyłany przez klienta jest propagowany za pośrednictwem nagłówka X-Forwarded-Host, a kod aplikacji wielodostępnej może używać tych informacji do mapowania żądania przychodzącego na prawidłową dzierżawę.

usługa Azure Web Application Firewallw usłudze Azure Front Door zapewnia scentralizowaną ochronę aplikacji internetowych. Usługa Azure Web Application Firewall może pomóc w obronie aplikacji dzierżawy hostowanych przez usługę AKS, które uwidacznia publiczny punkt końcowy w Internecie przed złośliwymi atakami.

Usługę Azure Front Door Premium można skonfigurować tak, aby prywatnie łączyć się z co najmniej jedną aplikacją dzierżawy uruchamianą w klastrze usługi AKS za pośrednictwem wewnętrznego źródła modułu równoważenia obciążenia przy użyciu usługi Private Link. Aby uzyskać więcej informacji, zobacz Connect Azure Front Door Premium to an internal load balancer origin with Private Link (Łączenie usługi Azure Front Door Premium z wewnętrznym źródłem modułu równoważenia obciążenia za pomocą usługi Private Link).

Połączenia wychodzące

Gdy aplikacje hostowane przez usługę AKS łączą się z dużą liczbą baz danych lub usług zewnętrznych, klaster może być narażony na wyczerpanie portów translacji adresów sieciowych (SNAT). portów SNAT generować unikatowe identyfikatory, które są używane do obsługi odrębnych przepływów uruchamianych przez aplikacje działające w tym samym zestawie zasobów obliczeniowych inicjowanych. Uruchomienie kilku aplikacji dzierżawy w udostępnionym klastrze usługi AKS może spowodować dużą liczbę wywołań wychodzących, co może prowadzić do wyczerpania portów SNAT. Klaster usługi AKS może obsługiwać połączenia wychodzące na trzy różne sposoby:

  • usługi Azure Load Balancer: domyślnie usługa AKS aprowizuje usługę Load Balancer w warstwie Standardowa do skonfigurowania i użycia na potrzeby połączeń wychodzących. Jednak domyślna konfiguracja może nie spełniać wymagań wszystkich scenariuszy, jeśli publiczne adresy IP są niedozwolone lub jeśli dodatkowe przeskoki są wymagane do ruchu wychodzącego. Domyślnie publiczny moduł równoważenia obciążenia jest tworzony z domyślnym publicznym adresem IP używanym reguł ruchu wychodzącego. Reguły ruchu wychodzącego umożliwiają jawne zdefiniowanie protokołu SNAT dla publicznego standardowego modułu równoważenia obciążenia. Ta konfiguracja umożliwia korzystanie z publicznych adresów IP modułu równoważenia obciążenia w celu zapewnienia wychodzącej łączności internetowej dla wystąpień zaplecza. W razie potrzeby, aby uniknąć wyczerpania portów SNAT, można skonfigurować reguły ruchu wychodzącego publicznego modułu równoważenia obciążenia, aby używać większej liczby publicznych adresów IP. Aby uzyskać więcej informacji, zobacz Używanie adresu IP frontonu modułu równoważenia obciążenia dla ruchu wychodzącego za pośrednictwem reguł ruchu wychodzącego.
  • usługi Azure NAT Gateway: można skonfigurować klaster usługi AKS do kierowania ruchu wychodzącego z aplikacji dzierżawy przy użyciu bramy translatora adresów sieciowych platformy Azure. Brama translatora adresów sieciowych umożliwia maksymalnie 64 512 przepływów ruchu wychodzącego UDP i TCP na publiczny adres IP z maksymalnie 16 adresami IP. Aby uniknąć ryzyka wyczerpania portów SNAT podczas korzystania z bramy translatora adresów sieciowych do obsługi połączeń wychodzących z klastra usługi AKS, można skojarzyć więcej publicznych adresów IP lub prefiks publicznego adresu IP do bramy. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące usługi Azure NAT Gateway dotyczące wielodostępności.
  • trasa zdefiniowana przez użytkownika (UDR): możesz dostosować trasę ruchu wychodzącego klastra usługi AKS w celu obsługi niestandardowych scenariuszy sieciowych, takich jak te, które nie zezwalają na publiczne adresy IP i wymagają, aby klaster siedział za urządzeniem sieciowym (NVA). Podczas konfigurowania klastra na potrzeby routingu zdefiniowanego przez użytkownikausługa AKS nie konfiguruje automatycznie ścieżek ruchu wychodzącego. Należy ukończyć konfigurację ruchu wychodzącego. Możesz na przykład kierować ruch wychodzący przez usługę Azure Firewall. Klaster usługi AKS należy wdrożyć w istniejącej sieci wirtualnej z wcześniej skonfigurowaną podsiecią. Jeśli nie używasz standardowej architektury modułu równoważenia obciążenia, musisz ustanowić jawny ruch wychodzący. W związku z tym ta architektura wymaga jawnego wysyłania ruchu wychodzącego do urządzenia, takiego jak zapora, brama lub serwer proxy. Lub architektura umożliwia translatora adresów sieciowych (NAT) przez publiczny adres IP przypisany do standardowego modułu równoważenia obciążenia lub urządzenia.

Monitoring

Do monitorowania aplikacji dzierżawy uruchamianych w udostępnionym klastrze usługi AKS i obliczania podziałów kosztów w poszczególnych przestrzeniach nazw można użyć usługi Azure Monitor i szczegółowych informacji o kontenerach. Monitorowanie kondycji i wydajności usługi AKS przy użyciu usługi Azure Monitor. Obejmuje ona zbieranie dzienników i metryk , analizy telemetrii i wizualizacji zebranych danych w celu identyfikowania trendów oraz konfigurowania alertów, które aktywnie powiadamiają o krytycznych problemach. Możesz włączyć szczegółowe informacje o kontenerach, aby rozwinąć to monitorowanie.

Można również wdrożyć narzędzia typu open source, takie jak Prometheus i Grafana, które są powszechnie używane do monitorowania platformy Kubernetes. Możesz też wdrożyć inne narzędzia innych firm innych niż Microsoft do monitorowania i obserwacji.

Koszty

Zarządzanie kosztami to ciągły proces implementowania zasad w celu kontrolowania kosztów. W kontekście platformy Kubernetes istnieje kilka metod, których organizacje mogą używać do kontrolowania i optymalizowania kosztów. Metody te obejmują używanie natywnych narzędzi Kubernetes do zarządzania użyciem i zużyciem zasobów oraz zarządzania nimi oraz proaktywnego monitorowania i optymalizowania podstawowej infrastruktury. Podczas obliczania kosztów poszczególnych dzierżaw należy wziąć pod uwagę koszty skojarzone z dowolnym zasobem używanym przez aplikację dzierżawy. Podejście, które należy wykonać, aby pobierać opłaty z powrotem do dzierżaw, zależy od modelu dzierżawy, który przyjmuje twoje rozwiązanie. Na poniższej liście opisano bardziej szczegółowo modele dzierżawy:

  • W pełni wielodostępny: gdy jedna aplikacja wielodostępna obsługuje wszystkie żądania dzierżawy, twoim zadaniem jest śledzenie zużycia zasobów i liczby żądań generowanych przez każdą dzierżawę. Następnie naliczasz opłaty za klientów.
  • Dedykowany klaster: gdy klaster jest dedykowany dla pojedynczej dzierżawy, łatwo jest obciążać koszty zasobów platformy Azure z powrotem do klienta. Całkowity koszt posiadania zależy od wielu czynników, w tym liczby i rozmiaru maszyn wirtualnych, kosztów sieci ruchu sieciowego, publicznych adresów IP, modułów równoważenia obciążenia i usług magazynu, takich jak dyski zarządzane lub pliki platformy Azure używane przez rozwiązanie dzierżawy. Możesz oznaczyć klaster usługi AKS i jego zasoby w grupie zasobów węzła, aby ułatwić operacje ładowania kosztów. Aby uzyskać więcej informacji, zobacz Dodawanie tagów do klastra.
  • Dedykowana pula węzłów: tag platformy Azure można zastosować do nowej lub istniejącej puli węzłów dedykowanej dla jednej dzierżawy. Tagi są stosowane do każdego węzła w puli węzłów i są utrwalane przez uaktualnienia. Tagi są również stosowane do nowych węzłów, które są dodawane do puli węzłów podczas operacji skalowania w poziomie. Dodanie tagu może pomóc w zadaniach, takich jak śledzenie zasad lub naliczanie opłat za koszty. Aby uzyskać więcej informacji, zobacz Dodawanie tagów do pul węzłów.
  • Inne zasoby: tagi umożliwiają kojarzenie kosztów dedykowanych zasobów z daną dzierżawą. W szczególności można tagować publiczne adresy IP, pliki i dyski przy użyciu manifestu platformy Kubernetes. Tagi ustawione w ten sposób utrzymują wartości kubernetes, nawet jeśli zaktualizujesz je później przy użyciu innej metody. Gdy publiczne adresy IP, pliki lub dyski zostaną usunięte za pośrednictwem platformy Kubernetes, wszystkie tagi, które zestawy Kubernetes zostaną usunięte. Tagi zasobów, których platforma Kubernetes nie śledzi, pozostają nienaruszone. Aby uzyskać więcej informacji, zobacz Dodawanie tagów przy użyciu platformy Kubernetes.

Do monitorowania i zarządzania kosztami klastra usługi AKS można użyć narzędzi typu open source, takich jak KubeCost. Możesz ograniczyć alokację kosztów do wdrożenia, usługi, etykiety, zasobnika i przestrzeni nazw, co zapewnia elastyczność ładowania zwrotnego lub pokazywania użytkowników klastra. Aby uzyskać więcej informacji, zobacz Zarządzanie kosztami za pomocą narzędzia Kubecost.

Aby uzyskać więcej informacji na temat pomiaru, alokacji i optymalizacji kosztów dla aplikacji wielodostępnej, zobacz Podejścia architektury do zarządzania kosztami i alokacji w wielodostępnym rozwiązaniu. Aby uzyskać ogólne wskazówki dotyczące optymalizacji kosztów, zobacz artykuł Azure Well-Architected Framework, Omówienie filaru optymalizacji kosztów.

Rządzenie

Jeśli wiele dzierżaw współużytkuje tę samą infrastrukturę, zarządzanie prywatnością danych, zgodnością i wymaganiami prawnymi może stać się skomplikowane. Należy wdrożyć silne środki zabezpieczeń i zasady ładu danych. Udostępnione klastry AKS stanowią większe ryzyko naruszeń danych, nieautoryzowanego dostępu i niezgodności z przepisami dotyczącymi ochrony danych. Każda dzierżawa może mieć unikatowe wymagania dotyczące ładu danych i zasady zgodności, co utrudnia zapewnienie bezpieczeństwa i prywatności danych.

Microsoft Defender for Containers to natywne dla chmury rozwiązanie zabezpieczeń kontenerów, które zapewnia funkcje wykrywania zagrożeń i ochrony dla środowisk Kubernetes. Korzystając z usługi Defender for Containers, możesz zwiększyć poziom ładu i zgodności danych podczas hostowania wielu dzierżaw w klastrze Kubernetes. Usługa Defender for Containers pomaga chronić poufne dane, wykrywać zagrożenia i reagować na nie, analizując zachowanie kontenera i ruch sieciowy oraz spełniając wymagania prawne. Zapewnia możliwości inspekcji, zarządzanie dziennikami i generowanie raportów w celu zademonstrowania zgodności z organami regulacyjnymi i audytorami.

Współpracowników

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Inni współautorzy: