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

Usługa Azure Kubernetes Service (AKS) upraszcza wdrażanie zarządzanego klastra Kubernetes na platformie Azure, odciążając obciążenie operacyjne platformy Azure w chmurze. Jako hostowana usługa Kubernetes platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji i konserwacja. Platforma Azure zarządza płaszczyzną sterowania usługi AKS i płaci tylko za węzły usługi AKS, na których są uruchamiane aplikacje.

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. Wszystkie te typy udostępniania są często opisywane przy użyciu wielodostępności w ramach parasola. 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óre są przydatne podczas tworzenia systemów wielodostępnych. Aby uzyskać ogólne wskazówki i najlepsze rozwiązania dotyczące wielodostępności platformy Kubernetes, zobacz Obsługa wielu dzierżaw 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 do dyspozycji. Ogólnie rzecz biorąc, wielodostępność w klastrach Kubernetes należy do dwóch głównych kategorii, choć wiele odmian jest nadal możliwe. W dokumentacji platformy Kubernetes opisano dwa typowe przypadki użycia wielodostępności: wiele 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óry jest hostowany w tym samym klastrze lub działa jako usługi 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 CD, lub 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 dla swoich klientów, które są uznawane za oddzielne dzierżawy. 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łu zasobów i zasady sieci, aby upewnić się, że obciążenia są silnie odizolowane od siebie.

Aby uzyskać więcej informacji na temat tego scenariusza, zobacz Wiele 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 współużytkowane przez wystąpienia poszczególnych klientów aplikacji SaaS (software-as-a-service).

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, istnieje obawa, że jeden zespół może używać więcej niż sprawiedliwego udziału zasobów. Limity przydziału zasobów to narzędzie, które administratorzy mogą rozwiązać ten problem.

W oparciu o poziom zabezpieczeń zapewniany przez izolację możemy odróżnić od siebie miękkie i twarde wielodostępność.

• 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ążeń, organizowanie zasobów klastra w różnych grupach użytkowników wewnętrznych i obronę przed możliwymi atakami zabezpieczeń.
• Twarda wielodostępność służy do opisywania scenariuszy, 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 Azure Kubernetes Service (AKS) należy wziąć pod uwagę warstwy izolacji zasobów i wielodostępności udostępniane przez platformę Kubernetes:

• Klaster
• Przestrzeń nazw
• Pula węzłów lub węzeł
• Zasobnik
• Kontener

Ponadto należy wziąć pod uwagę wpływ zabezpieczeń na udostępnianie różnych zasobów między wieloma dzierżawami. Na przykład planowanie zasobników z różnych dzierżaw w tym samym węźle może zmniejszyć liczbę maszyn potrzebnych w klastrze. 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żesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes i zasad sieciowych, aby wymusić izolację dzierżawy. Na przykład na poniższej ilustracji przedstawiono typowy model dostawcy SaaS hostujący 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.

