Utilizzare lo strumento a riga di comando nomos

Lo strumento a riga di comando nomos è uno strumento facoltativo per Config Sync che puoi utilizzare per ottenere lo stato di Config Sync e lo stato di sincronizzazione della tua fonte attendibile. Lo strumento nomos fornisce i seguenti comandi:

Comando	Utilizzo
nomos status	Controllare lo stato di Config Sync
nomos vet	Controllare la presenza di errori nella fonte attendibile
nomos hydrate	Visualizzare tutte le configurazioni nell'origine attendibile
nomos bugreport	Creare una segnalazione di bug
nomos migrate	Esegui la migrazione dall'oggetto ConfigManagement a RootSync
nomos init	Inizializzare un'unica fonte attendibile gerarchica

Prerequisiti

Prima di poter utilizzare lo strumento nomos per interagire con un cluster, Config Sync deve essere già installato sul cluster di destinazione. Devi anche installare e configurare lo strumento a riga di comando kubectl. Se interagisci con i cluster Google Kubernetes Engine, assicurati di installare anche gke-gcloud-auth-plugin.

Lo strumento nomos supporta l'anteprima e la convalida delle configurazioni Kustomize e dei grafici Helm. Prima di poter utilizzare questa funzionalità, installa Kustomize e Helm nella tua workstation locale. Se la tua fonte di riferimento contiene solo configurazioni completamente renderizzate, Kustomize e Helm sono facoltativi.

Installare lo strumento nomos

Lo strumento nomos è un binario compilato dal codice Go e puoi installarlo localmente, ad esempio su una workstation o un laptop.

Lo strumento nomos non è incluso quando installi Config Sync. Puoi installare lo strumento nomos installando Google Cloud CLI. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.

Se non hai Google Cloud CLI, ti consigliamo di utilizzare gcloud components install nomos per installare lo strumento nomos. L'installazione dello strumento nomos con Google Cloud CLI ti consente di utilizzare gcloud components update per aggiornare lo strumento nomos all'ultima versione.

Per informazioni su modi alternativi per installare lo strumento nomos, consulta la sezione Download.

Utilizzo di base

Per la sintassi di base dei comandi, utilizza l'argomento --help:

nomos --help

Lo strumento nomos legge dal clone locale della tua fonte attendibile. Utilizza il flag --path per specificare la posizione del livello superiore della fonte attendibile. Per impostazione predefinita, --path è impostato su . o sulla directory corrente. Ad esempio:

nomos vet --path=PATH_TO_SOURCE --source-format unstructured

Controllare lo stato di Config Sync

Puoi monitorare lo stato di Config Sync su tutti i cluster registrati utilizzando il comando nomos status. Per ogni cluster, nomos status riporta l'hash del commit applicato per ultimo al cluster e gli eventuali errori che si sono verificati durante il tentativo di applicare le modifiche recenti.

Puoi anche utilizzare nomos status per verificare se le risorse gestite da Config Sync sono pronte. nomos status riporta lo stato di ogni singola risorsa nella colonna STATUS della sezione Managed resources dell'output.

L'esempio seguente mostra alcune delle diverse condizioni che il comando nomos status potrebbe segnalare:

nomos status

Output di esempio:

MANAGED_CLUSTER_1
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
               k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services   Current
               namespace/hello                                                        Current

MANAGED_CLUSTER_2
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  PENDING  9edf8444

MANAGED_CLUSTER_3
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  ERROR    f52a11e4
  Error:   KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.

MANGED_CLUSTER_4
  --------------------
  NOT INSTALLED

