Wzorzec klastra Kubernetes o wysokiej dostępności

W tym artykule opisano sposób tworzenia architektury i obsługi infrastruktury opartej na platformie Kubernetes o wysokiej dostępności przy użyciu aparatu Azure Kubernetes Service (AKS) w usłudze Azure Stack Hub. Ten scenariusz jest typowy dla organizacji z krytycznymi obciążeniami w wysoce ograniczonych i regulowanych środowiskach. Organizacje w domenach, takich jak finanse, obrona i instytucje rządowe.

Kontekst i problem

Wiele organizacji opracowuje rozwiązania natywne dla chmury, które wykorzystują najnowocześniejsze usługi i technologie, takie jak Kubernetes. Chociaż platforma Azure udostępnia centra danych w większości regionów świata, czasami istnieją brzegowe przypadki użycia i scenariusze, w których aplikacje krytyczne dla działania firmy muszą działać w określonej lokalizacji. Zagadnienia obejmują:

• Czułość lokalizacji
• Opóźnienie między aplikacją a systemami lokalnymi
• Ochrona przepustowości
• Łączność
• Wymagania prawne lub ustawowe

Platforma Azure, w połączeniu z usługą Azure Stack Hub, rozwiązuje większość tych problemów. Poniżej opisano szeroki zestaw opcji, decyzji i zagadnień dotyczących pomyślnej implementacji platformy Kubernetes działającej w usłudze Azure Stack Hub.

Rozwiązanie

Ten wzorzec zakłada, że musimy radzić sobie z ścisłym zestawem ograniczeń. Aplikacja musi działać lokalnie, a wszystkie dane osobowe nie mogą docierać do usług w chmurze publicznej. Monitorowanie i inne dane inne niż dane osobowe mogą być wysyłane na platformę Azure i przetwarzane tam. Dostęp do usług zewnętrznych, takich jak publiczny rejestr kontenerów lub inne, mogą być filtrowane za pośrednictwem zapory lub serwera proxy.

Przykładowa aplikacja pokazana w tym miejscu została zaprojektowana tak, aby używała rozwiązań natywnych dla platformy Kubernetes, gdy jest to możliwe. Ten projekt pozwala uniknąć blokady dostawcy zamiast używania usług natywnych dla platformy. Na przykład aplikacja używa własnego zaplecza bazy danych MongoDB zamiast usługi PaaS lub zewnętrznej usługi bazy danych. Aby uzyskać więcej informacji, zobacz Wprowadzenie do platformy Kubernetes na ścieżce szkoleniowej platformy Azure.

Powyższy diagram przedstawia architekturę aplikacji przykładowej aplikacji uruchomionej na platformie Kubernetes w usłudze Azure Stack Hub. Aplikacja składa się z kilku składników, w tym:

1. Klaster Kubernetes oparty na aks engine w usłudze Azure Stack Hub.
2. cert-manager, który udostępnia zestaw narzędzi do zarządzania certyfikatami na platformie Kubernetes, używany do automatycznego żądania certyfikatów z usługi Let's Encrypt.
3. Przestrzeń nazw kubernetes zawierająca składniki aplikacji frontonu (ratings-web), api (ratings-api) i bazę danych (ratings-mongodb).
4. Kontroler ruchu przychodzącego, który kieruje ruch HTTP/HTTPS do punktów końcowych w klastrze Kubernetes.

Przykładowa aplikacja służy do ilustrowania architektury aplikacji. Wszystkie składniki są przykładami. Architektura zawiera tylko jedno wdrożenie aplikacji. Aby uzyskać wysoką dostępność ( HA), uruchomimy wdrożenie co najmniej dwa razy w dwóch różnych wystąpieniach usługi Azure Stack Hub — mogą one działać w tej samej lokalizacji lub w dwóch (lub więcej) różnych lokacjach:

Usługi, takie jak Azure Container Registry, Azure Monitor i inne, są hostowane poza usługą Azure Stack Hub na platformie Azure lub lokalnie. Ten projekt hybrydowy chroni rozwiązanie przed awarią pojedynczego wystąpienia usługi Azure Stack Hub.

Składniki

Ogólna architektura składa się z następujących składników:

Azure Stack Hub to rozszerzenie platformy Azure, które może uruchamiać obciążenia w środowisku lokalnym, zapewniając usługi platformy Azure w centrum danych. Przejdź do przeglądu usługi Azure Stack Hub , aby dowiedzieć się więcej.

Azure Kubernetes Service Engine (AKS Engine) to aparat zarządzanych usług Kubernetes, Azure Kubernetes Service (AKS), który jest obecnie dostępny na platformie Azure. W przypadku usługi Azure Stack Hub aparat AKS umożliwia wdrażanie, skalowanie i uaktualnianie w pełni funkcjonalnych klastrów Kubernetes zarządzanych przez siebie przy użyciu funkcji IaaS usługi Azure Stack Hub. Przejdź do sekcji Omówienie aparatu usługi AKS , aby dowiedzieć się więcej.

Przejdź do sekcji Znane problemy i ograniczenia , aby dowiedzieć się więcej o różnicach między aparatem usługi AKS na platformie Azure i a aparatem AKS w usłudze Azure Stack Hub.

Usługa Azure Virtual Network (VNet) służy do udostępniania infrastruktury sieciowej w każdej usłudze Azure Stack Hub dla Virtual Machines (maszyn wirtualnych) hostowania infrastruktury klastra Kubernetes.

Azure Load Balancer jest używany dla punktu końcowego interfejsu API Platformy Kubernetes i kontrolera ruchu przychodzącego Nginx. Moduł równoważenia obciążenia kieruje zewnętrzny (na przykład Internet) ruch do węzłów i maszyn wirtualnych oferujących określoną usługę.

Azure Container Registry (ACR) służy do przechowywania prywatnych obrazów platformy Docker i wykresów helm, które są wdrażane w klastrze. Aparat usługi AKS może uwierzytelniać się w usłudze Container Registry przy użyciu tożsamości Azure AD. Platforma Kubernetes nie wymaga usługi ACR. Możesz użyć innych rejestrów kontenerów, takich jak Docker Hub.

Azure Repos to zestaw narzędzi kontroli wersji, których można użyć do zarządzania kodem. Możesz również użyć usługi GitHub lub innych repozytoriów opartych na usłudze Git. Przejdź do Azure Repos Przegląd, aby dowiedzieć się więcej.

Usługa Azure Pipelines jest częścią Azure DevOps Services i uruchamia zautomatyzowane kompilacje, testy i wdrożenia. Możesz również użyć rozwiązań ciągłej integracji/ciągłego wdrażania innych firm, takich jak Jenkins. Przejdź do tematu Azure Pipeline Overview (Omówienie usługi Azure Pipeline), aby dowiedzieć się więcej.

Usługa Azure Monitor zbiera i przechowuje metryki i dzienniki, w tym metryki platformy dla usług platformy Azure w telemetrii rozwiązania i aplikacji. Te dane służą do monitorowania aplikacji, konfigurowania alertów i pulpitów nawigacyjnych oraz przeprowadzania analizy głównej przyczyny błędów. Usługa Azure Monitor integruje się z platformą Kubernetes w celu zbierania metryk z kontrolerów, węzłów i kontenerów, a także dzienników kontenerów i dzienników węzłów głównych. Przejdź do tematu Omówienie usługi Azure Monitor , aby dowiedzieć się więcej.

Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu, który umożliwia optymalną dystrybucję ruchu do usług w różnych regionach platformy Azure lub wdrożeniach usługi Azure Stack Hub. Usługa Traffic Manager zapewnia również wysoką dostępność i czas odpowiedzi. Punkty końcowe aplikacji muszą być dostępne z zewnątrz. Dostępne są również inne rozwiązania lokalne.

Kontroler ruchu przychodzącego Kubernetes uwidacznia trasy HTTP(S) do usług w klastrze Kubernetes. W tym celu można użyć serwera Nginx lub dowolnego odpowiedniego kontrolera ruchu przychodzącego.

Helm to menedżer pakietów dla wdrożenia platformy Kubernetes, który umożliwia łączenie różnych obiektów Kubernetes, takich jak Wdrożenia, Usługi, Wpisy tajne, w jeden "wykres". Można publikować, wdrażać, kontrolować zarządzanie wersjami i aktualizować obiekt wykresu. Azure Container Registry można użyć jako repozytorium do przechowywania spakowanych wykresów Helm.

Zagadnienia dotyczące projektowania

Ten wzorzec jest zgodny z kilkoma zagadnieniami wysokiego poziomu opisanymi bardziej szczegółowo w kolejnych sekcjach tego artykułu:

• Aplikacja używa rozwiązań natywnych dla platformy Kubernetes, aby uniknąć blokady dostawcy.
• Aplikacja używa architektury mikrousług.
• Usługa Azure Stack Hub nie wymaga ruchu przychodzącego, ale zezwala na wychodzącą łączność internetową.

Te zalecane rozwiązania będą również stosowane do rzeczywistych obciążeń i scenariuszy.

Zagadnienia dotyczące skalowalności

Skalowalność jest ważna, aby zapewnić użytkownikom spójny, niezawodny i wydajny dostęp do aplikacji.

Przykładowy scenariusz obejmuje skalowalność na wielu warstwach stosu aplikacji. Oto ogólne omówienie różnych warstw:

Poziom architektury	Wpływa	Jak to zrobić?
Aplikacja	Aplikacja	Skalowanie w poziomie na podstawie liczby zasobników/replik/Container Instances*
Klaster	Klaster Kubernetes	Liczba węzłów (od 1 do 50), rozmiary jednostek SKU maszyn wirtualnych i pule węzłów (aparat AKS w usłudze Azure Stack Hub obecnie obsługuje tylko jedną pulę węzłów); używanie polecenia skalowania aparatu AKS (ręczne)
Infrastruktura	Azure Stack Hub	Liczba węzłów, pojemności i jednostek skalowania we wdrożeniu usługi Azure Stack Hub

* Korzystanie z narzędzia Do automatycznego skalowania zasobników w poziomie platformy Kubernetes (HPA); zautomatyzowane skalowanie oparte na metrykach lub skalowanie w pionie przez ustalanie rozmiaru wystąpień kontenera (procesor/pamięć).

Azure Stack Hub (poziom infrastruktury)

Infrastruktura usługi Azure Stack Hub jest podstawą tej implementacji, ponieważ usługa Azure Stack Hub działa na sprzęcie fizycznym w centrum danych. Podczas wybierania sprzętu centrum należy dokonać wyboru procesora CPU, gęstości pamięci, konfiguracji magazynu i liczby serwerów. Aby dowiedzieć się więcej na temat skalowalności usługi Azure Stack Hub, zapoznaj się z następującymi zasobami:

• Planowanie pojemności dla usługi Azure Stack Hub — omówienie
• Dodawanie dodatkowych węzłów jednostki skalowania w usłudze Azure Stack Hub

Klaster Kubernetes (poziom klastra)

Sam klaster Kubernetes składa się i jest oparty na składnikach IaaS platformy Azure (Stack), takich jak zasoby obliczeniowe, magazynowe i sieciowe. Rozwiązania Kubernetes obejmują węzły główne i robocze, które są wdrażane jako maszyny wirtualne na platformie Azure (i w usłudze Azure Stack Hub).

