Udostępnij za pośrednictwem

Wprowadzenie do rejestru klastrów

  • Artykuł

Zwiększanie odporności funkcji sieci natywnych dla chmury za pomocą rejestru klastra usługi Azure Operator Service Manager (AOSM)

Historia dokumentów

  • Utworzono i opublikowano: 26 lipca 2024 r.
  • Zaktualizowano o wysoką dostępność: 16 października 2024 r.
  • Zaktualizowano dla GC: 5 listopada 2024 r.

Zależności funkcji

Ta funkcja wymaga następującego środowiska minimalnego:

  • Minimalna wersja interfejsu API arm AOSM: 2023-09-01
  • Pierwsza wersja, brak wysokiej dostępności dla rozszerzenia kubernetes funkcji sieciowej (NF): 1.0.2711-7
  • Pierwsza wersja z wysoką dostępnością dla rozszerzenia kubernetes systemu plików NF: 2.0.2810-144
  • Pierwsza wersja z GC dla rozszerzenia kubernetes NF: 2.0.2860-160

Omówienie rejestru klastrów

Rejestr klastra programu Azure Operator Service Manager (AOSM) umożliwia lokalną kopię obrazów kontenerów w klastrze Nexus K8s. Po zainstalowaniu konteneryzowanej funkcji sieciowej (CNF) z włączonym rejestrem klastra obrazy kontenerów są pobierane ze zdalnego magazynu artefaktów AOSM i zapisywane w tym rejestrze klastra lokalnego. Przy użyciumutowania elementu webhook rejestr klastra automatycznie przechwytuje żądania obrazów i zastępuje lokalną ścieżkę rejestru, aby uniknąć zmian pakietu wydawcy. W przypadku rejestrowania klastra dostęp CNF do obrazów kontenerów przetrwa utratę łączności z zdalnym magazynem artefaktów.

Kluczowe przypadki użycia i korzyści

Funkcje sieci natywnej w chmurze (CNF) wymagają dostępu do obrazów kontenerów, nie tylko podczas początkowego wdrażania przy użyciu magazynu artefaktów AOSM, ale także w celu zapewnienia działania funkcji sieciowej. Niektóre z tych scenariuszy obejmują:

  • Ponowne uruchamianie zasobnika: zatrzymywanie i uruchamianie zasobnika może spowodować ściąganie obrazów kontenerów z rejestru przez węzeł klastra.
  • Operacje harmonogramu platformy Kubernetes: Podczas przypisywania zasobnika do węzła zgodnie z regułami profilu harmonogramu, jeśli nowy węzeł nie ma lokalnie buforowanych obrazów kontenerów, węzeł ściąga obrazy kontenerów z rejestru.

Zalety korzystania z rejestru klastra AOSM:

  • Udostępnia niezbędne obrazy lokalne, aby zapobiec przerwom w działaniu systemu CNF w przypadku utraty łączności z magazynem artefaktów AOSM.
  • Zmniejsza liczbę ściągnięcia obrazu w magazynie artefaktów AOSM, ponieważ każdy węzeł klastra pobiera teraz obrazy tylko z rejestru lokalnego.
  • Pozwala wyeliminować problemy z nieprawidłowo sformułowanymi adresami URL rejestru, używając mutowanego elementu webhook w celu zastąpienia właściwej lokalnej ścieżki adresu URL rejestru.

Jak działa rejestr klastrów

Rejestr klastra AOSM jest włączony przy użyciu rozszerzenia K8s operatora funkcji sieciowej (NFO). Poniższy interfejs wiersza polecenia pokazuje, jak rejestr klastra jest włączony w klastrze Nexus K8s.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Gdy funkcja rejestru klastra jest włączona w rozszerzeniu K8s operatora funkcji sieciowej, wszystkie obrazy kontenerów wdrożone z magazynu artefaktów AOSM są dostępne lokalnie w klastrze Nexus K8s. Użytkownik może wybrać trwały rozmiar magazynu dla rejestru klastrów.

Uwaga

Jeśli użytkownik nie podaje żadnych danych wejściowych, zostanie użyty domyślny trwały wolumin 100 GB.

Składniki rejestru klastra

Funkcja rejestru klastra wdraża zasobniki pomocnicze w docelowym klastrze brzegowym w celu ułatwienia rozszerzenia NFO.

Uzgadnianie składników

  • Ten główny zasobnik zajmuje się uzgadnianiem składników niestandardowych obiektów zasobów (CRO) utworzonych przez K8sBridge za pomocą dostawcy zasobów Microsoft.Kubernetes (RP), hybrydowego przekaźnika i agenta usługi Arc uruchomionego w klastrze.

Zmutowanie elementu webhook zasobnika

  • Te zasobniki implementująmutowanie elementów webhook przyjęcia kubernetes obsługujących wystąpienie interfejsu APImutacji. Interfejs APImutacji wykonuje dwie czynności:
    • Modyfikuje ścieżkę rejestru obrazów do lokalnego adresu IP rejestru, zastępując magazyn artefaktów AOSM azure container registry (ACR).
    • Tworzy artefakt CR w klastrze brzegowym.

Uzgadnianie artefaktów

  • Ten zasobnik uzgadnia obiekty CRO artefaktu utworzone przez mutujący element webhook.

Rejestr

  • Ten zasobnik przechowuje i pobiera obrazy kontenerów dla systemu plików CNF.

Odzyskiwanie pamięci rejestru klastrów

Rozszerzenie klastra AOSM uruchamia zadanie odzyskiwania pamięci w tle (GC) w celu regularnego czyszczenia obrazów kontenerów. To zadanie zostanie uruchomione zgodnie z harmonogramem, sprawdź, czy użycie rejestru klastra osiągnęło określony próg, a jeśli tak, zainicjuj proces odzyskiwania pamięci. Harmonogram i próg zadania są konfigurowane przez użytkownika końcowego, ale domyślnie zadanie jest uruchamiane raz dziennie z progiem wykorzystania 0%.

Czyszczenie manifestów obrazu bezużytecznego

Usługa AOSM utrzymuje odwołania między zasobem właściciela zasobnika a używaniem obrazów w rejestrze klastrów. Po zainicjowaniu procesu oczyszczania obrazów obrazy zostaną zidentyfikowane, które nie są połączone z żadnymi zasobnikami, wystawiając usuwanie nietrwałe w celu usunięcia ich z rejestru klastra. Ten typ usuwania nietrwałego nie zwalnia natychmiast miejsca do magazynowania rejestru klastra. Rzeczywiste usuwanie plików obrazów zależy od odzyskiwania pamięci rejestru dystrybucji CNCF opisanego poniżej.

Uwaga

Odwołanie między właścicielem zasobnika a jego obrazami kontenerów gwarantuje, że usługa AOSM nie usuwa błędnie obrazów. Jeśli na przykład zasobnik zestawu replik ulegnie awarii, usługa AOSM nie wyłuszczy obrazów kontenerów. Usługa AOSM usuwa tylko obrazy kontenerów po usunięciu zestawu replik. Ta sama zasada dotyczy zasobników zarządzanych przez zadania i demony kubernetes.

Rozkład odzyskiwania pamięci z SYSTEMU CNCF

Usługa AOSM konfiguruje rejestr klastrów przy użyciu rejestru dystrybucji TYPU OPEN SOURCE CNCF. W związku z tym usługa AOSM opiera się na funkcjach odzyskiwania pamięci udostępnianych przez odzyskiwanie pamięci | Rozkład CNCF. Ogólnie rzecz biorąc, następuje standardowy proces "oznacz i zamiatanie" 2 fazy w celu usunięcia plików obrazów w celu zwolnienia miejsca do magazynowania rejestru.

Uwaga

Ten proces wymaga rejestru klastra w trybie tylko do odczytu. Jeśli obrazy są przekazywane, gdy rejestr nie jest w trybie tylko do odczytu, istnieje ryzyko, że warstwy obrazów zostaną błędnie usunięte, co prowadzi do uszkodzenia obrazu. Rejestr wymaga blokady w trybie tylko do odczytu przez maksymalnie 1 minutę. W związku z tym usługa AOSM odroczy inne wdrożenie systemu plików NF w przypadku rejestru klastra w trybie tylko do odczytu.

Parametry konfiguracji odzyskiwania pamięci

Poniższe parametry konfigurują harmonogram i próg zadania odzyskiwania pamięci.

  • global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
  • global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
  • Aby uzyskać więcej informacji o konfiguracji, zapoznaj się z najnowszymi instrukcjami instalacji rozszerzenia funkcji sieciowej

Zagadnienia dotyczące wysokiej dostępności i odporności

Rozszerzenie AOSM NF korzysta zmutowania elementu webhook i rejestru krawędzi do obsługi kluczowych funkcji.

  • Dołączanie wykresów helm bez konieczności dostosowywania ścieżki obrazu.
  • Rejestr klastra lokalnego w celu przyspieszenia operacji zasobnika i włączenia obsługi trybu rozłączonego. Te podstawowe składniki muszą być wysoce dostępne i odporne.

Podsumowanie zmian dotyczących wysokiej dostępności

Dzięki wysokiej dostępności zasobniki rejestru klastra i elementów webhook obsługują teraz zestaw replik z co najmniej trzema replikami i maksymalnie pięcioma replikami. Konfiguracja klucza zestawu replik jest następująca:

  • Jest używana strategia stopniowego uaktualniania wdrożenia.
  • PodDisruptionBudgets (PDB) są używane do dostępności podczas dobrowolnych zakłóceń.
  • Anty-koligacja zasobnika służy do równomiernego rozmieszczania zasobników między węzłami.
  • Sonda gotowości służy do upewnienia się, że zasobniki są gotowe przed obsługą ruchu.
  • Zasobniki obciążenia AOSM są przypisywane tylko do puli węzłów systemowych.
  • Zasobniki są skalowane w poziomie pod obciążeniem procesora CPU i pamięci.

Repliki

  • Klaster z wieloma kopiami lub replikami aplikacji zapewnia pierwszy poziom nadmiarowości. Zarówno rejestr klastra, jak i element webhook są definiowane jako "kind:deployment" z co najmniej trzema replikami.

DeploymentStrategy

  • Strategia rollingUpdate służy do zapewnienia zerowych uaktualnień przestojów i obsługi stopniowego wdrażania aplikacji. Domyślna konfiguracja maxUnavailable zezwala na wyłączenie tylko jednego zasobnika naraz, dopóki nie zostaną utworzone wystarczające zasobniki do spełnienia zasad nadmiarowości.

Budżet na zakłócenia zasobnika

  • Budżet zakłóceń zasad (PDB) chroni zasobniki przed dobrowolnymi zakłóceniami i jest wdrażany wraz z obiektami Deployment, ReplicaSet lub StatefulSet. W przypadku zasobników operatorów AOSM używany jest parametr PDB z parametrem minAvailable 2.

Anty-koligacja zasobnika

  • Pod anty-koligacja steruje dystrybucją zasobników aplikacji w wielu węzłach w klastrze. W przypadku wysokiej dostępności anty-koligacja zasobnika AOSM przy użyciu następujących parametrów:
    • Tryb planowania służy do definiowania sposobu ścisłego wymuszania reguły.
      • requiredDuringSchedulingIgnoredDuringExecution(Hard): Zasobniki muszą być zaplanowane w sposób spełniający zdefiniowaną regułę. Jeśli nie są dostępne żadne topologie spełniające wymagania reguły, zasobnik nie jest zaplanowany.
      • preferredDuringSchedulingIgnoredDuringExecution(Soft): ten typ reguły wyraża preferencje dotyczące planowania zasobników, ale nie wymusza ścisłego wymagania. Jeśli dostępne są topologie spełniające kryteria preferencji, platforma Kubernetes planuje zasobnik. Jeśli takie topologie nie są dostępne, zasobnik nadal może być zaplanowany na innych węzłach, które nie spełniają preferencji.
    • Selektor etykiet służy do określania docelowych zasobników, dla których jest stosowana koligacja.
    • Klucz topologii służy do definiowania potrzeb węzła.
  • Rozmieszczenie węzłów Nexus jest równomiernie rozłożone między strefami zgodnie z projektem, więc rozłożenie zasobników między węzłami zapewnia również nadmiarowość strefową.
  • Zasobniki operatora AOSM używają miękkiej koligacji z wagą 100 i kluczem topologii opartym na nazwach hostów węzłów.

Storage

  • Ponieważ rejestr usługi AOSM edge ma wiele replik rozmieszczonych w węzłach, trwały wolumin musi obsługiwać tryb dostępu ReadWriteMany (RWX). Wolumin "nexus-shared" pvc jest dostępny w klastrach Nexus i obsługuje tryb dostępu RWX.

Monitorowanie za pomocą sond gotowości

  • Usługa AOSM używa sond gotowości http, aby wiedzieć, kiedy kontener jest gotowy do rozpoczęcia akceptowania ruchu. Zasobnik jest uznawany za gotowy, gdy wszystkie kontenery są gotowe. Gdy zasobnik nie jest gotowy, zostanie usunięty z modułów równoważenia obciążenia usługi.

Pula węzłów systemowych

  • Wszystkie zasobniki operatora AOSM są przypisywane do puli węzłów systemowych. Ta pula uniemożliwia błędną konfigurację lub zasobniki aplikacji rouge wpływające na zasobniki systemowe.

Skalowanie w poziomie

  • Na platformie Kubernetes narzędzie HorizontalPodAutoscaler (HPA) automatycznie aktualizuje zasób obciążenia w celu automatycznego skalowania obciążenia w celu dopasowania obciążenia do zapotrzebowania. Zasobniki operatorów AOSM mają skonfigurowane następujące parametry zasad HPA;
    • Minimalna replika trzech.
    • Maksymalna replika pięciu.
    • TargetAverageU dziennie dla procesora CPU i pamięci wynoszącej 80%.

Limity zasobów

  • Limity zasobów służą do zapobiegania przeciążeniu zasobów w węzłach, w których działają zasobniki usługi AOSM. Usługa AOSM używa dwóch parametrów zasobów, aby ograniczyć użycie procesora CPU i pamięci.
    • Żądanie zasobu — minimalna kwota, która powinna być zarezerwowana dla zasobnika. Ta wartość powinna być ustawiona na użycie zasobów w ramach normalnego obciążenia aplikacji.
    • Limit zasobów — maksymalna ilość, jaką zasobnik powinien kiedykolwiek używać, jeśli użycie osiągnie limit, który zostanie zakończony. Wszystkie kontenery operatorów AOSM są skonfigurowane z odpowiednim żądaniem, limitem procesora CPU i pamięci.

Znane ograniczenia wysokiej dostępności

  • Klastry Nexus AKS (NAKS) z pojedynczym aktywnym węzłem w puli agentów systemowych nie są odpowiednie dla wysokiej dostępności. Topologia produkcji Nexus musi używać co najmniej trzech aktywnych węzłów w puli agentów systemowych.
  • Klasa magazynu udostępnionego nexus jest usługą magazynu sieciowego systemu plików (NFS). Ta usługa magazynu NFS jest dostępna dla sieci usług w chmurze (CSN). Każdy klaster Kubernetes Nexus dołączony do csN może aprowizować wolumin trwały z tej udostępnionej puli magazynów. Pula magazynów jest obecnie ograniczona do maksymalnego rozmiaru 1 TiB jako chmury sieciowej (NC) 3.10, gdzie jako NC 3.12 ma opcję 16-TiB.
  • Koligacja pod Antifinity dotyczy tylko początkowego umieszczania zasobników, kolejnych skalowania zasobników i naprawy, zgodnie ze standardową logiką planowania K8s.

Często zadawane pytania

Czy mogę używać rejestru klastra AOSM z wcześniej wdrożona aplikacją CNF?

Jeśli aplikacja CNF jest już wdrożona bez rejestru klastrów, obrazy kontenerów nie są dostępne automatycznie. Przed wdrożeniem funkcji sieciowej za pomocą usługi AOSM należy włączyć rejestr klastra.

Czy mogę zmienić rozmiar magazynu po wdrożeniu?

Nie można zmodyfikować rozmiaru magazynu po początkowym wdrożeniu. Zalecamy skonfigurowanie rozmiaru woluminu o 3x do 4x rozmiaru początkowego.

Czy mogę wyświetlić listę plików przechowywanych obecnie w repozytorium klastra?

Następujące polecenie może służyć do wyświetlania listy plików w formacie czytelnym dla człowieka:

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

To polecenie powinno wygenerować dane wyjściowe podobne do następujących:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0