MANAGED_CLUSTER_5
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
                namespace/gamestore                                                   Current
                namespace/monitoring                                                  Current
   gamestore    reposync.configsync.gke.io/repo-sync                                  Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-admin                 Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin        Current
   monitoring   deployment.apps/prometheus-operator                                   Current
   monitoring   prometheus.monitoring.coreos.com/acm                                  Current
   monitoring   service/prometheus-acm                                                Current
   monitoring   service/prometheus-operator                                           Current
   monitoring   serviceaccount/prometheus-acm                                         Current
   monitoring   serviceaccount/prometheus-operator                                    Current
   monitoring   servicemonitor.monitoring.coreos.com/acm-service                      Current
  --------------------
  bookstore  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8
  Managed resources:
   NAMESPACE   NAME                                 STATUS
   gamestore   configmap/store-inventory            Current
   gamestore   webstore.marketplace.com/gameplace   Current

In questo output:

• MANAGED_CLUSTER_1 ha sincronizzato la modifica più recente alla fonte di riferimento e tutte le risorse gestite hanno lo stato Current. Uno stato Current indica che lo stato della risorsa corrisponde a quello desiderato.
• MANAGED_CLUSTER_2 è ancora in fase di sincronizzazione.
• MANAGED_CLUSTER_3 presenta un errore che ha impedito l'applicazione della modifica. In questo esempio, MANAGED_CLUSTER_3 presenta l'errore KNV1021 perché manca una CustomResourceDefinition (CRD) installata negli altri cluster.
• MANAGED_CLUSTER_4 non ha installato Config Sync.
• MANAGED_CLUSTER_5 esegue la sincronizzazione da due repository Git. La <root>fonte attendibile appartiene all'amministratore del cluster e la bookstore fonte attendibile potrebbe appartenere a un team di sviluppo di applicazioni.

Stati delle risorse gestite

Lo stato delle risorse gestite può essere uno dei seguenti valori:

• InProgress: Lo stato effettivo della risorsa non ha ancora raggiunto lo stato specificato nel manifest della risorsa. Questo stato indica che la riconciliazione delle risorse non è ancora completata. Le risorse appena create di solito iniziano con questo stato, anche se alcune risorse come ConfigMap sono Current immediatamente.

• Failed: il processo di riconciliazione dello stato effettivo con lo stato desiderato ha rilevato un errore o non ha fatto progressi sufficienti.

• Current: Lo stato effettivo della risorsa corrisponde allo stato desiderato. Il processo di riconciliazione è considerato completo finché non vengono apportate modifiche allo stato desiderato o effettivo.

• Terminating: La risorsa è in fase di eliminazione.

• NotFound: la risorsa non esiste nel cluster.

• Unknown: Config Sync non è in grado di determinare lo stato della risorsa.

Per disattivare la visualizzazione dello stato a livello di risorsa, aggiungi --resources=false al comando nomos status.

Informazioni sull'ultimo commit sincronizzato

Il comando nomos status mostra l'hash del commit più recente applicato al cluster nel suo output in status.sync.commit. Per ottenere questo valore, esegui una query sull'oggetto RootSync o RepoSync e guarda il campo status.sync.

Ad esempio, per eseguire una query su un oggetto RootSync, esegui questo comando:

kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml

Output di esempio:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
  sync:
    commit: f1739af550912034139aca51e382dc50c4036ae0
    lastUpdate: "2021-04-20T00:25:01Z"

Per eseguire una query su un oggetto RepoSync, esegui questo comando:

kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml

Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato l'origine attendibile dello spazio dei nomi.

Output di esempio:

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
  sync:
    commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
    lastUpdate: "2021-04-20T00:25:20Z"

Questo commit rappresenta il commit più recente rispetto al cluster. Tuttavia, non tutte le risorse nel cluster sono interessate da ogni commit; per visualizzare il commit più recente per una risorsa specifica, esegui una query sulla risorsa specifica e guarda metadata.annotations.configmanagement.gke.io/token. Ad esempio:

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Sostituisci CLUSTER_ROLE_NAME con il nome del ruolo del cluster su cui vuoi eseguire la query.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f

nomos status flags

Per personalizzare il comando nomos status, aggiungi i seguenti flag:

