Udostępnij za pośrednictwem

Uaktualnianie klastra Kubernetes operatora platformy Azure

  • Artykuł

Ten artykuł zawiera instrukcje dotyczące uaktualniania klastra Kubernetes Operatora Nexus w celu uzyskania najnowszych funkcji i aktualizacji zabezpieczeń. Część cyklu życia klastra Kubernetes obejmuje okresowe uaktualnianie do najnowszej wersji rozwiązania Kubernetes. Ważne jest, aby zastosować najnowsze wersje zabezpieczeń lub uaktualnić, aby uzyskać najnowsze funkcje. W tym artykule przedstawiono sposób sprawdzania, konfigurowania i stosowania uaktualnień do klastra Kubernetes.

Ograniczenia

  • Domyślny proces uaktualniania klastra jest podejściem skalowalnym w poziomie, co oznacza, że jest dodawany co najmniej jeden dodatkowy węzeł (lub tyle węzłów, jak skonfigurowano w maksymalnym wzroście). Jeśli nie ma wystarczającej pojemności, uaktualnienie zakończy się niepowodzeniem.
  • Gdy nowe wersje platformy Kubernetes staną się dostępne, klastry dzierżaw nie zostaną poddane automatycznym uaktualnieniu. Użytkownicy powinni zainicjować uaktualnienie, gdy wszystkie funkcje sieciowe w klastrze są gotowe do obsługi nowej wersji rozwiązania Kubernetes. Aby uzyskać więcej informacji, zobacz Uaktualnianie klastra.
  • Operator Nexus oferuje uaktualnienia obejmujące cały klaster, zapewniając spójność we wszystkich pulach węzłów. Uaktualnianie pojedynczej puli węzłów nie jest obsługiwane. Ponadto obraz węzła jest uaktualniany w ramach uaktualnienia klastra, gdy jest dostępna nowa wersja.
  • Dostosowania wprowadzone w węzłach agenta zostaną utracone podczas uaktualniania klastra. Zaleca się umieszczenie tych dostosowań DaemonSet zamiast ręcznego wprowadzania zmian w konfiguracji węzła w celu ich zachowania po uaktualnieniu.
  • Modyfikacje wprowadzone w konfiguracjach podstawowych dodatków są przywracane do domyślnej konfiguracji dodatku w ramach procesu uaktualniania klastra. Unikaj dostosowywania konfiguracji dodatku (na przykład Calico itp.), aby zapobiec potencjalnym awariom uaktualniania. Jeśli przywracanie konfiguracji dodatku napotka problemy, może to prowadzić do niepowodzeń uaktualniania.
  • Podczas uaktualniania klastra Operator Nexus Kubernetes nie można pominąć wersji pomocniczych platformy Kubernetes. Wszystkie uaktualnienia należy wykonać sekwencyjnie według numeru wersji głównej. Na przykład uaktualnienia z zakresu od 1.14.x do> 1.15.x lub 1.15.x ->1.16.x są dozwolone, jednak wersja 1.14.x ->1.16.x nie jest dozwolona. Jeśli wersja znajduje się za więcej niż jedną wersją główną, należy wykonać wiele uaktualnień sekwencyjnych.
  • Podczas tworzenia klastra należy ustawić maksymalne skoki i/lub maksymalną niedostępną wartość. Nie można zmienić tych wartości po utworzeniu klastra. Aby uzyskać więcej informacji, zobacz upgradeSettings Create an Azure Operator Nexus Kubernetes cluster (Tworzenie klastra Kubernetes operatora platformy Azure).

Wymagania wstępne

  • Klaster Kubernetes Operatora platformy Azure wdrożony w grupie zasobów w ramach subskrypcji platformy Azure.
  • Jeśli używasz interfejsu wiersza polecenia platformy Azure, w tym artykule jest wymagana najnowsza wersja interfejsu wiersza polecenia platformy Azure. Jeśli musisz zainstalować lub uaktualnić, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure
  • Minimalna wymagana networkcloud wersja rozszerzenia az-cli: 2.0.b3
  • Zapoznaj się z koncepcją pakietów wersji. Aby uzyskać więcej informacji, zobacz Nexus Kubernetes version bundles (Pakiety wersji rozwiązania Nexus Kubernetes).

Sprawdzanie dostępnych uaktualnień

Sprawdź, które wersje platformy Kubernetes są dostępne dla klastra, wykonując następujące kroki:

Interfejs wiersza polecenia platformy Azure

Następujące polecenie interfejsu wiersza polecenia platformy Azure zwraca dostępne uaktualnienia dla klastra:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Przykładowe dane wyjściowe:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Korzystanie z witryny Azure Portal

  1. Zaloguj się w witrynie Azure Portal.
  2. Przejdź do klastra Operator Nexus Kubernetes.
  3. W obszarze Przegląd wybierz kartę Dostępne uaktualnienia .

Zrzut ekranu przedstawiający dostępne uaktualnienia.

Wybierz wersję do uaktualnienia do

Dostępne dane wyjściowe uaktualnienia wskazują, że istnieje wiele wersji do wyboru do uaktualnienia. W tym konkretnym scenariuszu bieżący klaster działa w wersji v1.25.4-3. W związku z tym dostępne opcje uaktualniania obejmują v1.25.4-4 i najnowszą wersję v1.25.6-1. poprawki Ponadto dostępna jest również nowa wersja pomocnicza.

Masz elastyczność uaktualniania do dowolnej z dostępnych wersji. Jednak zalecanym kursem akcji jest przeprowadzenie uaktualnienia do najnowszej dostępnej major-minor-patch-versionbundle wersji.

Uwaga

Format danych wejściowych dla wersji to major.minor.patch lub major.minor.patch-versionbundle. Dane wejściowe wersji muszą być jedną z dostępnych wersji uaktualnienia. Jeśli na przykład bieżąca wersja klastra to 1.1.1-1, prawidłowe dane wejściowe wersji to 1.1.1-2 lub 1.1.1-x. Chociaż 1.1.1 jest prawidłowym formatem, nie wyzwoli żadnej aktualizacji, ponieważ bieżąca wersja jest już 1.1.1. Aby zainicjować aktualizację, możesz określić pełną wersję z pakietem wersji, takim jak 1.1.1-2. 1.1.2 Jednak i są prawidłowymi danymi wejściowymi i 1.2.x będą używać najnowszego pakietu wersji dostępnego dla 1.1.2 programu lub 1.2.x.

Uaktualnianie klastra

Podczas procesu uaktualniania klastra operator Nexus wykonuje następujące operacje:

  • Dodaj nowy węzeł płaszczyzny sterowania z określoną wersją platformy Kubernetes do klastra.
  • Po dodaniu nowego węzła cordon i opróżnianie jednego ze starych węzłów płaszczyzny sterowania, zapewniając, że obciążenia uruchomione na nim są bezpiecznie przenoszone do innych węzłów płaszczyzny sterowania w dobrej kondycji.
  • Po opróżnieniu starego węzła płaszczyzny sterowania zostanie on usunięty, a nowy węzeł płaszczyzny sterowania zostanie dodany do klastra.
  • Ten proces powtarza się do momentu uaktualnienia wszystkich węzłów płaszczyzny sterowania w klastrze.
  • W przypadku uaktualniania węzłów procesu roboczego za pomocą operacji przesiąknięć (ustawienie domyślne):
    • Dla każdej puli agentów w klastrze dodaj nowy węzeł roboczy (lub dowolną liczbę węzłów skonfigurowanych w maksymalnym wzroście) z określoną wersją platformy Kubernetes. Wiele pul agentów jest uaktualnianych jednocześnie.
    • Cordon i opróżnianie jednego ze starych węzłów roboczych w celu zminimalizowania zakłóceń w uruchomionych aplikacjach. Jeśli używasz maksymalnego wzrostu, kordony i opróżniają tyle węzłów procesu roboczego w tym samym czasie co określona liczba węzłów buforu.
    • Po opróżnieniu starego węzła roboczego zostanie on usunięty, a nowy węzeł roboczy z nową wersją platformy Kubernetes zostanie dodany do klastra (lub dowolną liczbę węzłów skonfigurowanych w maksymalnym wzroście)
  • W przypadku uaktualniania węzłów roboczych bez skoku:
    • Dla każdej puli agentów w klastrze stary węzeł roboczy (lub dowolna liczba węzłów skonfigurowanych przez maksymalną niedostępność) jest cordoned, opróżniany, a następnie usuwany przed zastąpieniem nowego węzła roboczego z określoną wersją platformy Kubernetes. Wiele pul agentów jest uaktualnianych jednocześnie.
    • Podczas uaktualniania nastąpi tymczasowe zmniejszenie pojemności klastra, ponieważ zasobniki opróżnione ze starego węzła roboczego nie będą natychmiast miały nowego węzła do przejścia. Może to spowodować, że zasobniki wprowadzają stan oczekiwania, jeśli nie ma wystarczającej pojemności. W związku z tym ważne jest zaprojektowanie klastra w celu spełnienia wymagań dotyczących pojemności aplikacji, zwłaszcza podczas uaktualniania bez skoków.
  • Ten proces powtarza się do momentu uaktualnienia wszystkich węzłów roboczych w klastrze.

Uwaga

Uaktualnienie klastra nie spowoduje utworzenia nowych węzłów i zastąpienia starych, jeśli wersja obrazu systemu operacyjnego i wersja platformy Kubernetes pozostaną takie same między pakietami wersji. Jest to oczekiwane zachowanie, ponieważ uaktualnienie może obejmować tylko aktualizacje wersji dodatku, a nie nowe wersje systemu operacyjnego lub K8s. Ponieważ nie ma żadnego uaktualnienia stopniowego, nie ma kordonu i opróżniania węzłów, więc nie wystąpią zakłócenia zasobnika.

Ważne

Upewnij się, że każda PodDisruptionBudgets replika (PDB) zezwala na przenoszenie co najmniej jednej repliki zasobnika w danym momencie. W przeciwnym razie operacja opróżniania/eksmisji zakończy się niepowodzeniem. Jeśli operacja opróżniania zakończy się niepowodzeniem, operacja uaktualniania zakończy się niepowodzeniem, aby upewnić się, że aplikacje nie zostaną zakłócone. Popraw, co spowodowało zatrzymanie operacji (tj. nieprawidłowe pliki PDB, brak limitu przydziału itp.) i ponów próbę wykonania operacji. Istnieje również możliwość skonfigurowania limitu czasu opróżniania dla puli węzłów procesu roboczego, po którym węzeł zostanie usunięty, nawet jeśli zasobniki nie zakończyły jeszcze opróżniania. Może to uniemożliwić zablokowanie uaktualnień przez nieprawidłowo skonfigurowane pliki PDB. Ustawienie limitu czasu opróżniania jest konfigurowane w sekundach i domyślnie wynosi 1800.

  1. Uaktualnij klaster przy użyciu networkcloud kubernetescluster update polecenia .
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. Upewnij się, że uaktualnienie zakończyło się pomyślnie, używając show polecenia .
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

Następujące przykładowe dane wyjściowe pokazują, że klaster działa teraz w wersji 1.26.3:

"v1.26.3"
  1. Upewnij się, że klaster jest w dobrej kondycji.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

Następujące przykładowe dane wyjściowe pokazują, że klaster jest w dobrej kondycji:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Dostosowywanie wzrostu lub niedostępności węzła

Domyślnie operator Nexus konfiguruje uaktualnienia w celu zwiększenia z jednym dodatkowym węzłem roboczym. Wartość domyślna jednej dla ustawień maksymalnego wzrostu umożliwia operatorowi Nexus zminimalizowanie zakłóceń obciążenia przez utworzenie dodatkowego węzła przed kordonem/opróżnianie istniejących aplikacji w celu zastąpienia starszego węzła w wersji. Maksymalna wartość skoku można dostosować dla puli węzłów, aby umożliwić kompromis między szybkością uaktualniania a zakłóceniami uaktualniania. Po zwiększeniu maksymalnej wartości wzrostu proces uaktualniania zostanie ukończony szybciej. Jeśli ustawisz dużą wartość maksymalnego wzrostu, podczas procesu uaktualniania mogą wystąpić zakłócenia.

Na przykład maksymalna wartość wzrostu 100% zapewnia najszybszy możliwy proces uaktualniania (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ć wyższej wartości, takiej jak w środowiskach testowych. W przypadku pul węzłów produkcyjnych zalecamy ustawienie max_surge o wartości 33%.

Nie zawsze jest właściwe uaktualnienie za pośrednictwem skoku, na przykład w środowiskach ograniczonych zasobów. Uaktualnienia mogą również przebiegać bez skoków, gdzie węzeł procesu roboczego jest najpierw usuwany, a następnie zastępowany. Oznacza to, że nie jest potrzebny dodatkowy zasób, ale prowadzi do okresów mniejszej pojemności, w których zasobniki mogą nie być w stanie być zaplanowane do węzła. Ten typ uaktualnienia jest kontrolowany na pulę węzłów przez ustawienie maksymalnej niedostępności. Domyślnie wartość maksymalna niedostępna jest ustawiona na 0. Oznacza to, że co najwyżej 0 węzłów może być niedostępny, co oznacza, że ten typ uaktualnienia nie zostanie domyślnie wykonane.

Interfejs API akceptuje zarówno wartości całkowite, jak i wartość procentową dla maksymalnego wzrostu i maksymalnej niedostępności. Liczba całkowita, taka jak 5, wskazuje, że pięć węzłów może zostać wyprzedzonych/niedostępnych. Wartość 50% wskazuje wartość skoku/niedostępności o połowę bieżącej liczby węzłów w puli.

Jeden z maksymalnych wzrostów lub maksymalna niedostępność musi być co najmniej 1 (lub 1%), w przeciwnym razie nie będzie żadnego mechanizmu, za pomocą którego klaster może zostać uaktualniony. Wartość procentowa jest zaokrąglona do najbliższej liczby węzłów. Maksymalna liczba skoków i maksymalna niedostępność może wynosić maksymalnie 100%. Jeśli maksymalna wartość skoku jest wyższa niż wymagana liczba węzłów do uaktualnienia, liczba węzłów do uaktualnienia jest używana dla maksymalnej wartości wzrostu.

Maksymalny wzrost i maksymalna niedostępność można skonfigurować w tym samym czasie, w takim przypadku uaktualnienie będzie kontynuowane za pośrednictwem kombinacji skoków i niedostępności.

Ważne

Standardowe obciążenia Kubernetes są natywnie cykliczne do nowych węzłów, gdy są one opróżniane z węzłów, które są rozdarte. Należy pamiętać, że usługa Operator Nexus Kubernetes nie może składać obietnic obciążeń dla niestandardowych zachowań platformy Kubernetes.

Następne kroki

  • Dowiedz się więcej o pakietach wersji Rozwiązania Nexus Kubernetes.