Utilizzare lo strumento a riga di comando nomos

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

Comando Utilizzo
nomos status Controllare lo stato di Config Sync
nomos vet Verificare la presenza di errori nella fonte attendibile
nomos hydrate Visualizzare tutte le configurazioni nella verità effettiva
nomos bugreport Creare una segnalazione di bug
nomos migrate Eseguire la migrazione dall'oggetto ConfigManagement a RootSync
nomos init Inizializza una 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 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 visualizzate, Kustomize e Helm sono facoltativi.

Installa lo strumento nomos

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

Lo strumento nomos non è incluso nell'installazione di 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 consente di utilizzare gcloud components update per aggiornare lo strumento nomos all'ultima versione.

Per informazioni su metodi alternativi per installare lo strumento nomos, consulta Download.

Utilizzo di base

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

nomos --help

Lo strumento nomos legge dalla copia locale della tua fonte attendibile. Utilizza il flag --path per specificare la posizione del livello più alto dell'origine attendibile. Per impostazione predefinita, --path è impostato su . o sulla directory corrente. Ad esempio:

nomos --path=PATH_TO_SOURCE vet

Controlla 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 genera un report sull'hash del commit applicato per ultimo al cluster e su eventuali errori che si sono verificati durante il tentativo di applicazione di eventuali modifiche recenti.

Puoi anche utilizzare nomos status per verificare se le risorse gestite da Config Sync sono pronte. nomos status segnala lo stato di ogni singolo utente 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>   git@github.com: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>   git@github.com:foo-corp/acme@main
  PENDING  9edf8444

MANAGED_CLUSTER_3
  --------------------
  <root>   git@github.com: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>   git@github.com: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  git@github.com: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 con la fonte di riferimento e tutte le risorse gestite hanno lo stato Current. Lo stato Current indica in modo che lo stato della risorsa corrisponda a quello desiderato.
  • La sincronizzazione di MANAGED_CLUSTER_2 è ancora in corso.
  • MANAGED_CLUSTER_3 presenta un errore che ha impedito la modifica applicati. In questo esempio, MANAGED_CLUSTER_3 presenta l'errore KNV1021 perché manca un CustomResourceDefinition (CRD) installato negli altri cluster.
  • Config Sync non è installato su MANAGED_CLUSTER_4.
  • MANAGED_CLUSTER_5 è in fase di sincronizzazione da due repository Git. La fonte di verità <root> appartiene all'amministratore del cluster, mentre la fonte di verità bookstore 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 il specificato nel manifest della risorsa. Questo stato indica che la riconciliazione delle risorse non è ancora stata completata. In genere, le risorse appena create iniziano con questo stato, anche se alcune risorse come ConfigMap sono Current immediatamente.

  • Failed: la procedura di riconciliazione dello stato effettivo con lo stato che vuoi ha rilevato un errore o ha registrato progressi insufficienti.

  • Current: lo stato effettivo della risorsa corrisponde a quello che vuoi. Il processo di riconciliazione è considerato completo fino a quando non vengono apportate modifiche allo stato desiderato o a quello 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 nell'output in status.sync.commit. Per ottenere questo valore, esegui una query sull'oggetto RootSync o RepoSync e controlla 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 il seguente comando:

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

Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato la verità oggettiva 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 eseguito sul cluster. Tuttavia, non tutte le risorse del cluster sono interessate da ogni commit. Per visualizzare il commit più recente per una risorsa specifica, esegui una query sulla risorsa specifica e controlla 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 una query.

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

flag di stato nomos

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

Bandiera Descrizione
--contexts Accetta un elenco separato da virgole di contesti da utilizzare in cluster multipli tramite comandi SQL. Il valore predefinito è tutti i contesti. Utilizza "" per nessun contesto.
-h o --help Guida per il comando nomos status.
--namespace Accetta una stringa. Utilizza il flag namespace per limitare il comando a una specifica fonte attendibile dello spazio dei nomi. Lascia vuoto per recuperare tutte le origini. 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 stampare di nuovo la tabella di stato 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 il root o lo spazio dei nomi quando si esegue la sincronizzazione da più di una fonte attendibile. Il valore predefinito è true.
--timeout Timeout per la connessione a ogni cluster. Il valore predefinito è 3s.
--name Accetta una stringa. Utilizza questo flag per filtrare la sincronizzazione della radice e del repository con il nome fornito. Questo flag può essere utilizzato insieme namespace flag.