Flag	Descrizione
--contexts	Accetta un elenco separato da virgole di contesti da utilizzare nei comandi multi-cluster. Il valore predefinito è tutti i contesti. Utilizza "" per nessun contesto.
-h o --help	Guida per il comando nomos status.
--name	Accetta una stringa. Utilizza questo flag per filtrare la sincronizzazione di Root e Repo con il nome fornito. Questo flag può essere utilizzato insieme al flag namespace.
--namespace	Accetta una stringa. Utilizza il flag namespace per limitare il comando a una specifica origine attendibile dello spazio dei nomi. Lascia il campo vuoto per ottenere tutte le fonti. Questo flag è disponibile solo se hai attivato la sincronizzazione da più di una fonte attendibile.
--poll	Utilizza il flag poll per eseguire nomos status in modo continuo e fare in modo che la tabella di stato venga ristampata a intervalli regolari. Ad esempio 3s. Lascia questo flag non impostato per eseguire nomos status una volta
--resources	Accetta true o false. Se true, nomos status mostra lo stato a livello di risorsa per la tua origine attendibile principale o dello spazio dei nomi durante la sincronizzazione da più origini attendibili. Il valore predefinito è true.
--timeout	Timeout per la connessione a ogni cluster. Il valore predefinito è 3s.

Autorizzazioni obbligatorie

Se sei il proprietario di un progetto, disponi del ruolo RBAC cluster-admin e puoi utilizzare il comando nomos status per qualsiasi cluster nel tuo progetto senza aggiungere ulteriori autorizzazioni. Se non disponi del ruolo cluster-admin, puoi utilizzare nomos status creando il seguente ClusterRole:

1. Crea un file denominato nomos-status-reader.yaml e copia al suo interno il seguente ClusterRole. Le regole necessarie variano a seconda che tu stia utilizzando oggetti RootSync e RepoSync.

   Utilizzo di oggetti RootSync e RepoSync

   # nomos-status-reader.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: nomos-status-reader
   rules:
   - apiGroups: ["configsync.gke.io"]
     resources: ["reposyncs", "rootsyncs"]
     verbs: ["get"]
   - nonResourceURLs: ["/"]
     verbs: ["get"]
   

   Non utilizzare oggetti RootSync e RepoSync

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: nomos-status-reader
   rules:
   - apiGroups: ["configmanagement.gke.io"]
     resources: ["configmanagements", "repos"]
     verbs: ["get", "list"]
   - nonResourceURLs: ["/"]
     verbs: ["get"]
   

2. Applica il file nomos-status-reader.yaml:

   kubectl apply -f nomos-status-reader.yaml
   

Controllare la presenza di errori nella fonte attendibile

Prima di eseguire il commit di una configurazione nella fonte attendibile, utilizza il comando nomos vet per controllare la sintassi e la validità delle configurazioni nella fonte attendibile:

nomos vet --source-format unstructured

Se vengono rilevati errori di sintassi, il comando nomos vet esce con uno stato diverso da zero e registra i messaggi di errore in STDERR.

nomos vet flags

Per personalizzare il comando nomos vet, aggiungi i seguenti flag:

