Udostępnij za pośrednictwem


Architektura i obciążenia klastra Kubernetes dla usługi AKS włączone przez usługę Azure Arc

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server

Usługa Azure Kubernetes Service (AKS) na platformie Azure Local i Windows Server to platforma kontenerów klasy korporacyjnej Kubernetes obsługiwana przez usługę Azure Local. Obejmuje on platformę Kubernetes obsługiwaną przez firmę Microsoft, specjalnie utworzony host kontenera systemu Windows i host kontenera z systemem Linux obsługiwany przez firmę Microsoft, który ma na celu proste środowisko zarządzania wdrażaniem i cyklem życia.

W tym artykule przedstawiono podstawowe składniki infrastruktury Kubernetes, takie jak płaszczyzna sterowania, węzły i pule węzłów. Zasoby obciążeń, takie jak zasobniki, wdrożenia i zestawy, są również wprowadzane wraz z sposobem grupowania zasobów w przestrzenie nazw.

Architektura klastra Kubernetes

Platforma Kubernetes jest podstawowym składnikiem usługi AKS włączonym przez usługę Azure Arc. Usługa AKS używa zestawu wstępnie zdefiniowanych konfiguracji do efektywnego wdrażania klastrów Kubernetes i mając na uwadze skalowalność.

Operacja wdrażania tworzy wiele maszyn wirtualnych z systemem Linux lub Windows i łączy je razem w celu utworzenia klastrów Kubernetes.

Uwaga

Aby zwiększyć niezawodność systemu, jeśli korzystasz z wielu udostępnionych woluminów klastra (CSV) w klastrze, domyślnie dane maszyny wirtualnej są automatycznie rozłożone na wszystkie dostępne woluminy CSV w klastrze. Gwarantuje to, że aplikacje przetrwają w przypadku awarii woluminów CSV. Dotyczy to tylko nowych instalacji (nie uaktualnień).

Wdrożony system jest gotowy do odbierania standardowych obciążeń Kubernetes, skalowania tych obciążeń, a nawet skalowania liczby maszyn wirtualnych oraz liczby klastrów w górę i w dół zgodnie z potrzebami.

Klaster usługi Azure Kubernetes Service ma następujące składniki:

  • Klaster zarządzania (znany również jako host usługi AKS) udostępnia podstawowy mechanizm orkiestracji i interfejs do wdrażania klastrów obciążeń i zarządzania nimi.
  • Klastry obciążeń (nazywane również klastrami docelowymi) to miejsca wdrażania konteneryzowanych aplikacji.

Ilustracja przedstawiająca architekturę techniczną usługi Azure Kubernetes Service w systemie Azure Local i Windows Server.

Zarządzanie usługą AKS włączoną przez usługę Arc

Usługę AKS można zarządzać przy użyciu następujących opcji zarządzania:

  • Usługa Windows Admin Center oferuje intuicyjny interfejs użytkownika dla operatora Kubernetes do zarządzania cyklem życia klastrów.
  • Moduł programu PowerShell ułatwia pobieranie, konfigurowanie i wdrażanie usługi AKS. Moduł programu PowerShell obsługuje również wdrażanie i konfigurowanie innych klastrów obciążeń oraz ponowne konfigurowanie istniejących.

Klaster zarządzania

Podczas tworzenia klastra Kubernetes klaster zarządzania jest tworzony i konfigurowany automatycznie. Ten klaster zarządzania jest odpowiedzialny za aprowizowanie klastrów obciążeń i zarządzanie nimi, w których są uruchamiane obciążenia. Klaster zarządzania obejmuje następujące podstawowe składniki platformy Kubernetes:

  • Serwer interfejsu API: serwer interfejsu API jest sposobem uwidocznienia bazowych interfejsów API platformy Kubernetes. Ten składnik zapewnia interakcję z narzędziami do zarządzania, takimi jak Windows Admin Center, moduły programu PowerShell lub kubectl.
  • Moduł równoważenia obciążenia: moduł równoważenia obciążenia to jedna dedykowana maszyna wirtualna z systemem Linux z regułą równoważenia obciążenia dla serwera interfejsu API klastra zarządzania.

Klaster obciążeń

Klaster obciążenia to wysoce dostępne wdrożenie platformy Kubernetes przy użyciu maszyn wirtualnych z systemem Linux na potrzeby uruchamiania składników płaszczyzny sterowania Kubernetes i węzłów roboczych systemu Linux. Maszyny wirtualne oparte na systemie Windows Server Core są używane do ustanawiania węzłów roboczych systemu Windows. Może istnieć jeden lub więcej klastrów obciążeń zarządzanych przez jeden klaster zarządzania.