Autorizzazioni obbligatorie

Se sei un proprietario del progetto, disponi del ruolo RBAC cluster-admin e puoi utilizzare il comando nomos status per tutti i cluster del progetto senza aggiungere altre 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 sia che tu stia utilizzando Oggetti RootSync e RepoSync.

    Utilizzare gli 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 vengono utilizzati 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

Verificare 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

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.

bandiere veterinarie nomos

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

Bandiera Descrizione
--clusters Accetta un elenco di nomi di cluster separati da virgole da utilizzare nei comandi multi-cluster. Il valore predefinito è tutti i cluster. Utilizza "" per nessun cluster.
-h o --help Guida per il comando nomos vet.
--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 l'API per il rilevamento. Per ulteriori informazioni su questo flag, consulta la sezione Convalida lato server.
--path Accetta una stringa. Il percorso alla directory principale della fonte attendibile di Config Sync. Il valore predefinito è "."
--source-format Accetta hierarchy o unstructured. Se hierarchy o non impostato, convalida la verità come verità gerarchica. Se unstructured, convalida la fonte di riferimento come una fonte di dati non strutturata. Questo flag è obbligatorio se utilizzi una fonte di riferimento non strutturata.
--keep-output Accetta un valore booleano. Se true, l'output visualizzato viene salvato nella posizione che puoi specificare con il flag --output.
--output Accetta una stringa. Il percorso dell'output di cui è stato eseguito il rendering. Il valore predefinito è la directory compiled. Se il criterio --keep-output è impostato su false, questo flag viene ignorato.
--format Accetta yaml o json. Il formato dell'output. Il valore predefinito è yaml.

Convalida lato server

Se il comando nomos vet non è in grado di determinare se il tipo ha uno spazio dei nomi, Lo strumento nomos si connette al server API. Poiché lo strumento nomos per impostazione predefinita comprende i tipi di Kubernetes principali e i CRD di Config Sync, cerca solo connettersi al server API se sono presenti RP che non hanno CRD In questo caso, se al server API non è stato applicato il CRD, il comando nomos vet restituisce l'errore KNV1021. A disattiva questo controllo ed elimina gli errori relativi ai CRD mancanti, --no-api-server-check flag.

Memorizzazione nella cache dei metadati del server API

Anziché eliminare i controlli del server API, puoi memorizzare i dati nella cache sull'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 tutti i CRD di cui hai bisogno per la tua origine attendibile. Non è necessario che Config Sync sia abilitato nel cluster.
  2. Vai al criterio PolicyDir della tua fonte di riferimento. 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 il valore di output di kubectl api-resources.

D'ora in poi, le esecuzioni di nomos vet all'interno della fonte di riferimento rilevano questo tipo le tue definizioni. Se il file api-resources.txt viene rimosso o rinominato, nomos vet non riesce a trovare il file. 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 presenti nella fonte attendibile sottoposta a convalida. nomos vet importa le definizioni, ma non le utilizza.

Aggiorna api-resources.txt

Dopo aver verificato che tutti i CRD desiderati siano sul cluster, esegui questo :

kubectl api-resources > api-resources.txt

Controlla automaticamente gli errori di sintassi durante il commit

Se esegui il commit di un file con errori JSON o YAML, Config Sync non per applicare la modifica. Tuttavia, puoi impedire che questi tipi di errori accedano alla fonte attendibile utilizzando gli 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 per gli errori di sintassi quando esegui il commit di una modifica nel clone Git locale del tuo repository. Se un hook pre-commit esce con uno stato diverso da zero, l'operazione git commit non va a buon fine.

Per eseguire il comando nomos vet come hook di pre-commit, modifica il .git/hooks/pre-commit nella tua fonte di riferimento (nota che .git inizia con un . ). Potresti dover creare il file manualmente. Aggiungi nomos vet in una nuova riga dello script. L'argomento --path è facoltativo.

nomos vet --path=/path/to/repo

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 origine attendibile, nomos vet viene eseguito automaticamente.

I contenuti della directory .git/ non vengono monitorati dalla stessa verità oggettiva e non possono essere sottoposti a commit nella stessa posizione. Puoi creare una directory nella fonte attendibile per gli hook Git e le persone che usano la fonte di riferimento, possono copiare gli hook nella posizione appropriata della loro clone locale.

Utilizza nomos vet in un hook lato server

