Lo strumento a riga di comando nomos
è uno strumento facoltativo per Config Sync che puoi utilizzare per ottenere lo stato di Config Sync e della sincronizzazione della tua fonte attendibile. Lo
strumento nomos
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 |
Visualizza tutte le configurazioni nella fonte attendibile |
nomos bugreport |
Creare una segnalazione di bug |
nomos migrate |
Eseguire la migrazione dall'oggetto ConfigManagement a RootSync |
nomos init |
Inizializzare una fonte di riferimento gerarchica |
Prerequisiti
Prima di poter utilizzare lo strumento nomos
per interagire con un cluster, Config Sync deve essere già installato nel cluster di destinazione. Devi inoltre installare e configurare lo strumento a riga di comando kubectl
.
Se interagisci con i cluster di 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 fonte di riferimento contiene solo configurazioni
con rendering completo, Kustomize e Helm sono facoltative.
Installa lo strumento nomos
Lo strumento nomos
è un programma binario compilato dal codice Go che puoi installare
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
permette di utilizzare
gcloud components update
per
aggiornare lo strumento nomos
alla versione più recente.
Per informazioni sulle modalità alternative di installazione dello 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 di riferimento. Utilizza il flag --path
per specificare la posizione del livello superiore della fonte di riferimento. 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
segnala l'hash dell'ultimo commit applicato al cluster e gli eventuali errori che si sono verificati durante il tentativo di applicare 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 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> 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 attendibile e tutte le risorse gestite hanno lo statoCurrent
. Lo statoCurrent
indica che lo stato della risorsa corrisponde a quello che vuoi.MANAGED_CLUSTER_2
è ancora in fase di sincronizzazione.MANAGED_CLUSTER_3
contiene un errore che ha impedito l'applicazione della modifica. In questo esempio,MANAGED_CLUSTER_3
presenta l'errore KNV1021 perché non ha una CustomResourceDefinition (CRD) installata dagli altri cluster.- Config Sync non è installato su
MANAGED_CLUSTER_4
. MANAGED_CLUSTER_5
sta eseguendo la sincronizzazione da due repository Git. La fonte attendibile<root>
appartiene all'amministratore del cluster, mentre la fonte attendibilebookstore
potrebbe appartenere a un team di sviluppo delle 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 completa. Le risorse appena create in genere iniziano con questo stato, anche se alcune risorse come ConfigMap vengono subitoCurrent
.Failed
: si è verificato un errore o i progressi sono stati insufficienti durante il processo di riconciliazione dello stato effettivo con quello desiderato.Current
: lo stato effettivo della risorsa corrisponde a quello che vuoi. Il processo di riconciliazione è considerato completato 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 di 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 osserva 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 per il 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 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 la 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:
Flag | Descrizione |
---|---|
--contexts |
Accetta un elenco separato da virgole di contesti da utilizzare nei comandi multi-cluster. Il valore predefinito è tutti i contesti. Utilizza "" in 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 fonte attendibile dello spazio dei nomi specifica. Non impostare il valore per
tutte le origini. Questo flag è disponibile solo se hai abilitato la sincronizzazione da più di un'origine attendibile. |
--poll |
Utilizza il flag poll per eseguire nomos status in modo continuo e fare in modo che ristampi 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 l'origine attendibile principale
o dello spazio dei nomi quando esegui la sincronizzazione da più di un'origine attendibile.
Il valore predefinito è true . |
--timeout |
Timeout per la connessione a ciascun cluster. Il valore predefinito è
3s . |
--name |
Accetta una stringa. Utilizza questo flag per filtrare la sincronizzazione root e del repository con il nome fornito. Questo flag può essere utilizzato insieme al
flag namespace . |
Autorizzazioni obbligatorie
Se sei proprietario del progetto, hai il ruolo RBAC cluster-admin
e puoi utilizzare il comando nomos status
per qualsiasi cluster nel progetto senza aggiungere ulteriori autorizzazioni. Se non hai il ruolo cluster-admin
, puoi utilizzare nomos status
creando il seguente ClusterRole:
Crea un file denominato
nomos-status-reader.yaml
e copia al suo interno il seguente ClusterRole. Le regole di cui hai bisogno variano a seconda che utilizzi o meno gli oggetti RootSync e RepoSync.Utilizzo degli 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"]
Applica il file
nomos-status-reader.yaml
:kubectl apply -f nomos-status-reader.yaml
Verificare la presenza di errori nella fonte dei dati
Prima di eseguire il commit di una configurazione nella fonte attendibile, utilizza il comando nomos vet
per verificare la sintassi e la validità delle configurazioni nella fonte attendibile:
nomos vet
Se vengono rilevati errori di sintassi, il comando nomos vet
si chiude 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:
Flag | Descrizione |
---|---|
--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. |
-h o --help |
Guida per il comando nomos vet . |
--namespace |
Accetta una stringa. Se impostato, convalida la fonte attendibile come origine 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 API per il rilevamento. Per maggiori informazioni su questo flag, consulta la sezione
Convalida lato server. |
--path |
Accetta una stringa. Il percorso della directory radice della fonte attendibile di Config Sync. Il valore predefinito è ". " |
--source-format |
Accetta hierarchy o unstructured . Se
hierarchy o non viene configurato, convalida la fonte di riferimento come
fonte di riferimento gerarchica. Se
unstructured , convalida la fonte di riferimento come
origine 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 --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 principali di Kubernetes e i CRD di Config Sync, tenta di
connettersi al server API solo se sono presenti RP a cui non è stata dichiarata una CRD dichiarata. In questo caso, se al server API non è applicato il CRD, il comando nomos
vet
restituisce l'errore KNV1021. Per disabilitare questo controllo ed eliminare gli errori causati da CRD mancanti, 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 questi passaggi:
- Connettiti a un cluster che contiene tutti i CRD di cui hai bisogno per la tua fonte di riferimento. Non è necessario che Config Sync sia abilitato nel cluster.
- Vai alla pagina policyDir della tua fonte di riferimento. Questa è la stessa directory specificata nella risorsa ConfigManagement o RootSync.
- Esegui questo comando:
kubectl api-resources > api-resources.txt
Questo comando crea un file denominato api-resources.txt contenente l'output esatto di kubectl api-resources.
D'ora in poi, le esecuzioni di nomos vet
all'interno della fonte attendibile sono a conoscenza di questo tipo
definizioni. 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.
È possibile inserire nel file api-resources.txt voci aggiuntive destinate a tipi che non rientrano nell'origine di riferimento da convalidare. nomos vet
importa le definizioni, ma non vi opera.
Aggiorna api-resources.txt
Dopo aver verificato che tutti i CRD che vuoi siano sul cluster, esegui questo comando:
kubectl api-resources > api-resources.txt
I titoli delle colonne non corrispondono nelle risorse-api
Kubernetes versione 1.20 e successive sostituisce la colonna denominata APIGROUP
con
APIVERSION
. Per nomos versione 1.16.1 e precedenti, l'utilizzo di api-resources.txt
provoca un errore:
[1] KNV1064: unable to find APIGROUP column. Re-run "kubectl api-resources > api-resources.txt" in the root policy directory
Per limitare il problema, sostituisci manualmente APIVERSION
in api-resources.txt
in APIGROUP
.
Controlla automaticamente gli 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 evitare che questi tipi di errori raggiungano la fonte attendibile utilizzando gli hook lato client o lato server.
Usa nomos vet
in un hook di pre-commit
Puoi configurare un hook di pre-commit che esegue il comando nomos vet
per verificare la presenza di errori di sintassi quando esegui il commit di una modifica sul clone Git locale del tuo repository.
Se un hook di pre-commit si chiude 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
file .git/hooks/pre-commit
nella tua fonte attendibile (nota che .git
inizia con un
carattere .
). Potrebbe essere necessario creare il file manualmente. Aggiungi il comando nomos vet
a 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 dati, nomos vet
viene eseguito automaticamente.
I contenuti della directory .git/
non vengono monitorati dalla
fonte attendibile stessa e non possono essere impegnati nella fonte attendibile nella
stessa posizione. Puoi creare una directory nell'origine dati attendibile per gli hook Git e le persone che utilizzano la fonte attendibile possono copiare gli hook nella posizione appropriata del proprio clone locale.
Utilizza nomos vet
in un hook lato server
Git fornisce un meccanismo per eseguire i controlli a livello di server, anziché di client, durante un'operazione git push
. Se il controllo non va a buon fine, anche git push
non viene superato. Questi hook lato server non possono essere bypassati dal client. Il metodo di configurazione degli hook lato server dipende dalla modalità di hosting del server Git. Per ulteriori informazioni, visita uno
dei seguenti link o controlla la documentazione del tuo
servizio di hosting Git.
Visualizza tutte le configurazioni nella fonte attendibile
Puoi utilizzare il comando nomos hydrate
per visualizzare i contenuti combinati della tua origine di riferimento su ciascun cluster registrato.
Se esegui nomos hydrate
senza opzioni, viene creata una directory compiled/
nella directory di lavoro attuale. All'interno di questa directory, viene creata una sottodirectory per ogni cluster registrato, con le configurazioni completamente risolte che l'operatore applica al cluster.
Questo comando può anche convertire una fonte di attendibilità gerarchica
in una o più origini di dati non strutturate,
utilizzando i contenuti nella directory compiled/
.
flag nomos hydrate
Per personalizzare il comando nomos hydrate
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--clusters |
Accetta un elenco separato da virgole di nomi di cluster. Usa 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 questa opzione è attiva, tutti gli output vengono stampati 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 yaml o json . Il formato dell'output. Il valore predefinito è yaml . |
--no-api-server-check |
Accetta un valore booleano. Se true , disabilita la comunicazione con il server API per il rilevamento. Per maggiori informazioni su questo flag, consulta la sezione
Convalida lato server. |
--output |
Accetta una stringa. La località in cui scrivere la configurazione idratata. La
predefinita è la directory compiled .
Se --flat non è abilitato, scrive il manifest di ogni risorsa come
file separato.
Se --flat è abilitato, scrive nel file e scrive un singolo file che contiene tutti i manifest delle risorse.
|
--path |
Accetta una stringa. Il percorso della directory radice della fonte attendibile di Config Sync. Il valore predefinito è ". " |
--source-format |
Accetta hierarchy o unstructured . Se
hierarchy o non viene configurato, convalida la fonte di riferimento come
fonte di riferimento gerarchica. Se
unstructured , convalida la fonte di riferimento come
origine di dati non strutturata.
Questo flag è obbligatorio se utilizzi una fonte di riferimento non strutturata. |
Crea una segnalazione di bug
Se hai un problema con Config Sync che richiede l'aiuto dell'assistenza Google Cloud, puoi fornire preziose informazioni di debug utilizzando il comando nomos bugreport
. Puoi utilizzare questo comando per un'unica fonte attendibile e più repository.
nomos bugreport
Questo comando genera un file ZIP con timestamp con informazioni sul cluster Kubernetes
impostato nel tuo contesto kubectl
. Il file contiene anche i log dei pod di Config Sync. Non contiene le informazioni delle risorse sincronizzate
con Config Sync. Per ulteriori informazioni sui contenuti del file ZIP,
consulta la documentazione di riferimento sul bugreport nomos.
Limitazioni
Il comando nomos bugreport
non riesce e produce un file ZIP incompleto se
un singolo file supera 1 GiB. Questo problema si verifica spesso a causa di file di log di grandi dimensioni.
La tabella seguente include le cause più comuni dei file di log di grandi dimensioni e il modo in cui puoi risolverli:
Causa | Azione consigliata |
---|---|
Livello di dettaglio log aumentato | Riduci il livello di dettaglio dei log con gli log level overrides |
Oggetti molto grandi | Annulla la gestione dell'oggetto di grandi dimensioni o riducine le dimensioni. |
Molti oggetti | Suddividi il repository in più repository |
Combattimenti tra controller | Risolvi la rissa |
Eseguire 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 abilitare le API RootSync
e RepoSync
. Il comando è disponibile nello strumento nomos
versione 1.10.0 e successive.
nomos migrate
supporta la modalità dry run per visualizzare l'anteprima del processo di migrazione.
nomos migrate
modifica l'oggetto ConfigManagement direttamente nel cluster.
Per evitare il ripristino delle modifiche apportate tramite nomos migrate
, assicurati che
l'oggetto ConfigManagement non venga archiviato nella tua origine attendibile.
nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run
Se il risultato della prova di prova sembra 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 è 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
flag nomos migrate
Per personalizzare il comando nomos migrate
, aggiungi i seguenti flag:
Flag | Descrizione |
---|---|
--connect-timeout |
Accetta una durata. Durata del timeout per la connessione a ciascun cluster.
Il valore predefinito è 3s . |
--contexts |
Accetta un elenco separato da virgole di contesti da utilizzare in ambienti multi-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 prima che le condizioni delle risorse Kubernetes siano vere. Il valore predefinito è 10m . |
Inizializzare una fonte di riferimento gerarchica
Puoi organizzare la tua fonte di riferimento in modo arbitrario se utilizzi una fonte di attendibilità non strutturata.
Se utilizzi una fonte di attendibilità gerarchica, devi eseguire il comando nomos init
per inizializzare una directory gerarchica:
nomos init
Viene così creata la struttura di directory di base di un'origine attendibile gerarchica, che include le directory system/
, cluster/
e namespaces/
.
flag nomos init
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 root da utilizzare come 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)