Flag	Descrizione
--api-server-timeout	Accetta una stringa di durata. Imposta il timeout lato client per la comunicazione con il server API Kubernetes. Il valore predefinito è 15s.
--clusters	Accetta un elenco separato da virgole di nomi di cluster da utilizzare nei comandi multi-cluster. Il valore predefinito è tutti i cluster. Utilizza "" per nessun cluster.
--format	Accetta yaml o json. Il formato dell'output. Il valore predefinito è yaml.
-h o --help	Guida per il comando nomos vet.
--keep-output	Accetta un valore booleano. Se true, l'output sottoposto a rendering viene salvato nella posizione che puoi specificare con il flag --output.
--namespace	Accetta una stringa. Se impostato, convalida l'origine attendibile come origine attendibile dello spazio dei nomi con il nome fornito. Imposta automaticamente --source-format=unstructured.
--no-api-server-check	Accetta un valore booleano. Se true, disabilita la comunicazione con il server dell'API Kubernetes per il rilevamento. Per ulteriori informazioni su questo flag, consulta la sezione Convalida lato server.
--output	Accetta una stringa. Il percorso dell'output sottoposto a rendering. Il valore predefinito è la directory compiled. Se --keep-output è impostato su false, questo flag viene ignorato.
--path	Accetta una stringa. Il percorso della directory principale dell'origine attendibile di Config Sync. Il valore predefinito è ".".
--source-format	Accetta hierarchy o unstructured. Se hierarchy o non impostato, convalida l'origine attendibile come origine attendibile gerarchica. Se unstructured, convalida la fonte attendibile come fonte attendibile non strutturata. Questo flag è obbligatorio se utilizzi una fonte attendibile non strutturata.
--threshold	Accetta facoltativamente un numero intero. Imposta il numero massimo di oggetti consentiti per repository; genera un errore se viene superato. Ometti il flag o utilizza --threshold=0 per disattivare la convalida del numero massimo di oggetti. Fornisci il flag senza un valore per utilizzare il valore predefinito 1000 oppure utilizza --threshold=N per impostare un limite specifico.

Convalida lato server

Se il comando nomos vet non riesce a determinare se il tipo è namespaced, lo strumento nomos si connette al server API del contesto kubectl corrente. Poiché lo strumento nomos per impostazione predefinita comprende i tipi Kubernetes di base e le CRD di Config Sync, tenta di connettersi al server API solo se le CR non hanno una CRD dichiarata corrispondente. In questo caso, se il server API non ha applicato il CRD, il comando nomos vet restituisce l'errore KNV1021. Per disattivare questo controllo e sopprimere gli errori dovuti alla mancanza di CRD, passa il flag --no-api-server-check.

Memorizzazione nella cache dei metadati del server API

Anziché eliminare i controlli del server API, puoi memorizzare nella cache i dati sul server API per il comando nomos vet. Per memorizzare nella cache il tuo api-resources, completa i seguenti passaggi:

1. Connettiti a un cluster che contiene tutte le CRD necessarie per la tua fonte di riferimento. Non è necessario che Config Sync sia abilitato nel cluster.
2. Vai a policyDir della tua fonte attendibile. Si tratta della stessa directory specificata nella risorsa ConfigManagement o RootSync.
3. Esegui questo comando: kubectl api-resources > api-resources.txt Questo comando crea un file denominato api-resources.txt che contiene l'output esatto di kubectl api-resources.

D'ora in poi, le esecuzioni di nomos vet all'interno dell'origine attendibile sono a conoscenza di queste definizioni di tipo. Se il file api-resources.txt viene rimosso o rinominato, nomos vet non riesce a trovarlo. nomos vet tenterà comunque di connettersi al cluster se trova manifest per tipi non dichiarati in api-resources.txt (a meno che non venga passato --no-api-server-check).

Il file api-resources.txt influisce solo sul funzionamento dello strumento nomos. Non modifica in alcun modo il comportamento di Config Sync.

È consentito avere voci aggiuntive nel file api-resources.txt per tipi che non sono nell'origine attendibile in fase di convalida. nomos vet importa le definizioni, ma non le utilizza.

Attenzione: i tipi personalizzati in una fonte attendibile devono avere uno spazio dei nomi o non averlo. Il comando nomos vet non supporta i tipi con ambito namespace in alcuni cluster e ambito cluster in altri.

Aggiorna api-resources.txt

Dopo aver verificato che tutte le CRD che ti interessano si trovino nel cluster, esegui questo comando:

kubectl api-resources > api-resources.txt

Attenzione: evita di modificare direttamente api-resources.txt, perché è facile formattare in modo errato e causare errori.

Controllare automaticamente la presenza di errori di sintassi durante il commit

Se esegui il commit di un file con errori JSON o YAML, Config Sync non applica la modifica. Tuttavia, puoi impedire che questi tipi di errori vengano inseriti nella fonte attendibile utilizzando hook lato client o lato server.

Utilizzare nomos vet in un hook pre-commit

Puoi configurare un hook pre-commit che esegue il comando nomos vet per verificare la presenza di errori di sintassi quando esegui il commit di una modifica nel clone Git locale del tuo repository. Se un hook pre-commit termina con uno stato diverso da zero, l'operazione git commit non va a buon fine.

Nota: gli hook pre-commit vengono eseguiti sul client, non sul server. Devono essere aggiunti manualmente a ogni cliente e l'utente può ignorarli o disattivarli in qualsiasi momento.

Per eseguire il comando nomos vet come hook pre-commit, modifica il file .git/hooks/pre-commit nella tua origine attendibile (nota che .git inizia con il carattere .). Potrebbe essere necessario creare il file manualmente. Aggiungi il comando nomos vet a una nuova riga dello script. L'argomento --path è facoltativo. Imposta l'argomento --source-format sul formato di origine del repository.

nomos vet --path=/path/to/repo --source-format unstructured

Assicurati che il file pre-commit sia eseguibile:

chmod +x .git/hooks/pre-commit

Ora, quando esegui un comando git commit nel clone della tua fonte attendibile, nomos vet viene eseguito automaticamente.

I contenuti della directory .git/ non vengono monitorati dall'origine attendibile stessa e non possono essere salvati nell'origine attendibile nella stessa posizione. Puoi creare una directory nella fonte di riferimento per gli hook Git e le persone che utilizzano la fonte di riferimento possono copiare gli hook nella posizione appropriata nel clone locale.

Utilizzare nomos vet in un hook lato server

Git fornisce un meccanismo per eseguire i controlli sul server, anziché sul client, durante un'operazione git push. Se il controllo non va a buon fine, anche git push non va a buon fine. Questi hook lato server non possono essere bypassati dal client. Il metodo per configurare gli hook lato server dipende dalla modalità di hosting del server Git. Per saperne di più, consulta uno dei seguenti link o controlla la documentazione del tuo servizio di hosting Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Server Git self-hosted

Imponi il numero massimo di oggetti da sincronizzare

Config Sync memorizza un riferimento a ogni oggetto sincronizzato in un oggetto inventario ResourceGroup, insieme allo stato attuale dell'oggetto. Poiché Kubernetes ha un limite di dimensioni in byte per gli oggetti risorsa, ciò limita il numero massimo di oggetti che Config Sync può sincronizzare con un singolo RootSync o RepoSync.

Per impostazione predefinita, il limite di dimensioni di etcd lato server è 1,5 MiB. Per ulteriori dettagli, consulta la documentazione di etcd. L'applicazione di un oggetto più grande di questo limite causa uno dei seguenti errori, a seconda delle dimensioni dell'oggetto:

• etcdserver: request is too large
• rpc error: code = ResourceExhausted desc = trying to send message larger than max
• Request entity too large: limit is 3145728

Per proteggerti dal superamento del limite di dimensioni di Kubernetes da parte degli oggetti ResourceGroup, puoi utilizzare nomos vet --threshold per convalidare il numero di oggetti nel tuo repository di origine.

Per impostazione predefinita, quando utilizzi il comando nomos vet, la soglia non viene applicata. Il passaggio del flag --threshold causerà l'errore del comando vet se il numero di oggetti nel repository di origine supera la soglia.

L'inventario ResourceGroup contiene sia i riferimenti agli oggetti sia lo stato attuale dell'oggetto. Può diventare particolarmente grande quando gli oggetti non vengono sincronizzati o riconciliati. Per evitare di superare il limite di dimensioni degli oggetti Kubernetes, scegli una soglia che lasci una capacità sufficiente per registrare gli errori degli oggetti. Il valore predefinito di 1000 dovrebbe funzionare in quasi tutti i casi, ma puoi aumentare o diminuire la soglia in base alle tue esigenze.

Questa soglia viene convalidata solo dal comando nomos vet, non da Config Sync stesso. Per applicare la soglia, utilizza il comando nomos vet --threshold in un controllo pre-invio del repository di origine o nell'hook pre-commit di Git.

Visualizza tutte le configurazioni nella fonte di riferimento

Puoi utilizzare il comando nomos hydrate per visualizzare i contenuti combinati della tua fonte attendibile in ogni cluster registrato.

Se esegui nomos hydrate senza opzioni, viene creata una directory compiled/ nella directory di lavoro corrente. All'interno di questa directory viene creata una sottodirectory per ogni cluster registrato, con le configurazioni completamente risolte che l'operatore applicherebbe al cluster.

Questo comando può anche convertire una fonte attendibile gerarchica in una o più fonti attendibili non strutturate, utilizzando i contenuti della directory compiled/.

nomos hydrate flags

Per personalizzare il comando nomos hydrate, aggiungi i seguenti flag:

Flag	Descrizione
--api-server-timeout	Accetta una stringa di durata. Imposta il timeout lato client per la comunicazione con il server API Kubernetes. Il valore predefinito è 15s.
--clusters	Accetta un elenco di nomi di cluster separati da virgole. Utilizza questo flag per limitare l'output a un singolo cluster o a un elenco di cluster. Il valore predefinito è tutti i cluster. Utilizza "" per nessun cluster.
--flat	Se attivata, stampa tutto l'output in un unico file. Utilizza questo flag se vuoi emulare il comportamento di nomos view.
--format	Accetta un yaml o un json. Il formato dell'output. Il valore predefinito è yaml.
-h o --help	Guida per il comando nomos hydrate.
--no-api-server-check	Accetta un valore booleano. Se true, disabilita la comunicazione con il server API per l'individuazione. Per ulteriori informazioni su questo flag, consulta la sezione Convalida lato server.
--output	Accetta una stringa. La posizione in cui scrivere la configurazione idratata. Il valore predefinito è la directory compiled. Se --flat non è attivato, scrive ogni manifest delle risorse come file separato. Se --flat è abilitato, scrive un singolo file contenente tutti i manifest delle risorse.
--path	Accetta una stringa. Il percorso della directory principale dell'origine attendibile di Config Sync. Il valore predefinito è ".".
--source-format	Accetta hierarchy o unstructured. Se hierarchy o non impostato, convalida l'origine attendibile come origine attendibile gerarchica. Se unstructured, convalida la fonte attendibile come fonte attendibile non strutturata. Questo flag è obbligatorio se utilizzi una fonte attendibile non strutturata.

Creare una segnalazione di bug

Se hai un problema con Config Sync che richiede l'aiuto dell'assistenzaGoogle Cloud , puoi fornire informazioni di debug preziose utilizzando il comando nomos bugreport. Puoi utilizzare questo comando per una singola fonte attendibile e più repository.

nomos bugreport

Questo comando genera un file zip con timestamp contenente informazioni sul cluster Kubernetes impostato nel contesto kubectl. Il file contiene anche i log dei pod Config Sync. Non contiene informazioni dalle risorse sincronizzate con Config Sync. Per ulteriori informazioni sui contenuti del file ZIP, consulta la documentazione di riferimento di nomos bugreport.

Limitazioni

Il comando nomos bugreport non va a buon fine e produce un file ZIP incompleto se un singolo file supera 1 GiB. Ciò si verifica spesso a causa di file di log di grandi dimensioni.

La seguente tabella include le cause più comuni dei file di log di grandi dimensioni e come risolverle:

Causa	Azione consigliata
Aumento della verbosità dei log	Ridurre la verbosità dei log con gli override del livello di log
Oggetti molto grandi	Annulla la gestione dell'oggetto di grandi dimensioni o riducine le dimensioni.
Molti oggetti	Dividere il repository in più repository
Controller fights	Risolvere la lite

Esegui la migrazione da un oggetto ConfigManagement a un oggetto RootSync

Puoi eseguire il comando nomos migrate per eseguire la migrazione dall'oggetto ConfigManagement a un oggetto RootSync per attivare le API RootSync e RepoSync.

nomos migrate supporta l'esecuzione di prova per visualizzare in anteprima il processo di migrazione.

nomos migrate modifica direttamente l'oggetto ConfigManagement sul cluster. Per evitare che le modifiche apportate tramite nomos migrate vengano ripristinate, assicurati che l'oggetto ConfigManagement non sia archiviato nella tua fonte attendibile.

Nota: il passaggio del flag --contexts specifica i contesti da migrare. Questa operazione è necessaria solo se vuoi eseguire la migrazione dei cluster al di fuori del contesto attuale.

nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run

Se il risultato della prova generale è soddisfacente, puoi eseguire la migrazione dell'oggetto ConfigManagement utilizzando nomos migrate:

nomos migrate --contexts=KUBECONFIG_CONTEXTS

L'output è simile al seguente:

--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
  kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.

Finished migration on all the contexts. Please check the sync status with `nomos status`.

Nota: nomos migrate salva l'oggetto ConfigManagement originale, l'oggetto ConfigManagement aggiornato e l'oggetto RootSync convertito in una directory temporanea. Se nomos migrate non va a buon fine o viene interrotto inaspettatamente, puoi recuperare manualmente la migrazione eseguendo i comandi forniti nell'output di nomos migrate.

Eseguire il rollback alla configurazione precedente

Se devi eseguire il rollback dopo aver eseguito la migrazione con nomos migrate, applica l'oggetto ConfigManagement originale. nomos migrate salva l'oggetto ConfigManagement originale in un file e stampa il nome nel terminale. Il nome del file è nel formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Per eseguire il rollback alla configurazione precedente, copia il percorso del file per cm-original.yaml e applica il file al cluster:

kubectl apply -f CM_ORIGINAL_PATH

nomos migrate flags

Per personalizzare il comando nomos migrate, aggiungi i seguenti flag:

Flag	Descrizione
--connect-timeout	Accetta una durata. Durata del timeout per la connessione a ogni cluster. Il valore predefinito è 3s.
--contexts	Accetta un elenco separato da virgole di contesti da utilizzare in ambienti multicluster. Il valore predefinito è il contesto corrente. Utilizza "all" per tutti i contesti.
--dry-run	Accetta un valore booleano. Se true, stampa solo l'output della migrazione.
-h o --help	Guida per il comando nomos migrate.
--remove-configmanagement	Accetta un valore booleano. Se true, esegue la migrazione a OSS Config Sync rimuovendo l'operatore ConfigManagement e la CRD ConfigManagement.
--wait-timeout	Accetta una durata. Durata del timeout per l'attesa delle condizioni delle risorse Kubernetes. Il valore predefinito è 10m.

Inizializzare una fonte attendibile gerarchica

Puoi organizzare la fonte attendibile in modo arbitrario se utilizzi una fonte attendibile non strutturata. Se utilizzi una fonte attendibile gerarchica, devi eseguire il comando nomos init per inizializzare una directory gerarchica:

nomos init

In questo modo viene creata la struttura di directory di base di una singola fonte di verità gerarchica, incluse le directory system/, cluster/ e namespaces/.

nomos init flags

Per personalizzare nomos init, aggiungi i seguenti flag:

Flag	Descrizione
--force	Scrivi nella directory anche se non è vuota, sovrascrivendo i file in conflitto
-h o --help	Guida per il comando nomos init.
--path	Accetta una stringa. La directory principale da utilizzare per la fonte attendibile. Il valore predefinito è "."

Risoluzione dei problemi

Su Linux, potresti visualizzare il seguente errore durante l'esecuzione di un comando nomos:

failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64

Per risolvere il problema, crea una variabile di ambiente USER:

export USER=$(whoami)

Passaggi successivi

• Inizia a utilizzare Config Sync