Zarządzanie węzłami i pulami węzłów kubernetes

Architektura platformy Kubernetes jest oparta na dwóch warstwach: płaszczyzna sterowania i co najmniej jeden węzeł w pulach węzłów. W tym artykule opisano i porównaliśmy sposób, w jaki usługa Amazon Elastic Kubernetes Service (Amazon EKS) i usługa Azure Kubernetes Service (AKS) zarządza węzłami agenta lub procesu roboczego.

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.

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. Aktualizacje i zakończenia węzłów automatycznie kordon i węzły opróżniania w celu zapewnienia, że aplikacje pozostaną dostępne.

Każdy węzeł zarządzany jest aprowizowany w ramach grupy automatycznego skalowania usługi Amazon EC2, która działa i kontroluje usługę 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. Każdą grupę węzłów można skonfigurować do uruchamiania w wielu Strefy dostępności w regionie.

Aby uzyskać więcej informacji na temat węzłów zarządzanych usługi Amazon EKS, 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 na temat korzystania z rozwiązania Fargate z usługą Amazon EKS, zobacz AWS Fargate.

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

Tworzenie klastra usługi AKS automatycznie tworzy i konfiguruje płaszczyznę sterowania, która zapewnia podstawowe usługi Kubernetes i aranżację 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 jego zasoby istnieją tylko w regionie, w którym utworzono klaster.

Węzły, nazywane również węzłami agenta lub węzłami procesu roboczego, hostować obciążenia i aplikacje. W usłudze AKS klienci w pełni zarządzają węzłami agenta dołączonymi do klastra usługi AKS i płacą za nie.

Aby uruchamiać aplikacje i usługi pomocnicze, klaster usługi AKS musi mieć co najmniej jeden węzeł: maszyna wirtualna platformy Azure do uruchamiania składników węzła kubernetes i środowiska uruchomieniowego kontenera. Każdy klaster usługi AKS musi zawierać co najmniej jedną pulę węzłów systemowych z co najmniej jednym węzłem.

Usługa AKS grupuje węzły tej samej konfiguracji w pulach węzłów maszyn wirtualnych z obciążeniami usługi AKS. Pule węzłów systemowych służą głównemu celowi hostowania krytycznych zasobników systemu, takich jak CoreDNS. Pule węzłów użytkownika służą głównemu celowi hostowania zasobników obciążeń. Jeśli chcesz mieć tylko jedną pulę 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.

Można również utworzyć wiele pul węzłów użytkownika, aby rozdzielić różne obciążenia na różnych węzłach, aby uniknąć problemu z hałaśliwym sąsiadem lub obsługiwać aplikacje z różnymi wymaganiami obliczeniowymi lub magazynowymi.

Każdy węzeł agenta puli węzłów systemu lub użytkownika jest maszyną wirtualną aprowizowaną w ramach usługi Azure Virtual Machine Scale Sets i zarządzaną przez klaster usługi AKS. Aby uzyskać więcej informacji, zobacz Węzły i pule węzłów.

Możesz zdefiniować początkową liczbę i rozmiar węzłów procesu roboczego podczas tworzenia klastra usługi AKS 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.

Tworzenie puli węzłów

Pulę węzłów można dodać do nowego lub istniejącego klastra usługi AKS przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, interfejsu API REST usługi AKS lub narzędzi infrastruktury jako kodu (IaC), takich jak Bicep, szablony usługi Azure Resource Manager lub narzędzie Terraform. Aby uzyskać więcej informacji na temat dodawania pul węzłów do istniejącego klastra usługi AKS, zobacz Tworzenie wielu pul węzłów dla klastra w usłudze Azure Kubernetes Service (AKS) i zarządzanie nimi.

Podczas tworzenia nowej puli węzłów skojarzony zestaw skalowania maszyn wirtualnych jest tworzony w grupie zasobów węzła, czyli grupie zasobów platformy Azure zawierającej wszystkie zasoby infrastruktury klastra usługi AKS. Te zasoby obejmują węzły Kubernetes, zasoby sieci wirtualnej, 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 podczas usuwania klastra, dlatego należy użyć tej grupy zasobów tylko dla zasobów współużytkujących cykl życia klastra.

Dodawanie puli węzłów

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 z trzema węzłami do istniejącego klastra usługi AKS o nazwie mynodepool myAKSCluster w myResourceGroup grupie zasobów.

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 wspierana przez zestaw skalowania maszyn wirtualnych typu spot. Korzystanie z maszyn wirtualnych typu spot dla węzłów z klastrem usługi AKS korzysta z nieużywanej pojemności platformy Azure przy znacznych oszczędnościach. Ilość dostępnej nieuprawnionej pojemności zależy od wielu czynników, w tym rozmiaru węzła, regionu i godziny dnia.

Podczas wdrażania puli węzłów typu spot platforma Azure przydziela węzły typu spot, jeśli jest dostępna pojemność. Nie ma jednak umowy dotyczącej poziomu usług (SLA) dla węzłów typu spot. Zestaw skalowania typu spot, który wspiera pulę węzłów typu spot, jest wdrażany w jednej domenie błędów i nie oferuje gwarancji wysokiej dostępności. Gdy platforma Azure potrzebuje pojemności z powrotem, infrastruktura platformy Azure eksmituje węzły typu spot i otrzymasz co najwyżej 30-sekundowe powiadomienie przed eksmisją. Należy pamiętać, że pula węzłów typu spot nie może być domyślną pulą węzłów klastra. Pula węzłów typu spot może być używana tylko dla puli pomocniczej.

Węzły typu spot są przeznaczone dla obciążeń, które mogą obsługiwać przerwy, wczesne kończenie lub eksmisji. Na przykład zadania przetwarzania wsadowego, środowiska programistyczne i testowe oraz duże obciążenia obliczeniowe są dobrymi kandydatami do planowania w puli węzłów typu spot. Aby uzyskać więcej informacji, zobacz ograniczenia wystąpienia 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 na temat pul węzłów typu spot, zobacz Dodawanie puli węzłów typu spot do klastra usługi Azure Kubernetes Service (AKS).

Efemeryczne dyski systemu operacyjnego

Domyślnie platforma Azure automatycznie replikuje dysk systemu operacyjnego maszyny wirtualnej do usługi Azure Storage, aby uniknąć utraty danych, jeśli maszyna wirtualna musi zostać przeniesiona na inny host. Ponieważ kontenery nie są przeznaczone do utrwalania stanu lokalnego, przechowywanie dysku systemu operacyjnego w magazynie zapewnia ograniczoną wartość usługi AKS. Istnieją pewne wady, takie jak wolniejsza aprowizacja węzłów i większe opóźnienie odczytu/zapisu.

Natomiast efemeryczne dyski systemu operacyjnego są przechowywane tylko na maszynie hosta, takiej jak dysk tymczasowy, i zapewniają mniejsze opóźnienie odczytu/zapisu oraz szybsze skalowanie węzłów i uaktualnienia klastra. Podobnie jak dysk tymczasowy, efemeryczny dysk systemu operacyjnego jest uwzględniony w cenie maszyny wirtualnej, więc nie ponosisz dodatkowych kosztów magazynowania.

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 przedstawia rozmiar pamięci podręcznej maszyny wirtualnej w nawiasach obok przepływności operacji 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 86 GB rozmiaru pamięci podręcznej. Ta konfiguracja jest domyślnie ustawiona na dysk zarządzany, jeśli nie określisz jawnie innego ustawienia. Jeśli jawnie zażądasz efemerycznego systemu operacyjnego dla tego rozmiaru, zostanie wyświetlony 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 o pojemności 100 GB obsługuje efemeryczny system operacyjny i ma 200 GB miejsca w pamięci podręcznej. Jeśli użytkownik nie określi typu dysku systemu operacyjnego, pula węzłów domyślnie pobiera efemeryczny 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 na temat efemerycznych dysków systemu operacyjnego, zobacz Efemeryczny system operacyjny.

Węzły wirtualne