Git fornisce un meccanismo per eseguire i controlli a livello di server, anziché 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 ignorati dal client. Il metodo per configurare gli hook lato server dipende da come è ospitato il server Git. Per ulteriori informazioni, consulta uno dei seguenti link o la documentazione del tuo servizio di hosting Git.

Visualizza tutte le configurazioni nella fonte di riferimento

Puoi utilizzare il comando nomos hydrate per visualizzare i contenuti combinati la tua fonte attendibile su ciascun cluster registrato.

Se esegui nomos hydrate senza opzioni, viene creata una directory compiled/ nella directory di lavoro corrente. All'interno di questa directory, viene creato per ogni cluster registrato, con le configurazioni completamente risolte L'operatore verrà applicato al cluster.

Questo comando può anche convertire una fonte di riferimento gerarchica a una o più fonti di dati non strutturate, utilizzando i contenuti della directory compiled/.

flag nomos hydrate

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

Bandiera Descrizione
--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 abilitata, stampa tutta l'uscita in un unico file. Utilizza questo flag se vuoi emulare il comportamento di nomos view.
-h o --help Guida per il comando nomos hydrate.
--format Accetta un valore yaml o json. Il formato del come output. Il valore predefinito è yaml.
--no-api-server-check Accetta un valore booleano. Se true, viene disattivata la comunicazione con il server API per il rilevamento. Per ulteriori informazioni su questo flag, consulta la sezione Convalida lato server.
--output Accetta una stringa. La località in cui scrivere la configurazione idratata. Il valore predefinito è la directory compiled. Se --flat non è abilitato, scrive ogni manifest della risorsa come file separato. Se --flat è attivato, vengono scritti in un singolo file tutti i manifest delle risorse.
--path Accetta una stringa. Il percorso della directory principale di Config Sync una fonte attendibile. Il valore predefinito è "."
--source-format Accetta hierarchy o unstructured. Se hierarchy o non impostato, convalida la verità come verità 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'assistenza Google Cloud, puoi fornire informazioni utili per il debug 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 sulle risorse sincronizzate con Config Sync. Per ulteriori informazioni sui contenuti del file ZIP, consulta il riferimento per i report di bug di Nomos.

Limitazioni

Il comando nomos bugreport non va a buon fine e genera un file ZIP incompleto se un singolo file supera 1 GB. Questo accade spesso a causa di file di log di grandi dimensioni.

La tabella seguente include le cause più comuni di file di log di grandi dimensioni e il puoi risolverli:

Causa Azione consigliata
Maggiore livello di dettaglio dei log Riduci la verbosità dei log con le sostituzione dei livelli di log
Oggetti di dimensioni molto grandi Rimuovi dalla gestione l'oggetto di grandi dimensioni o riduci le sue dimensioni
Molti oggetti Suddividi il repository in più repository
Combattimenti tra controller Risolvere i conflitti

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.

Se hai usato spec.enableLegacyFields per eseguire il bootstrap di un RootSync, segui la guida per disattivare i campi precedenti anziché utilizzare nomos migrate. I campi legacy non sono supportati a partire dalla versione 1.19.0.

nomos migrate supporta la modalità dry run per visualizzare l'anteprima del processo di migrazione.

nomos migrate modifica direttamente l'oggetto ConfigManagement sul cluster. Per evitare che le modifiche apportate tramite nomos migrate vengano annullate, assicurati che l'oggetto ConfigManagement non sia sottoposto a check-in nella tua origine attendibile.

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

Se il risultato della prova è corretto, 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`.

Esegui 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 ne stampa il nome nel terminale. Il nome del file è del tipo /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

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

kubectl apply -f CM_ORIGINAL_PATH

flag nomos migrate

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

Bandiera Descrizione
--connect-timeout Accetta una durata. Durata del timeout per la connessione a ciascun cluster. Il valore predefinito è 3s.
--contexts Accetta un elenco di contesti separati da virgole da utilizzare in ambienti con più cluster. 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.
--wait-timeout Accetta una durata. Durata del timeout per l'attesa che le condizioni delle risorse Kubernetes siano vere. Il valore predefinito è 10m.

Inizializzare una fonte di riferimento gerarchica

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

nomos init

Viene creata la struttura di directory di base di una fonte attendibile gerarchica, incluse le directory system/, cluster/ e namespaces/.

nomos init flags

Per personalizzare nomos init, aggiungi i seguenti flag:

Bandiera 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 tua origine di riferimento. 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