• Węzły płaszczyzny sterowania (master) zapewniają podstawowe usługi Kubernetes i aranżację obciążeń aplikacji.
• Węzły robocze (proces roboczy) uruchamiają obciążenia aplikacji.

Podczas wybierania rozmiarów maszyn wirtualnych dla początkowego wdrożenia należy wziąć pod uwagę kilka kwestii:

• Koszt — podczas planowania węzłów roboczych należy pamiętać o ogólnym koszcie na maszynę wirtualną. Jeśli na przykład obciążenia aplikacji wymagają ograniczonych zasobów, należy zaplanować wdrożenie maszyn wirtualnych o mniejszym rozmiarze. Usługa Azure Stack Hub, taka jak platforma Azure, jest zwykle rozliczana na podstawie zużycia, dlatego odpowiednie ustalanie rozmiaru maszyn wirtualnych dla ról kubernetes ma kluczowe znaczenie dla optymalizacji kosztów zużycia.

• Skalowalność — skalowalność klastra jest osiągana przez skalowanie w i w poziomie liczby węzłów głównych i węzłów roboczych lub przez dodanie dodatkowych pul węzłów (obecnie niedostępnych w usłudze Azure Stack Hub). Skalowanie klastra można przeprowadzić na podstawie danych wydajności zebranych przy użyciu usługi Container Insights (Azure Monitor + Log Analytics).

  Jeśli aplikacja potrzebuje więcej (lub mniej) zasobów, możesz skalować w poziomie (lub w poziomie) bieżące węzły (od 1 do 50 węzłów). Jeśli potrzebujesz więcej niż 50 węzłów, możesz utworzyć dodatkowy klaster w oddzielnej subskrypcji. Nie można skalować w górę rzeczywistych maszyn wirtualnych w pionie do innego rozmiaru maszyny wirtualnej bez ponownego wdrażania klastra.

  Skalowanie odbywa się ręcznie przy użyciu maszyny wirtualnej pomocnika aparatu AKS, która została użyta do początkowego wdrożenia klastra Kubernetes. Aby uzyskać więcej informacji, zobacz Skalowanie klastrów Kubernetes

• Limity przydziału — weź pod uwagę limity przydziału skonfigurowane podczas planowania wdrożenia usługi AKS w usłudze Azure Stack Hub. Upewnij się, że każda subskrypcja ma odpowiednie plany i skonfigurowane limity przydziału. Subskrypcja będzie musiała pomieścić ilość zasobów obliczeniowych, magazynu i innych usług potrzebnych dla klastrów podczas skalowania w poziomie.

• Obciążenia aplikacji — zapoznaj się z pojęciami dotyczącymi klastrów i obciążeń w dokumencie Podstawowe pojęcia dotyczące platformy Kubernetes dotyczące Azure Kubernetes Service. Ten artykuł pomoże Ci w zakresie odpowiedniego rozmiaru maszyny wirtualnej na podstawie potrzeb obliczeniowych i pamięci aplikacji.

Aplikacja (poziom aplikacji)

W warstwie aplikacji używamy narzędzia Kubernetes Horizontal Pod Autoscaler (HPA). Narzędzie HPA może zwiększyć lub zmniejszyć liczbę replik (zasobników/Container Instances) we wdrożeniu na podstawie różnych metryk (takich jak użycie procesora CPU).

Inną opcją jest skalowanie wystąpień kontenerów w pionie. Można to osiągnąć przez zmianę ilości procesora CPU i pamięci żądanej i dostępnej dla określonego wdrożenia. Aby dowiedzieć się więcej, zobacz Zarządzanie zasobami dla kontenerów w kubernetes.io.

Zagadnienia dotyczące sieci i łączności

Sieć i łączność mają również wpływ na trzy warstwy wymienione wcześniej dla platformy Kubernetes w usłudze Azure Stack Hub. W poniższej tabeli przedstawiono warstwy i usługi, które zawierają:

Warstwa	Wpływa	Co?
Aplikacja	Aplikacja	Jak aplikacja jest dostępna? Czy będzie on narażony na Internet?
Klaster	Klaster Kubernetes	Interfejs API kubernetes, maszyna wirtualna aparatu AKS, ściąganie obrazów kontenerów (ruch wychodzący), wysyłanie danych monitorowania i telemetrii (ruch wychodzący)
Infrastruktura	Azure Stack Hub	Dostępność punktów końcowych zarządzania usługi Azure Stack Hub, takich jak portal i punkty końcowe usługi Azure Resource Manager.

Aplikacja

W przypadku warstwy aplikacji najważniejszą kwestią jest to, czy aplikacja jest uwidoczniona i dostępna z Internetu. Z perspektywy platformy Kubernetes ułatwienia dostępu do Internetu oznaczają uwidacznianie wdrożenia lub zasobnika przy użyciu usługi Kubernetes Service lub kontrolera ruchu przychodzącego.

Uwidacznianie aplikacji przy użyciu publicznego adresu IP za pośrednictwem Load Balancer lub kontrolera ruchu przychodzącego nie oznacza, że aplikacja jest teraz dostępna za pośrednictwem Internetu. Usługa Azure Stack Hub może mieć publiczny adres IP widoczny tylko w lokalnym intranecie — nie wszystkie publiczne adresy IP są naprawdę dostępne z Internetu.

Poprzedni blok uwzględnia ruch przychodzący do aplikacji. Innym tematem, który należy uwzględnić w przypadku pomyślnego wdrożenia kubernetes, jest ruch wychodzący/wychodzący. Oto kilka przypadków użycia, które wymagają ruchu wychodzącego:

• Ściąganie obrazów kontenerów przechowywanych w usłudze DockerHub lub Azure Container Registry
• Pobieranie wykresów programu Helm
• Emitowanie danych usługi Application Insights (lub innych danych monitorowania)

Niektóre środowiska przedsiębiorstwa mogą wymagać użycia przezroczystych lub niezroczystych serwerów proxy. Te serwery wymagają określonej konfiguracji w różnych składnikach klastra. Dokumentacja aparatu AKS zawiera różne szczegóły dotyczące sposobu obsługi serwerów proxy sieci. Aby uzyskać więcej informacji, zobacz Aparat usługi AKS i serwery proxy

Na koniec ruch między klastrami musi przepływać między wystąpieniami usługi Azure Stack Hub. Przykładowe wdrożenie składa się z poszczególnych klastrów Kubernetes działających w poszczególnych wystąpieniach usługi Azure Stack Hub. Ruch między nimi, taki jak ruch związany z replikacją między dwiema bazami danych, to "ruch zewnętrzny". Ruch zewnętrzny musi być kierowany przez sieć VPN typu lokacja-lokacja lub publiczne adresy IP usługi Azure Stack Hub w celu połączenia rozwiązania Kubernetes w dwóch wystąpieniach usługi Azure Stack Hub:

Klaster

Klaster Kubernetes nie musi być dostępny za pośrednictwem Internetu. Odpowiednią częścią jest interfejs API platformy Kubernetes używany do obsługi klastra, na przykład przy użyciu polecenia kubectl. Punkt końcowy interfejsu API kubernetes musi być dostępny dla wszystkich użytkowników, którzy obsługują klaster lub wdraża na nim aplikacje i usługi. Ten temat został szczegółowo omówiony z perspektywy metodyki DevOps w sekcji zagadnienia dotyczące wdrażania (CI/CD) poniżej.

Na poziomie klastra istnieje również kilka zagadnień dotyczących ruchu wychodzącego:

• Aktualizacje węzła (dla systemu Ubuntu)
• Dane monitorowania (wysyłane do usługi Azure LogAnalytics)
• Inni agenci wymagający ruchu wychodzącego (specyficzne dla środowiska każdego wdrażającego)

Przed wdrożeniem klastra Kubernetes przy użyciu aparatu AKS zaplanuj ostateczny projekt sieci. Zamiast tworzyć dedykowane Virtual Network, wdrożenie klastra w istniejącej sieci może być bardziej wydajne. Możesz na przykład skorzystać z istniejącego połączenia sieci VPN typu lokacja-lokacja skonfigurowanego już w środowisku usługi Azure Stack Hub.

Infrastruktura

Infrastruktura odnosi się do uzyskiwania dostępu do punktów końcowych zarządzania usługi Azure Stack Hub. Punkty końcowe obejmują portale dzierżawy i administratorów oraz punkty końcowe administratora i dzierżawy usługi Azure Resource Manager. Te punkty końcowe są wymagane do obsługi usługi Azure Stack Hub i jej podstawowych usług.

Zagadnienia dotyczące danych i magazynowania

Dwa wystąpienia naszej aplikacji zostaną wdrożone w dwóch pojedynczych klastrach Kubernetes w dwóch wystąpieniach usługi Azure Stack Hub. Ten projekt będzie wymagał od nas rozważenia sposobu replikowania i synchronizowania danych między nimi.

Dzięki platformie Azure mamy wbudowaną funkcję replikowania magazynu w wielu regionach i strefach w chmurze. Obecnie w usłudze Azure Stack Hub nie ma natywnych sposobów replikowania magazynu w dwóch różnych wystąpieniach usługi Azure Stack Hub — tworzą one dwie niezależne chmury bez nadrzędnych sposobów zarządzania nimi jako zestawem. Planowanie odporności aplikacji działających w usłudze Azure Stack Hub wymusza rozważenie tej niezależności w projekcie i wdrożeniach aplikacji.

W większości przypadków replikacja magazynu nie będzie konieczna w przypadku odpornej i wysoce dostępnej aplikacji wdrożonej w usłudze AKS. Należy jednak rozważyć niezależny magazyn na wystąpienie usługi Azure Stack Hub w projekcie aplikacji. Jeśli ten projekt jest problemem lub przeszkodą w wdrażaniu rozwiązania w usłudze Azure Stack Hub, istnieją możliwe rozwiązania od partnerów Microsoft, które udostępniają załączniki magazynu. Załączniki magazynu zapewniają rozwiązanie replikacji magazynu w wielu usługach Azure Stack Hubs i Azure. Aby uzyskać więcej informacji, zobacz Rozwiązania partnerskie.

W naszej architekturze te warstwy zostały uwzględnione:

Konfiguracja

Konfiguracja obejmuje konfigurację usługi Azure Stack Hub, aparatu AKS i samego klastra Kubernetes. Konfiguracja powinna być zautomatyzowana jak najwięcej i przechowywana jako infrastruktura jako kod w systemie kontroli wersji opartym na usłudze Git, na przykład Azure DevOps lub GitHub. Tych ustawień nie można łatwo zsynchronizować w wielu wdrożeniach. Dlatego zalecamy przechowywanie i stosowanie konfiguracji z zewnątrz oraz używanie potoku DevOps.

Aplikacja

Aplikacja powinna być przechowywana w repozytorium opartym na usłudze Git. Za każdym razem, gdy jest nowe wdrożenie, zmiany aplikacji lub odzyskiwania po awarii, można je łatwo wdrożyć przy użyciu usługi Azure Pipelines.

Dane

Dane są najważniejszą kwestią w przypadku większości projektów aplikacji. Dane aplikacji muszą być zsynchronizowane między różnymi wystąpieniami aplikacji. Dane wymagają również strategii tworzenia kopii zapasowych i odzyskiwania po awarii, jeśli wystąpi awaria.

Osiągnięcie tego projektu zależy w dużym stopniu od wyborów technologicznych. Poniżej przedstawiono kilka przykładów rozwiązań do implementowania bazy danych w sposób o wysokiej dostępności w usłudze Azure Stack Hub:

• Wdrażanie grupy dostępności SQL Server 2016 na platformie Azure i w usłudze Azure Stack Hub
• Wdrażanie rozwiązania MongoDB o wysokiej dostępności na platformie Azure i w usłudze Azure Stack Hub

Zagadnienia dotyczące pracy z danymi w wielu lokalizacjach są jeszcze bardziej złożone w przypadku rozwiązania o wysokiej dostępności i odporności. Rozważ następujące kwestie:

• Opóźnienie i łączność sieciowa między usługą Azure Stack Hubs.
• Dostępność tożsamości dla usług i uprawnień. Każde wystąpienie usługi Azure Stack Hub integruje się z katalogiem zewnętrznym. Podczas wdrażania należy użyć usługi Azure Active Directory (Azure AD) lub Active Directory Federation Services (ADFS). W związku z tym istnieje możliwość użycia jednej tożsamości, która może współdziałać z wieloma niezależnymi wystąpieniami usługi Azure Stack Hub.

Ciągłość działania i odzyskiwanie po awarii

Ciągłość działania i odzyskiwanie po awarii (BCDR) to ważny temat zarówno w usłudze Azure Stack Hub, jak i na platformie Azure. Główną różnicą jest to, że w usłudze Azure Stack Hub operator musi zarządzać całym procesem BCDR. Na platformie Azure części bcDR są automatycznie zarządzane przez Microsoft.

BcDR ma wpływ na te same obszary wymienione w poprzedniej sekcji Zagadnienia dotyczące danych i magazynowania:

• Infrastruktura/konfiguracja
• Dostępność aplikacji
• Dane aplikacji

Jak wspomniano w poprzedniej sekcji, te obszary są odpowiedzialne za operator usługi Azure Stack Hub i mogą się różnić między organizacjami. Zaplanuj trasę BCDR zgodnie z dostępnymi narzędziami i procesami.

Infrastruktura i konfiguracja

W tej sekcji opisano infrastrukturę fizyczną i logiczną oraz konfigurację usługi Azure Stack Hub. Obejmuje ona akcje w obszarze administratora i przestrzeni dzierżawy.

Operator usługi Azure Stack Hub (lub administrator) jest odpowiedzialny za konserwację wystąpień usługi Azure Stack Hub. Uwzględnianie składników, takich jak sieć, magazyn, tożsamość i inne tematy, które wykraczają poza zakres tego artykułu. Aby dowiedzieć się więcej na temat szczegółowych informacji o operacjach usługi Azure Stack Hub, zobacz następujące zasoby:

• Odzyskiwanie danych w usłudze Azure Stack Hub za pomocą usługi tworzenia kopii zapasowych infrastruktury
• Włączanie tworzenia kopii zapasowej usługi Azure Stack Hub z poziomu portalu administratora
• Odzyskiwanie sprawności po utracie danych w wyniku katastrofy
• Najlepsze rozwiązania dotyczące usługi Infrastructure Backup

Usługa Azure Stack Hub to platforma i sieć szkieletowa, w której zostaną wdrożone aplikacje Kubernetes. Właściciel aplikacji dla aplikacji Kubernetes będzie użytkownikiem usługi Azure Stack Hub z dostępem przyznanym do wdrożenia infrastruktury aplikacji potrzebnej dla rozwiązania. Infrastruktura aplikacji w tym przypadku oznacza klaster Kubernetes, wdrożony przy użyciu aparatu AKS i okolicznych usług. Te składniki zostaną wdrożone w usłudze Azure Stack Hub, ograniczone przez ofertę usługi Azure Stack Hub. Upewnij się, że oferta zaakceptowana przez właściciela aplikacji Kubernetes ma wystarczającą pojemność (wyrażoną w limitach przydziału usługi Azure Stack Hub), aby wdrożyć całe rozwiązanie. Zgodnie z zaleceniami w poprzedniej sekcji wdrożenie aplikacji powinno być zautomatyzowane przy użyciu potoków infrastruktury jako kodu i wdrażania, takich jak Azure DevOps Azure Pipelines.

Aby uzyskać więcej informacji na temat ofert i przydziałów usługi Azure Stack Hub, zobacz Omówienie usług, planów, ofert i subskrypcji usługi Azure Stack Hub

Ważne jest, aby bezpiecznie zapisywać i przechowywać konfigurację aparatu AKS, w tym jego dane wyjściowe. Te pliki zawierają poufne informacje używane do uzyskiwania dostępu do klastra Kubernetes, dlatego muszą być chronione przed ujawnieniem nieadministratorom.

Dostępność aplikacji

Aplikacja nie powinna polegać na kopiach zapasowych wdrożonego wystąpienia. W standardowej praktyce ponownie wdróż aplikację zgodnie ze wzorcami infrastruktury jako kodu. Na przykład ponownie wdróż przy użyciu usługi Azure DevOps Azure Pipelines. Procedura BCDR powinna obejmować ponowne wdrożenie aplikacji w tym samym lub innym klastrze Kubernetes.

Dane aplikacji

Dane aplikacji są krytyczną częścią, aby zminimalizować utratę danych. W poprzedniej sekcji opisano techniki replikowania i synchronizowania danych między dwoma (lub więcej) wystąpieniami aplikacji. W zależności od infrastruktury bazy danych (MySQL, MongoDB, MSSQL lub innych) używanych do przechowywania danych dostępne będą różne techniki dostępności i tworzenia kopii zapasowych bazy danych.

Zalecane sposoby osiągnięcia integralności są następujące:

• Natywne rozwiązanie do tworzenia kopii zapasowych dla określonej bazy danych.
• Rozwiązanie do tworzenia kopii zapasowych, które oficjalnie obsługuje tworzenie kopii zapasowych i odzyskiwanie typu bazy danych używanego przez aplikację.

Ważne

Nie należy przechowywać danych kopii zapasowej w tym samym wystąpieniu usługi Azure Stack Hub, w którym znajdują się dane aplikacji. Całkowita awaria wystąpienia usługi Azure Stack Hub spowoduje również naruszenie kopii zapasowych.

Zagadnienia dotyczące dostępności

Platforma Kubernetes w usłudze Azure Stack Hub wdrożona za pośrednictwem aparatu AKS nie jest usługą zarządzaną. Jest to automatyczne wdrażanie i konfiguracja klastra Kubernetes przy użyciu usługi Azure Infrastructure-as-a-Service (IaaS). W związku z tym zapewnia taką samą dostępność jak podstawowa infrastruktura.

Infrastruktura usługi Azure Stack Hub jest już odporna na awarie i zapewnia możliwości, takie jak zestawy dostępności, aby dystrybuować składniki w wielu domenach błędów i aktualizacji. Jednak podstawowa technologia (klaster trybu failover) nadal wiąże się z pewnymi przestojami maszyn wirtualnych na serwerze fizycznym, jeśli wystąpi awaria sprzętowa.

Dobrym rozwiązaniem jest wdrożenie produkcyjnego klastra Kubernetes oraz obciążenia w dwóch (lub więcej) klastrach. Te klastry powinny być hostowane w różnych lokalizacjach lub centrach danych i korzystać z technologii takich jak Usługa Azure Traffic Manager, aby kierować użytkowników na podstawie czasu odpowiedzi klastra lub na podstawie lokalizacji geograficznej.

Klienci, którzy mają pojedynczy klaster Kubernetes, zazwyczaj łączą się z adresem IP usługi lub nazwą DNS danej aplikacji. W przypadku wdrożenia obejmującego wiele klastrów klienci powinni nawiązać połączenie z nazwą DNS usługi Traffic Manager wskazującą usługi/ruch przychodzący w każdym klastrze Kubernetes.

Uwaga

Ten wzorzec jest również najlepszym rozwiązaniem dla klastrów usługi AKS (zarządzanych) na platformie Azure.

Sam klaster Kubernetes wdrożony za pośrednictwem aparatu AKS powinien składać się z co najmniej trzech węzłów głównych i dwóch węzłów roboczych.

Zagadnienia dotyczące tożsamości i zabezpieczeń

Tożsamość i zabezpieczenia są ważnymi tematami. Szczególnie gdy rozwiązanie obejmuje niezależne wystąpienia usługi Azure Stack Hub. Platforma Kubernetes i platforma Azure (w tym Azure Stack Hub) mają odrębne mechanizmy kontroli dostępu opartej na rolach (RBAC):

• Kontrola dostępu oparta na rolach platformy Azure kontroluje dostęp do zasobów na platformie Azure (i w usłudze Azure Stack Hub), w tym możliwość tworzenia nowych zasobów platformy Azure. Uprawnienia można przypisać do użytkowników, grup lub jednostek usługi. (Jednostka usługi to tożsamość zabezpieczeń używana przez aplikacje).
• Kontrola RBAC platformy Kubernetes kontroluje uprawnienia do interfejsu API Kubernetes. Na przykład tworzenie zasobników i zasobników listy to akcje, które można autoryzować (lub odmówić) użytkownikowi za pośrednictwem kontroli dostępu opartej na rolach. Aby przypisać uprawnienia platformy Kubernetes użytkownikom, należy utworzyć role i powiązania ról.

Tożsamość usługi Azure Stack Hub i kontrola dostępu oparta na rolach

Usługa Azure Stack Hub udostępnia dwie opcje dostawcy tożsamości. Używany dostawca zależy od środowiska i tego, czy działa w połączonym lub odłączonym środowisku:

• Azure AD — może być używany tylko w połączonym środowisku.
• Usługi ADFS do tradycyjnego lasu usługi Active Directory — mogą być używane zarówno w środowisku połączonym, jak i odłączonym.

Dostawca tożsamości zarządza użytkownikami i grupami, w tym uwierzytelnianiem i autoryzacją dostępu do zasobów. Dostęp można przyznać zasobom usługi Azure Stack Hub, takich jak subskrypcje, grupy zasobów i poszczególne zasoby, takie jak maszyny wirtualne lub moduły równoważenia obciążenia. Aby mieć spójny model dostępu, należy rozważyć użycie tych samych grup (bezpośrednich lub zagnieżdżonych) dla wszystkich usług Azure Stack Hubs. Oto przykład konfiguracji:

Przykład zawiera dedykowaną grupę (używającą usługi AAD lub ADFS) do określonego celu. Aby na przykład podać uprawnienia współautora dla grupy zasobów zawierającej infrastrukturę klastra Kubernetes w określonym wystąpieniu usługi Azure Stack Hub (tutaj "Współautor klastra K8s Seattle"). Te grupy są następnie zagnieżdżone w ogólnej grupie zawierającej "podgrupy" dla każdej usługi Azure Stack Hub.

Nasz przykładowy użytkownik będzie teraz mieć uprawnienia "Współautor" do obu grup zasobów, które zawierają cały zestaw zasobów infrastruktury Kubernetes. Użytkownik będzie miał dostęp do zasobów w obu wystąpieniach usługi Azure Stack Hub, ponieważ wystąpienia współużytkują tego samego dostawcę tożsamości.

Ważne

Te uprawnienia mają wpływ tylko na usługę Azure Stack Hub i niektóre zasoby wdrożone na nim. Użytkownik, który ma ten poziom dostępu, może wyrządzić wiele szkód, ale nie może uzyskać dostępu do maszyn wirtualnych IaaS kubernetes ani interfejsu API Kubernetes bez dodatkowego dostępu do wdrożenia platformy Kubernetes.

Tożsamość i kontrola dostępu oparta na rolach platformy Kubernetes

Klaster Kubernetes domyślnie nie używa tego samego dostawcy tożsamości, co podkreślając usługę Azure Stack Hub. Maszyny wirtualne hostujące klaster Kubernetes, węzły główne i robocze używają klucza SSH określonego podczas wdrażania klastra. Ten klucz SSH jest wymagany do nawiązania połączenia z tymi węzłami przy użyciu protokołu SSH.

Interfejs API Platformy Kubernetes (na przykład dostępny przy użyciu programu kubectl) jest również chroniony przez konta usług, w tym domyślne konto usługi "administrator klastra". Poświadczenia dla tego konta usługi są początkowo przechowywane w pliku w .kube/config węzłach głównych platformy Kubernetes.

Zarządzanie wpisami tajnymi i poświadczenia aplikacji

Do przechowywania wpisów tajnych, takich jak parametry połączenia lub poświadczenia bazy danych, istnieje kilka opcji, w tym:

• Azure Key Vault
• Wpisy tajne usługi Kubernetes
• Rozwiązania innych firm, takie jak HashiCorp Vault (uruchomione na platformie Kubernetes)

Nie należy przechowywać wpisów tajnych ani poświadczeń w postaci zwykłego tekstu w plikach konfiguracji, kodzie aplikacji ani w skryptach. I nie przechowuj ich w systemie kontroli wersji. Zamiast tego automatyzacja wdrażania powinna pobierać wpisy tajne zgodnie z potrzebami.

Stosowanie poprawek i aktualizowanie

Proces poprawek i aktualizacji (PNU) w Azure Kubernetes Service jest częściowo zautomatyzowany. Uaktualnienia wersji platformy Kubernetes są wyzwalane ręcznie, podczas gdy aktualizacje zabezpieczeń są stosowane automatycznie. Te aktualizacje mogą obejmować poprawki zabezpieczeń systemu operacyjnego lub aktualizacje jądra. Usługa AKS nie uruchamia automatycznie tych węzłów systemu Linux w celu ukończenia procesu aktualizacji.

Proces PNU dla klastra Kubernetes wdrożonego przy użyciu aparatu AKS w usłudze Azure Stack Hub jest niezarządzany i jest odpowiedzialny za operatora klastra.

Aparat AKS pomaga w dwóch najważniejszych zadaniach:

• Uaktualnianie do nowszej wersji obrazu kubernetes i podstawowego obrazu systemu operacyjnego
• Uaktualnij tylko podstawowy obraz systemu operacyjnego

Nowsze podstawowe obrazy systemu operacyjnego zawierają najnowsze poprawki zabezpieczeń systemu operacyjnego i aktualizacje jądra.

Mechanizm nienadzorowanego uaktualnienia automatycznie instaluje aktualizacje zabezpieczeń wydane przed udostępnieniem nowej podstawowej wersji obrazu systemu operacyjnego w witrynie Azure Stack Hub Marketplace. Uaktualnienie nienadzorowane jest domyślnie włączone i automatycznie instaluje aktualizacje zabezpieczeń, ale nie uruchamia ponownie węzłów klastra Kubernetes. Ponowne uruchomienie węzłów można zautomatyzować przy użyciu Aemon (kured)) rozruchu typu open source KUbernetes RE. Kured zegarki dla węzłów systemu Linux, które wymagają ponownego uruchomienia, a następnie automatycznie obsługują ponowne uruchamianie zasobników i procesu ponownego uruchamiania węzła.

Zagadnienia dotyczące wdrażania (CI/CD)

Na platformie Azure i w usłudze Azure Stack Hub uwidaczniane są te same interfejsy API REST usługi Azure Resource Manager. Te interfejsy API są adresowane jak każda inna chmura platformy Azure (Azure, Chiny 21Vianet, Azure Government). Mogą występować różnice w wersjach interfejsu API między chmurami, a usługa Azure Stack Hub udostępnia tylko podzbiór usług. Identyfikator URI punktu końcowego zarządzania jest również inny dla każdej chmury, a każde wystąpienie usługi Azure Stack Hub.

Oprócz subtelnych różnic wymienionych interfejsy API REST platformy Azure Resource Manager zapewniają spójny sposób interakcji z platformą Azure i usługą Azure Stack Hub. W tym miejscu można użyć tego samego zestawu narzędzi, co w przypadku dowolnej innej chmury platformy Azure. Za pomocą usługi Azure DevOps, narzędzi, takich jak Jenkins lub PowerShell, można wdrażać i organizować usługi w usłudze Azure Stack Hub.

Zagadnienia do rozważenia

Jedną z głównych różnic w przypadku wdrożeń usługi Azure Stack Hub jest kwestia ułatwień dostępu do Internetu. Ułatwienia dostępu do Internetu określają, czy wybrać Microsoft hostowanego, czy własnego agenta kompilacji dla zadań ciągłej integracji/ciągłego wdrażania.

Agent hostowany samodzielnie może działać w usłudze Azure Stack Hub (jako maszynie wirtualnej IaaS) lub w podsieci sieciowej, która może uzyskiwać dostęp do usługi Azure Stack Hub. Przejdź do agentów usługi Azure Pipelines , aby dowiedzieć się więcej o różnicach.

Poniższa ilustracja ułatwia podjęcie decyzji, czy potrzebujesz własnego agenta kompilacji, czy Microsoft hostowanego agenta kompilacji:

• Czy punkty końcowe zarządzania usługi Azure Stack Hub są dostępne za pośrednictwem Internetu?
  • Tak: możemy użyć usługi Azure Pipelines z agentami hostowanymi Microsoft, aby nawiązać połączenie z usługą Azure Stack Hub.
  • Nie: Potrzebujemy własnych agentów, którzy mogą łączyć się z punktami końcowymi zarządzania usługi Azure Stack Hub.
• Czy nasz klaster Kubernetes jest dostępny za pośrednictwem Internetu?
  • Tak: możemy użyć usługi Azure Pipelines z agentami hostowanymi Microsoft do bezpośredniej interakcji z punktem końcowym interfejsu API Kubernetes.
  • Nie: Potrzebujemy własnych agentów, którzy mogą łączyć się z punktem końcowym interfejsu API klastra Kubernetes.

W scenariuszach, w których punkty końcowe zarządzania usługi Azure Stack Hub i interfejs API Kubernetes są dostępne za pośrednictwem Internetu, wdrożenie może używać agenta hostowanego Microsoft. To wdrożenie spowoduje, że architektura aplikacji będzie wyglądać następująco:

Jeśli punkty końcowe usługi Azure Resource Manager, interfejs API platformy Kubernetes lub oba te punkty nie są bezpośrednio dostępne za pośrednictwem Internetu, możemy użyć własnego agenta kompilacji, aby uruchomić kroki potoku. Ten projekt wymaga mniejszej łączności i można go wdrożyć tylko przy użyciu lokalnej łączności sieciowej z punktami końcowymi usługi Azure Resource Manager i interfejsem API Kubernetes:

Uwaga

Co z scenariuszami rozłączenia? W scenariuszach, w których usługa Azure Stack Hub lub Kubernetes lub obie z nich nie mają internetowych punktów końcowych zarządzania, nadal można używać usługi Azure DevOps na potrzeby wdrożeń. Możesz użyć własnej puli agentów (czyli agenta DevOps działającego lokalnie lub w usłudze Azure Stack Hub) lub całkowicie samodzielnie hostowanej Azure DevOps Server lokalnie. Agent hostowany samodzielnie wymaga tylko połączenia wychodzącego HTTPS (TCP/443).

Wzorzec może używać klastra Kubernetes (wdrożonego i orkiestrowanego za pomocą aparatu AKS) w każdym wystąpieniu usługi Azure Stack Hub. Obejmuje ona aplikację składającą się z frontonu, warstwy środkowej, usług zaplecza (na przykład MongoDB) i kontrolera ruchu przychodzącego opartego na nginx. Zamiast używać bazy danych hostowanej w klastrze K8s, możesz korzystać z "zewnętrznych magazynów danych". Opcje bazy danych obejmują mySQL, SQL Server lub dowolną bazę danych hostowaną poza usługą Azure Stack Hub lub W usłudze IaaS. Konfiguracje takie jak te nie są w zakresie tutaj.

Rozwiązania partnerskie

Istnieją Microsoft rozwiązania partnerskie, które mogą rozszerzać możliwości usługi Azure Stack Hub. Te rozwiązania okazały się przydatne we wdrożeniach aplikacji działających w klastrach Kubernetes.

Rozwiązania do magazynowania i danych

Zgodnie z opisem w temacie Zagadnienia dotyczące danych i magazynowania usługa Azure Stack Hub obecnie nie ma natywnego rozwiązania do replikowania magazynu między wieloma wystąpieniami. W przeciwieństwie do platformy Azure, możliwości replikowania magazynu w wielu regionach nie istnieją. W usłudze Azure Stack Hub każde wystąpienie jest własną odrębną chmurą. Jednak rozwiązania są dostępne od Microsoft Partnerów, którzy umożliwiają replikację magazynu w usługach Azure Stack Hubs i Azure.

SKALOWALNOŚĆ

Skalowalność zapewnia magazyn w skali internetowej, który od 2009 roku obsługuje firmy cyfrowe. Pierścień skalowalności, nasz magazyn zdefiniowany programowo, zamienia towary x86 serwerów w nieograniczoną pulę magazynów dla dowolnego typu danych — plików i obiektów — w skali petabajtów.

CLOUDIAN

Cloudian upraszcza magazyn w przedsiębiorstwie z nieograniczonym skalowalnym magazynem, który konsoliduje ogromne zestawy danych w jednym, łatwym środowisku zarządzanym.

Następne kroki

Aby dowiedzieć się więcej o pojęciach przedstawionych w tym artykule:

• Wzorce aplikacji rozproszonych między chmurami i skalowania geograficznego w usłudze Azure Stack Hub.
• Architektura mikrousług w usłudze Azure Kubernetes Service (AKS).

Gdy wszystko będzie gotowe do przetestowania przykładu rozwiązania, przejdź do przewodnika wdrażania klastra Kubernetes o wysokiej dostępności. Przewodnik wdrażania zawiera instrukcje krok po kroku dotyczące wdrażania i testowania jego składników.