Za pomocą węzłów wirtualnych można szybko skalować obciążenia aplikacji w poziomie w klastrze usługi AKS. Węzły wirtualne zapewniają szybką aprowizację zasobników i płacisz tylko za sekundę za czas wykonywania. Nie musisz czekać na automatyczne skalowanie klastra w celu wdrożenia nowych węzłów roboczych w celu uruchomienia większej liczby replik zasobników. Węzły wirtualne są obsługiwane tylko w przypadku zasobników i węzłów systemu Linux. Dodatek węzłów wirtualnych dla usługi AKS jest oparty na projekcie Kubelet typu open source.

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

Defekty, etykiety i tagi

Podczas tworzenia puli węzłów do tej puli węzłów można dodawać etykiety i etykiety platformy Kubernetes oraz tagi platformy Azure. Po dodaniu defektu, etykiety lub tagu wszystkie węzły w tej puli węzłów uzyskują ten znak, etykietę lub tag.

Aby utworzyć pulę węzłów z defektem, możesz użyć az aks nodepool add polecenia z parametrem --node-taints . Aby oznaczyć węzły w puli węzłów, możesz użyć parametru --labels i określić 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 defektu, 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 grupie węzłów zarządzanych, takich jak eks.amazonaws.com/capacityType, która określa 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 żadnym węźle:

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

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

W poniższej tabeli wymieniono etykiety zarezerwowane dla użycia usługi AKS i nie można ich używać w żadnym węźle. W tabeli kolumna Użycie węzła wirtualnego określa, czy etykieta jest obsługiwana w węzłach wirtualnych.

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łaby modyfikacji hosta.
• Oznacza to, że oczekiwane wartości są takie same dla puli węzłów wirtualnych co w przypadku standardowej puli węzłów.
• Maszyna wirtualna zastępuje wartości jednostki SKU maszyny wirtualnej, ponieważ zasobniki węzłów wirtualnych nie uwidaczniają żadnej bazowej maszyny wirtualnej.
• 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 Azure Container Instances.
• Sieć wirtualna węzła wirtualnego to sieć wirtualna zawierająca podsieć węzłów wirtualnych.

Pule węzłów systemu Windows

Usługa AKS obsługuje tworzenie i używanie pul węzłów kontenera systemu Windows Server za pośrednictwem wtyczki sieciowej interfejsu sieciowego kontenera platformy Azure (CNI). Aby zaplanować wymagane zakresy podsieci i zagadnienia dotyczące sieci, zobacz Konfigurowanie sieci azure CNI.

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 używa domyślnej podsieci w sieci wirtualnej klastra usługi AKS. Aby uzyskać więcej informacji na temat tworzenia klastra usługi AKS za pomocą puli węzłów systemu Windows, zobacz Tworzenie kontenera systemu Windows Server w usłudze AKS.

Zagadnienia dotyczące puli węzłów

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

• Limity przydziału, ograniczenia rozmiaru maszyny wirtualnej i dostępność regionu 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 maszyny wirtualnej 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 jednostki 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 dowolnej puli węzłów muszą znajdować się w tej samej sieci wirtualnej.

• Jeśli tworzysz wiele pul węzłów w czasie tworzenia klastra, wersje platformy Kubernetes dla wszystkich pul węzłów muszą być zgodne z wersją płaszczyzny sterowania. Wersje można aktualizować po aprowizacji klastra przy użyciu operacji na pulę węzłów.

Skalowanie puli węzłów

W miarę zmiany obciążenia aplikacji może być konieczna zmiana liczby węzłów w puli węzłów. Liczbę węzłów można skalować w górę lub w dół ręcznie za pomocą 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 przy użyciu narzędzia do automatycznego skalowania klastra

Usługa AKS obsługuje automatyczne skalowanie pul węzłów za pomocą 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 włącza narzędzie do automatycznego skalowania klastra w nowej puli węzłów, a --min-count parametry 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

Funkcję automatycznego skalowania az aks nodepool update klastra można wyłączyć, przekazując --disable-cluster-autoscaler parametr .

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

Aby ponownie włączyć skalowanie automatyczne klastra w istniejącym klastrze, użyj polecenia az aks nodepool update, określając --enable-cluster-autoscalerparametry , --min-counti --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 Automatyczne skalowanie klastra w celu spełnienia wymagań aplikacji w usłudze Azure Kubernetes Service (AKS).

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 na temat sposobu aktualizowania maszyn wirtualnych platformy Azure, zobacz Konserwacja maszyn wirtualnych na platformie Azure.

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

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

Za pomocą planowanej konserwacji można aktualizować maszyny wirtualne i zarządzać powiadomieniami o planowanej konserwacji za pomocą interfejsu wiersza polecenia platformy Azure, programu PowerShell lub witryny Azure Portal. Planowana konserwacja wykrywa, czy używasz automatycznego uaktualniania klastra i planuje uaktualnienia podczas okna obsługi automatycznie. Aby uzyskać więcej informacji na temat planowanej konserwacji, zobacz polecenie az aks maintenanceconfiguration i Użyj planowanej konserwacji, aby zaplanować okna obsługi klastra usługi Azure Kubernetes Service (AKS).

Uaktualnienia platformy Kubernetes

Okresowe uaktualnianie do najnowszej wersji rozwiązania Kubernetes jest częścią cyklu życia klastra AKS. Ważne jest, aby zastosować uaktualnienia, aby uzyskać najnowsze wersje zabezpieczeń i funkcje. Aby uaktualnić wersję platformy Kubernetes istniejących maszyn wirtualnych puli węzłów, należy połączyć węzły cordonu i opróżnić węzły i zastąpić je nowymi węzłami opartymi na zaktualizowanym obrazie dysku Kubernetes.

Domyślnie usługa AKS konfiguruje uaktualnienia w celu zwiększenia przy użyciu jednego dodatkowego węzła. Wartość domyślna dla max-surge ustawień minimalizuje zakłócenia obciążenia przez utworzenie dodatkowego węzła w celu zastąpienia starszych wersji węzłów przed kordonem lub opróżnianie istniejących aplikacji. Możesz dostosować max-surge wartość dla puli węzłów, aby umożliwić kompromis między szybkością uaktualniania a zakłóceniami uaktualniania. max-surge Zwiększenie wartości powoduje szybsze ukończenie procesu uaktualniania, ale duża wartość może max-surge spowodować zakłócenia w procesie uaktualniania.

Na przykład max-surge wartość 100% zapewnia najszybszy możliwy proces uaktualniania przez podwojenie liczby węzłów, ale także powoduje jednoczesne opróżnianie wszystkich węzłów w puli węzłów. Możesz użyć tej wysokiej wartości do testowania, ale w przypadku pul węzłów max-surge produkcyjnych ustawienie 33% jest lepsze.

Usługa AKS akceptuje zarówno wartości całkowite, jak i procentowe dla elementu max-surge. Liczba całkowita, taka jak 5 wskazuje pięć dodatkowych węzłów do wzrostu. Wartości max-surge procentowe dla parametru 100%mogą być co najmniej wartością 1% i maksymalną wartością , zaokrąglaną do najbliższej liczby węzłów. Wartość wskazuje wartość skoku 50% o połowę bieżącej liczby węzłów w puli.

Podczas uaktualniania max-surge wartość może być minimalną 1 i maksymalną wartością równą liczbie węzłów w puli węzłów. Można ustawić większe wartości, ale maksymalna liczba węzłów używanych do max-surge obsługi nie będzie większa niż liczba węzłów w puli.

Uaktualnianie 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 polecenia az aks nodepool list.

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

Następujące polecenie używa polecenia az aks nodepool upgrade w celu uaktualnienia pojedynczej puli węzłów.

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

Aby uzyskać więcej informacji na temat uaktualniania wersji rozwiązania Kubernetes dla płaszczyzny sterowania klastra i pul węzłów, zobacz:

• Uaktualnianie obrazu węzła usługi Azure Kubernetes Service (AKS)
• Uaktualnianie płaszczyzny sterowania klastra przy użyciu wielu pul węzłów

Zagadnienia dotyczące uaktualniania

Należy pamiętać o tych najlepszych rozwiązaniach i zagadnieniach dotyczących uaktualniania wersji rozwiązania Kubernetes w klastrze usługi AKS.

• Najlepiej uaktualnić wszystkie pule węzłów w klastrze usługi AKS do tej samej wersji platformy Kubernetes. Domyślne zachowanie uaktualniania az aks upgrade wszystkich pul węzłów i płaszczyzny sterowania.

• Ręcznie uaktualnij lub ustaw kanał automatycznego uaktualniania w klastrze. Jeśli używasz planowanej konserwacji do stosowania poprawek maszyn wirtualnych, automatyczne uaktualnienia również są uruchamiane podczas określonego okna obsługi. Aby uzyskać więcej informacji, zobacz Uaktualnianie klastra usługi Azure Kubernetes Service (AKS).

• Polecenie az aks upgrade z flagą --control-plane-only uaktualnia tylko płaszczyznę sterowania klastrem i nie zmienia żadnej skojarzonej puli 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 na temat zwiększania limitu przydziału, zobacz Zwiększanie regionalnych przydziałów procesorów wirtualnych.

• max-surge Skonfiguruj parametr na podstawie Twoich potrzeb przy użyciu liczby całkowitej lub wartości procentowej. W przypadku pul węzłów produkcyjnych użyj max-surge ustawienia 33%. Aby uzyskać więcej informacji, zobacz Dostosowywanie uaktualniania skoków węzłów.

• Podczas uaktualniania klastra usługi AKS korzystającego z sieci CNI upewnij się, że podsieć ma wystarczająco dużo dostępnych prywatnych adresów IP dla dodatkowych węzłów utworzonych max-surge przez ustawienia. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci CNI platformy Azure w usłudze Azure Kubernetes Service (AKS).

• Jeśli pule węzłów klastra obejmują wiele Strefy dostępności w obrębie regionu, proces uaktualniania może tymczasowo spowodować niezrównoważone konfigurację strefy. Aby uzyskać więcej informacji, zobacz Specjalne zagadnienia dotyczące pul węzłów obejmujących wiele Strefy dostępności.

Sieci wirtualne węzłów

Podczas tworzenia nowego klastra lub dodawania nowej puli węzłów do istniejącego klastra należy określić identyfikator zasobu podsieci w sieci wirtualnej klastra, w której są wdrażane węzły agenta. Obciążenie może wymagać podzielenia węzłów klastra na oddzielne pule węzłów na potrzeby izolacji logicznej. Można osiągnąć tę izolację z oddzielnymi podsieciami, z których każda jest przeznaczona dla oddzielnej puli węzłów. Maszyny wirtualne puli węzłów uzyskują prywatny adres IP ze skojarzonej podsieci.

Usługa AKS obsługuje dwie wtyczki sieciowe:

• Kubenet to podstawowa, prosta wtyczka sieciowa dla systemu Linux. Za pomocą kubenetpolecenia węzły uzyskują prywatny adres IP z podsieci usługi Azure Virtual Network. Zasobniki pobierają adres IP z logicznie innej przestrzeni adresowej. Translacja adresów sieciowych (NAT) umożliwia zasobnikom dostęp do zasobów w sieci wirtualnej platformy Azure przez tłumaczenie adresu IP ruchu źródłowego na podstawowy adres IP węzła. Takie podejście zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej dla zasobników.

• Interfejs sieci kontenera platformy Azure (CNI) zapewnia każdemu zasobnikowi adres IP do bezpośredniego wywoływania i uzyskiwania dostępu. Te adresy IP muszą być unikatowe w przestrzeni sieciowej. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby zasobników, które obsługuje. Równoważna liczba adresów IP na węzeł jest następnie zarezerwowana dla tego węzła. Takie podejście wymaga wcześniejszego planowania i może prowadzić do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji.

  Podczas tworzenia nowego klastra lub dodawania nowej puli węzłów do klastra korzystającego z usługi Azure CNI można określić identyfikator zasobu dwóch oddzielnych podsieci, jeden dla węzłów i jeden dla zasobników. Aby uzyskać więcej informacji, zobacz Dynamiczna alokacja adresów IP i rozszerzona obsługa podsieci.

Dynamiczna alokacja adresów IP

Zasobniki korzystające z usługi Azure CNI uzyskują prywatne adresy IP z podsieci puli węzłów hostingu. Dynamiczne przydzielanie adresów IP usługi Azure CNI może przydzielić prywatne adresy IP do zasobników z podsieci, która jest oddzielona od podsieci hostingu puli węzłów. Ta funkcja zapewnia następujące korzyści:

• Podsieć zasobnika dynamicznie przydziela adresy IP zasobnikom. Alokacja dynamiczna zapewnia lepsze wykorzystanie adresów IP w porównaniu z tradycyjnym rozwiązaniem CNI, które wykonuje statyczną alokację adresów IP dla każdego węzła.

• Węzły i podsieci zasobników można skalować i udostępniać niezależnie. Pojedynczą podsieć zasobnika można udostępnić w wielu pulach węzłów lub klastrach wdrożonych w tej samej sieci wirtualnej. Można również skonfigurować oddzielną podsieć zasobnika dla puli węzłów.

• Ponieważ zasobniki mają prywatne adresy IP sieci wirtualnej, mają bezpośrednią łączność z innymi zasobnikami klastra i zasobami w sieci wirtualnej. Ta możliwość zapewnia lepszą wydajność w przypadku bardzo dużych klastrów.

• Jeśli zasobniki mają oddzielną podsieć, można skonfigurować zasady sieci wirtualnej dla zasobników, które różnią się od zasad węzłów. Oddzielne zasady umożliwiają wiele przydatnych scenariuszy, takich jak zezwolenie na łączność z Internetem tylko dla zasobników, a nie dla węzłów, naprawianie źródłowego adresu IP zasobnika w puli węzłów przy użyciu bramy translatora adresów sieciowych oraz filtrowanie ruchu między pulami węzłów przy użyciu sieciowych grup zabezpieczeń.

• Zarówno zasady sieci, jak i zasady sieci Calico Kubernetes działają z dynamiczną alokacją adresów IP.

Współautorzy

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

Autorzy zabezpieczeń:

• Paolo Salvatori | Główny inżynier systemu

Inni współautorzy:

• Laura Nicolas | Starszy inżynier oprogramowania
• Chad Kittel | Główny inżynier oprogramowania
• Cena Ed | Starszy menedżer programu zawartości
• Theano Petersen | Składnik zapisywania technicznego

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

Następne kroki

• Usługa AKS dla specjalistów amazon EKS
• Zarządzanie tożsamościami i dostępem na platformie Kubernetes
• Monitorowanie i rejestrowanie na platformie Kubernetes
• Zabezpieczanie dostępu sieciowego do platformy Kubernetes
• Opcje magazynu dla klastra Kubernetes
• Zarządzanie kosztami dla platformy Kubernetes
• Nadzór nad klastrem
• Podróż rozwiązania usługi Azure Kubernetes Service (AKS)
• Przewodnik po operacjach usługi Azure Kubernetes Services (AKS) z dnia 2
• Wybierz platformę Kubernetes w opcji obliczeń brzegowych
• GitOps dla usługi Azure Kubernetes Service

Powiązane zasoby

• Najlepsze rozwiązania dotyczące klastra usługi AKS
• Tworzenie prywatnego klastra usługi AKS z publiczną strefą DNS
• Tworzenie prywatnego klastra usługi Azure Kubernetes Service przy użyciu narzędzia Terraform i usługi Azure DevOps
• Tworzenie publicznego lub prywatnego klastra usługi Azure Kubernetes Service za pomocą usługi Azure NAT Gateway i bramy aplikacja systemu Azure
• Używanie prywatnych punktów końcowych z prywatnym klastrem usługi AKS
• Tworzenie klastra usługi Azure Kubernetes Service za pomocą kontrolera ruchu przychodzącego usługi Application Gateway
• Wprowadzenie do platformy Kubernetes
• Wprowadzenie do platformy Kubernetes na platformie Azure
• Implementowanie usługi Azure Kubernetes Service (AKS)
• Tworzenie i wdrażanie aplikacji na platformie Kubernetes
• Optymalizowanie kosztów obliczeń w usłudze Azure Kubernetes Service (AKS)