Składniki klastra obciążenia

Klaster obciążenia ma wiele składników, które opisano w poniższych sekcjach.

Płaszczyzna sterowania

  • Serwer interfejsu API: serwer interfejsu API umożliwia interakcję z interfejsem API Platformy Kubernetes. Ten składnik zapewnia interakcję z narzędziami do zarządzania, takimi jak Windows Admin Center, moduły programu PowerShell lub kubectl.
  • Etcd: Etcd to rozproszony magazyn par klucz-wartość, który przechowuje dane wymagane do zarządzania cyklem życia klastra. Przechowuje stan płaszczyzny sterowania.

Moduł równoważenia obciążenia

Moduł równoważenia obciążenia to maszyna wirtualna z systemem Linux i haProxy + KeepAlive w celu zapewnienia zrównoważonych usług dla klastrów obciążeń wdrożonych przez klaster zarządzania. W przypadku każdego klastra obciążenia usługa AKS dodaje co najmniej jedną maszynę wirtualną modułu równoważenia obciążenia. Każda usługa Kubernetes typu LoadBalancer utworzona w klastrze obciążenia ostatecznie tworzy regułę równoważenia obciążenia na maszynie wirtualnej.

Węzły robocze

Do uruchamiania aplikacji i usług pomocniczych potrzebny jest węzeł Kubernetes. Klaster obciążenia usługi AKS ma co najmniej jeden węzeł roboczy. Węzły procesu roboczego działają jako maszyny wirtualne, które uruchamiają składniki węzła Kubernetes i hostuje zasobniki i usługi tworzące obciążenie aplikacji.

Istnieją podstawowe składniki obciążenia Kubernetes, które można wdrożyć w klastrach obciążeń usługi AKS, takich jak zasobniki i wdrożenia.

Zasobniki

Platforma Kubernetes używa zasobników do uruchamiania wystąpienia aplikacji. Zasobnik reprezentuje pojedyncze wystąpienie aplikacji. Zazwyczaj zasobniki mają mapowanie 1:1 z kontenerem, chociaż istnieją zaawansowane scenariusze, w których zasobnik może zawierać wiele kontenerów. Te zasobniki z wieloma kontenerami są zaplanowane razem w tym samym węźle i umożliwiają kontenerom udostępnianie powiązanych zasobów. Aby uzyskać więcej informacji, zobacz Kubernetes pods and Kubernetes pod lifecycle (Cykl życia zasobników Kubernetes).

Wdrożenia

Wdrożenie reprezentuje co najmniej jeden identyczny zasobnik zarządzany przez kontroler wdrażania platformy Kubernetes. Wdrożenie definiuje liczbę replik (zasobników) do utworzenia, a harmonogram Kubernetes gwarantuje, że jeśli zasobniki lub węzły napotkają problemy, dodatkowe zasobniki są zaplanowane na węzłach w dobrej kondycji. Aby uzyskać więcej informacji, zobacz Wdrożenia platformy Kubernetes.

StatefulSets i DaemonSets

Kontroler wdrażania używa harmonogramu kubernetes do uruchamiania określonej liczby replik w dowolnym dostępnym węźle z dostępnymi zasobami. Takie podejście do używania wdrożeń może być wystarczające dla aplikacji bezstanowych, ale nie w przypadku aplikacji wymagających trwałej konwencji nazewnictwa lub magazynu. W przypadku aplikacji, które wymagają istnienia repliki w każdym węźle (lub wybranych węzłach) w klastrze, kontroler wdrażania nie sprawdza sposobu dystrybucji replik między węzłami.

  • StatefulSets: stanowy zestaw jest podobny do wdrożenia w tym, że co najmniej jeden identyczny zasobnik jest tworzony i zarządzany. Repliki w elemencie StatefulSet są zgodne z bezproblemowym, sekwencyjnym podejściem do wdrażania, skalowania, uaktualniania i kończenia. W przypadku elementu StatefulSet (gdy repliki są ponownie ułożone) konwencja nazewnictwa, nazwy sieci i magazyn są utrwalane. Repliki w zestawie StatefulSet są zaplanowane i uruchamiane we wszystkich dostępnych węzłach w klastrze Kubernetes. Jeśli musisz upewnić się, że co najmniej jeden zasobnik w zestawie działa w węźle, możesz zamiast tego użyć elementu DaemonSet. Aby uzyskać więcej informacji, zobacz Kubernetes StatefulSets.
  • DaemonSets: w przypadku określonych potrzeb dotyczących zbierania dzienników lub monitorowania może być konieczne uruchomienie danego zasobnika na wszystkich lub wybranych węzłach. Zestaw DaemonSet jest ponownie używany do wdrażania co najmniej jednego identycznego zasobnika, ale kontroler DaemonSet gwarantuje, że każdy określony węzeł uruchamia wystąpienie zasobnika. Aby uzyskać więcej informacji, zobacz Kubernetes DaemonSets.

