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 dovrai gestire le configurazioni in un parco risorse di cluster e supportare più team che lavorano negli stessi repository. Una parte fondamentale di una strategia GitOps di successo è 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, ResourceQuota 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 attendibile. 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 non essere appropriate per l'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 di pod in un oggetto Deployment. Non puoi modificare alcun campo immutabile in una configurazione modificando il valore nella fonte attendibile. Se tenti di apportare una modifica di questo tipo, viene generato un errore KNV2009. Se devi modificare un campo immutabile, elimina l'oggetto dalla fonte attendibile, attendi che Config Sync elimini l'oggetto dal cluster e poi ricrea l'oggetto nella fonte attendibile con gli aggiornamenti.

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

  • Non puoi utilizzare Config Sync per gestire direttamente i ClusterRole Kubernetes integrati. GKE include alcuni ruoli integrati 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 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 cartelle o rami 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 strutturata (gerarchica) 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 un'origine 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 consiste nell'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, la fonte attendibile è organizzata nel seguente modo:

  • cluster-essentials/: contiene la configurazione che si applica a tutti i cluster, indipendentemente dall'ambiente. Potrebbe includere 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 le modifiche 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 oggetti RootSync che eseguono la sincronizzazione da cluster-essentials/, system/ e environments/dev/.

Layout basato sul cluster

Se il tuo obiettivo è gestire un parco risorse di singoli cluster con configurazioni distinte, un layout basato sul cluster potrebbe essere più adatto.

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

In questo esempio, la fonte attendibile è organizzata nel seguente modo:

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

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

Quando configuri Config Sync in questo scenario, puoi utilizzare un RepoSync per configurare ogni cluster in modo che esegua la sincronizzazione 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, la fonte 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 le configurazioni a livello di cluster gestite da un team di 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 probabilità che le modifiche di un team influiscano accidentalmente su un altro team. Tuttavia, questo approccio richiede una gestione attenta delle dipendenze tra i team di app e i team di piattaforma.

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

Convalidare i file di configurazione

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

Ignorare le 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 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 ulteriori dettagli, consulta Comandinomos.

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 discendenti (quelle originariamente nella directory namespaces/).

Passaggi successivi