Share via

Propagacja zasobów kubernetes z klastra koncentratora do klastrów członkowskich

  • Artykuł

W tym artykule opisano koncepcję propagacji zasobów Kubernetes z klastrów piasty do klastrów członkowskich przy użyciu usługi Azure Kubernetes Fleet Manager (Fleet).

Administratorzy platformy często muszą wdrażać zasoby kubernetes w wielu klastrach z różnych powodów, na przykład:

  • Zarządzanie kontrolą dostępu przy użyciu ról i powiązań ról w wielu klastrach.
  • Uruchamianie aplikacji infrastruktury, takich jak Prometheus lub Flux, które muszą znajdować się we wszystkich klastrach.

Deweloperzy aplikacji często muszą wdrażać zasoby kubernetes w wielu klastrach z różnych powodów, na przykład:

  • Wdrażanie aplikacji obsługującej wideo w wielu klastrach w różnych regionach w celu oglądania z małym opóźnieniem.
  • Wdrażanie aplikacji koszyka zakupów w dwóch sparowanych regionach dla klientów w celu kontynuowania zakupów podczas awarii jednego regionu.
  • Wdrażanie aplikacji obliczeniowej wsadowej w klastrach z dostępnymi niedrogimi pulami węzłów typu spot.

Żmudne jest ręczne tworzenie, aktualizowanie i śledzenie tych zasobów Kubernetes w wielu klastrach. Rozwiązanie Fleet zapewnia propagację zasobów Kubernetes w celu umożliwienia zarządzania zasobami Kubernetes na dużą skalę. Za pomocą rozwiązania Fleet możesz utworzyć zasoby kubernetes w klastrze koncentratora i propagować je do wybranych klastrów członkowskich za pośrednictwem zasobów niestandardowych Kubernetes: MemberCluster i ClusterResourcePlacement. Rozwiązanie Fleet obsługuje te zasoby niestandardowe na podstawie rozwiązania wieloklasowego natywnego dla chmury typu open source. Aby uzyskać więcej informacji, zobacz dokumentację nadrzędnej floty.

Ważne

Funkcje usługi Azure Kubernetes Fleet Manager w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi Azure Kubernetes Fleet Manager są częściowo objęte pomocą techniczną w oparciu o najlepsze nakłady pracy. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego.

Przepływ pracy propagacji zasobów

Diagram pokazujący, jak zasób Kubernetes jest propagowany do klastrów członkowskich.

Co to jest MemberCluster?

Po dołączeniu klastra do floty odpowiedni MemberCluster zasób niestandardowy zostanie utworzony w klastrze koncentratora. Za pomocą tego zasobu niestandardowego można wybrać klastry docelowe w propagacji zasobów.

Następujące etykiety mogą służyć do wyboru klastra docelowego w propagacji zasobów i są automatycznie dodawane do wszystkich klastrów członkowskich:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Aby uzyskać więcej informacji, zobacz dokumentację interfejsu API MemberCluster.

Co to jest ClusterResourcePlacement?

Obiekt ClusterResourcePlacement służy do określania harmonogramu fleet, jak umieścić dany zestaw obiektów o zakresie klastra z klastra w klastrach członkowskich. Obiekty o zakresie przestrzeni nazw, takie jak Wdrożenia, StatefulSets, DaemonSets, Config Mapy, Secrets i PersistentVolumeClaims, są uwzględniane podczas wybierania ich zawierającej przestrzeń nazw.

Za pomocą ClusterResourcePlacementprogramu można wykonywać następujące czynności:

  • Wybierz zasoby Kubernetes o zakresie klastra, które mają być propagowane do klastrów członkowskich.
  • Określ zasady umieszczania, aby ręcznie lub automatycznie wybrać podzestaw lub wszystkie klastry członkowskie jako klastry docelowe.
  • Określ strategie wdrażania, aby bezpiecznie wdrożyć wszystkie aktualizacje wybranych zasobów Kubernetes w wielu klastrach docelowych.
  • Wyświetl postęp propagacji w każdym klastrze docelowym.

Obiekt ClusterResourcePlacement obsługuje używanie obiektu ConfigMap do otaczania obiektu w celu propagowania ich do klastrów członkowskich bez niezamierzonych skutków ubocznych. Metody wyboru obejmują:

  • Grupa, wersja i rodzaj: wybierz i umieść wszystkie zasoby danego typu.
  • Grupa, wersja, rodzaj i nazwa: wybierz i umieść jeden konkretny zasób danego typu.
  • Grupuj, wersję, rodzaj i etykiety: wybierz i umieść wszystkie zasoby danego typu zgodne z podanymi etykietami.

Aby uzyskać więcej informacji, zobacz dokumentację interfejsu ClusterResourcePlacement API.

Podczas tworzenia ClusterResourcePlacementelementu można określić następujące typy koligacji:

  • requiredDuringSchedulingIgnoredDuringExecution: Ponieważ ta koligacja jest wymaganym typem podczas planowania, filtruje klastry na podstawie ich właściwości.
  • preferredDuringSchedulingIgnoredDuringExecution: Ponieważ koligacja jest tylko preferowanym typem, ale nie jest wymagana podczas planowania, zapewnia preferencyjne klasyfikowanie klastrów na podstawie właściwości określonych przez Ciebie, takich jak koszt lub dostępność zasobów.

Dostępnych jest wiele typów umieszczania do kontrolowania liczby klastrów, do których należy propagować zasób Kubernetes:

  • PickAll umieszcza zasoby we wszystkich dostępnych klastrach członkowskich. Te zasady są przydatne w przypadku umieszczania obciążeń infrastruktury, takich jak aplikacje do monitorowania klastra lub raportowania.
  • PickFixed umieszcza zasoby na określoną listę klastrów członkowskich według nazwy.
  • PickN jest najbardziej elastyczną opcją umieszczania i umożliwia wybór klastrów na podstawie ograniczeń koligacji lub topologii i jest przydatny podczas rozkładania obciążeń w wielu odpowiednich klastrach w celu zapewnienia dostępności.

PickAll zasady umieszczania

Możesz użyć PickAll zasad umieszczania, aby wdrożyć obciążenie we wszystkich klastrach członkowskich w floty (opcjonalnie pasujące do zestawu kryteriów).

W poniższym przykładzie pokazano, jak wdrożyć test-deployment przestrzeń nazw i wszystkie jej obiekty we wszystkich klastrach oznaczonych etykietą environment: production:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Te proste zasady pobierają test-deployment przestrzeń nazw i wszystkie zawarte w niej zasoby i wdrażają je we wszystkich klastrach członkowskich w flocie z daną environment etykietą. Jeśli wszystkie klastry są pożądane, możesz całkowicie usunąć affinity termin.

PickFixed zasady umieszczania

Jeśli chcesz wdrożyć obciążenie w znanym zestawie klastrów członkowskich, możesz użyć PickFixed zasad umieszczania, aby wybrać klastry według nazwy.

W poniższym przykładzie pokazano, jak wdrożyć test-deployment przestrzeń nazw w klastrach cluster1 członkowskich i cluster2:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickN zasady umieszczania

Zasady umieszczania PickN są najbardziej elastyczną opcją i umożliwiają umieszczanie zasobów w konfigurowalnej liczbie klastrów na podstawie ograniczeń rozkładu koligacji i topologii.

PickN z koligacjami

Używanie koligacji z PickN funkcjami zasad umieszczania podobnie do używania koligacji z planowaniem zasobników. Można ustawić zarówno wymagane, jak i preferowane koligacje. Wymagane koligacje uniemożliwiają umieszczanie w klastrach, które nie są zgodne z określonymi koligacjami, a preferowane koligacje umożliwiają porządkowanie zestawu prawidłowych klastrów podczas podejmowania decyzji o umieszczeniu.

W poniższym przykładzie pokazano, jak wdrożyć obciążenie w trzech klastrach. Tylko klastry z etykietą critical-allowed: "true" są prawidłowymi miejscami docelowymi umieszczania, a preferencje są przekazywane klastrom z etykietą critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN z ograniczeniami rozprzestrzeniania topologii

Za pomocą ograniczeń rozprzestrzeniania topologii można wymusić podział umieszczania klastrów w granicach topologii w celu spełnienia wymagań dotyczących dostępności, na przykład dzielenia umieszczania między regionami lub pierścieni aktualizacji. Można również skonfigurować ograniczenia rozprzestrzeniania topologii, aby zapobiec harmonogramowi, jeśli ograniczenie nie może być spełnione (whenUnsatisfiable: DoNotSchedule) lub jak najlepiej (whenUnsatisfiable: ScheduleAnyway).

W poniższym przykładzie pokazano, jak rozłożyć dany zestaw zasobów w wielu regionach i próbuje zaplanować harmonogram między klastrami członkowskimi z różnymi dniami aktualizacji:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą ograniczeń topologii nadrzędnej floty.

Strategia aktualizacji

Rozwiązanie Fleet używa strategii aktualizacji stopniowej do kontrolowania sposobu wdrażania aktualizacji w wielu miejscach klastra.

W poniższym przykładzie pokazano, jak skonfigurować strategię aktualizacji stopniowej przy użyciu ustawień domyślnych:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Harmonogram wdraża aktualizacje dla każdego klastra sekwencyjnie, czekając przynajmniej unavailablePeriodSeconds między klastrami. Stan wdrożenia jest uznawany za pomyślny, jeśli wszystkie zasoby zostały poprawnie zastosowane do klastra. Sprawdzanie stanu wdrożenia nie powoduje kaskadowego użycia zasobów podrzędnych, na przykład nie potwierdza, że zasobniki utworzone przez wdrożenie staną się gotowe.

Aby uzyskać więcej informacji, zobacz dokumentację strategii wdrażania nadrzędnego Floty.

Stan umieszczania

Harmonogram floty aktualizuje szczegóły i stan decyzji dotyczących umieszczania ClusterResourcePlacement na obiekcie. Te informacje można wyświetlić przy użyciu kubectl describe crp <name> polecenia . Dane wyjściowe zawierają następujące informacje:

  • Warunki, które są obecnie stosowane do umieszczania, które obejmują, jeśli umieszczanie zostało pomyślnie ukończone.
  • Sekcja stanu umieszczania dla każdego klastra członkowskiego, która pokazuje stan wdrożenia w tym klastrze.

W poniższym przykładzie pokazano, ClusterResourcePlacement że wdrożono test przestrzeń nazw i test-1 ConfigMap w dwóch klastrach członkowskich przy użyciu polecenia PickN. Umieszczanie zostało ukończone pomyślnie, a zasoby zostały umieszczone w aks-member-1 klastrach i aks-member-2 .

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Zmiany umieszczania

Harmonogram floty określa priorytety stabilności istniejących umieszczania obciążeń. Ta priorytetyzacja może ograniczyć liczbę zmian, które powodują usunięcie obciążenia i jego ponowne utworzenie. Następujące scenariusze mogą wyzwalać zmiany umieszczania:

  • Zmiany zasad umieszczania w ClusterResourcePlacement obiekcie mogą wyzwalać usuwanie i ponowne zmienianie obciążenia.
    • Skalowanie operacji w poziomie (zwiększanie numberOfClusters bez innych zmian) spowoduje umieszczenie obciążeń tylko w nowych klastrach i nie ma wpływu na istniejące umieszczanie.
  • Zmiany klastra, w tym:
    • Nowy klaster kwalifikujący się może wyzwolić umieszczanie, jeśli spełnia zasady umieszczania PickAll , na przykład zasady.
    • Klaster z rozmieszczeniem zostanie usunięty z floty, podejmie próbę zastąpienia wszystkich obciążeń, których to dotyczy, bez wpływu na ich inne miejsca.

Zmiany tylko dla zasobów (aktualizowanie zasobów lub aktualizowanie ResourceSelector obiektu) są stopniowo wdrażane w ClusterResourcePlacement istniejących miejscach, ale nie wyzwalają ponownej zmiany obciążenia.

Tolerancje

ClusterResourcePlacement obiekty obsługują specyfikację tolerancji, które mają zastosowanie do ClusterResourcePlacement obiektu. Każdy obiekt tolerancji składa się z następujących pól:

  • key: klucz tolerancji.
  • value: wartość tolerancji.
  • effect: Efekt tolerancji, taki jak NoSchedule.
  • operator: operator tolerancji, taki jak Exists lub Equal.

Każda tolerancja jest używana do tolerowania co najmniej jednego konkretnego defektu stosowanego w obiekcie ClusterResourcePlacement. Po tolerowaniu wszystkich defektów na obiekcie MemberCluster harmonogram może następnie propagować zasoby do klastra. Nie można zaktualizować ani usunąć tolerancji z obiektu po jego utworzeniu ClusterResourcePlacement .

Aby uzyskać więcej informacji, zobacz dokumentację nadrzędnej floty.

Uzyskiwanie dostępu do interfejsu API kubernetes klastra zasobów Fleet

Jeśli utworzono zasób usługi Azure Kubernetes Fleet Manager z włączonym klastrem koncentratora, możesz użyć go do centralnego sterowania scenariuszami, takimi jak propagacja obiektów Kubernetes. Aby uzyskać dostęp do interfejsu API kubernetes klastra zasobów Fleet, wykonaj kroki opisane w artykule Uzyskiwanie dostępu do interfejsu API kubernetes klastra zasobów Fleet za pomocą usługi Azure Kubernetes Fleet Manager.

Następne kroki

Skonfiguruj propagację zasobów Kubernetes z klastra koncentratora do klastrów członkowskich.