Przestrzenie nazw

Zasoby platformy Kubernetes, takie jak zasobniki i wdrożenia, są logicznie grupowane w przestrzeń nazw. Te grupowania umożliwiają logiczne dzielenie klastrów obciążeń i ograniczanie dostępu do tworzenia, wyświetlania lub zarządzania zasobami. Można na przykład utworzyć przestrzenie nazw, aby oddzielić grupy biznesowe. Użytkownicy mogą korzystać tylko z zasobów znajdujących się w przypisanych przestrzeniach nazw. Aby uzyskać więcej informacji, zobacz Kubernetes namespaces (Przestrzenie nazw kubernetes).

Podczas tworzenia klastra usługi Azure Kubernetes Service w usłudze AKS włączonej przez usługę Arc dostępne są następujące przestrzenie nazw:

  • ustawienie domyślne: przestrzeń nazw, w której zasobniki i wdrożenia są tworzone domyślnie, gdy żadne z nich nie jest udostępniane. W mniejszych środowiskach można wdrażać aplikacje bezpośrednio w domyślnej przestrzeni nazw bez tworzenia dodatkowych separacji logicznych. W przypadku interakcji z interfejsem API Kubernetes, takim jak z kubectl get pods, domyślna przestrzeń nazw jest używana, gdy nie zostanie określona żadna.
  • kube-system: przestrzeń nazw, w której istnieją podstawowe zasoby, takie jak funkcje sieciowe, takie jak DNS i proxy, lub pulpit nawigacyjny platformy Kubernetes. W tej przestrzeni nazw zazwyczaj nie wdraża się własnych aplikacji.
  • kube-public: przestrzeń nazw zwykle nie jest używana, ale może służyć do wyświetlania zasobów w całym klastrze i może być wyświetlana przez dowolnego użytkownika.

Wpisy tajne

Wpisy tajne platformy Kubernetes umożliwiają przechowywanie poufnych informacji, takich jak hasła, tokeny OAuth i klucze SSH (Secure Shell). Domyślnie platforma Kubernetes przechowuje wpisy tajne jako niezaszyfrowane ciągi zakodowane w formacie base64 i mogą być pobierane jako zwykły tekst przez każdego, kto ma dostęp do interfejsu API. Aby uzyskać więcej informacji, zobacz Kubernetes Secrets (Wpisy tajne platformy Kubernetes).

Trwałe woluminy

Wolumin trwały to zasób magazynu w klastrze Kubernetes, który został aprowizowany przez administratora lub dynamicznie aprowizowany przy użyciu klas magazynu. Aby użyć woluminów trwałych, zasobniki żądają dostępu przy użyciu elementu PersistentVolumeClaim. Aby uzyskać więcej informacji, zobacz Trwałe woluminy.

Wdrożenia mieszanego systemu operacyjnego

Jeśli dany klaster obciążenia składa się zarówno z węzłów roboczych systemu Linux, jak i Windows, należy zaplanować go w systemie operacyjnym, który może obsługiwać aprowizowanie obciążenia. Platforma Kubernetes oferuje dwa mechanizmy zapewniające, że obciążenia lądują na węzłach z docelowym systemem operacyjnym:

  • Selektor węzłów to proste pole w specyfikacji zasobnika, które ogranicza harmonogram zasobników tylko do węzłów w dobrej kondycji pasujących do systemu operacyjnego.
  • Defekty i tolerancje współpracują ze sobą, aby upewnić się, że zasobniki nie są zaplanowane na węzły przypadkowo. Węzeł może być "skażony", tak aby nie akceptował zasobników, które nie są jawnie tolerowane przez "tolerancję" w specyfikacji zasobnika.

Aby uzyskać więcej informacji, zobacz selektory węzłów i defekty i tolerancje.

Następne kroki

W tym artykule przedstawiono architekturę klastra usługi AKS włączoną przez usługę Azure Arc oraz składniki klastra obciążenia. Aby uzyskać więcej informacji na temat tych pojęć, zobacz następujące artykuły: