Klastry i obciążenia dla Azure Kubernetes Service on Azure Stack HCI

Dotyczy: Azure Stack HCI, wersje 21H2 i 20H2; Windows Server 2022 Datacenter, Windows Server 2019 Datacenter

Azure Kubernetes Service on Azure Stack HCI to platforma kontenerów Kubernetes klasy korporacyjnej, która jest Azure Stack HCI. Obejmuje on podstawową platformę Kubernetes obsługiwaną przez firmę Microsoft, celowo sbudowaną usługę Windows Container Host oraz obsługiwany przez firmę Microsoft host kontenera systemu Linux, który ma na celu łatwe wdrażanie i zarządzanie cyklem życia.

W tym artykule oprowadzono podstawowe składniki infrastruktury kubernetes, takie jak płaszczyzna sterowania, węzły i pule węzłów. Zostaną również wprowadzone zasoby obciążeń, takie jak zasobniki, wdrożenia i zestawy, oraz sposób grupowania zasobów w przestrzenie nazw.

Składniki klastra

Kubernetes jest podstawowym składnikiem Azure Kubernetes Service on Azure Stack HCI. Azure Kubernetes Service on Azure Stack HCI zestaw wstępnie zdefiniowanych konfiguracji do efektywnego wdrażania klastrów Kubernetes z myślą o skalowalności.

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

Uwaga

Aby zwiększyć niezawodność systemu, w przypadku uruchamiania wielu udostępnionych woluminów klastra (CSV) w klastrze usługi Azure Stack HCI domyślnie dane maszyny wirtualnej są automatycznie rozłożone na wszystkie dostępne woluminy CSV w klastrze. Gwarantuje to, że aplikacje będą sobie z nich zrównoważyć 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 Azure Kubernetes Service ma następujące składniki na Azure Stack HCI:

  • Klaster zarządzania (znany również jako host usługi AKS) udostępnia podstawowy mechanizm aranżacji i interfejs do wdrażania co najmniej jednego klastra obciążenia i zarządzania nimi.
  • Klastry obciążeń (nazywane również klastrami docelowymi) to miejsca, w których wdrażane są konteneryzowane aplikacje.

Illustrates the technical architecture of Azure Kubernetes Service on Azure Stack HCI

Zarządzanie aks na platformie Azure Stack HCI

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

  • Windows Administracyjne oferuje intuicyjny interfejs użytkownika dla operatora kubernetes do zarządzania cyklem życia Azure Kubernetes Service klastrów w Azure Stack HCI.
  • Moduł programu PowerShell, który ułatwia pobieranie, konfigurowanie i wdrażanie Azure Kubernetes Service on Azure Stack HCI. Moduł programu PowerShell obsługuje również wdrażanie i konfigurowanie dodatkowych klastrów obciążeń oraz ponowne konfigurowanie istniejących.

Klaster zarządzania

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

  • Serwer interfejsu API — serwer interfejsu API to sposób, w jaki są udostępniane podstawowe interfejsy API platformy Kubernetes. Ten składnik umożliwia interakcję z narzędziami do zarządzania, takimi jak Windows Admin Center, moduły programu PowerShell lub kubectl .
  • Load Balancer — usługa równoważenia obciążenia to pojedyncza 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ążeń jest wdrożeniem rozwiązania Kubernetes o wysokiej dostępie, które używa maszyn wirtualnych z systemem Linux do uruchamiania składników płaszczyzny sterowania kubernetes i węzłów procesu roboczego systemu Linux. Windows maszyn wirtualnych opartych na systemie Server Core służą do ustanawiania Windows procesów roboczych. Jeden klaster zarządzania może być zarządzany przez co najmniej jeden klaster obciążenia.

Składniki klastra obciążenia

Klaster obciążeń 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 kubernetes. Ten składnik umożliwia interakcję z narzędziami do zarządzania, takimi jak Windows Admin Center, moduły programu PowerShell lub kubectl .
  • Etcd — etcd to rozproszony magazyn klucz-wartość, który przechowuje dane wymagane do zarządzania cyklem życia klastra. Przechowuje stan płaszczyzny sterowania.

Moduł równoważenia obciążenia

Usługa równoważenia obciążenia to maszyna wirtualna z systemem Linux i systemem HAProxy + KeepAlive, która zapewnia usługi o zrównoważonym obciążeniu dla klastrów obciążeń wdrożonych przez klaster zarządzania. Dla każdego klastra obciążenia Azure Kubernetes Service on Azure Stack HCI co najmniej jedną maszynę wirtualną usługi równoważenia obciążenia. Każda usługa Kubernetes typu utworzona w klastrze obciążenia spowoduje utworzenie reguły równoważenia obciążenia na LoadBalancer maszynie wirtualnej.

Węzły procesu roboczego

Do uruchamiania aplikacji i usług obsługi potrzebny jest węzeł Kubernetes. Klaster obciążeń Azure Kubernetes Service na platformie Azure Stack HCI ma co najmniej jeden węzeł procesu roboczego, który jest maszyną wirtualną, która uruchamia składniki węzła Kubernetes oraz hostuje zasobniki i usługi, które z tego obciążenia aplikacji. Istnieją podstawowe składniki obciążenia Kubernetes, które można wdrożyć Azure Kubernetes Service on Azure Stack HCI klastrach obciążeń, takich jak zasobniki i wdrożenia.

Strąków

W przypadku usługi Kubernetes zasobniki są używane 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ą planowane razem w tym samym węźle i umożliwiają kontenerom udostępnianie powiązanych zasobów. Aby uzyskać więcej informacji, zobacz Kubernetes pods (Zasobniki rozwiązania Kubernetes) i Kubernetes pod lifecycle (Cykl życia zasobnika rozwiązania Kubernetes).

Wdrożenia

Wdrożenie reprezentuje co najmniej jeden identyczny zasobnik zarządzany przez kontroler wdrażania kubernetes. Wdrożenie definiuje liczbę replik (zasobników) do utworzenia, a harmonogram kubernetes zapewnia, że w przypadku wystąpienia problemów z zasobnikami lub węzłami zostaną zaplanowane dodatkowe zasobniki w węzłach w dobrej kondycji. Aby uzyskać więcej informacji, zobacz Wdrożenia rozwiązania Kubernetes.

Zestawy StatefulSets i DaemonSets

Kontroler wdrażania używa harmonogramu kubernetes do uruchamiania danej 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 w przypadku aplikacji bez stanowych, ale nie w przypadku aplikacji, które wymagają trwałej konwencji nazewnictwa lub magazynu. W przypadku aplikacji, które wymagają, aby replika istniała w każdym węźle lub wybranych węzłach w klastrze, kontroler wdrażania nie pokazuje, jak repliki są dystrybuowane między węzłami.

  • StatefulSets — zestaw StatefulSet jest podobny do wdrożenia w tym, że co najmniej jeden identyczny zasobnik jest tworzony i zarządzany. Repliki w zestawie StatefulSet są zgodne z graceful, sekwencyjnym podejściem do wdrażania, skalowania, uaktualnień i zakończenia. W przypadku zestawu StatefulSet (gdy repliki są ponownie publikowane) konwencja nazewnictwa, nazwy sieciowe i magazyn są utrwalane. Repliki w zestawie StatefulSet są zaplanowane i uruchamiane w dowolnym dostępnym węźle w Azure Kubernetes Service on Azure Stack HCI klastra. Jeśli musisz upewnić się, że co najmniej jeden zasobnik w zestawie działa w węźle, możesz zamiast tego użyć zestawu DaemonSet. Aby uzyskać więcej informacji, zobacz Kubernetes StatefulSets.

  • DaemonSets — w przypadku określonych potrzeb w zakresie zbierania dzienników lub monitorowania może być konieczne uruchomienie danego zasobnika we wszystkich węzłach lub wybranych węzłach. Element DaemonSet jest ponownie używany do wdrażania co najmniej jednego identycznego zasobnika, ale kontroler DaemonSet zapewnia, że każdy określony węzeł uruchamia wystąpienie zasobnika. Aby uzyskać więcej informacji, zobacz Kubernetes DaemonSets.

Przestrzenie nazw

Zasoby rozwiązania Kubernetes, takie jak zasobniki i wdrożenia, są logicznie pogrupowane w przestrzeni nazw. Te grupowania zapewniają sposób logicznego dzielenia klastra obciążenia Azure Kubernetes Service on Azure Stack HCI i ograniczania dostępu do tworzenia i wyświetlania zasobów oraz zarządzania nimi. Przestrzenie nazw można na przykład tworzyć w celu oddzielenia grup biznesowych. Użytkownicy mogą wchodzić w interakcje tylko z zasobami w ramach przypisanych im przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Kubernetes namespaces (Przestrzenie nazw kubernetes).

Podczas tworzenia klastra Azure Kubernetes Service na Azure Stack HCI dostępne są następujące przestrzenie nazw:

  • default — ta przestrzeń nazw to miejsce, w którym zasobniki i wdrożenia są tworzone domyślnie, gdy nie zostaną podane żadne. W mniejszych środowiskach można wdrażać aplikacje bezpośrednio w domyślnej przestrzeni nazw bez tworzenia dodatkowych odestań logicznych. Podczas interakcji z interfejsem API Kubernetes, takim jak za pomocą usługi , domyślna przestrzeń nazw jest używana, kubectl get pods gdy nie zostanie określona żadna przestrzeń nazw.
  • kube-system — ta przestrzeń nazw to miejsce, w którym istnieją podstawowe zasoby, takie jak funkcje sieciowe, takie jak system DNS i serwer proxy, lub pulpit nawigacyjny kubernetes. Zazwyczaj nie wdraża się własnych aplikacji w tej przestrzeni nazw.
  • kube-public — ta przestrzeń nazw zwykle nie jest używana, ale może być używana, aby zasoby były widoczne w całym klastrze i mogą być widoczne dla dowolnego użytkownika.

Wpisy tajne

Wpisy tajne usługi Kubernetes umożliwiają przechowywanie poufnych informacji, takich jak hasła, tokeny OAuth i klucze Secure Shell (SSH). Domyślnie usługa 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 kubernetes).

Trwałe woluminy

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

Wdrożenia w różnych systemach operacyjnych

Jeśli dany klaster obciążenia składa się zarówno z węzłów procesu roboczego systemu Linux, jak i Windows, obciążenia muszą być zaplanowane w systemie operacyjnym, który może obsługiwać aprowizowanie obciążenia. Na platformie Kubernetes są dwa mechanizmy zapewniające, że obciążenia trafią do węzłów z docelowym systemem operacyjnym:

  • Selektor węzłów to proste pole w specyfikacji zasobnika, które umożliwia zaplanowanie zasobników tylko na węzłach w dobrej kondycji zgodnych z systemem operacyjnym.
  • Taints and tolerations work together to ensure that pods are not scheduled in nodesintionally. Węzeł może być "pomykany", aby nie akceptować zasobników, które nie tolerują jawnie jego awarii przez "tolerancję" w specyfikacji zasobnika.

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

Następne kroki

Ten artykuł zawiera informacje na temat architektury klastra usługi AKS na platformie Azure Stack HCI i składników klastra obciążenia. Aby dowiedzieć się więcej na temat Azure Stack HCI AKS, zobacz następujące artykuły: