Udostępnij za pośrednictwem

Zarządzanie węzłami i pulami węzłów platformy Kubernetes

Architektura platformy Kubernetes składa się z dwóch warstw: płaszczyzny sterowania i co najmniej jednego węzła w puli węzłów. W tym artykule opisano i porównaliśmy sposób, w jaki usługa Amazon Elastic Kubernetes Service (EKS) i usługa Azure Kubernetes Service (AKS) zarządzają węzłami agenta i węzłami procesu roboczego.

Uwaga

Ten artykuł jest częścią serii artykułów, które ułatwiają specjalistom, którzy znają usługę Amazon EKS, rozumieją usługę Azure Kubernetes Service (AKS).

Zarówno w usługach Amazon EKS, jak i AKS platforma w chmurze udostępnia warstwę płaszczyzny sterowania i zarządza nią, a klient zarządza warstwą węzła. Na poniższym diagramie przedstawiono relację między płaszczyzną sterowania a węzłami w architekturze AKS Kubernetes.

Diagram przedstawiający plan kontrolny i węzły w architekturze AKS.

Grupy węzłów zarządzanych usługi Amazon EKS

Grupy węzłów zarządzanych amazon EKS automatyzują aprowizowanie i zarządzanie cyklem życia węzłów roboczych usługi Amazon Elastic Compute Cloud (EC2) dla klastrów Amazon EKS. Użytkownicy usług Amazon Web Services (AWS) mogą używać narzędzia wiersza polecenia eksctl do tworzenia, aktualizowania lub kończenia węzłów dla klastrów EKS. Automatyczne aktualizacje i zakończenia odgradzają i wyłączają węzły, aby zapewnić, że aplikacje pozostaną dostępne.

Każdy zarządzany węzeł jest aprowizowany w ramach grupy automatycznego skalowania Amazon EC2, którą obsługuje i kontroluje Amazon EKS. Narzędzie do automatycznego skalowania klastra Kubernetes automatycznie dostosowuje liczbę węzłów roboczych w klastrze, gdy zasobniki kończą się niepowodzeniem lub są ponownie zaplanowane na inne węzły. Można skonfigurować każdą grupę węzłów, aby działały w wielu strefach dostępności w regionie.

Aby uzyskać więcej informacji, zobacz Tworzenie zarządzanej grupy węzłów i Aktualizowanie zarządzanej grupy węzłów.

Możesz również uruchomić zasobniki Kubernetes na platformie AWS Fargate. Platforma Fargate zapewnia pojemność obliczeniową o odpowiednim rozmiarze na żądanie dla kontenerów. Aby uzyskać więcej informacji, zobacz Upraszczanie zarządzania obliczeniami.

Karpenter

Karpenter to projekt typu open source, który ułatwia ulepszanie zarządzania cyklem życia węzłów w klastrach Kubernetes. Automatyzuje aprowizowanie i dezaktywację węzłów na podstawie konkretnych potrzeb związanych z planowaniem podów, co poprawia skalowanie i optymalizację kosztów. Użyj Narzędzia Karpenter do następujących głównych funkcji:

  • Monitoruj zasobniki, których harmonogram platformy Kubernetes nie może zaplanować z powodu ograniczeń zasobów.

  • Oceń wymagania dotyczące planowania, takie jak żądania zasobów, selektory węzłów, koligacje i tolerancje, zasobników, których nie można anulować.

  • Skonfiguruj nowe węzły spełniające wymagania nieplanowanych zasobników.

  • Usuń węzły, gdy nie są już potrzebne.

Za pomocą Karpenter można zdefiniować pule węzłów, które mają ograniczenia związane z aprowizowaniem węzłów, takie jak tainty, etykiety, wymagania (typy instancji i strefy) oraz limity na całkowitą liczbę aprowizowanych zasobów. Podczas wdrażania obciążeń określ różne ograniczenia planowania w specyfikacji zasobnika. Można na przykład określić żądania zasobów lub limity, selektory węzłów, powiązania węzłów lub powiązania zasobników, tolerancje i ograniczenia rozprzestrzenienia topologii. Następnie Karpenter konfiguruje węzły o odpowiednich rozmiarach na podstawie tych specyfikacji.

Przed uruchomieniem Firmy Karpenter użytkownicy amazon EKS polegali przede wszystkim na grupach automatycznego skalowania usługi Amazon EC2 i autoskalatorze klastra Kubernetes , aby dynamicznie dostosować pojemność obliczeniową swoich klastrów. Nie musisz tworzyć kilkudziesięciu grup węzłów, aby osiągnąć elastyczność i różnorodność zapewnianą przez Firmę Karpenter. W przeciwieństwie do narzędzia do automatycznego skalowania klastra Kubernetes, Narzędzie Karpenter jest mniej zależne od wersji platformy Kubernetes i nie wymaga przejścia między platformami AWS i Kubernetes API.

Karpenter konsoliduje zadania związane z orkiestracją instancji w ramach jednego systemu, który jest prostszy, bardziej stabilny i lepiej rozumie działanie klastra. Karpenter pomaga przezwyciężyć wyzwania związane z autoskalerem klastra, oferując łatwiejsze sposoby na:

  • Konfigurowanie węzłów na podstawie wymagań dotyczących obciążenia.

  • Utwórz różne konfiguracje węzłów według typu wystąpienia przy użyciu opcji elastycznej puli węzłów. Zamiast zarządzać kilkoma określonymi niestandardowymi grupami węzłów, użyj Karpenter do zarządzania zróżnicowaną pojemnością obciążeń za pomocą elastycznej, pojedynczej puli węzłów.

  • Ulepsz planowanie zasobników na dużą skalę poprzez szybkie uruchamianie węzłów i planowanie zasobników.

W porównaniu z grupami automatycznego skalowania i zarządzanymi grupami węzłów, Platforma Karpenter ściślej integruje zarządzanie skalowaniem z interfejsami API natywnymi dla platformy Kubernetes. Automatyczne skalowanie grup i zarządzanych grup węzłów to abstrakcje natywne dla platformy AWS, które wyzwalają skalowanie na podstawie metryk na poziomie platformy AWS, takich jak obciążenie procesora CPU EC2. Mimo że funkcja automatycznego skalowania klastra łączy abstrakcję Kubernetes z abstrakcjami platformy AWS, poświęca pewną elastyczność, taką jak planowanie dla określonej strefy dostępności.

Karpenter upraszcza zarządzanie węzłami, eliminując składniki specyficzne dla platformy AWS, co zapewnia większą elastyczność bezpośrednio w ramach platformy Kubernetes. Użyj Karpenter w klastrach, które uruchamiają obciążenia napotykające zwiększone, nieregularne zapotrzebowanie lub mają zróżnicowane wymagania obliczeniowe. Użyj grup węzłów zarządzanych i grup automatycznego skalowania dla klastrów, które uruchamiają bardziej statyczne i spójne obciążenia. W zależności od wymagań można użyć kombinacji dynamicznie i statycznie zarządzanych węzłów.

Kontenery kata

Kata Containers to projekt typu open source, który zapewnia wysoce bezpieczne środowisko uruchomieniowe kontenera. Łączy ona lekki charakter kontenerów z zaletami zabezpieczeń maszyn wirtualnych. Kontenery Kata zwiększają izolację obciążeń i zabezpieczenia, uruchamiając każdy kontener z innym systemem operacyjnym gościa, w przeciwieństwie do tradycyjnych kontenerów, które współdzielą to samo jądro systemu Linux między obciążeniami. Kontenery Kata uruchamiają kontenery na maszynie wirtualnej zgodnej ze standardem OCI (Open Container Initiative), która zapewnia ścisłą izolację między kontenerami na tej samej maszynie hosta. Kontenery kata udostępniają następujące funkcje:

  • Rozszerzona izolacja obciążenia: Każdy kontener działa we własnej lekkiej maszynie wirtualnej, aby zapewnić izolację na poziomie sprzętu.

  • Ulepszone zabezpieczenia: Użycie technologii maszyn wirtualnych zapewnia dodatkową warstwę zabezpieczeń, co zmniejsza ryzyko wystąpienia awarii kontenerów.

  • Zgodność ze standardami branżowymi: Kontenery Kata integrują się z standardowymi narzędziami branżowymi, takimi jak format kontenera OCI i interfejs środowiska uruchomieniowego kontenera Kubernetes.

  • Obsługa wielu architektur i funkcji hypervisor: Kontenery Kata obsługują architektury AMD64 i ARM i można ich używać z funkcjami hypervisor, takimi jak Cloud Hypervisor i Firecracker.

  • Łatwe wdrażanie i zarządzanie: Kata Containers upraszcza orkiestrację obciążeń, ponieważ korzysta z systemu orkiestracji Kubernetes.

Aby skonfigurować i uruchomić kontenery Kata na platformie AWS, skonfiguruj klaster Amazon EKS do używania platformy Firecracker. Firecracker to technologia wirtualizacji typu open source firmy Amazon, która ułatwia tworzenie bezpiecznych, wielodostępnych usług opartych na kontenerach i opartych na funkcjach oraz zarządzanie nimi. Użyj narzędzia Firecracker, aby wdrożyć obciążenia w lekkich maszynach wirtualnych nazywanych mikroVM, które zapewniają zwiększone zabezpieczenia i izolację obciążeń w porównaniu z tradycyjnymi maszynami wirtualnymi. Maszyny microVM zwiększają również szybkość i wydajność zasobów kontenerów. Wykonaj kroki, aby uruchomić kontenery Kata na platformie AWS EKS.

Dedykowane hosty

Gdy używasz usługi Amazon EKS do wdrażania i uruchamiania kontenerów, możesz uruchamiać kontenery na dedykowanych hostach usługi Amazon EC2. Ta funkcja jest jednak dostępna tylko dla grup węzłów zarządzanych samodzielnie. Dlatego należy ręcznie utworzyć szablon uruchamiania i grupy automatycznego skalowania. Następnie zarejestruj dedykowane hosty, uruchom szablon i grupy automatycznego skalowania w klastrze EKS. Aby utworzyć te zasoby, użyj tej samej metody co ogólne skalowanie automatyczne EC2.

Aby uzyskać więcej informacji na temat używania usługi AWS EKS do uruchamiania kontenerów na dedykowanych hostach USŁUGI EC2, zobacz następujące zasoby:

Węzły i pule węzłów AKS

Podczas automatycznego tworzenia klastra usługi AKS tworzy i konfiguruje płaszczyznę sterowania, która zapewnia podstawowe usługi Kubernetes i orkiestrację obciążeń aplikacji. Platforma Azure zapewnia płaszczyznę sterowania usługi AKS bez ponoszenia kosztów jako zarządzany zasób platformy Azure. Płaszczyzna sterowania i jej zasoby istnieją tylko w regionie, w którym tworzysz klaster.

Węzły, nazywane również węzłami agenta lub węzłami roboczymi, hostują obciążenia i aplikacje. W usłudze AKS można w pełni zarządzać węzłami agenta dołączonymi do klastra usługi AKS i płacić za nie.

Aby uruchamiać aplikacje i usługi pomocnicze, klaster usługi AKS potrzebuje co najmniej jednego węzła, czyli maszyny wirtualnej platformy Azure, która uruchamia składniki węzła Kubernetes i środowisko uruchomieniowe kontenera. Każdy klaster usługi AKS musi zawierać co najmniej jedną pulę węzłów systemowych , która ma co najmniej jeden węzeł.

AKS łączy węzły o tej samej konfiguracji w pule maszyn wirtualnych, które obsługują obciążenia AKS. Użyj pul węzłów systemowych do hostowania krytycznych zasobników systemu, takich jak CoreDNS. Użyj pul węzłów użytkownika do hostowania zasobników obciążeń. Jeśli potrzebujesz tylko jednej puli węzłów w klastrze usługi AKS, na przykład w środowisku deweloperskim, możesz zaplanować zasobniki aplikacji w puli węzłów systemowych.

Diagram przedstawiający pojedynczy węzeł Kubernetes.

Można również utworzyć wiele pul węzłów dla użytkowników, aby rozgraniczyć różne obciążenia na różnych węzłach. Takie podejście pomaga zapobiec problemowi z hałaśliwym sąsiadem i obsługuje aplikacje, które mają różne wymagania dotyczące zasobów obliczeniowych lub magazynu.

Każdy węzeł agenta w puli węzłów systemu lub użytkownika jest zasadniczo maszyną wirtualną. Zestawy skalowania maszyn wirtualnych platformy Azure konfigurują maszyny wirtualne, a klaster usługi AKS zarządza nimi. Aby uzyskać więcej informacji, zobacz Pule węzłów.

Podczas tworzenia klastra usługi AKS można zdefiniować początkową liczbę i rozmiar węzłów roboczych lub podczas dodawania nowych węzłów i pul węzłów do istniejącego klastra usługi AKS. Jeśli nie określisz rozmiaru maszyny wirtualnej, domyślnym rozmiarem jest Standard_D2s_v3 dla pul węzłów systemu Windows i Standard_DS2_v2 dla pul węzłów systemu Linux.

Ważne

Aby zapewnić lepsze opóźnienie dla wewnętrznych wywołań węzłów i komunikacji z usługami platformy, wybierz serię maszyn wirtualnych, która obsługuje przyspieszoną sieć.

Tworzenie puli węzłów

Podczas tworzenia nowej puli węzłów skojarzony zestaw skalowania maszyn wirtualnych jest tworzony w grupie zasobów węzła. Ta grupa zasobów platformy Azure zawiera wszystkie zasoby infrastruktury klastra usługi AKS. Te zasoby obejmują węzły Kubernetes, wirtualne zasoby sieciowe, tożsamości zarządzane i magazyn.

Domyślnie grupa zasobów węzła ma nazwę taką jak MC_<resourcegroupname>_<clustername>_<location>. Usługa AKS automatycznie usuwa grupę zasobów węzła po usunięciu klastra. Tę grupę zasobów należy używać tylko dla zasobów, które dzielą cykl życia klastra.

Aby uzyskać więcej informacji, zobacz Utwórz pule węzłów dla klastra w AKS.

Dodaj pulę węzłów

Aby dodać pulę węzłów do nowego lub istniejącego klastra usługi AKS, użyj witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST usługi AKS. Możesz również użyć narzędzi infrastruktury jako kodu (IaC), takich jak Bicep, szablony usługi Azure Resource Manager lub Terraform.

W poniższym przykładzie kodu użyto polecenia az aks nodepool add interfejsu wiersza polecenia platformy Azure, aby dodać pulę węzłów o nazwie mynodepool , która ma trzy węzły. W grupie zasobów myAKSCluster dodaje pulę węzłów do istniejącego klastra AKS o nazwie myResourceGroup.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Pule węzłów typu spot

Pula węzłów typu spot to pula węzłów obsługiwana przez zestaw skalowania maszyn wirtualnych typu spot . Użyj maszyn wirtualnych typu spot dla węzłów w klastrze usługi AKS, aby korzystać z nieużywanej pojemności platformy Azure po obniżonym koszcie. Ilość dostępnej nieużywanej pojemności zależy od czynników, takich jak rozmiar węzła, region i godzina dnia.

Podczas wdrażania puli węzłów typu spot platforma Azure przydziela węzły typu spot, jeśli pojemność jest dostępna. Węzły typu spot nie mają jednak umowy dotyczącej poziomu usług (SLA). Zestaw skalowania typu spot obsługujący pulę węzłów typu spot jest wdrażany w pojedynczej domenie błędów i nie zapewnia gwarancji wysokiej dostępności. Gdy platforma Azure potrzebuje pojemności, infrastruktura platformy Azure eksmituje węzły typu spot. Przed eksmisją otrzymasz powiadomienie do 30 sekund. Nie można użyć puli węzłów typu spot jako domyślnej puli węzłów klastra. Użyj puli węzłów typu spot tylko jako puli pomocniczej.

Użyj węzłów typu spot dla obciążeń, które mogą obsługiwać przerwy, wczesne kończenie lub eksmisji. Na przykład zaplanuj pulę węzłów typu spot dla zadań przetwarzania wsadowego, środowisk programistycznych i testowych oraz dużych obciążeń obliczeniowych. Aby uzyskać więcej informacji, zobacz Ograniczenia wystąpień typu spot.

Następujące az aks nodepool add polecenie dodaje pulę węzłów typu spot do istniejącego klastra z włączonym skalowaniem automatycznym.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Aby uzyskać więcej informacji, zobacz Dodawanie puli węzłów typu spot do klastra usługi AKS.

Efemeryczne dyski systemu operacyjnego

Domyślnie platforma Azure automatycznie replikuje dysk systemu operacyjnego maszyny wirtualnej do usługi Azure Storage. Takie podejście uniemożliwia utratę danych, jeśli maszyna wirtualna musi zostać przeniesiona do innego hosta. Jednak kontenery nie są przeznaczone do zachowania stanu lokalnego, dlatego przechowywanie dysku systemu operacyjnego w usłudze Azure Storage zapewnia ograniczone korzyści dla usługi AKS. Takie podejście może prowadzić do wolniejszego przydzielania węzłów i zwiększonego opóźnienia odczytu i zapisu.

Natomiast efemeryczne dyski systemu operacyjnego są przechowywane tylko na maszynie hosta, na przykład dysk tymczasowy. Zapewniają one również mniejsze opóźnienie odczytu i zapisu oraz szybsze skalowanie węzłów i uaktualnienia klastra. Podobnie jak dysk tymczasowy, cena maszyny wirtualnej obejmuje efemeryczny dysk systemu operacyjnego, dzięki czemu nie ponosisz dodatkowych kosztów magazynowania.

Ważne

Jeśli nie zażądasz jawnie dysków zarządzanych dla systemu operacyjnego, usługa AKS domyślnie wybiera efemeryczny system operacyjny, jeśli to możliwe w ramach danej konfiguracji puli węzłów.

Aby korzystać z efemerycznego systemu operacyjnego, dysk systemu operacyjnego musi mieścić się w pamięci podręcznej maszyny wirtualnej. Dokumentacja maszyny wirtualnej platformy Azure pokazuje rozmiar pamięci podręcznej maszyny wirtualnej w nawiasach obok przepustowości wejścia/wyjścia (We/Wy) jako rozmiar pamięci podręcznej w gibibajtach (GiB).

Na przykład domyślny rozmiar maszyny wirtualnej usługi AKS Standard_DS2_v2 z domyślnym rozmiarem dysku systemu operacyjnego 100 GB obsługuje efemeryczny system operacyjny, ale ma tylko rozmiar pamięci podręcznej 86 GB. Ta konfiguracja jest domyślnie ustawiona na dyski zarządzane, jeśli nie określisz jawnie inaczej. Jeśli jawnie zażądasz tymczasowego systemu operacyjnego dla tego rozmiaru, pojawi się błąd weryfikacji.

Jeśli żądasz tej samej maszyny wirtualnej Standard_DS2_v2 z dyskiem systemu operacyjnego o rozmiarze 60 GB, domyślnie otrzymasz efemeryczny system operacyjny. Żądany rozmiar systemu operacyjnego 60 GB jest mniejszy niż maksymalny rozmiar pamięci podręcznej 86 GB.

Standard_D8s_v3 z dyskiem systemu operacyjnego 100 GB obsługuje efemeryczny system operacyjny i ma rozmiar pamięci podręcznej 200 GB. Jeśli nie określisz typu dysku systemu operacyjnego, pula węzłów domyślnie otrzymuje tymczasowy system operacyjny.

Poniższe az aks nodepool add polecenie pokazuje, jak dodać nową pulę węzłów do istniejącego klastra z efemerycznym dyskiem systemu operacyjnego. Parametr --node-osdisk-type ustawia typ dysku systemu operacyjnego na Ephemeralwartość , a --node-osdisk-size parametr definiuje rozmiar dysku systemu operacyjnego.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Aby uzyskać więcej informacji, zobacz Efemeryczny dysk systemu operacyjnego.

Pule węzłów usługi Azure Virtual Machines w usłudze AKS

Każda zarządzana grupa węzłów w EKS jest wspierana przez grupę automatycznego skalowania Amazon EC2, zarządzaną przez Amazon EKS. Ta integracja umożliwia EKS automatyczne konfigurowanie i skalowanie wystąpień EC2 w grupie węzłów.

Grupy skalowania automatycznego można skonfigurować tak, aby obsługiwały wiele typów wystąpień USŁUGI EC2, ale nie można określić liczby węzłów do utworzenia lub skalowania dla każdego typu wystąpienia. Zamiast tego EKS zarządza skalowaniem grupy węzłów na podstawie żądanej konfiguracji i zasad. Takie podejście upraszcza i automatyzuje proces zarządzania grupą węzłów, dzięki czemu można wybrać typy wystąpień EC2, które odpowiadają wymaganiom związanym z obciążeniem. Możesz również uruchomić własne węzły systemu Amazon Linux przy użyciu eksctl narzędzia wiersza polecenia lub konsoli zarządzania platformy AWS.

W przypadku pul węzłów Azure Virtual Machines usługa AKS konfiguruje i przygotowuje do działania każdy węzeł agenta. W przypadku pul węzłów usługi Azure Virtual Machine Scale Sets usługa AKS zarządza modelem zestawów skalowania maszyn wirtualnych i używa go do zapewnienia spójności we wszystkich węzłach agenta w puli węzłów. Pule węzłów usługi Virtual Machines umożliwiają organizowanie klastra za pomocą maszyn wirtualnych, które najlepiej pasują do poszczególnych obciążeń. Można również określić liczbę węzłów do utworzenia lub skalowania dla każdego rozmiaru maszyny wirtualnej.

Pula węzłów składa się z zestawu maszyn wirtualnych o różnych rozmiarach. Każda maszyna wirtualna obsługuje inny typ obciążenia. Te rozmiary maszyn wirtualnych, nazywane jednostkami SKU, są podzielone na różne rodziny zoptymalizowane pod kątem określonych celów. Aby uzyskać więcej informacji, zobacz Rozmiary maszyn wirtualnych na platformie Azure.

Aby włączyć skalowanie wielu rozmiarów maszyn wirtualnych, typ puli węzłów maszyn wirtualnych używa klasy ScaleProfile. Ten profil konfiguruje sposób skalowania puli węzłów przez określenie żądanego rozmiaru i liczby maszyn wirtualnych. A ManualScaleProfile to profil skalowania, który określa żądany rozmiar i liczbę maszyn wirtualnych. W obiekcie ManualScaleProfiledozwolony jest tylko jeden rozmiar maszyny wirtualnej. Musisz utworzyć oddzielny ManualScaleProfile dla każdego rozmiaru VM w puli węzłów.

Podczas tworzenia nowej puli węzłów maszyn Wirtualnych, potrzebny jest co najmniej jeden ManualScaleProfile w elemencie ScaleProfile. Dla pojedynczej puli węzłów maszyn wirtualnych można utworzyć wiele profilów skalowania ręcznego.

Zalety pul węzłów maszyn wirtualnych obejmują:

  • Elastyczność: Specyfikacje węzłów można aktualizować zgodnie z potrzebami i obciążeniami.

  • Dostrojona kontrolka: Kontrolki na poziomie pojedynczego węzła ułatwiają określanie i łączenie węzłów różnych specyfikacji w celu poprawy spójności.

  • Sprawność: Możesz zmniejszyć zużycie węzła dla klastra, aby uprościć wymagania operacyjne.

Pule węzłów maszyn wirtualnych zapewniają lepsze środowisko obsługi obciążeń dynamicznych i wymagań dotyczących wysokiej dostępności. Można ich użyć do skonfigurowania wielu maszyn wirtualnych tej samej rodziny w jednej puli węzłów, a obciążenie jest automatycznie zaplanowane na skonfigurowanych zasobach.

W poniższej tabeli porównaliśmy pule węzłów maszyn wirtualnych ze standardowymi pulami węzłów zestawów skalowania maszyn wirtualnych .

Typ puli węzłów Możliwości
Pula węzłów maszyn wirtualnych Węzły można dodawać, usuwać lub aktualizować w puli węzłów. Typy maszyn wirtualnych mogą być dowolną maszyną wirtualną tego samego typu rodziny, taką jak seria D lub seria A.
Pula węzłów dla zestawów skalowania maszyn wirtualnych Możesz dodawać lub usuwać węzły o tym samym rozmiarze i typie w puli węzłów. W przypadku dodania nowego rozmiaru maszyny wirtualnej do klastra należy utworzyć nową pulę węzłów.

Pule węzłów maszyn wirtualnych mają następujące ograniczenia:

  • Funkcja automatycznego skalowania klastra nie jest obsługiwana.
  • Aplikacja InfiniBand jest niedostępna.
  • Nie są obsługiwane grupy węzłów Windows.
  • Ta funkcja nie jest dostępna w witrynie Azure Portal. Użyj interfejsu wiersza polecenia platformy Azure lub interfejsów API REST, aby wykonywać operacje tworzenia, odczytu, aktualizowania i usuwania (CRUD) lub zarządzania pulą.
  • Zrzut puli węzłów nie jest obsługiwany.
  • Wszystkie rozmiary maszyn wirtualnych w puli węzłów muszą pochodzić z tej samej rodziny VM. Na przykład nie można połączyć typu maszyny wirtualnej serii N z typem maszyny wirtualnej serii D w tej samej puli węzłów.
  • Pule węzłów dla maszyn wirtualnych pozwalają na maksymalnie pięć różnych rozmiarów VM w każdej puli węzłów.

Węzły wirtualne

Możesz użyć węzłów wirtualnych, aby szybko zwiększyć obciążenia aplikacji w klastrze AKS. Węzły wirtualne zapewniają szybkie udostępnianie podów i płacisz tylko za sekundę czasu działania. Nie musisz czekać na działanie autoskalera klastra, aby wdrożyć nowe węzły robocze do uruchomienia większej liczby replik podów. Tylko zasobniki i węzły systemu Linux obsługują węzły wirtualne. Dodatek węzłów wirtualnych dla usługi AKS jest oparty na projekcie open-source Virtual Kubelet.

Funkcja węzła wirtualnego zależy od usługi Azure Container Instances. Aby uzyskać więcej informacji, zobacz Tworzenie i konfigurowanie klastra usługi AKS do korzystania z węzłów wirtualnych.

Defekty, etykiety i tagi

Podczas tworzenia puli węzłów można dodać tainty i etykiety Kubernetes oraz tagi platformy Azure. Każde naniesienie, etykieta lub tag ma zastosowanie do wszystkich węzłów w danej puli.

Aby utworzyć pulę węzłów, która ma skazę, możesz użyć polecenia az aks nodepool add z parametrem --node-taints. Aby oznaczyć węzły w puli węzłów, użyj parametru --labels i określ listę etykiet, jak pokazano w poniższym kodzie:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Aby uzyskać więcej informacji, zobacz Określanie skazy, etykiety lub tagu dla puli węzłów.

Zastrzeżone etykiety systemowe

Usługa Amazon EKS dodaje automatyczne etykiety Kubernetes do wszystkich węzłów w zarządzanej grupie węzłów, takich jak eks.amazonaws.com/capacityType, które określają typ pojemności. Usługa AKS automatycznie dodaje również etykiety systemowe do węzłów agenta.

Następujące prefiksy są zarezerwowane do użycia usługi AKS i nie można ich używać w przypadku węzłów:

  • kubernetes.azure.com/
  • kubernetes.io/

Aby zapoznać się z innymi zarezerwowanymi prefiksami, zobacz dobrze znane etykiety, adnotacje i tainty platformy Kubernetes.

W poniższej tabeli wymieniono etykiety zarezerwowane dla użycia usługi AKS i nie można ich używać dla węzłów. W tabeli kolumna Użycie węzła wirtualnego określa, czy węzły wirtualne obsługują etykietę.

W kolumnie Użycie węzła wirtualnego:

  • N/A oznacza, że właściwość nie ma zastosowania do węzłów wirtualnych, ponieważ wymaga modyfikacji hosta.
  • Oznacza to, że oczekiwane wartości są takie same dla puli węzłów wirtualnych i standardowej puli węzłów.
  • Maszyna wirtualna zastępuje wartości jednostki SKU maszyn wirtualnych, ponieważ zasobniki węzłów wirtualnych nie uwidaczniają bazowych maszyn wirtualnych.
  • Wersja węzła wirtualnego odnosi się do bieżącej wersji wirtualnego łącznika Kubelet-ACI.
  • Nazwa podsieci węzła wirtualnego to podsieć, która wdraża zasobniki węzłów wirtualnych w usłudze Container Instances.
  • Wirtualna sieć węzła wirtualnego to sieć wirtualna zawierająca podsieć węzła wirtualnego.
Etykieta Wartość Przykład lub opcje Użycie węzła wirtualnego
kubernetes.azure.com/agentpool <agent pool name> nodepool1 To samo
kubernetes.io/arch amd64 runtime.GOARCH N/A
kubernetes.io/os <OS type> Linux lub Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 To samo
topology.kubernetes.io/zone <Azure zone> 0 To samo
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 To samo
kubernetes.azure.com/mode <mode> User lub System User
kubernetes.azure.com/role agent Agent To samo
kubernetes.azure.com/scalesetpriority <scale set priority> Spot lub Regular N/A
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 To samo
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/A
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/A
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Wersja węzła wirtualnego
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nazwa podsieci węzła wirtualnego
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Wirtualny węzeł wirtualnej sieci
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/A
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/A
kubernetes.azure.com/accelerator <accelerator> nvidia N/A
kubernetes.azure.com/fips_enabled <fips enabled> True N/A
kubernetes.azure.com/os-sku <os/sku> Zobacz Tworzenie lub aktualizowanie SKU systemu operacyjnego Jednostka Magazynowa (SKU) Linux

Pule węzłów systemu Windows

Za pomocą usługi AKS można tworzyć pule węzłów kontenera systemu Windows Server i korzystać z nich za pośrednictwem wtyczki sieciowej interfejsu sieci kontenera platformy Azure . Aby zaplanować wymagane zakresy podsieci i zagadnienia dotyczące sieci, zobacz Konfigurowanie interfejsu sieciowego kontenera platformy Azure.

Następujące az aks nodepool add polecenie dodaje pulę węzłów, która uruchamia kontenery systemu Windows Server:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Poprzednie polecenie korzysta z domyślnej podsieci w sieci wirtualnej klastra AKS. Aby uzyskać więcej informacji na temat tworzenia klastra usługi AKS z pulą węzłów systemu Windows, zobacz Tworzenie kontenera systemu Windows Server w usłudze AKS.

Zagadnienia dotyczące puli węzłów

Podczas tworzenia jednej lub wielu pul węzłów i zarządzania nimi mają zastosowanie następujące zagadnienia i ograniczenia:

  • Limity przydziału, ograniczenia dotyczące rozmiaru maszyn wirtualnych i dostępność w regionie mają zastosowanie do pul węzłów usługi AKS.

  • Pule systemowe muszą zawierać co najmniej jeden węzeł. Możesz usunąć pulę węzłów systemowych, jeśli masz inną pulę węzłów systemowych, która ma zostać utworzona w klastrze usługi AKS. Pule węzłów użytkownika mogą zawierać zero lub więcej węzłów.

  • Nie można zmienić rozmiaru VM w puli węzłów po jej utworzeniu.

  • W przypadku wielu pul węzłów klaster usługi AKS musi używać modułów równoważenia obciążenia jednostek SKU w warstwie Standardowa. Podstawowe moduły równoważenia obciążenia jednostek SKU nie obsługują wielu pul węzłów.

  • Wszystkie pule węzłów klastra muszą znajdować się w tej samej sieci wirtualnej, a wszystkie podsieci przypisane do puli węzłów muszą znajdować się w tej samej sieci wirtualnej.

  • Jeśli tworzysz wiele pul węzłów podczas tworzenia klastra, wersje platformy Kubernetes dla wszystkich pul węzłów muszą być zgodne z wersją płaszczyzny sterowania. Aby zaktualizować wersje po skonfigurowaniu klastra, użyj operacji na pulę węzłów.

Skalowanie pul węzłów

W miarę zmiany obciążenia aplikacji może być konieczna zmiana liczby węzłów w puli węzłów. Aby ręcznie skalować liczbę węzłów w górę lub w dół, użyj polecenia az aks nodepool scale . W poniższym przykładzie liczba węzłów mynodepool jest skalowana do pięciu:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Automatyczne skalowanie pul węzłów

Usługa AKS obsługuje automatyczne skalowanie pul węzłów przy użyciu narzędzia do automatycznego skalowania klastra. Włącz tę funkcję w każdej puli węzłów i zdefiniuj minimalną i maksymalną liczbę węzłów.

Następujące az aks nodepool add polecenie dodaje nową pulę węzłów o nazwie mynodepool do istniejącego klastra. Parametr --enable-cluster-autoscaler umożliwia automatyczne skalowanie klastra w nowej puli węzłów. Parametry --min-count i --max-count określają minimalną i maksymalną liczbę węzłów w puli.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Następujące polecenie az aks nodepool update aktualizuje minimalną liczbę węzłów z jednego do trzech dla mynewnodepool puli węzłów.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Aby wyłączyć funkcję automatycznego skalowania klastra, użyj az aks nodepool update polecenia z parametrem --disable-cluster-autoscaler .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Aby ponownie włączyć automatyczne skalowanie klastra w istniejącym klastrze, użyj polecenia az aks nodepool update i określ parametry --enable-cluster-autoscaler, --min-count i --max-count.

Aby uzyskać więcej informacji na temat używania narzędzia do automatycznego skalowania klastra dla poszczególnych pul węzłów, zobacz Używanie narzędzia do automatycznego skalowania klastra w usłudze AKS.

Pod piaskownicy

Aby łatwo skonfigurować i uruchomić kontenery Kata na AKS jako w pełni zarządzane rozwiązanie, użyj funkcji Pod Sandboxing. Sandboxing Podów to funkcja w AKS, która tworzy granicę izolacji pomiędzy aplikacją w kontenerze a współdzielonym jądrem oraz zasobami obliczeniowymi hosta kontenerowego, takimi jak CPU, pamięć i sieć.

Pod Sandboxing uzupełnia inne środki zabezpieczeń lub mechanizmy kontroli ochrony danych, aby pomóc najemcom zabezpieczyć poufne informacje i spełniać wymagania zgodności z przepisami, normami branżowymi lub zarządzaniem. Wymagania te obejmują Payment Card Industry Data Security Standard (PCI DSS), Międzynarodową Organizację Standaryzacji (ISO) 27001 oraz Health Insurance Portability and Accountability Act (HIPAA).

Wdrażaj aplikacje w oddzielnych klastrach lub pulach węzłów, aby wyizolować obciążenia najemców różnych zespołów lub klientów. Możesz użyć wielu klastrów i pul węzłów, jeśli wymaga tego rozwiązanie organizacji lub oprogramowania jako usługi (SaaS). Jednak niektóre scenariusze korzystają z jednego klastra, który ma udostępnione pule węzłów maszyn wirtualnych. Na przykład można użyć jednego klastra do uruchamiania niezaufanych i zaufanych zasobników na tym samym węźle lub do wspólnego umieszczenia DaemonSets i uprzywilejowanych kontenerów na tym samym węźle w celu szybszej komunikacji lokalnej i grupowania funkcjonalnego.

Sandboxing kontenera może ułatwić izolowanie aplikacji najemców w tych samych węzłach w klastrze bez konieczności uruchamiania tych obciążeń w oddzielnych klastrach lub pulach węzłów. Inne metody mogą wymagać ponownego skompilowania kodu lub mogą powodować inne problemy ze zgodnością. Podsandboxing w AKS może uruchomić dowolny niezmodyfikowany kontener wewnątrz rozszerzonej granicy zabezpieczeń maszyny wirtualnej.

Piaskownicą poda jest oparta na Kontenerach Kata działających na hoście kontenera systemu Linux platformy Azure dla stosu usługi AKS w celu zapewnienia wymuszonej sprzętowo izolacji. Kata Containers na AKS są oparte na hypervisorze platformy Azure z wzmocnionymi zabezpieczeniami. Zapewnia izolację dla każdego zasobnika za pomocą zagnieżdżonej, lekkiej maszyny wirtualnej Kata, która korzysta z zasobów węzła nadrzędnej 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 kilku kontenerów Kata na jednej maszynie wirtualnej gościa podczas kontynuowania uruchamiania kontenerów na nadrzędnej maszynie wirtualnej. Ten model zapewnia silną granicę izolacji w udostępnionym klastrze usługi AKS.

Aby uzyskać więcej informacji, zobacz Wsparcie dla kontenerów izolowanych maszyn wirtualnych Kata w usłudze AKS dla izolacji zasobników.

Dedykowany host platformy Azure

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

Użyj dedykowanego hosta z usługą AKS, aby zapewnić następujące korzyści:

  • 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ć oraz podstawową infrastrukturę przechowywania co inne nieizolowane hosty.

  • Dedykowany host zapewnia kontrolę nad zdarzeniami konserwacji inicjowanych przez platformę Azure. Możesz wybrać okno konserwacyjne, aby zmniejszyć wpływ na usługi oraz zapewnić dostępność i prywatność obciążeń lokatorów.

Dedykowany host może pomóc dostawcom SaaS zapewnić, że aplikacje najemców spełniają wymagania dotyczące zgodności z przepisami, standardami branżowymi i rządowymi, aby zabezpieczyć poufne informacje. Aby uzyskać więcej informacji, zobacz Dodawanie dedykowanego hosta do klastra usługi AKS.

Karpenter

Karpenter to projekt zarządzania cyklem życia typu open source utworzony dla platformy Kubernetes. Dodaj Karpenter do klastra Kubernetes, aby poprawić wydajność i obniżyć koszty eksploatacji obciążeń w tym klastrze. Karpenter monitoruje zasobniki, które harmonogram Kubernetes oznacza jako niemożliwe do zaplanowania. Dynamicznie konfiguruje i zarządza węzłami, które mogą spełniać wymagania zasobnika.

Karpenter zapewnia szczegółową kontrolę nad prowizjonowaniem węzłów i umieszczaniem obciążeń w klastrze zarządzanym. Ta kontrola optymalizuje alokację zasobów, pomaga zapewnić izolację między aplikacjami każdego najemcy i zmniejsza koszty operacyjne, co zwiększa efektywność rozwiązania wielodostępowego. Podczas tworzenia wielodostępnego rozwiązania w usłudze AKS Firma Karpenter zapewnia przydatne możliwości ułatwiające zarządzanie różnymi wymaganiami aplikacji w celu obsługi różnych dzierżaw.

Na przykład aplikacje niektórych dzierżawców mogą być potrzebne do uruchamiania w pulach węzłów zoptymalizowanych pod kątem procesora GPU, a inne do uruchamiania w pulach węzłów zoptymalizowanych pod kątem pamięci. Jeśli aplikacja wymaga niskiego opóźnienia w przechowywaniu, możesz użyć Karpenter, aby wskazać, że pod wymaga węzła uruchomionego w określonej strefie dostępności. Następnie możesz przenieść magazyn i warstwę aplikacji.

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

Poufne maszyny wirtualne

Poufne przetwarzanie to środek zabezpieczeń, który pomaga chronić dane podczas korzystania z nich za pośrednictwem izolacji i szyfrowania wspomaganego przez oprogramowanie lub sprzętu. Ta technologia dodaje dodatkową warstwę zabezpieczeń do tradycyjnych metod, co pomaga chronić dane magazynowane i przesyłane dane.

Platforma AWS obsługuje poufne przetwarzanie poprzez enklawy Nitro, które są dostępne na instancjach EC2 i na Amazon EKS. Wystąpienia usługi Amazon EC2 obsługują również funkcję AMD Secure Encrypted Virtualization z bezpiecznym stronicowaniem zagnieżdżonym (SEV-SNP). Repozytorium GitHub atestacji czasu uruchomienia udostępnia artefakty do kompilowania i wdrażania Amazon Machine Image dla EKS z obsługą AMD SEV-SNP.

Platforma Azure udostępnia klientom poufne maszyny wirtualne, które pomagają spełnić ścisłe wymagania dotyczące izolacji, prywatności i zabezpieczeń w klastrze usługi AKS. Te poufne maszyny wirtualne używają opartego na sprzęcie zaufanego środowiska wykonawczego. W szczególności poufne maszyny wirtualne platformy Azure używają technologii AMD SEV-SNP. Ta technologia odmawia dostępu hypervisorowi i innym kodom zarządzania hostem do pamięci i stanu maszyny wirtualnej. Użyj tego podejścia, aby dodać dodatkową warstwę ochrony i ochrony przed dostępem operatora. Aby uzyskać więcej informacji, zobacz Używanie poufnych maszyn wirtualnych w klastrze usługi AKS i Omówienie poufnych maszyn wirtualnych na platformie Azure.

Standardy federalnego procesu informacyjnego

Federal Information Process Standards (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łącz zgodność ze standardem FIPS dla pul węzłów usługi AKS, aby zwiększyć izolację, prywatność i bezpieczeństwo obciążeń dzierżawcy. Zgodność ze standardem FIPS pomaga zapewnić użycie zweryfikowanych modułów kryptograficznych na potrzeby szyfrowania, tworzenia skrótów i innych operacji związanych z zabezpieczeniami. Użyj pul węzłów usługi AKS z obsługą standardu FIPS, aby stosować niezawodne algorytmy kryptograficzne i mechanizmy, które pomagają spełnić wymagania dotyczące zgodności z przepisami i branżą. Aby uzyskać więcej informacji na temat wzmacniania poziomu zabezpieczeń wielodostępnych środowisk AKS, zobacz Włączanie pul węzłów FIPS dla usługi AKS.

Szyfrowanie oparte na hoście

W EKS, twoja architektura może używać następujących funkcji w celu zwiększenia bezpieczeństwa danych:

Szyfrowanie oparte na hoście w usłudze AKS dodatkowo zwiększa izolację, prywatność i bezpieczeństwo obciążeń najemców. Po włączeniu szyfrowania opartego na hoście usługa AKS szyfruje dane magazynowane na podstawowych maszynach hosta. Takie podejście pomaga chronić poufne informacje dzierżawy przed nieautoryzowanym dostępem. Po włączeniu kompleksowego szyfrowania dyski tymczasowe i efemeryczne dyski systemu operacyjnego są szyfrowane w spoczynku za pośrednictwem kluczy zarządzanych przez platformę.

W usłudze AKS dyski systemu operacyjnego i dyski danych domyślnie używają szyfrowania po stronie serwera za pośrednictwem kluczy zarządzanych przez platformę. Bufory dla tych dysków są szyfrowane w stanie spoczynku za pośrednictwem kluczy zarządzanych przez platformę. Możesz użyć własnego klucza szyfrowania , aby zaszyfrować klucz ochrony danych. Ta metoda jest nazywana szyfrowaniem koperty lub zawijaniem. Określony klucz szyfrowania szyfruje również pamięć podręczną dla dysków systemu operacyjnego i dysków danych.

Szyfrowanie oparte na hoście dodaje warstwę zabezpieczeń dla środowisk wielodostępnych. Dane każdego najemcy na dysku systemu operacyjnego i podręczne pamięci dysków danych są szyfrowane w spoczynku za pomocą kluczy zarządzanych przez klienta lub zarządzane przez platformę, w zależności od wybranego rodzaju szyfrowania dysku. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Aktualizacje i uaktualnienia

Platforma Azure okresowo aktualizuje swoją platformę hostingu maszyn wirtualnych w celu zwiększenia niezawodności, wydajności i zabezpieczeń. Te aktualizacje obejmują od poprawek składników oprogramowania w środowisku hostingu do uaktualniania składników sieciowych lub likwidowania sprzętu. Aby uzyskać więcej informacji, zobacz Konserwacja maszyn wirtualnych na platformie Azure.

Aktualizacje infrastruktury hostingowej maszyn wirtualnych zwykle nie mają wpływu na hostowane maszyny wirtualne, takie jak węzły agentów w istniejących klastrach AKS. W przypadku aktualizacji mających wpływ na hostowane maszyny wirtualne platforma Azure minimalizuje przypadki, które wymagają ponownego uruchomienia, wstrzymując maszynę wirtualną podczas aktualizowania hosta lub migracji na żywo do już zaktualizowanego hosta.

Jeśli aktualizacja wymaga ponownego uruchomienia, platforma Azure udostępnia powiadomienie i przedział czasu, kiedy można uruchomić aktualizację. Okno samodzielnej konserwacji dla maszyn hosta wynosi zwykle 35 dni, chyba że aktualizacja jest pilna.

Aby zaktualizować maszyny wirtualne, można użyć planowanej konserwacji. Zarządzanie powiadomieniami o planowanej konserwacji przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal. Zaplanowana konserwacja wykrywa, czy używasz funkcji automatycznego aktualizowania klastra i automatycznie planuje aktualizacje podczas okna konserwacji. Aby uzyskać więcej informacji, zobacz Używanie planowanej konserwacji do tworzenia okien serwisowych dla klastra AKS i polecenie az aks maintenanceconfiguration.

Uaktualnienia platformy Kubernetes

Część cyklu życia klastra usługi AKS obejmuje okresowe uaktualnianie do najnowszej wersji rozwiązania Kubernetes. Należy zastosować uaktualnienia, aby uzyskać najnowsze wersje zabezpieczeń i funkcje. Aby uaktualnić wersję Kubernetes na istniejących maszynach wirtualnych w puli węzłów, musisz oznaczyć węzły jako nieprzyjmujące nowych zadań (cordonować), opróżnić je z zadań i zastąpić nowymi węzłami opartymi na zaktualizowanym obrazie dysku Kubernetes.

Domyślnie usługa AKS konfiguruje aktualizacje w celu zwiększenia liczby węzłów o jeden dodatkowy węzeł. Domyślna wartość jeden dla ustawień max-surge minimalizuje zakłócenia obciążenia. Ta konfiguracja tworzy dodatkowy węzeł, aby zastąpić węzły w starszych wersjach przed odseparowaniem lub opróżnieniem istniejących aplikacji. Możesz dostosować wartość max-surge dla puli węzłów, aby zoptymalizować kompromis między szybkością aktualizacji a zakłóceniami aktualizacji. Wyższa max-surge wartość zwiększa szybkość procesu uaktualniania, ale duża wartość max-surge może spowodować zakłócenia w procesie uaktualniania.

Na przykład wartość max-surge 100% zapewnia najszybszy możliwy proces uaktualniania poprzez podwojenie liczby węzłów. Jednak ta wartość również opróżnia wszystkie węzły w puli węzłów jednocześnie. Możesz użyć tej wysokiej wartości do testowania, ale w przypadku pul węzłów produkcyjnych ustaw wartość max-surge na 33%.

Usługa AKS akceptuje zarówno wartości całkowite, jak i procentowe dla max-surge wartości. Liczba całkowita, taka jak 5 wskazuje pięć dodatkowych węzłów do wzrostu. Można ustawić wartość procentową dla max-surge w zakresie od 1% do 100%, zaokrąglając w górę do najbliższej liczby węzłów. Wartość 50% wskazuje na skok odpowiadający połowie obecnej liczby węzłów w puli.

Podczas uaktualniania można ustawić wartość max-surge na co najmniej 1 i maksymalnie na wartość odpowiadającą liczbie węzłów w puli węzłów. Można ustawić większe wartości, ale maksymalna liczba węzłów dla max-surge nie może przekraczać liczby węzłów w puli.

Ważne

W przypadku operacji uaktualniania gwałtowne zwiększenie liczby węzłów wymaga wystarczającego limitu przydziału subskrypcji dla żądanej max-surge liczby. Na przykład klaster, który ma pięć pul węzłów, z których każdy ma cztery węzły, ma łącznie 20 węzłów. Jeśli każda pula węzłów ma max-surge wartość 50%, do ukończenia uaktualnienia potrzebna jest dodatkowa moc obliczeniowa i limit przydziału adresów IP dla 10 węzłów, czyli dwa węzły pomnożone przez pięć pul.

Jeśli używasz interfejsu sieci kontenera platformy Azure, upewnij się, że masz wystarczającą liczbę adresów IP w podsieci, aby spełnić wymagania dotyczące usługi AKS.

Aktualizacja pul węzłów

Aby wyświetlić dostępne uaktualnienia, użyj polecenia az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Aby wyświetlić stan pul węzłów, użyj az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Aby uaktualnić pojedynczy zasób w pulach węzłów, użyj az aks nodepool upgrade.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Zagadnienia dotyczące uaktualniania

Podczas uaktualniania wersji rozwiązania Kubernetes w klastrze usługi AKS należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Należy uaktualnić wszystkie pule węzłów w klastrze usługi AKS do tej samej wersji rozwiązania Kubernetes. Domyślne zachowanie az aks upgrade aktualizuje wszystkie pule węzłów, oraz płaszczyznę sterowania.

  • Ręczne przeprowadzanie uaktualnień lub ustawianie kanału automatycznego uaktualniania w klastrze. Jeśli używasz planowanej konserwacji do aktualizacji maszyn wirtualnych, automatyczne uaktualnienia również są uruchamiane podczas określonego okna konserwacji. Aby uzyskać więcej informacji, zapoznaj się z Uaktualnianiem klastra usługi AKS.

  • Polecenie az aks upgrade z flagą --control-plane-only uaktualnia płaszczyznę sterowania klastra i nie zmienia skojarzonych pul węzłów w klastrze. Aby uaktualnić poszczególne pule węzłów, określ pulę węzłów docelowych i wersję platformy Kubernetes w poleceniu az aks nodepool upgrade .

  • Uaktualnianie klastra usługi AKS wyzwala proces izolowania i opróżniania węzłów. Jeśli masz dostępny niski limit przydziału zasobów obliczeniowych, uaktualnienie może zakończyć się niepowodzeniem. Aby uzyskać więcej informacji, zobacz Zwiększanie regionalnych limitów przydziałów procesorów wirtualnych.

  • max-surge Skonfiguruj parametr na podstawie Twoich potrzeb. Użyj wartości całkowitej lub procentowej. W przypadku pul węzłów produkcyjnych użyj ustawienia max-surge na poziomie 33%. Aby uzyskać więcej informacji, zobacz Dostosowywanie modernizacji przełączania węzłów.

  • Podczas uaktualniania klastra AKS korzystającego z Interfejsu Azure Container Networking, upewnij się, że podsieć ma wystarczającą liczbę dostępnych prywatnych adresów IP dla dodatkowych węzłów tworzonych przez ustawienia max-surge. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci interfejsu sieciowego kontenera platformy Azure w usłudze AKS.

  • Jeśli pule węzłów klastra obejmują wiele stref dostępności w regionie, proces aktualizacji może tymczasowo utworzyć niezrównoważoną konfigurację stref. Aby uzyskać więcej informacji, zobacz Pule węzłów obejmujące wiele stref dostępności.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

Inni współautorzy:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki