Wprowadzenie inteligentnego umieszczania zasobów przez Azure Kubernetes Fleet Manager

✔️ Dotyczy Fleet Manager z klastrem hubowym

Zarządzanie zasobami platformy Kubernetes w wielu klastrach stanowi istotne wyzwanie zarówno dla administratorów platformy, jak i deweloperów aplikacji. Ponieważ organizacje skalują infrastrukturę Kubernetes poza pojedynczy klaster, często napotykają złożoność związaną z dystrybucją zasobów, spójnością i ręcznym obciążeniem związanym z zarządzaniem. Tradycyjne podejście do zarządzania poszczególnymi klastrami niezależnie tworzy silosy operacyjne, które stają się coraz trudniejsze do utrzymania w miarę wzrostu wielkości floty.

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

  • 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, w tym:

  • Wdrażanie aplikacji obsługującej wideo w wielu klastrach w różnych regionach na potrzeby oglądania z małym opóźnieniem.
  • Wdrażanie aplikacji koszyka zakupów w dwóch sparowanych regionach, dzięki czemu klienci mogą nadal robić zakupy podczas awarii w jednym regionie.
  • Wdrażanie aplikacji obliczeniowej wsadowej w klastrach z dostępnymi niedrogimi pulami węzłów typu spot.

Ręczne tworzenie, aktualizowanie i śledzenie zasobów Kubernetes w wielu klastrach jest żmudne i wiąże się z ryzykiem błędów.

W tym artykule dowiesz się, jak korzystać z funkcji inteligentnego rozmieszczania zasobów w usłudze Fleet Manager do zarządzania rozmieszczaniem zasobów Kubernetes o zakresie klastra i przestrzeni nazw między klastrami członkowskimi we flocie.

Możliwość umieszczania zasobów w usłudze Fleet Manager jest oparta na projekcie KubeFleet CNCF.

Omówienie procesu umieszczania zasobów

Aby użyć inteligentnego umieszczania zasobów usługi Fleet Manager, wykonaj następujące kroki:

  1. Przygotuj zasoby w klastrze centralnym: użyj ciągłego wdrażania, GitOps lub podobnej metody, aby zastosować manifesty do rozmieszczania zasobów w centralnym klastrze Fleet Managera.
  2. Utwórz rozmieszczenie zasobu: utwórz manifest rozmieszczenia, który wybiera zasób i definiuje zasady określające, które klastry członkowskie otrzymają ten zasób.
  3. Zastosuj rozmieszczenie zasobów w klastrze centralnym: zastosuj manifest rozmieszczenia w klastrze centralnym, aby rozpocząć dystrybucję zasobu.
  4. Fleet Manager planuje zasoby: Fleet Manager obserwuje rozmieszczenie zasobów i wybrany zakres oraz wykonuje dystrybucję zasobów.
  5. Obserwuj dystrybucję za pomocą funkcji ResourcePlacement: sprawdź obiekt ResourcePlacement w klastrze centralnym, aby monitorować stan zasobu w miarę jego wdrażania.

Fleet Manager ma doświadczenie portalowe Azure do rozmieszczania zasobów, które zapewnia bardziej wizualne przedstawienie wdrożenia.

Wprowadzenie do rozlokowania zasobów w klastrze

Użyj obiektu ClusterResourcePlacement (CRP), aby rozmieścić określony zestaw zasobów na poziomie klastra lub całe przestrzenie nazw z klastra centralnego Fleet Manager do jednego lub większej liczby klastrów członkowskich.

Kluczowe cechy:

  • Zakres całego klastra: wybiera zasoby z zakresu całego klastra lub przestrzenie nazw.
  • Deklaratywny: używa tych samych zasad rozmieszczania co ResourcePlacement, aby zapewnić spójne działanie.

Za pomocą protokołu CRP można wykonywać następujące czynności:

  • Wybierz zasoby kubernetes do dystrybucji. Te zasoby mogą być zasobami Kubernetes o zakresie całego klastra zdefiniowanymi za pomocą odwołań Kubernetes Group Version Kind (GVK) albo przestrzenią nazw, co powoduje rozprowadzenie tej przestrzeni nazw i wszystkich jej zasobów.
  • Określ zasady lokalizacji, aby wybrać klastry członkowskie. Te zasady mogą jawnie wybierać klastry według nazw lub dynamicznie wybierać klastry na podstawie etykiet i właściwości klastra.
  • Określ strategie wdrażania, aby bezpiecznie wdrożyć wszystkie aktualizacje wybranych zasobów Kubernetes w wielu klastrach docelowych.
  • Wyświetl postęp wdrażania dla każdego klastra docelowego.

W przypadku scenariuszy wymagających precyzyjnej kontroli nad indywidualnymi zasobami w obrębie przestrzeni nazw, zobacz rozmieszczanie zasobów w obrębie przestrzeni nazw, co umożliwia dystrybucję określonych zasobów zamiast całych przestrzeni nazw.

Przedstawienie umieszczania zasobów ograniczonych do przestrzeni nazw

Użyj elementu ResourcePlacement (RP), aby dystrybuować dany zestaw zasobów w ramach określonej przestrzeni nazw z klastra centrum Fleet Manager na co najmniej jeden klaster członkowski. ResourcePlacement zapewnia szczegółową kontrolę nad tym, jak każdy z zasobów w przestrzeni nazw jest rozmieszczany wśród klastrów członkowskich.

Kluczowe cechy:

  • Zakres przestrzeni nazw: zarówno ResourcePlacement jak i zasoby, które wybiera, istnieją w tej samej przestrzeni nazw.
  • Selektywne: wybiera określone zasoby w przestrzeni nazw według typu, nazwy lub etykiet, a nie całych przestrzeni nazw.
  • Deklaratywne: używa tych samych zasad umieszczania co ClusterResourcePlacement dla jednolitego zachowania.

Kiedy należy używać usługi ResourcePlacement

ResourcePlacement jest idealnym rozwiązaniem w scenariuszach wymagających precyzyjnej kontroli nad zasobami w zakresie przestrzeni nazw:

  • Selektywna dystrybucja zasobów: wdrażanie określonych map konfiguracji, wpisów tajnych lub usług bez wpływu na całą przestrzeń nazw.
  • Środowiska wielodzierżawne: umożliwiają różnym zespołom niezależne zarządzanie zasobami we współdzielonych przestrzeniach nazw.
  • Zarządzanie konfiguracją: dystrybuuj konfiguracje specyficzne dla środowiska w różnych środowiskach klastra.
  • Zgodność i ład: zastosuj różne zasady do różnych typów zasobów w ramach tej samej przestrzeni nazw.
  • Progresywne wdrażanie: bezpieczne wdrażanie aktualizacji zasobów w klastrach przy użyciu strategii bez przestojów.

W środowiskach wieloklastrowych obciążenia często składają się zarówno z zasobów o zakresie klastra, jak i zasobów o zakresie przestrzeni nazw, które należy dystrybuować w różnych klastrach. Chociaż ClusterResourcePlacement (CRP) skutecznie obsługuje zasoby o zakresie klastra, zarządza również całą przestrzenią nazw i ich zawartością. Jednak niektóre scenariusze wymagają bardziej szczegółowej kontroli nad zasobami o zakresie przestrzeni nazw w istniejących przestrzeniach nazw.

ResourcePlacement (RP) rozwiązuje tę lukę, zapewniając:

  • Zarządzanie zasobami przestrzeni nazw: celowanie w konkretne zasoby w przestrzeni nazw bez wpływu na całą przestrzeń.
  • Elastyczność operacyjna: umożliwia zespołom niezależne zarządzanie różnymi zasobami w ramach tej samej przestrzeni nazw.
  • Funkcje uzupełniające: praca z CRP w celu zapewnienia kompletnego rozwiązania do zarządzania zasobami wieloklastrowymi.

Uwaga / Notatka

Można używać ResourcePlacement w połączeniu z ClusterResourcePlacement w trybie obsługującym tylko przestrzenie nazw. Na przykład użyj CRP do wdrożenia przestrzeni nazw, a RP do precyzyjnego zarządzania określonymi zasobami, takimi jak mapy ConfigMap specyficzne dla środowiska lub obiekty Secrets w obrębie tej przestrzeni nazw.

Składniki alokacji zasobów

Umieszczanie zasobów, niezależnie od zakresu (klastra lub przestrzeni nazw), składa się z następujących składników:

  • Selektory zasobów: wybierz zasoby, które chcesz uwzględnić za pomocą resourceSelectors.
  • Zasady rozmieszczania: określa sposób wybierania klastrów za pomocą placementType przy użyciu jednego z typów PickAll, PickFixed lub PickN.
  • Strategia wdrażania: kontroluj sposób wdrażania zasobów w wybranych klastrach za pomocą opcjonalnego strategy.

Ten przykładowy zasób ClusterResourcePlacement (CRP) rozmieszcza przestrzeń nazw my-app we wszystkich klastrach w flocie. Jeśli nie zdefiniujesz jawnej strategii, proces używa elementu RollingUpdate.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

Ten przykładowy zasób ResourcePlacement (RP) umieszcza obiekt ConfigMap oznaczony app=my-application w przestrzeni nazw my-app, umieszczając go w odpowiadającej przestrzeni nazw na dwóch nazwanych klastrach. Jeśli nie zdefiniujesz jawnej strategii, proces używa elementu RollingUpdate.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Selektory zasobów

Wybierz zasoby, używając co najmniej jednego elementu resourceSelectors w rozmieszczeniu. Każdy selektor zasobów może określać:

  • Grupa, wersja, rodzaj (GVK): typ zasobu Kubernetes do wybrania.
  • Nazwa: nazwa określonego zasobu.
  • Selektory etykiet: etykiety pasujące do wielu zasobów.

Zakres wyboru przestrzeni nazw

Jeśli używasz rozmieszczania o zakresie klastra do wybrania całej przestrzeni nazw, użyj pola selectionScope, aby określić, czy uwzględnić wszystkie zasoby podrzędne w tej przestrzeni nazw, czy umieścić tylko pustą przestrzeń nazw.

  • Zachowanie domyślne (gdy selectionScope nie zostanie określone): dystrybuuje przestrzeń nazw i wszystkie zasoby w niej.
  • NamespaceOnly: dystrybuuje tylko zasób przestrzeni nazw, bez żadnych zasobów zawartych w przestrzeni nazw. Ta opcja jest przydatna, gdy chcesz ustanowić przestrzenie nazw w klastrach, zarządzając poszczególnymi zasobami oddzielnie przy użyciu polecenia ResourcePlacement.

W tym przykładzie pokazano, jak dystrybuować tylko przestrzeń nazw bez jej zawartości.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Takie podejście umożliwia przepływ pracy, w którym administratorzy platformy używają ClusterResourcePlacement do ustanawiania przestrzeni nazw, podczas gdy zespoły aplikacji używają ResourcePlacement do dokładnej kontroli nad konkretnymi zasobami w tych przestrzeniach nazw.

Polityka dotycząca rozmieszczania

Rozmieszczanie zasobów usługi Fleet Manager obsługuje następujące typy zasad rozmieszczania, które określają sposób wybierania klastrów:

  • PickFixed umieszcza zasoby w klastrach członkowskich przy użyciu ich nazw klastrów.
  • Wybierzwszystkie umieszcza zasoby we wszystkich klastrach członkowskich lub wszystkich klastrach członkowskich spełniających kryteria. Te zasady są przydatne w przypadku umieszczania obciążeń infrastruktury, takich jak aplikacje do monitorowania klastra lub raportowania.
  • PickN to najbardziej elastyczna opcja umieszczania. Umożliwia wybrać klastry na podstawie afinity lub ograniczeń rozkładu topologii. Użyj tych zasad podczas rozmieszczania obciążeń w wielu podobnych klastrach, aby zapewnić utrzymanie dostępności.

Typ umiejscowienia PickFixed

Użyj PickFixed polecenia , aby wybrać klastry według nazwy. Podaj nazwy w tablicy clusterNames .

W tym przykładzie pokazano, jak dystrybuować przestrzeń nazw test-deployment na klastry członkowskie cluster1 i cluster2.

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

Ten przykładowy zasób ResourcePlacement (RP) umieszcza obiekt ConfigMap oznaczony app: my-application w przestrzeni nazw my-app, umieszczając go w odpowiadającej przestrzeni nazw na dwóch nazwanych klastrach.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

PickAll - rodzaj umieszczania

Służy PickAll do dystrybuowania zasobów we wszystkich klastrach członkowskich lub wszystkich klastrach spełniających określone kryteria.

Podczas tworzenia tego typu rozmieszczenia określ następujące typy powinowactwa klastra:

  • requiredDuringSchedulingIgnoredDuringExecution: ponieważ ta zasada jest wymagana podczas planowania, filtruje klastry na podstawie określonych kryteriów.

W tym przykładzie pokazano, jak dokonać repartycji przestrzeni nazw prod-deployment oraz wszystkich jej zasobów podrzędnych we wszystkich klastrach członkowskich oznaczonych etykietą environment: production.

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

Ten przykładowy element ResourcePlacement (RP) umieszcza obiekt ConfigMap oznaczony app: my-application w przestrzeni nazw my-app do pasującej przestrzeni nazw we wszystkich klastrach oznaczonych etykietą environment: production:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

Typ rozmieszczenia pickN

Użyj PickN do dystrybucji zasobów na konfigurowalną liczbę klastrów, uwzględniając zarówno preferencje koligacji, jak i ograniczenia dotyczące rozproszenia topologii.

Podczas tworzenia tego typu rozmieszczenia określ następujące typy powinowactwa klastra:

  • requiredDuringSchedulingIgnoredDuringExecution: ponieważ ta zasada jest wymagana podczas planowania, filtruje klastry na podstawie określonych kryteriów.
  • preferredDuringSchedulingIgnoredDuringExecution: jako że zasady te są preferowane, ale nie są wymagane podczas planowania, klasyfikuje klastry na podstawie określonych kryteriów.

Można ustawić zarówno wymagane, jak i preferowane preferencje. Wymagane koligacje uniemożliwiają umieszczanie w klastrach, które nie są zgodne. Preferowane powiązania określają kolejność dopasowanych klastrów.

PickN z powiązaniami

Korzystanie z affinity z zasadą rozmieszczania PickN działa tak samo jak korzystanie z affinity z harmonogramowaniem podów w pojedynczym klastrze Kubernetes.

W poniższym przykładzie pokazano, jak wdrożyć zasób 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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

Użyj ograniczeń rozkładu topologii, aby wymusić rozmieszczanie między domenami topologicznymi w celu spełnienia wymagań dotyczących dostępności.

Można skonfigurować zachowanie ograniczeń rozprzestrzeniania topologii, używając właściwości whenUnsatisfiable.

  • DoNotSchedule: jeśli nie można spełnić ograniczenia, nie powiodło się żądanie umieszczenia.
  • ScheduleAnyway: jeśli nie można spełnić ograniczenia, i tak umieść zasoby.

Poniższy przykład pokazuje, jak rozmieścić zasoby w wielu regionach platformy Azure, oraz jak próbować planować rozmieszczanie w klastrach członkowskich mających różne dni aktualizacji przy użyciu etykiety niestandardowej updateDay.

Gdy nie można zapewnić rozproszenia między regionami platformy Azure, rozmieszczenie kończy się niepowodzeniem. Jeśli ograniczenie updateDay nie zostanie spełnione, umieszczenie i tak nastąpi.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Aby uzyskać więcej informacji, zobacz dokumentację rozwiązania KubeFleet dotyczącą ograniczeń rozprzestrzeniania się topologii.

Wybieranie klastrów przy użyciu etykiet i właściwości

Inteligentne rozmieszczanie zasobów w usłudze Fleet Manager oferuje zestaw zaawansowanych kryteriów, których można użyć przy określaniu sposobu wyboru klastrów podczas korzystania z typów rozmieszczania PickN i PickAll. W tej sekcji dowiesz się, jak używać tych opcji do tworzenia zasad odpowiadających Twoim potrzebom.

Opcje polityki umieszczania

Poniższa tabela przedstawia dostępne pola zasad harmonogramowania dla każdego typu rozmieszczenia.

Dziedzina polityki PickFixed PickAll PickN
placementType ✅ ✅ ✅
affinity ❌ ✅ ✅
clusterNames ✅ ❌ ❌
numberOfClusters ❌ ❌ ✅
topologySpreadConstraints ❌ ❌ ✅

Etykiety klastrów członkowskich

Możesz nadać etykietę zasobowi MemberCluster w klastrze centralnym, tak jak każdemu zasobowi Kubernetes.

Ponadto usługa Fleet Manager automatycznie dodaje następujące etykiety tylko do odczytu do wszystkich klastrów członkowskich.

Etykieta Opis
fleet.azure.com/location Region Azure klastra (westus)
fleet.azure.com/resource-group Grupa zasobów Azure dla klastra (rg_prodapps_01)
fleet.azure.com/subscription-id Identyfikator subskrypcji Azure, w którym znajduje się klaster. Sformatowany jako UUID/GUID.
fleet.azure.com/cluster-name Nazwa klastra skojarzonego z zasobem klastra członkowskiego Fleet.
fleet.azure.com/member-name Nazwa klastra członkowskiego Fleet Manager, która odpowiada temu klastrowi.

Właściwości klastra

Użyj następujących właściwości jako części zasad rozmieszczania.

Nazwa właściwości Opis
kubernetes-fleet.io/node-count Dostępne węzły w klastrze członkowskim.
resources.kubernetes-fleet.io/total-cpu Łączna liczba jednostek zasobów procesora CPU klastra.
resources.kubernetes-fleet.io/allocatable-cpu Jednostki zasobów CPU klastra możliwe do przydzielenia.
resources.kubernetes-fleet.io/dostępne-cpu Dostępne jednostki zasobów procesora klastra.
resources.kubernetes-fleet.io/total-memory Łączna jednostka zasobów pamięci klastra.
resources.kubernetes-fleet.io/allocatable-memory Przydzielalne jednostki zasobów pamięci klastra.
resources.kubernetes-fleet.io/dostępna-pamięć Dostępne jednostki zasobów pamięci klastra.
kubernetes.azure.com/per-koszt-jednego-rdzenia-cpu (koszt na rdzeń CPU) Koszt na rdzeń procesora w klastrze.
kubernetes.azure.com/per-gb-memory-cost Koszt pamięci klastra na GiB.
kubernetes.azure.com/vm-sizes/{vm-sku-name}/count Dostępna liczba istniejących węzłów typu vm-sku-name w klastrze*.
Przykładowa nazwa SKU maszyny wirtualnej: NV16as_v4.
* W wersji zapoznawczej za pośrednictwem interfejsu API v1beta1.
kubernetes.azure.com/vm-sizes/{vm-sku-name}/capacity Liczba potencjalnych nowych węzłów typu vm-sku-name w regionie platformy Azure klastra*.
Przykładowa nazwa SKU maszyny wirtualnej: NV16as_v4.
* W wersji zapoznawczej za pośrednictwem interfejsu API v1beta1.

  • Jednostki zasobów platformy Kubernetes reprezentują właściwości procesora CPU i pamięci. Aby uzyskać więcej informacji, zobacz Resource units in Kubernetes (Jednostki zasobów na platformie Kubernetes).

  • Właściwości kosztowe to liczby dziesiętne, które określają koszt za godzinę w dolarach amerykańskich zasobów obliczeniowych platformy Azure używanych przez węzły w klastrze. Koszt oparty jest na publicznych cenach Azure.

Kryteria dopasowania wyboru

W przypadku używania właściwości klastra w kryteriach zasad określ:

  • Nazwa: nazwa właściwości, która jest jedną z właściwości wymienionych w tym artykule.

  • Operator: Operator, który wyraża warunek między ograniczeniem lub żądaną wartością a obserwowaną wartością w klastrze. Obecnie obsługiwane są następujące operatory:

    • Gt (Większe niż): obserwowana wartość danej właściwości klastra musi być większa niż wartość warunku, zanim będzie można ją wybrać do umieszczania zasobów.
    • Ge (Większe lub równe): obserwowana wartość danej właściwości klastra musi być większa lub równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.
    • Lt (Mniej niż): obserwowana wartość danej właściwości klastra musi być mniejsza niż wartość warunku, zanim będzie można ją wybrać do umieszczania zasobów.
    • Le (Mniejsze niż lub równe): obserwowana wartość danej właściwości klastra musi być mniejsza lub równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.
    • Eq (Równe): obserwowana wartość danej właściwości klastra musi być równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.
    • Ne (Nie równa się): obserwowana wartość danej właściwości klastra nie może być równa wartości określonej w warunku, zanim klaster będzie mógł zostać wybrany do rozmieszczenia zasobów.

    Jeśli używasz operatora Gt, , Ge, LtLe, Eqlub Ne, lista wartości w warunku powinna mieć dokładnie jedną wartość.

  • Wartości: lista wartości, które są możliwymi wartościami właściwości.

Fleet ocenia każdy klaster na podstawie właściwości, które określisz w warunku. Jeśli klaster nie spełnia warunków wymienionych w obszarze requiredDuringSchedulingIgnoredDuringExecution, flota wyklucza klaster z umieszczania zasobów.

Uwaga / Notatka

Jeśli klaster członkowski nie ma właściwości wyrażonej w warunku, automatycznie nie spełnia tego warunku.

Oto przykładowe zasady umieszczania, aby wybrać tylko klastry z co najmniej pięcioma węzłami.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Jak działa klasyfikacja właściwości

Gdy używasz preferredDuringSchedulingIgnoredDuringExecution, wszystkie klastry we flocie są uszeregowane według ich wartości w kolejności rosnącej lub malejącej. Wagi używane do zamawiania są obliczane na podstawie określonej wartości.

Sorter właściwości składa się z:

  • Nazwa: nazwa właściwości klastra.
  • Kolejność sortowania: kolejność sortowania może mieć wartość Ascending lub Descending. W przypadku używania Ascending kolejności preferowane są klastry składowe z niższymi obserwowanymi wartościami. W przypadku używania Descending kolejności preferowane są klastry członkowskie o wyższej obserwowanej wartości.

Aby uzyskać więcej informacji, zobacz dokumentację platformy KubeFleet dotyczącą planowania opartego na właściwościach.

Konfigurowanie strategii wdrażania

Umieszczanie zasobów w usłudze Fleet Manager używa domyślnej RollingUpdate strategii do kontrolowania sposobu dystrybucji zasobów do klastrów członkowskich.

W poniższym przykładzie wdrażanie odbywa się sekwencyjnie do każdego z klastrów członkowskich, odczekując co najmniej unavailablePeriodSeconds między klastrami.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Stan wdrożenia jest uznawany za pomyślny, jeśli wszystkie zasoby są poprawnie stosowane do klastra. Ten stan nie uwzględnia statusu zasobów podrzędnych, dlatego nie potwierdza, że zasobniki utworzone przez wdrożenie w klastrze członkowskim osiągną stan gotowości.

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą strategii wdrażania.

Używanie tolerancji

Możesz taintować klastry członkowskie, tak jak taintujesz węzły w klastrze.

Rozmieszczenie zasobów umożliwia wykorzystanie tolerancji, w których każda tolerancja 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 stosowana do tolerowania jednego lub więcej konkretnych niedoskonałości zastosowanych na węźle MemberCluster. Po tolerowaniu wszystkich zakłóceń Fleet Manager może dystrybuować zasoby do klastra członkowskiego.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą tolerancji.

Korzystanie z zasobów koperty

Klaster centrum Fleet Manager jest również klastrem Kubernetes. Najpierw wdroż w klastrze centralnym dowolny zasób, który chcesz dystrybuować. Takie podejście może prowadzić do:

  1. Niezamierzone skutki uboczne: Konfiguracje ValidatingWebhookConfigurations, MutatingWebhookConfigurations lub Kontrolery Admission stają się aktywne w klastrze hub, potencjalnie przechwytując i wpływając na operacje tego klastra.

  2. Zagrożenia bezpieczeństwa: zasoby RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) przeznaczone dla klastrów członkowskich mogą nadawać lub ograniczać uprawnienia w klastrze centralnym.

  3. Ograniczenia zasobów: elementy ResourceQuotas, FlowSchema lub LimitRanges zdefiniowane dla klastrów członkowskich obowiązują w klastrze centralnym.

Aby uniknąć niepotrzebnych skutków ubocznych, usługa Fleet Manager udostępnia niestandardowe zasoby kopert (ClusterResourceEnvelope i ResourceEnvelope) w celu opakowania obiektów i uniknięcia tych potencjalnych problemów.

Stosujesz zasób koperty do klastra centralnego, ale zawarte w nim zasoby są z niego wyodrębniane i stosowane, gdy dotrą do klastrów członkowskich.

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą obiektów koperty.

Określanie stanu umieszczania

Umieszczanie zasobów w systemie Fleet Manager oferuje dwa sposoby wyświetlania stanu w zależności od poziomu dostępu do klastra centralnego i wymagań:

  • Stan rozmieszczenia ClusterResourcePlacement: wyświetl stan rozmieszczenia bezpośrednio w zasobie o zasięgu klastra ClusterResourcePlacement. Użyj, gdy masz uprawnienia na poziomie klastra i musisz wyświetlić status dowolnego umiejscowienia w całej flocie.
  • Status rozmieszczenia zasobów: Wyświetl stan lokalizacji bezpośrednio w zasobie z zakresem przestrzeni nazw ResourcePlacement. Użyj tej funkcji, jeśli masz uprawnienia na poziomie przestrzeni nazw i musisz wyświetlić stan rozmieszczenia w zakresie przestrzeni nazw w całej flocie.

Wyświetlanie stanu rozmieszczenia zasobów klastra

Użyj polecenia , kubectl describe resourceplacement <rp-name> aby wyświetlić te informacje.

kubectl describe resourceplacement place-cmap-1
  • ClusterResourcePlacementStatus (wersja zapoznawcza): wyświetlanie stanu umieszczania za pośrednictwem zasobu o zakresie ClusterResourcePlacementStatus przestrzeni nazw. Użyj tego zasobu, gdy użytkownicy ograniczeni do przestrzeni nazw muszą wyświetlać stan rozmieszczenia bez przyznawania uprawnień na poziomie klastra. Aby uzyskać więcej informacji, zobacz sekcję ClusterResourcePlacementStatus.

Oba podejścia zawierają następujące informacje:

  • Warunki, które obecnie mają zastosowanie do umiejscowienia, w tym to, czy zostało ono pomyślnie zakończone.
  • Sekcja dotycząca stanu rozmieszczenia dla każdego klastra członkowskiego, która pokazuje stan wdrożenia w tym klastrze.

Użyj statusu ClusterResourcePlacement

Poniższy przykład pokazuje wyświetlanie stanu bezpośrednio w ClusterResourcePlacement, który wdrożył przestrzeń nazw test i obiekt ConfigMap test-1 w dwóch klastrach członkowskich przy użyciu PickN. Umieszczanie zostało ukończone pomyślnie, a zasoby zostały umieszczone w klastrach aks-member-1 i aks-member-2.

Użyj polecenia , kubectl describe clusterresourceplacement <crp-name> aby wyświetlić te informacje.

kubectl describe clusterresourceplacement crp-1

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1
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

Korzystanie z zasobu ClusterResourcePlacementStatus (wersja zapoznawcza)

Zasób ClusterResourcePlacementStatus jest ograniczony do przestrzeni nazw i udostępnia stan rozmieszczenia dla odpowiadającego mu obiektu ClusterResourcePlacement o zakresie klastra. Ten zasób umożliwia użytkownikom przestrzeni nazw bez uprawnień na poziomie klastra odczytywanie stanu.

Ważna

Zasób ClusterResourcePlacementStatus oraz pole StatusReportingScope są dostępne jako funkcja zapoznawcza w wersji interfejsu API placement.kubernetes-fleet.io/v1beta1. Nie są dostępne w interfejsie API placement.kubernetes-fleet.io/v1.

Aby użyć tego podejścia, skonfiguruj element ClusterResourcePlacement za pomocą statusReportingScope: NamespaceAccessible, korzystając z interfejsu API v1beta1.

Gdy ustawisz statusReportingScope na NamespaceAccessible, możesz określić tylko jeden selektor zasobów przestrzeni nazw i nie możesz go zmienić po utworzeniu.

Konfigurowanie Statusu Rozmieszczenia Zasobów Klastra

Aby użyć tej funkcji, określ wersję interfejsu v1beta1 API w pliku ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

Wyświetlanie parametru ClusterResourcePlacementStatus

Stan można wyświetlić za pomocą kubectl describe polecenia :

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Dane wyjściowe zawierają te same informacje o stanie co ClusterResourcePlacement, ale są dostępne dla użytkowników posiadających uprawnienia na poziomie przestrzeni nazw.

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą sposobu zrozumienia wyniku umieszczania.

Wyzwalacze zmiany położenia

Mechanizm harmonogramowania Fleet Manager traktuje priorytetowo stabilność istniejących przydziałów zasobów. Ten priorytet ogranicza liczbę zmian polegających na usunięciu zasobu i ponownym zaplanowaniu go.

Następujące scenariusze mogą wyzwalać zmiany rozmieszczenia:

  • Zmiany zasad umieszczania zasobów (ClusterResourcePlacement lub ResourcePlacement) mogą wyzwalać usuwanie i ponowne rozmieszczanie zasobu.
    • Operacje skalowania w poziomie (zwiększanie numberOfClusters bez żadnych innych zmian) powodują, że obciążenia robocze są umieszczane wyłącznie w nowych klastrach i nie wpływają na istniejące rozmieszczenie.
  • Zmiany klastra członkowskiego, w tym:
    • Nowy klaster członkowski, który staje się uprawniony i spełnia zasady rozmieszczania, na przykład politykę PickAll.
    • Usunięcie klastra członkowskiego z floty. W zależności od polityki, scheduler próbuje umieścić wszystkie objęte zasoby w pozostałych klastrach, nie wpływając na istniejące umiejscowienie.

Aktualizacja wybranych zasobów (na przykład modyfikacja elementu Deployment) lub aktualizacja elementu resourceSelector w rozmieszczeniu zasobów powoduje, że Fleet Manager stopniowo wdraża istniejące rozmieszczenia, ale nie powoduje ponownego planowania zasobu (to znaczy zmiany wybranych klastrów).

Praca z ResourcePlacement i ClusterResourcePlacement razem

Chociaż ClusterResourcePlacement zakłada się, że przestrzenie nazw reprezentują granice aplikacji, wzorce użycia w świecie rzeczywistym są często bardziej złożone. Organizacje często używają przestrzeni nazw jako granic zespołu, a nie granic aplikacji. Takie podejście prowadzi do kilku wyzwań, na które ResourcePlacement bezpośrednio odpowiada:

Przestrzenie nazw wielu aplikacji: w wielu organizacjach jedna przestrzeń nazw zawiera wiele niezależnych aplikacji należących do tego samego zespołu. Te aplikacje mogą mieć następujące zastosowania:

  • Różne wymagania dotyczące cyklu życia. Na przykład jedna aplikacja może wymagać częstych aktualizacji, podczas gdy inna pozostaje stabilna.
  • Różne potrzeby dotyczące lokalizacji klastra. Na przykład aplikacje programistyczne i produkcyjne.
  • Niezależne wymagania dotyczące skalowania i zasobów.
  • Oddzielne wymagania dotyczące zgodności lub zarządzania.

Indywidualne decyzje dotyczące planowania: wiele obciążeń, szczególnie zadań sztucznej inteligencji/uczenia maszynowego, wymaga indywidualnych decyzji dotyczących planowania:

  • Zadania sztucznej inteligencji: obciążenia uczenia maszynowego często składają się z krótkoterminowych zadań intensywnie korzystających z zasobów, które muszą być zaplanowane na podstawie dostępności zasobów klastra, dostępności procesora GPU lub lokalizacji danych.
  • Obciążenia wsadowe: różne zadania wsadowe w tej samej przestrzeni nazw mogą być przeznaczone dla różnych typów klastrów na podstawie wymagań obliczeniowych.

Pełna kontrola zespołu aplikacji: ResourcePlacement zapewnia zespołom aplikacji bezpośrednią kontrolę nad umieszczaniem zasobów bez konieczności interwencji zespołu platformy:

  • Operacje samoobsługowe: zespoły mogą zarządzać własnymi strategiami dystrybucji zasobów.
  • Niezależne cykle wdrażania: różne aplikacje w przestrzeni nazw mogą mieć niezależne harmonogramy wdrażania.
  • Szczegółowe możliwości przesłonięcia: Zespoły mogą dostosowywać konfiguracje zasobów dla klastra bez wpływu na inne aplikacje w przestrzeni nazw.

To szczegółowe podejście gwarantuje, że ResourcePlacement można dostosować się do różnych struktur organizacyjnych i wzorców obciążeń przy zachowaniu prostoty i mocy struktury planowania Floty.

Kluczowe różnice między ResourcePlacement a ClusterResourcePlacement

W poniższej tabeli przedstawiono kluczowe różnice między elementami ResourcePlacement i ClusterResourcePlacement:

Aspekt ResourcePlacement (RP) ClusterResourcePlacement (CRP)
Scope Tylko zasoby w zakresie przestrzeni nazw Zasoby w zakresie klastra (zwłaszcza przestrzenie nazw i ich zawartość)
Zasób Obiekt API ograniczony do przestrzeni nazw Obiekt interfejsu API o przestrzeni zakresu klastra
Granica zaznaczenia Ograniczone do zasobów w tej samej przestrzeni nazw co rp Może wybrać dowolny zasób w zakresie klastra
Typowe przypadki użycia Zadania AI/ML, poszczególne obciążenia robocze, konkretne ConfigMaps/Secrets, które wymagają niezależnych decyzji dotyczących rozmieszczania Pakiety aplikacji, całe przestrzenie nazw, zasady obejmujące cały klaster
Własność zespołu Właściciele przestrzeni nazw i programiści Operatory platformy

Oba ResourcePlacement i ClusterResourcePlacement posiadają te same podstawowe możliwości we wszystkich innych aspektach, których nie wymieniono w tabeli różnic.

Przykładowy scenariusz korzystający z rozwiązania ResourcePlacement i ClusterResourcePlacement

ResourcePlacement współpracuje z ClusterResourcePlacement (CRP) w celu zapewnienia kompletnego rozwiązania do zarządzania zasobami wieloklastrowymi. Zrozumienie tej relacji ma kluczowe znaczenie dla efektywnego zarządzania flotą.

Ważna

ResourcePlacement może umieszczać tylko zasoby o zasięgu przestrzeni nazw w klastrach, które mają już docelową przestrzeń nazwową. Użyj ClusterResourcePlacement do ustanawiania przestrzeni nazw.

Typowy przepływ pracy:

  1. Administratorzy platformy: użyjcie ClusterResourcePlacement, aby wdrażać przestrzenie nazw w całej flocie.
  2. Zespoły aplikacyjne: używajcie ResourcePlacement, aby zarządzać określonymi zasobami w tych utworzonych przestrzeniach nazw.

Poniższe przykłady pokazują, jak skoordynować CRP i RP.

Administrator platformy: utwórz przestrzeń nazw przy użyciu polecenia ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Zespół aplikacji: zarządzanie określonymi zasobami w przestrzeni nazw przy użyciu polecenia ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Najlepsze praktyki dla ResourcePlacement i ClusterResourcePlacement

Korzystając z ResourcePlacement z ClusterResourcePlacement, postępuj zgodnie z tymi najlepszymi praktykami:

  • Najpierw ustanów przestrzenie nazw: zawsze wdrażaj przestrzenie nazw za pośrednictwem protokołu CRP przed utworzeniem ResourcePlacement obiektów.
  • Monitorowanie zależności: użyj monitorowania floty, aby upewnić się, że listy CSP na poziomie przestrzeni nazw są w dobrej kondycji przed wdrożeniem zależnych adresów IP.
  • Skoordynuj zasady: Uzgodnij zasady rozmieszczania CRP i RP, aby uniknąć konfliktów. Jeśli na przykład CRP umieszcza przestrzeń nazw w klastrach A, B i C, RP może być kierowany do dowolnego podzbioru tych klastrów.
  • Granice zespołowe: użyj CRP dla zasobów zarządzanych przez platformę (przestrzeni nazw, RBAC) i RP dla zasobów zarządzanych przez aplikację (konfiguracji aplikacji, sekrety).

Skoordynowane podejście zapewnia, że ResourcePlacement dostarcza zespołom potrzebną elastyczność, jednocześnie utrzymując podstawową infrastrukturę zarządzaną przez operatorów platformy.

Wybieranie, umieszczanie i wdrażanie zasobów

ResourcePlacement używa tych samych wzorców umieszczania co ClusterResourcePlacement:

  • Zasady umieszczania: Zasady PickAll, PickFixed i PickN działają identycznie dla obu interfejsów API.
  • Strategia wdrażania: kontrolowanie sposobu propagacji aktualizacji między klastrami przy użyciu tych samych mechanizmów aktualizacji stopniowej.
  • Stan i możliwość obserwowania: Monitorowanie postępu wdrażania przy użyciu polecenia kubectl describe resourceplacement <name> -n <namespace>.
  • Funkcje zaawansowane: używaj tolerancji, przesłonięć zasobów, ograniczeń rozprzestrzeniania topologii i reguł koligacji.

Kluczową różnicą jest zakres wyboru zasobów . Podczas gdy ClusterResourcePlacement zazwyczaj wybiera całe przestrzenie nazw i ich zawartość, ResourcePlacement zapewnia szczegółową kontrolę nad poszczególnymi zasobami w zakresie przestrzeni nazw.

Następne kroki

  • Last updated on