Introduzione al posizionamento intelligente delle risorse di Azure Kubernetes Fleet Manager

Si applica a ✔️ Fleet Manager con cluster hub

La gestione delle risorse Kubernetes in più cluster presenta sfide significative sia per gli amministratori della piattaforma che per gli sviluppatori di applicazioni. Man mano che le organizzazioni ridimensionano l'infrastruttura Kubernetes oltre un singolo cluster, spesso riscontrano complessità correlate alla distribuzione, alla coerenza e al sovraccarico manuale della gestione delle risorse. L'approccio tradizionale di gestione di ogni cluster crea in modo indipendente i silo operativi che diventano sempre più difficili da mantenere man mano che le dimensioni della flotta aumentano.

Gli amministratori della piattaforma spesso devono distribuire risorse Kubernetes in più cluster per diversi motivi, tra cui:

• Gestione del controllo di accesso tramite ruoli e associazioni di ruolo in più cluster.
• Esecuzione di applicazioni di infrastruttura, ad esempio Prometheus o Flux, che devono trovarsi in tutti i cluster.

Gli sviluppatori di applicazioni spesso devono distribuire le risorse di Kubernetes in più cluster per diversi motivi, ad esempio:

• Distribuzione di un'applicazione di gestione video in più cluster in aree diverse per un'esperienza di visione a bassa latenza.
• Distribuzione di un'applicazione di carrello acquisti in due aree abbinate per consentire ai clienti di continuare a acquistare durante un'interruzione di un'area.
• Distribuzione di un'applicazione di calcolo batch in cluster con pool di nodi spot economici disponibili.

È noioso e potenzialmente soggetto a errori per creare, aggiornare e tenere traccia manualmente delle risorse Kubernetes in più cluster.

In questo articolo viene illustrato come usare la funzionalità di posizionamento intelligente delle risorse di Fleet Manager per gestire la distribuzione delle risorse Kubernetes con ambito cluster e spazio dei nomi tra cluster membri in una flotta.

La funzionalità di posizionamento delle risorse di Fleet Manager si basa sul progetto KUBeFleet CNF.

Panoramica del processo di posizionamento delle risorse

L'uso del posizionamento intelligente delle risorse di Fleet Manager prevede questi passaggi:

1. Gestione temporanea delle risorse nel cluster hub: usare distribuzione continua, GitOps o simile per applicare i manifesti per le risorse per le distribuzioni nel cluster hub di Fleet Manager.
2. Creare un posizionamento delle risorse: creare un manifesto di posizionamento che selezioni la risorsa e definisca un criterio usato per selezionare i cluster membro che riceveranno la risorsa.
3. Applicare il posizionamento delle risorse nel cluster hub: accettare il manifesto del posizionamento e applicarlo al cluster hub per avviare la distribuzione della risorsa.
4. Fleet Manager pianifica le risorse: Fleet Manager osserva il posizionamento delle risorse e l'ambito selezionato ed esegue la distribuzione delle risorse.
5. Osservare la distribuzione tramite il posizionamento delle risorse: eseguire una query sul posizionamento delle risorse nel cluster hub per osservare lo stato della risorsa durante la distribuzione.

Fleet Manager offre un'esperienza del portale di Azure per il posizionamento delle risorse che offre una rappresentazione più visiva dell'implementazione.

Componenti di posizionamento delle risorse

Un posizionamento delle risorse, indipendentemente dall'ambito (cluster o spazio dei nomi) è costituito dai componenti seguenti:

• Selettori di risorse: selezionare le risorse da includere tramite resourceSelectors.
• Criteri di posizionamento: definisce come selezionare i cluster tramite placeType utilizzando uno dei tipi PickAll, PickFixed o PickN.
• Strategia di implementazione: controllare la modalità di implementazione delle risorse nei cluster selezionati includendo un oggetto facoltativo strategy.

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   

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

Selettori di risorse

Selezionare le risorse usando una o più resourceSelectors risorse in una posizione. Ogni selettore di risorse può specificare:

• Gruppo, Versione, Tipo (GVK): tipo di risorsa Kubernetes da selezionare.
• Nome: nome di una risorsa specifica.
• Selettori di etichetta: le etichette corrispondono a più risorse.

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

Criteri di posizionamento

I tipi di criteri di posizionamento seguenti sono disponibili per controllare il modo in cui i cluster vengono selezionati dal posizionamento delle risorse di Fleet Manager:

• PickFixed inserisce le risorse nei cluster membri usando il nome del cluster.
• PickAll colloca le risorse su tutti i cluster membri, o su tutti i cluster membri che soddisfano un determinato criterio. Questi criteri sono utili per posizionare carichi di lavoro dell'infrastruttura, ad esempio il monitoraggio del cluster o le applicazioni di creazione report.
• PickN è l'opzione di posizionamento più flessibile e consente di selezionare i cluster in base ai vincoli di diffusione di affinità o topologia ed è utile quando si distribuiscono carichi di lavoro in più cluster simili per garantire che la disponibilità venga mantenuta.

Tipo di posizionamento PickFixed

Usare PickFixed per selezionare i cluster in base al nome, specificando i nomi nella clusterNames matrice.

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

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

Tipo di posizionamento PickAll

Usare PickAll per distribuire le risorse in tutti i cluster membri o in tutti i cluster corrispondenti a un criterio specificato.

Quando si crea questo tipo di posizionamento, è possibile specificare i tipi di affinità cluster seguenti:

• requiredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è necessario durante la pianificazione, filtra i cluster in base ai criteri specificati.

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

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

Tipo di posizionamento PickN

Usare PickN per distribuire le risorse in un numero configurabile di cluster in base alle affinità e ai vincoli di distribuzione della topologia.

Quando si crea questo tipo di posizionamento, è possibile specificare i tipi di affinità cluster seguenti:

• requiredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è necessario durante la pianificazione, filtra i cluster in base ai criteri specificati.
• preferredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è preferibile, ma non necessario durante la pianificazione, classifica i cluster in base ai criteri specificati.

È possibile impostare affinità obbligatorie e preferite. Le affinità obbligatorie impediscono il posizionamento ai cluster che non corrispondono. Le affinità preferite forniscono l'ordinamento dei cluster corrispondenti.

PickN con affinità

L'uso delle affinità con una politica di posizionamento PickN funziona in modo simile all'uso delle affinità con la schedulazione dei pod in un singolo cluster Kubernetes.

L'esempio seguente illustra come distribuire una risorsa in tre cluster. Solo i cluster con l'etichetta critical-allowed: "true" sono destinazioni di selezione host valide e la preferenza viene assegnata ai cluster con l'etichetta 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 con vincoli di distribuzione della topologia

Usare i vincoli di distribuzione della topologia per forzare il posizionamento tra i limiti della topologia per soddisfare i requisiti di disponibilità.

È possibile configurare il comportamento dei vincoli di distribuzione della topologia usando la whenUnsatisfiable proprietà :

• DoNotSchedule: se il vincolo non può essere soddisfatto, non eseguire la richiesta di posizionamento.
• ScheduleAnyway: se il vincolo non può essere soddisfatto, inserire le risorse in ogni modo.

L'esempio seguente illustra come distribuire le risorse in più aree di Azure e tenta di pianificare tra cluster membri con giorni di aggiornamento diversi usando un'etichetta updateDaypersonalizzata .

Quando non è possibile soddisfare lo spread dell'area di Azure, il posizionamento avrà esito negativo. Se il updateDay vincolo non viene soddisfatto, il posizionamento verrà comunque eseguito.

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

Per altre informazioni, vedere la documentazione di KubeFleet sui vincoli di distribuzione della topologia.

Selezionare i cluster usando etichette e proprietà

Il posizionamento intelligente delle risorse di Fleet Manager offre un set di criteri avanzati che è possibile usare per determinare la modalità di selezione dei cluster quando si usano i PickN tipi di posizionamento e PickAll . In questa sezione verrà illustrato come usare queste opzioni per creare criteri in base alle proprie esigenze.

Opzioni dei criteri di posizionamento

I campi dei criteri di pianificazione disponibili per ogni tipo di posizionamento sono visualizzati nella tabella.

Etichette dei membri del cluster

La MemberCluster risorsa nel cluster hub può essere etichettata come qualsiasi risorsa Kubernetes.

Inoltre, Fleet Manager aggiunge automaticamente le etichette di sola lettura seguenti a tutti i cluster membri.

Proprietà del cluster

Le proprietà seguenti sono disponibili per l'uso come parte dei criteri di posizionamento.

• Le proprietà della CPU e della memoria sono rappresentate come unità di risorse Kubernetes.

• Le proprietà dei costi sono decimali, che rappresentano il costo orario in dollari USA per i servizi di calcolo di Azure usati per i nodi all'interno del cluster. Il costo è basato sui prezzi pubblici di Azure.

Criteri di corrispondenza per la selezione

Quando si usano le proprietà del cluster nei criteri di un criterio, specificare:

• Nome: nome della proprietà, che corrisponde a una delle proprietà elencate in questo articolo.

• Operatore: operatore usato per esprimere la condizione tra il vincolo/valore desiderato e il valore osservato nel cluster. Attualmente sono supportati gli operatori seguenti:

  • Gt (Maggiore di): il valore osservato di un cluster della proprietà specificata deve essere maggiore del valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Ge (Maggiore o uguale a): il valore osservato di un cluster della proprietà specificata deve essere maggiore o uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Lt (Minore di): il valore osservato di un cluster della proprietà specificata deve essere minore del valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Le (Minore o uguale a): il valore osservato di un cluster della proprietà specificata deve essere minore o uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Eq (Uguale a): il valore osservato di un cluster della proprietà specificata deve essere uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Ne (Diverso da): il valore osservato di un cluster della proprietà specificata non deve essere uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.

  Se si usa l'operatore Gt, GeLt, Le, Eq o Ne, l'elenco di valori nella condizione deve avere un valore esatto.

• Valori: elenco di valori possibili della proprietà.

Fleet valuta ogni cluster in base alle proprietà specificate nella condizione. Il mancato rispetto delle condizioni elencate in requiredDuringSchedulingIgnoredDuringExecution esclude un cluster membro dal posizionamento delle risorse.

Ecco un esempio di criteri di posizionamento che consente di selezionare solo cluster con cinque o più nodi.

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"

Come funziona la classificazione delle proprietà

Quando viene usato preferredDuringSchedulingIgnoredDuringExecution, un ordinamento delle proprietà classifica tutti i cluster della flotta in base ai valori in ordine crescente o decrescente. I pesi usati per l'ordinamento vengono calcolati in base al valore specificato.

Un ordinamento delle proprietà è costituito da:

• Nome: nome della proprietà del cluster.
• Ordinamento: l'ordinamento può essere Ascending o Descending. Quando si usa l'ordine Ascending, è preferibile usare cluster membri con valori osservati inferiori. Quando si usa l'ordine Descending, è preferibile utilizzare cluster membri con un valore osservato superiore.

Per altre informazioni, vedere la documentazione di KubeFleet sulla pianificazione basata su proprietà.

Configurazione della strategia di distribuzione

Il posizionamento delle risorse di Fleet Manager usa una strategia predefinita RollingUpdate per controllare il modo in cui le risorse vengono distribuite ai cluster membri.

Nell'esempio seguente la distribuzione viene effettuata in sequenza a ogni cluster membro, in attesa almeno unavailablePeriodSeconds tra i cluster.

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

Lo stato di implementazione viene considerato corretto se tutte le risorse sono state applicate correttamente al cluster. Questo stato non si verifica a catena dello stato delle risorse figlio, quindi, ad esempio, non conferma che i pod creati in un cluster membro da una distribuzione diventano pronti.

Per altre informazioni, vedere la documentazione sulle strategie di implementazione.

Utilizzo delle tollerazioni

I cluster membri possono essere marcati nello stesso modo in cui i nodi in un cluster possono essere marcati.

I posizionamenti delle risorse supportano l'uso di tolleranze in cui ogni tollerazione è costituita dai campi seguenti:

• key: chiave della tolleranza.
• value: valore della tolleranza.
• effect: effetto della tolleranza, ad esempio NoSchedule.
• operator: operatore della tolleranza, ad esempio Exists o Equal.

Ogni tolleranza viene utilizzata per tollerare una o più contaminazioni specifiche applicate su MemberCluster. Una volta tollerati tutti i taints, Fleet Manager può distribuire le risorse al cluster membro.

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

Per altre informazioni, vedere la documentazione sulle tolerazioni.

Uso delle risorse envelope

È importante comprendere che il cluster hub Fleet Manager è anche un cluster Kubernetes. Qualsiasi risorsa da distribuire viene prima applicata al cluster hub, che può portare a:

1. Effetti collaterali imprevisti: ValidatingWebhookConfigurations, MutatingWebhookConfigurations o Admission Controllers diventano attivi nel cluster hub, potenzialmente intercettando e influenzando le operazioni del cluster hub.

2. Rischi per la sicurezza: le risorse RBAC (Ruoli, ClusterRoles, RoleBindings, ClusterRoleBindings) destinate ai cluster membri potrebbero concedere o limitare le autorizzazioni nel cluster hub.

3. Limitazioni delle risorse: ResourceQuotas, FlowSchema o LimitRanges definiti per i cluster membri hanno effetto sul cluster hub.

Per evitare effetti collaterali non necessari, Fleet Manager fornisce risorse buste personalizzate (ClusterResourceEnvelope e ResourceEnvelope) per eseguire il wrapping degli oggetti per evitare questi potenziali problemi.

La risorsa envelope viene applicata al cluster hub, ma le risorse che contiene vengono estratte e applicate quando raggiungono i cluster membri.

Per altre informazioni, vedere la documentazione sugli oggetti envelope.

Determinare lo stato di posizionamento

Il posizionamento delle risorse di Fleet Manager offre due modi per visualizzare lo stato a seconda del livello di accesso e dei requisiti del cluster hub:

kubectl describe resourceplacement place-cmap-1

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

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

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

Trigger di modifica del posizionamento

L'utilità di pianificazione di Fleet Manager assegna priorità alla stabilità dei posizionamenti delle risorse esistenti, che possono limitare il numero di modifiche che causano la rimozione e la riprogrammazione di una risorsa.

Gli scenari seguenti possono attivare modifiche di selezione host:

• Le modifiche ai criteri di posizionamento nel posizionamento delle risorse (ClusterResourcePlacement o ResourcePlacement) possono attivare la rimozione e la riprogrammazione di una risorsa.
  • Le operazioni di aumento (incrementando numberOfClusters senza altre modifiche) collocano i carichi di lavoro solo nei nuovi cluster e non influiscono sui posizionamenti esistenti.
• Modifiche del cluster membro, tra cui:
  • Un nuovo cluster membro diventa idoneo e soddisfa la politica di posizionamento, ad esempio una politica PickAll.
  • Un cluster membro viene rimosso dalla flotta. A seconda della politica, lo scheduler tenta di collocare tutte le risorse interessate nei cluster rimanenti senza influire sulle allocazioni esistenti.

L'aggiornamento delle risorse selezionate (ad esempio la modifica di un Deployment) o l'aggiornamento resourceSelector in un posizionamento delle risorse fa sì che Fleet Manager implementi gradualmente i posizionamenti esistenti, ma non attiva la riprogrammazione (ad esempio la modifica dei cluster selezionati) della risorsa.

Uso di ResourcePlacement e ClusterResourcePlacement insieme

Anche se ClusterResourcePlacement si presuppone che gli spazi dei nomi rappresentino i limiti dell'applicazione, i modelli di utilizzo reali sono spesso più complessi. Le organizzazioni usano spesso i namespace come limiti del team anziché i limiti dell'applicazione, causando diversi problemi che ResourcePlacement affronta direttamente.

Spazi dei nomi multi-applicazione: in molte organizzazioni, un singolo spazio dei nomi contiene più applicazioni indipendenti di proprietà dello stesso team. Queste applicazioni potrebbero avere:

• Requisiti del ciclo di vita diversi (un'applicazione potrebbe richiedere aggiornamenti frequenti, mentre un'altra rimane stabile).
• Esigenze di posizionamento dei cluster diverse (sviluppo e applicazioni di produzione).
• Requisiti di scalabilità e risorse indipendenti.
• Requisiti di conformità o governance separati.

Decisioni di pianificazione individuali: molti carichi di lavoro, in particolare i processi di intelligenza artificiale/Machine Learning, richiedono decisioni di pianificazione individuali:

• Processi di intelligenza artificiale: i carichi di lavoro di Machine Learning spesso sono costituiti da processi a elevato utilizzo di risorse di breve durata che devono essere pianificati in base alla disponibilità delle risorse del cluster, alla disponibilità gpu o alla località dei dati.
• Carichi di lavoro batch: processi batch diversi all'interno dello stesso spazio dei nomi possono essere destinati a tipi di cluster diversi in base ai requisiti di calcolo.

Completare il controllo del team dell'applicazione: ResourcePlacement fornisce ai team delle applicazioni il controllo diretto sul posizionamento delle risorse senza richiedere l'intervento del team della piattaforma:

• Operazioni self-service: I team possono gestire le proprie strategie di distribuzione delle risorse.
• Cicli di distribuzione indipendenti: applicazioni diverse all'interno di uno spazio dei nomi possono avere pianificazioni di implementazione indipendenti.
• Funzionalità di override granulari: Teams può personalizzare le configurazioni delle risorse per ogni cluster senza influire sulle altre applicazioni nello spazio dei nomi.

Questo approccio granulare garantisce che ResourcePlacement possa adattarsi a diverse strutture organizzative e modelli di carico di lavoro mantenendo al tempo stesso la semplicità e la potenza del framework di pianificazione fleet.

Differenze principali tra ResourcePlacement e ClusterResourcePlacement

Nella tabella seguente sono evidenziate le differenze principali tra ResourcePlacement e ClusterResourcePlacement:

Entrambe ResourcePlacement e ClusterResourcePlacement condividono le stesse funzionalità di base per tutti gli altri aspetti non elencati nella tabella delle differenze.

Scenario di esempio con ResourcePlacement e ClusterResourcePlacement

ResourcePlacement è progettato per funzionare in coordinamento con ClusterResourcePlacement (CRP) per fornire una soluzione completa di gestione delle risorse multi-cluster. Comprendere questa relazione è fondamentale per una gestione efficace della flotta.

Flusso di lavoro tipico:

1. Amministratori della piattaforma: usare ClusterResourcePlacement per distribuire namespace nella rete.
2. Application Teams: Utilizza ResourcePlacement per gestire risorse specifiche all'interno di tali spazi dei nomi stabiliti.

Gli esempi seguenti illustrano come coordinare CRP e RP:

Amministratore della piattaforma: creare lo spazio dei nomi usando ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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.

Team delle applicazioni: gestiona risorse specifiche all'interno dello spazio dei nomi usando ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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

Procedure consigliate per ResourcePlacement e ClusterResourcePlacement

Quando si usa ResourcePlacement con ClusterResourcePlacement, seguire queste procedure consigliate:

• Definire prima gli spazi dei nomi: assicurarsi sempre che gli spazi dei nomi vengano implementati tramite CRP prima di creare ResourcePlacement oggetti.
• Monitorare le dipendenze: usare il monitoraggio della flotta per assicurarsi che i CRP a livello di spazio dei nomi siano integri prima di distribuire RPs dipendenti.
• Politiche coordinate: allineare le politiche di posizionamento CRP e RP per evitare conflitti, ad esempio se CRP posiziona lo spazio dei nomi nei cluster A, B, C, RP può puntare a qualsiasi sottoinsieme di tali cluster.
• Limiti del team: usare CRP per le risorse gestite dalla piattaforma (namespace, RBAC) e RP per le risorse gestite dall'applicazione (configurazioni app, segreti).

Questo approccio coordinato garantisce che ResourcePlacement fornisca la flessibilità di cui i team hanno bisogno mentre viene mantenuta l'infrastruttura di base gestita dagli operatori della piattaforma.

Selezione, posizionamento e implementazione delle risorse

ResourcePlacement usa gli stessi modelli di posizionamento di ClusterResourcePlacement:

• Criteri di posizionamento: PickAll, PickFixede PickN i criteri funzionano in modo identico per entrambe le API.
• Strategia di implementazione: controllare la propagazione degli aggiornamenti tra cluster con gli stessi meccanismi di aggiornamento in sequenza.
• Stato e osservabilità: monitorare lo stato della distribuzione usando kubectl describe resourceplacement <name> -n <namespace>.
• Funzionalità avanzate: usare tolerazioni, override delle risorse, vincoli di diffusione della topologia e regole di affinità.

La differenza principale è nell'ambito di selezione delle risorse . Anche se ClusterResourcePlacement in genere seleziona interi spazi dei nomi e il relativo contenuto, ResourcePlacement fornisce un controllo granulare sulle singole risorse con ambito spazio dei nomi.

:::zone-end

Passaggi successivi

• Usare il posizionamento delle risorse cluster per distribuire i carichi di lavoro in più cluster.
• Uso di ResourcePlacement per deplorare risorse con ambito namespace.
• Posizionamento intelligente delle risorse Kubernetes tra cluster in base alle proprietà dei cluster membri.
• Controllo della rimozione e delle interruzioni per il posizionamento delle risorse del cluster.
• Definizione di una strategia di implementazione per un posizionamento delle risorse cluster.
• Domande frequenti sul posizionamento delle risorse del cluster.