Istnieje kilka sposobów projektowania i tworzenia wielodostępnych rozwiązań za pomocą usługi Azure Kubernetes Service (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ą mieć wpływu 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 Kubernetes przestrzeń nazw jest abstrakcją używaną do obsługi izolacji grup zasobów w ramach jednego klastra. Przestrzenie nazw mogą służyć do izolowania obciążeń dzierżawy, które współużytkują 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 uzyskiwania 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.
• Limity przydziału zasobów dla procesora CPU i pamięci są obiektami przestrzeni nazw. Zespoły mogą ich używać w celu zapewnienia, że obciążenia współużytkujące ten sam klaster są silnie odizolowane od zużycia zasobów systemowych. Ta metoda może zapewnić, że każda aplikacja dzierżawy, która działa w oddzielnej przestrzeni nazw, ma zasoby potrzebne do uruchomienia i uniknąć hałaśliwych problemów z sąsiadami, które mogą mieć wpływ na inne aplikacje dzierżawy, które współużytkowują ten sam klaster.
• Zasady sieciowe to obiekty 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, aby uzyskiwać dostęp do zasobów w ramach tego samego klastra, aplikacji zewnętrznych lub usług 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:

• Przestrzenie nazw
• Kontrole dostępu
• Przydziały

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 sieciowa

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. Za pomocą zasad sieci można rozdzielić komunikację między aplikacjami dzierżawcy, które współużytkują ten sam klaster.

Usługa Azure Kubernetes Service (AKS) udostępnia dwa sposoby implementowania zasad sieciowych:

1. Platforma Azure ma swoją implementację zasad sieciowych, nazywanych zasadami sieci platformy Azure.
2. Zasady sieci Calico to rozwiązanie sieci typu open source i zabezpieczeń sieci założone przez Firmę 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 IPTable. Zasady sieci platformy Azure można używać tylko z klastrami AKS skonfigurowanymi za pomocą wtyczki sieciowej usługi Azure CNI . Jednak zasady sieci Calico obsługują zarówno usługi Azure CNI , jak i kubenet. Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze Azure Kubernetes Service.

Aby uzyskać więcej informacji, zobacz Izolacja sieci w dokumentacji rozwiązania Kubernetes.

Izolacja magazynu

Platforma Azure udostępnia bogaty zestaw zarządzanych repozytoriów danych typu "platforma jako usługa" (PaaS), takich jak azure SQL Database i Azure Cosmos DB, oraz inne usługi magazynu, których można używać jako trwałych woluminów 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ów albo korzystać z 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 Metody architektury magazynowania i danych w rozwiązaniach wielodostępnych.

Obciążenia uruchomione w usłudze Azure Kubernetes Service (AKS) mogą również używać woluminów trwałych do przechowywania danych. Na platformie Azure można tworzyć woluminy trwałe jako zasoby kubernetes, które są wspierane przez usługę Azure Storage. Woluminy danych można tworzyć ręcznie i przypisywać je bezpośrednio do zasobników. Możesz też automatycznie utworzyć je za pomocą oświadczeń trwałych woluminów za pomocą usługi AKS. Usługa AKS udostępnia wbudowane klasy magazynu do tworzenia trwałych woluminów, które są wspierane przez usługi Azure Disks, Azure Files i Azure NetApp Files. Aby uzyskać więcej informacji, zobacz Opcje magazynu dla aplikacji w usłudze Azure Kubernetes Service (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 wartości emptyDir i hostPath.

Gdy wbudowane klasy magazynu usługi AKS nie są dobrym rozwiązaniem dla co najmniej jednej dzierżawy, można utworzyć niestandardowe klasy magazynu, aby spełnić różne wymagania dotyczące 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 na temat tego scenariusza, zobacz Używanie tagów platformy Azure w usłudze Azure Kubernetes Service (AKS).

Aby uzyskać więcej informacji, zobacz Izolacja magazynu 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ąć problemu z hałaśliwym sąsiadem 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żaw 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:

• Na poziomie jądra, uruchamiając obciążenia dzierżawy w lekkich maszynach wirtualnych na udostępnionych węzłach agenta i używając piaskownicy zasobnika na podstawie kontenerów 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, zapewniając 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 grupie hostów platformy Azure, aby osiągnąć segregację obciążeń i izolację fizyczną 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ą standard FIPS (Federal Information Process Standard), Poufne maszyny wirtualne (CVM) lub szyfrowanie oparte na hoście.

Izolacja węzła umożliwia łatwe kojarzenie i obciążanie kosztem zestawu węzłów lub puli węzłów do jednej dzierżawy. 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 Azure Kubernetes Service (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:

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ą tworzone przy użyciu tego modelu, umożliwiają szerokie wykorzystanie infrastruktury jako kodu (IaC). Na przykład Bicep, Azure Resource Manager, Terraform lub interfejsy API REST usługi Azure Resource Manager ułatwiają inicjowanie i koordynowanie wdrożenia 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 Sygnatury wdrożenia.

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, będzie miała dostęp tylko do kontenerów i woluminów zainstalowanych w jednej dzierżawie. 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, co pozwala uniknąć problemu hałaśliwego sąsiada. 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. Funkcja umowy SLA dotyczącej czasu działania (umowa dotycząca poziomu usług) umożliwia skalowanie w poziomie płaszczyzny 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ę.

Ryzyka:

• 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ż musi być replikowana w wielu klastrach usługi AKS, po jednym dla każdej dzierżawy. Rozważ zautomatyzowanie procesów operacyjnych i stopniowe stosowanie zmian w środowiskach. Byłoby to pomocne, jeśli rozważasz również inne operacje między wdrożeniami, takie jak raportowanie i analiza w całym majątku. Podobnie 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 jeden zestaw infrastruktury do wdrażania, monitorowania i konserwacji. Wszystkie dzierżawy używają zasobu, jak pokazano na poniższym diagramie:

Korzyści:

• 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 w celu utrzymania ruchu generowanego przez zasoby wszystkich dzierżaw, takich jak repozytoria danych.

Czynniki 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ą spowolnić cały system i wpłynąć 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ć w poziomie liczbę zasobników i węzłów klastra na podstawie metryk niestandardowych. Możesz na przykład zapoznać się z liczbą oczekujących żądań lub metrykami zewnętrznego systemu obsługi komunikatów, który korzysta z automatycznego skalowania opartego na zdarzeniach (KEDA) platformy Kubernetes.
• Upewnij się, że rozdzielisz dane dla każdej dzierżawy i zaimplementujesz zabezpieczenia, aby uniknąć wycieku danych między różnymi dzierżawami.
• Pamiętaj, aby śledzić i kojarzyć koszty platformy Azure z poszczególnymi dzierżawami na podstawie rzeczywistego użycia. Rozwiązania innych firm, takie jak kubecost, mogą ułatwić obliczanie i podział 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ę. Jednak często jest to 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 rozważyć dystrybucję dzierżaw 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 polega na udostępnianiu niektórych składników rozwiązania we wszystkich dzierżawach i wdrażaniu dedykowanych zasobów 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:

Korzyści:

• Wdrożenia partycjonowane w poziomie mogą pomóc w ograniczeniu problemu z hałaśliwym sąsiadem. Rozważ to podejście, jeśli zidentyfikowano, że większość obciążenia ruchu w aplikacji Kubernetes jest spowodowana określonymi składnikami, 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 pojedyncza 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 składniki udostępnione, takie jak warstwa aplikacji), pozostają nienaruszone.

Ryzyka:

• W przypadku wdrożenia partycjonowanego w poziomie nadal trzeba 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 tych klientów, którzy nie mogą sobie pozwolić na udostępnianie zasobów innym dzierżawcom, ze względu na zasady wewnętrzne lub zgodność.

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. Mimo to 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żdy zapewnia przyrostowy poziom wydajności i izolacji, w zakresie 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óre są współużytkowane przez wszystkie dzierżawy w warstwie Podstawowa.
• Warstwa Standardowa: żądania dzierżaw są obsługiwane przez dedykowaną aplikację Kubernetes działającą w oddzielnej przestrzeni nazw, która zapewnia granice izolacji pod względem zabezpieczeń, sieci, 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ę dotyczącą poziomu usług, 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 używanych do hostowania aplikacji dzierżawy. Piaskownicę zasobnika można użyć jako alternatywnego rozwiązania do używania dedykowanych klastrów lub pul węzłów do izolowania 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.

Podobnie 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.

Ten model może również oferować różne umowy dotyczące poziomu usług dla różnych warstw. Na przykład warstwa podstawowa może oferować czas pracy na poziomie 99,9%, warstwa Standardowa może oferować 99,95% czasu pracy, a warstwa Premium może oferować 99,99%. Wyższą umowę dotyczącą poziomu usług (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. Klastry i pule węzłów, które są współużytkowane w wielu aplikacjach 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, Konnectivity lub kontroler ruchu przychodzącego bramy aplikacja systemu Azure, można uruchamiać w dedykowanej puli węzłów trybu systemowego. Można użyć defektów, tolerancji, etykiet węzłów, selektorów węzłów i koligacji węzłów, aby uruchomić aplikację dzierżawy w co najmniej jednej puli węzłów trybu użytkownika.
• Do uruchamiania udostępnionych zasobów można używać defektów, tolerancji, etykiet węzłów, selektorów węzłów i koligacji węzłów. Na przykład możesz mieć kontroler ruchu przychodzącego lub system obsługi komunikatów w dedykowanej puli węzłów z określonym rozmiarem maszyny wirtualnej, ustawieniami skalowania automatycznego i obsługą stref dostępności.

Ryzyka:

• 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 (jednego punktu widzenia), aby monitorować klastry usługi AKS i zarządzać nimi.

Skalowanie automatyczne

Aby nadążyć za zapotrzebowaniem na ruch generowanym przez aplikacje dzierżawy, możesz włączyć narzędzie do automatycznego skalowania klastra w celu skalowania węzłów agenta usługi Azure Kubernetes Service (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 strefowych.

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 uniknąć przechodzenia zasobników do stanu oczekiwania z powodu niedoboru zasobów pod względem procesora CPU i pamięci.

Podobnie, gdy obciążenie zmniejsza się, skalowanie automatyczne klastra zmniejsza liczbę węzłów agenta w puli węzłów w oparciu o określone granice, co pomaga zmniejszyć koszty operacyjne.

Automatyczne skalowanie zasobników umożliwia automatyczne skalowanie zasobników na podstawie zapotrzebowania na zasoby. Narzędzie do automatycznego skalowania zasobników w poziomie (HPA) automatycznie skaluje liczbę replik zasobników na podstawie użycia procesora CPU/pamięci lub metryk niestandardowych. Dzięki funkcji automatycznego skalowania opartego na zdarzeniach platformy Kubernetes (KEDA) można sterować skalowaniem dowolnego kontenera na platformie Kubernetes na podstawie liczby zdarzeń systemów zewnętrznych, takich jak azure Event Hubs lub Azure Service Bus, które są używane przez aplikacje dzierżawy.

Konserwacja

Aby zmniejszyć ryzyko przestojów, które mogą mieć wpływ na aplikacje dzierżawy podczas uaktualniania klastra lub puli węzłów, zaplanuj zaplanowaną konserwację usługi AKS w godzinach poza godzinami szczytu. Planowana konserwacja umożliwia zaplanowanie cotygodniowych okien konserwacji w celu zaktualizowania płaszczyzny sterowania klastrów usługi AKS, które uruchamiają aplikacje dzierżawy i pule węzłów, co minimalizuje 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 będą wykonywane w zaplanowanych oknach.

Zabezpieczenia

Dostęp do klastra

Jeśli udostępniasz klaster usługi AKS między wieloma zespołami w organizacji, musisz 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, Flux, Argo CD lub innych typów narzędzi.

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

• Opcje dostępu i tożsamości dla usługi Azure Kubernetes Service (AKS)
• Integracja aplikacji Microsoft Entra zarządzana przez usługę AKS
• Kontrolowanie dostępu do zasobów klastra przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes i tożsamości firmy Microsoft Entra w usłudze Azure Kubernetes Service

Tożsamość obciążenia

Jeśli hostujesz wiele aplikacji dzierżawy w jednym klastrze usługi AKS, a każda z nich 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, dzięki czemu mogą być używane przez autoryzowane zasobniki 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 wdrożone 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. Tożsamość obciążeń Microsoft Entra 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 Piaskownica zasobnika, 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żanie aplikacji w oddzielnych klastrach lub pulach węzłów umożliwia zdecydowanie izolowanie obciążeń dzierżawy różnych zespołów lub klientów. Użycie 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 maszyny wirtualnej jest bardziej wydajny, na przykład w przypadku uruchamiania niezaufanych i zaufanych zasobników w tym samym węźle lub współlokowania zestawów DaemonSet i uprzywilejowanych kontenerów w tym samym węźle w celu szybszej komunikacji lokalnej i grup funkcjonalnych. Piaskownica zasobnika może pomóc w silnie 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 kontenera systemu Linux platformy Azure dla stosu usługi AKS w celu zapewnienia wymuszonej sprzętowo izolacji. Kontenery Kata w usłudze AKS są oparte na funkcji hypervisor platformy Azure ze wzmocnionym zabezpieczeniami. Izolacja na zasobnik jest osiągana 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. Model zapewnia silną granicę izolacji w udostępnionym klastrze usługi AKS.

Aby uzyskać więcej informacji, zobacz:

• Piaskownica zasobnika za pomocą usługi Azure Kubernetes Service (AKS)
• Obsługa kontenerów izolowanych maszyn wirtualnych Kata w usłudze AKS na potrzeby piaskownicy zasobników

Azure Dedicated Host

Azure Dedicated Host to usługa, która udostępnia serwery fizyczne dedykowane dla pojedynczej subskrypcji platformy Azure i zapewnia izolację sprzętową na poziomie serwera fizycznego. Te dedykowane hosty można aprowizować w obrębie regionu, strefy dostępności i domeny błędów, a maszyny wirtualne można umieszczać bezpośrednio na zaaprowizowanych hostach.

Możesz uzyskać kilka korzyści, korzystając z usługi Azure Dedicated Host z usługą AKS, 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, które są inicjowane 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 Azure Kubernetes Service (AKS).

Poufne maszyny wirtualne

Aby dodać co najmniej jedną pulę węzłów do klastra usługi AKS, możesz użyć funkcji Poufne maszyny wirtualne, aby spełnić wymagania dotyczące ścisłej izolacji, prywatności i zabezpieczeń dzierżawców. CvMs używają opartego na sprzęcie zaufanego środowiska wykonawczego (TEE). 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, dodając warstwę ochrony przed dostępem operatora. Aby uzyskać więcej informacji, zobacz Use CVMs in an AKS cluster (Używanie cvms 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ść 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 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:

• ByOK z dyskami platformy Azure w usłudze AKS
• Szyfrowanie po stronie serwera usługi Azure Disk Storage

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 (KEK), aby zaszyfrować klucz ochrony danych (DEK) przy użyciu szyfrowania kopert, nazywanego również zawijaniem. Pamięć podręczna dla dysków systemu operacyjnego i danych jest również szyfrowana za pośrednictwem określonego elementu 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:

• Szyfrowanie oparte na hoście w usłudze AKS
• ByOK z dyskami platformy Azure w usłudze AKS
• Szyfrowanie po stronie serwera usługi Azure Disk Storage

Sieć

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. W przypadku udostępniania klastra usługi AKS w wielu zespołach w organizacji należy chronić 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 Azure Kubernetes Service.

Autoryzowane adresy IP

Drugą opcją zwiększenia bezpieczeństwa klastra i zminimalizowania ataków jest użycie autoryzowanych 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 (Internet Protocol) i routingu międzydomenowego (CIDR, Classless Inter-Domain Routing). W przypadku korzystania z autoryzowanych adresów IP są one nadal udostępniane publicznie, ale dostęp jest ograniczony do zestawu zakresów adresów IP. 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 Azure Kubernetes Service (AKS).

Integracja usługi Private Link

Usługa Azure Private Link (PLS) to składnik infrastruktury, który umożliwia aplikacjom prywatne łączenie się z usługą za pośrednictwem prywatnego punktu końcowego (PE) platformy Azure zdefiniowanego w sieci wirtualnej i połączonego z konfiguracją adresu IP frontonu wystąpienia usługi Azure Load Balancer (ALB ). Dzięki usłudze Azure Private Link dostawcy 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.

Za pomocą integracji usługi Azure Private Link można 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ć ogólne wskazówki dotyczące sposobu konfigurowania usługi Private Link dla wielodostępnego rozwiązania hostowanego na platformie Azure, zobacz Multitenancy i Azure Private Link.

Odwrotne serwery proxy

Zwrotny 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:

• Kontroler ruchu przychodzącego NGINX to popularny zwrotny serwer proxy, który obsługuje zaawansowane funkcje, takie jak równoważenie obciążenia, kończenie żądań SSL i routing warstwy 7.
• Dostawca ruchu przychodzącego Traefik Kubernetes to kontroler ruchu przychodzącego Kubernetes, który może służyć do zarządzania dostępem do usług klastra przez obsługę specyfikacji ruchu przychodzącego.
• HaProxy Kubernetes Ingress Controller to kolejny zwrotny serwer proxy dla platformy Kubernetes, który obsługuje standardowe funkcje, takie jak kończenie żądań TLS, routing oparty na ścieżkach URL i inne.
• aplikacja systemu Azure Gateway Ingress Controller (AGIC) to aplikacja Kubernetes, która umożliwia klientom usługi Azure Kubernetes Service (AKS) wykorzystanie natywnego modułu równoważenia obciążenia usługi Application Gateway L7 platformy Azure w celu uwidocznienia aplikacji dzierżawy w publicznym Internecie lub wewnętrznie do innych systemów uruchomionych w sieci wirtualnej.

W przypadku używania zwrotnego serwera proxy hostowanego przez usługę AKS do zabezpieczania i obsługi żądań przychodzących w wielu aplikacjach 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 włączoną przepustowością sieci o wysokiej przepustowości i przyspieszoną siecią .
• 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 bramy aplikacja systemu Azure (AGIC) należy rozważyć wdrożenie następujących najlepszych rozwiązań:

• Skonfiguruj usługę Application Gateway używaną przez kontroler ruchu przychodzącego na potrzeby skalowania automatycznego. Po włączeniu skalowania automatycznego jednostki SKU usługi Application Gateway i zapory aplikacji internetowej 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 pozwala również zaoszczędzić koszty, nie wymagając uruchomienia bramy 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ń kontrolera ruchu przychodzącego usługi Application Gateway (AGIC), z których każda jest skojarzona z oddzielną usługą Application Gateway, gdy liczba aplikacji dzierżawy przekracza maksymalną ilość lokacji. 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ń kontrolera ruchu przychodzącego usługi Application Gateway (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 przekierowywanie, które można wykorzystać 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.

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

Usługa Azure Web Application Firewall (WAF) w usłudze Azure Front Door zapewnia scentralizowaną ochronę aplikacji internetowych. Zapora aplikacji internetowych platformy Azure umożliwia obronę 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 Azure Private Link. Aby uzyskać więcej informacji, zobacz Łą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ć zagrożony wyczerpaniem portów SNAT. Porty SNAT generują unikatowe identyfikatory używane do obsługi odrębnych przepływów inicjowanych przez aplikacje uruchamiane w tym samym zestawie zasobów obliczeniowych. Uruchomienie kilku aplikacji dzierżawy w udostępnionym klastrze usługi Azure Kubernetes Service (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:

• Publiczny moduł równoważenia obciążenia platformy Azure: 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 dla ruchu wychodzącego. Domyślnie publiczny moduł równoważenia obciążenia jest tworzony z domyślnym publicznym adresem IP używanym przez reguły ruchu wychodzącego. Reguły ruchu wychodzącego umożliwiają jawne zdefiniowanie źródłowego tłumaczenia adresów sieciowych (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 do korzystania z dodatkowych 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.
• Brama translatora adresów sieciowych platformy Azure: klaster usługi AKS można skonfigurować do kierowania ruchu wychodzącego z aplikacji dzierżawy przy użyciu usługi Azure NAT Gateway. 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 prefiksu publicznego adresu IP z bramą. 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 wirtualnym urządzeniem sieciowym (NVA). Podczas konfigurowania klastra na potrzeby routingu zdefiniowanego przez użytkownika usługa AKS nie będzie automatycznie konfigurować ścieżek ruchu wychodzącego. Konfiguracja ruchu wychodzącego musi być wykonywana przez Ciebie. Można na przykład kierować ruch wychodzący przez usługę Azure Firewall. Klaster usługi AKS musi zostać wdrożony w istniejącej sieci wirtualnej z wcześniej skonfigurowaną podsiecią. Jeśli nie używasz standardowej architektury modułu równoważenia obciążenia (SLB), 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.

Monitorowanie

Usługi Azure Monitor i Container Insights umożliwiają monitorowanie aplikacji dzierżawy uruchamianych w udostępnionym klastrze usługi AKS oraz obliczanie podziałów kosztów w poszczególnych przestrzeniach nazw. Usługa Azure Monitor umożliwia monitorowanie kondycji i wydajności usługi Azure Kubernetes Service (AKS). Obejmuje ona zbieranie dzienników i metryk, analizę telemetrii i wizualizacje zebranych danych, identyfikowanie trendów i konfigurowanie alertów w celu proaktywnego powiadamiania o krytycznych problemach. Możesz włączyć usługę Container Insights , aby rozwinąć to monitorowanie.

Możesz również wdrożyć narzędzia typu open source, takie jak Prometheus i Grafana, które są powszechnie używane przez społeczność do monitorowania platformy Kubernetes. Możesz też wdrożyć inne narzędzia innych firm 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 sposobów, w jaki organizacje mogą kontrolować i optymalizować koszty. Obejmują one natywne narzędzia Kubernetes do zarządzania użyciem i zużyciem zasobów oraz proaktywnego monitorowania i optymalizowania podstawowej infrastruktury oraz zarządzania nimi. Podczas obliczania kosztów dzierżawy należy wziąć pod uwagę koszty związane 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 przyjętego przez rozwiązanie. Dalsze szczegóły zostały wyjaśnione przy użyciu następujących modeli dzierżawy:

• W pełni wielodostępny: gdy jedna aplikacja wielodostępna obsługuje wszystkie żądania dzierżawy, twoim zadaniem jest śledzenie uż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 pobierać koszty zasobów platformy Azure z powrotem do klienta. Całkowity koszt posiadania zależy od wielu czynników, takich jak liczba i rozmiar maszyn wirtualnych, koszty sieci spowodowane ruchem sieciowym, publicznymi adresami IP, modułami równoważenia obciążenia, usługami magazynu, takimi jak dyski zarządzane lub pliki platformy Azure używane przez rozwiązanie dzierżawy itd. 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 stosowane do puli węzłów 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 oznaczać publiczne adresy IP, pliki i dyski przy użyciu manifestu platformy Kubernetes. Tagi ustawione w ten sposób będą obsługiwać wartości platformy 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 ustawione przez platformę Kubernetes zostaną usunięte. Tagi dotyczące tych zasobów, które nie są śledzone przez platformę Kubernetes, pozostają nienaruszone. Aby uzyskać więcej informacji, zobacz Dodawanie tagów przy użyciu platformy Kubernetes.

Możesz użyć narzędzi typu open source, takich jak KubeCost, do monitorowania kosztów klastra usługi AKS i zarządzania nimi. Alokacja kosztów może być ograniczona do wdrożenia, usługi, etykiety, zasobnika i przestrzeni nazw, co zapewnia elastyczność w sposobie obciążenia zwrotnego lub wyświetlania użytkowników klastra. Aby uzyskać więcej informacji, zobacz Zarządzanie kosztami za pomocą rozwiązania Kubecost.

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

Współautorzy

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

Główny autor:

• Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure

Inni współautorzy:

• John Downs | Główny inżynier oprogramowania
• Cena Ed | Starszy menedżer programu zawartości
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
• Bohdan Cherchyk | Starszy inżynier klienta, fasttrack dla platformy Azure

Następne kroki

Przejrzyj zasoby dla architektów i deweloperów rozwiązań wielodostępnych.