Condividi tramite

Uso di ResourcePlacement per implementare risorse con ambito spazio dei nomi (anteprima)

Questo articolo descrive l'API ResourcePlacement , che consente un controllo granulare sulle risorse Kubernetes con ambito spazio dei nomi tra cluster membri usando Azure Kubernetes Fleet Manager.

Importante

Le funzionalità di anteprima di Azure Kubernetes Fleet Manager sono disponibili in modalità self-service, su base volontaria. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le versioni di anteprima di Azure Kubernetes Fleet Manager sono parzialmente coperte dall'assistenza clienti su base di miglior sforzo. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione.

Informazioni generali

ResourcePlacement è un'API con ambito spazio dei nomi che consente la selezione dinamica e la propagazione multicluster di risorse con ambito spazio dei nomi. Fornisce un controllo granulare sul modo in cui le risorse specifiche all'interno di uno spazio dei nomi vengono distribuite tra cluster membri in una flotta.

Importante

ResourcePlacement usa la versione dell'API placement.kubernetes-fleet.io/v1beta1 ed è attualmente in anteprima. Alcune funzionalità illustrate in questo articolo, ad esempio selectionScope in ClusterResourcePlacement, fanno anche parte dell'API v1beta1 e non sono disponibili nell'API v1.

Caratteristiche chiave:

  • Ambito spazio dei nomi: l'oggetto ResourcePlacement e le risorse gestite esistono all'interno dello stesso spazio dei nomi.
  • Selettiva: può specificare risorse specifiche in base al tipo, al nome o alle etichette anziché a interi spazi dei nomi.
  • Dichiarativo: usa gli stessi modelli di posizionamento di ClusterResourcePlacement per un comportamento coerente.

Un ResourcePlacement oggetto è costituito da tre componenti principali:

  • Selettori di risorse: Definire quali risorse con ambito di spazio dei nomi includere.
  • Criteri di posizionamento: determinano i cluster di destinazione usando PickAll, PickFixed o PickN strategie.
  • Strategia di implementazione: controllare la propagazione delle modifiche tra i cluster selezionati.

Quando usare ResourcePlacement

ResourcePlacement è ideale per gli scenari che richiedono un controllo accurato sulle risorse con ambito spazio dei nomi:

  • Distribuzione selettiva delle risorse: Distribuire ConfigMaps, Secrets o Services specifici senza influire sull'intero namespace.
  • Ambienti multi-tenant: consente a team diversi di gestire le risorse in modo indipendente all'interno degli spazi dei nomi condivisi.
  • Gestione della configurazione: distribuire configurazioni specifiche dell'ambiente in ambienti cluster diversi.
  • Conformità e governance: applicare criteri diversi a tipi di risorse diversi all'interno dello stesso spazio dei nomi.
  • Implementazioni progressive: distribuire in modo sicuro gli aggiornamenti delle risorse tra cluster con strategie di tempo di inattività zero.

Nell'ambito degli ambienti multi-cluster, i carichi di lavoro spesso sono costituiti da risorse con ambito del cluster e con ambito dello spazio dei nomi che devono essere distribuite tra diversi cluster. Sebbene ClusterResourcePlacement (CRP) gestisca in modo efficace le risorse con ambito cluster, gli interi spazi dei nomi e il relativo contenuto, esistono scenari in cui è necessario un controllo più granulare sulle risorse con ambito spazio dei nomi all'interno degli spazi dei nomi esistenti.

ResourcePlacement (RP) è stato progettato per risolvere questo divario fornendo:

  • Gestione delle risorse con ambito spazio dei nomi: specificare come destinazione risorse specifiche all'interno di uno spazio dei nomi senza influire sull'intero spazio dei nomi.
  • Flessibilità operativa: consente ai team di gestire risorse diverse all'interno dello stesso spazio dei nomi in modo indipendente.
  • Funzionalità complementari: collaborare con CRP per offrire una soluzione completa di gestione delle risorse multi-cluster.

Annotazioni

ResourcePlacement può essere usato insieme a ClusterResourcePlacement in modalità namespace solo. Ad esempio, è possibile usare CRP per distribuire lo spazio dei nomi, usando RP per la gestione con granularità fine di risorse specifiche, ad esempio ConfigMaps o Segreti specifici dell'ambiente all'interno di tale spazio dei nomi.

Modelli di utilizzo dello spazio dei nomi nel mondo reale

Mentre CRP 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:

Aspetto ResourcePlacement (RP) ClusterResourcePlacement (CRP)
Scope Solo risorse con ambito spazio dei nomi Risorse con ambito cluster (in particolare gli spazi dei nomi e il relativo contenuto)
risorsa Oggetto API con ambito spazio dei nomi Oggetto API con ambito cluster
Limite di selezione Limitato alle risorse all'interno dello stesso spazio dei nomi dell'RP È possibile selezionare qualsiasi risorsa con ambito a livello di cluster
Casi d'uso tipici Processi di IA/ML, singoli carichi di lavoro, ConfigMaps/Secrets specifici che necessitano di decisioni di posizionamento indipendenti Bundle di applicazioni, interi spazi dei nomi, criteri a livello di cluster
Proprietà del team Può essere gestito da proprietari/sviluppatori dello spazio dei nomi In genere gestito dagli operatori della piattaforma

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

Uso di 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.

Prerequisiti del namespace

Importante

ResourcePlacement può posizionare solo le risorse con ambito namespace nei cluster che dispongono già del namespace obiettivo. È consigliabile usare ClusterResourcePlacement per la definizione dello spazio dei nomi.

Flusso di lavoro tipico:

  1. Amministratore della piattaforma: usa ClusterResourcePlacement per distribuire i namespace nel cluster.
  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:

Annotazioni

Gli esempi seguenti usano la versione dell'API placement.kubernetes-fleet.io/v1beta1 . Il selectionScope: NamespaceOnly campo è una funzionalità di anteprima disponibile nella versione 1beta1 e non è disponibile nell'API v1.

Amministratore della Piattaforma: Innanzitutto, crea 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 applicazione: gestire quindi 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

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:

  • Tipi di posizionamento: PickAll, PickFixede PickN le strategie 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.

Per informazioni dettagliate su queste funzionalità, vedere la documentazione di ClusterResourcePlacement.

Passaggi successivi

  • Last updated on