Organizzare i file di configurazione in un'unica fonte attendibile

Questa pagina spiega come organizzare le configurazioni in una fonte attendibile.

Man mano che la tua organizzazione cresce, probabilmente devi gestire le configurazioni in un parco risorse di cluster e supportare più team che lavorano negli stessi repository. Un aspetto fondamentale di una strategia GitOps efficace è garantire che le configurazioni vengano applicate ai cluster corretti e che i team possano lavorare senza interferire tra loro.

Informazioni sui file di configurazione

Config Sync è progettato per gli operatori di cluster che gestiscono molti cluster. Puoi assicurarti che i tuoi cluster soddisfino gli standard aziendali e di conformità consentendo a Config Sync di gestire spazi dei nomi, ruoli, associazioni di ruoli, quote di risorse e altri oggetti Kubernetes importanti nel tuo parco risorse.

Quando Config Sync gestisce queste risorse, mantiene sincronizzati i cluster registrati utilizzando le configurazioni. Una configurazione è un file YAML o JSON in una fonte di riferimento. Config Sync supporta repository Git, immagini OCI e grafici Helm come fonte attendibile. Le configurazioni contengono lo stesso tipo di dettagli di configurazione che puoi applicare manualmente a un cluster utilizzando il comando kubectl apply. Puoi creare una configurazione per qualsiasi oggetto Kubernetes che può esistere in un cluster. Tuttavia, alcuni oggetti Kubernetes, come i secret, contengono informazioni sensibili che potrebbero essere inadatte all'archiviazione in una fonte attendibile. Valuta attentamente se gestire questi tipi di oggetti utilizzando Config Sync.

Requisiti e limitazioni

  • Alcune risorse Kubernetes contengono campi immutabili, come i selettori pod in un oggetto Deployment. Non puoi modificare alcun campo immutabile in una configurazione modificando il valore nell'origine attendibile. Il tentativo di apportare una modifica di questo tipo causa un errore KNV2009. Se devi modificare un campo immutabile, elimina l'oggetto dalla tua fonte attendibile, attendi che Config Sync elimini l'oggetto dal cluster e poi ricrea l'oggetto nella tua fonte attendibile con gli aggiornamenti.

  • Se utilizzi i sottomoduli Git, devi concedere l'accesso a Config Sync a tutti i repository, inclusi i sottomoduli.

  • Non puoi utilizzare Config Sync per gestire direttamente i ClusterRole Kubernetes integrati. GKE include alcuni ruoli rivolti agli utenti, come cluster-admin, admin, edit e view. Non puoi gestire direttamente questi ClusterRole con Config Sync, altrimenti Config Sync entra in conflitto con GKE. Per aggiungere autorizzazioni ai ClusterRole integrati, utilizza l'aggregazione dei ruoli per modificarli indirettamente. Per modificare i ruoli, crea un ClusterRole con un nome univoco nella tua fonte attendibile con le annotazioni appropriate.

Organizzare la fonte attendibile

Puoi configurare Config Sync in modo che esegua la sincronizzazione da un intero repository o da rami o cartelle specifici. Grazie a questa flessibilità, organizza i file di configurazione in base alle esigenze del tuo team o della tua organizzazione.

Ti consigliamo di impostare sourceFormat su unstructured quando configuri Config Sync. Il tipo di origine strutturato (gerarchico) richiede una struttura di cartelle molto specifica per sincronizzare correttamente le configurazioni e aggiunge una complessità non necessaria nella maggior parte dei casi.

La maggior parte della documentazione di Config Sync, inclusa questa pagina, utilizza il formato non strutturato per impostazione predefinita, ma puoi trovare informazioni sul formato gerarchico, se necessario, in Utilizzare un repository gerarchico.

Quando utilizzi una sorgente non strutturata, hai la flessibilità di organizzare le configurazioni in base al flusso di lavoro del tuo team. Questa sezione fornisce alcuni pattern comuni per strutturare il repository.

Layout basato sull'ambiente

Un approccio comune è organizzare il repository per ambiente.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

In questo esempio, l'origine attendibile è organizzata nel seguente modo:

  • cluster-essentials/: contiene la configurazione che si applica a tutti i cluster, indipendentemente dall'ambiente. Potrebbero essere incluse risorse come le definizioni di risorse personalizzate (CRD) e gli spazi dei nomi essenziali.
  • environments/: la directory principale per tutte le configurazioni specifiche dell'ambiente.
  • system/: contiene le configurazioni per i servizi a livello di sistema come il monitoraggio.

Questo approccio è semplice da comprendere e navigare e fornisce un percorso di promozione chiaro per i cambiamenti da un ambiente all'altro.

Quando configuri Config Sync in questo scenario, crei più oggetti RootSync su ogni cluster. Ad esempio, un cluster di sviluppo ha RootSync oggetti sincronizzati da cluster-essentials/, system/ e environments/dev/.

Layout basato su cluster

Se ti concentri sulla gestione di una flotta di singoli cluster con configurazioni distinte, un layout basato sui cluster potrebbe essere più adatto.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

In questo esempio, l'origine attendibile è organizzata nel seguente modo:

  • clusters/: contiene una directory per ogni cluster che gestisci.
  • shared/: contiene configurazioni comuni a tutti i cluster, come ruoli RBAC e criteri di sicurezza.

Questo approccio è efficace per la gestione di molti cluster se questi hanno tutti configurazioni uniche, in quanto fornisce una proprietà chiara e l'isolamento delle configurazioni. Questo approccio può essere più complesso da gestire se hai molte configurazioni del cluster condivise.

Quando configuri Config Sync in questo scenario, puoi utilizzare un RepoSync per configurare ogni cluster in modo che la sincronizzazione avvenga sia da shared sia dalla directory specifica del cluster.

Layout basato sul team

Per le organizzazioni in cui team diversi gestiscono applicazioni o servizi diversi, un layout basato sul team può essere efficace. Questo approccio allinea la struttura della fonte attendibile alla struttura organizzativa.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

In questo esempio, l'origine attendibile è organizzata nel seguente modo:

  • teams/: organizza la configurazione per team, con ogni team che gestisce le proprie configurazioni di applicazioni e servizi.
  • platform/: contiene configurazioni a livello di cluster gestite da un team della piattaforma centrale e utilizzate da tutti i team.

Questo approccio consente ai team di gestire i propri cicli di configurazione e rilascio e riduce la possibilità che le modifiche di un team influiscano accidentalmente su un altro. Tuttavia, questo approccio richiede un'attenta gestione delle dipendenze tra i team delle app e i team della piattaforma.

Quando configuri Config Sync, per questo scenario, ogni team utilizza un oggetto RootSync per sincronizzare le configurazioni, ad esempio team-alpha si sincronizza da teams/team-alpha/.

Convalida dei file di configurazione

Dopo aver creato, organizzato e aggiunto i file di configurazione a una fonte attendibile, utilizza il comando nomos vet --source-format=unstructured per controllare la sintassi e la validità delle configurazioni. In questo modo eviti errori durante o dopo una sincronizzazione.

Ignora mutazioni degli oggetti

Se non vuoi che Config Sync mantenga lo stato dell'oggetto nel cluster dopo la sua esistenza, aggiungi l'annotazione client.lifecycle.config.k8s.io/mutation: ignore all'oggetto in cui vuoi che Config Sync ignori le mutazioni.

L'esempio seguente mostra come aggiungere l'annotazione a un oggetto:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

Non puoi modificare manualmente questa annotazione sugli oggetti gestiti nel cluster.

Convertire un repository gerarchico in un repository non strutturato

Se utilizzi un repository gerarchico e vuoi convertirlo in un repository non strutturato, esegui il seguente comando:

nomos hydrate PATH

Sostituisci PATH con il percorso della tua directory.

Questo comando crea una directory compiled/ nella directory di lavoro corrente. All'interno di questa directory, viene creata una sottodirectory per ogni cluster registrato. Queste sottodirectory contengono le configurazioni completamente risolte e possono essere utilizzate in un repository non strutturato.

Per maggiori dettagli, vedi Comandi nomos.

Se preferisci convertire manualmente il repository, completa le seguenti istruzioni:

  1. Rimuovi le configurazioni Repo nella directory system/ dal repository Git. La risorsa Repo non è necessaria per un repository non strutturato.

  2. La directory dello spazio dei nomi astratto non è supportata in un repository non strutturato. Pertanto, dichiara lo spazio dei nomi di tutte le risorse originariamente incluse nella directory namespaces/ e nelle relative sottodirectory.

  3. L'ereditarietà dello spazio dei nomi non è supportata nel repository non strutturato. Pertanto, dichiara tutte le risorse originariamente ereditate negli spazi dei nomi secondari (quelle originariamente nella directory namespaces/).

Passaggi successivi