Usar a ferramenta de linha de comando nomos

A ferramenta de linha de comando nomos é opcional para o Config Sync que pode ser usada para conferir o status dele e o status de sincronização da sua fonte de verdade. A ferramenta nomos fornece os seguintes comandos:

Comando	Uso
nomos status	Verificar o status do Config Sync
nomos vet	Verificar se há erros na fonte da verdade
nomos hydrate	Conferir todas as configurações na fonte de verdade
nomos bugreport	Criar um relatório do bug
nomos migrate	Migrar do objeto ConfigManagement para o RootSync
nomos init	Inicializar uma fonte hierárquica de verdade

Pré-requisitos

Antes de usar a ferramenta nomos para interagir com um cluster, o Config Sync já precisa estar instalado no cluster de destino. Também é necessário instalar e configurar a ferramenta de linha de comando kubectl. Se você estiver interagindo com clusters do Google Kubernetes Engine, verifique se também instalou o gke-gcloud-auth-plugin.

A ferramenta nomos é compatível com a visualização e validação de configurações do Kustomize e gráficos do Helm. Antes de usar esse recurso, instale o Kustomize e o Helm na sua estação de trabalho local. Se a fonte da verdade tiver apenas configurações totalmente renderizadas, o Kustomize e o Helm serão opcionais.

Instalar a ferramenta nomos

A ferramenta nomos é um binário compilado do código Go e pode ser instalada localmente, por exemplo, em uma estação de trabalho ou laptop.

A ferramenta nomos não está incluída quando você instala o Config Sync. É possível instalar a ferramenta nomos instalando o Google Cloud CLI. Se você usa o Cloud Shell, o Google Cloud CLI já vem pré-instalado.

Se você não tiver o Google Cloud CLI, recomendamos usar gcloud components install nomos para instalar a ferramenta de linha de comando nomos. A instalação da ferramenta nomos com o Google Cloud CLI permite usar gcloud components update para atualizar a ferramenta nomos para a versão mais recente.

Para conferir formas alternativas de instalar a ferramenta nomos, consulte Downloads.

Uso básico

Para a sintaxe de comando básica, use o argumento --help:

nomos --help

A ferramenta nomos lê a partir do clone local da sua fonte da verdade. Use a sinalização --path para especificar o local do nível superior da fonte de verdade. Por padrão, --path é definido como . ou o diretório atual. Exemplo:

nomos --path=PATH_TO_SOURCE vet

Verificar o status do Config Sync

É possível monitorar o status do Config Sync em todos os clusters registrados usando o comando nomos status. Para cada cluster, nomos status informa o hash da confirmação que foi aplicado pela última vez ao cluster e todos os erros que ocorreram ao tentar aplicar as alterações recentes.

Também é possível usar nomos status para verificar se os recursos gerenciados pelo Config Sync estão prontos. nomos status informa o status de cada recurso individual na coluna STATUS da seção Managed resources da saída.

O exemplo a seguir mostra algumas das diferentes condições que o comando nomos status pode informar:

nomos status

Exemplo de saída:

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

Nesta saída:

• MANAGED_CLUSTER_1 sincronizou a mudança mais recente com a fonte de informações, e todos os recursos gerenciados têm status Current. O status Current significa que o estado do recurso corresponde ao estado que você quer.
• MANAGED_CLUSTER_2 ainda está sincronizando.
• MANAGED_CLUSTER_3 tem um erro que impediu a aplicação da alteração. Nesse exemplo, MANAGED_CLUSTER_3 tem o erro KNV1021, já que falta um CustomResourceDefinition (CRD) que os outros clusters instalaram.
• MANAGED_CLUSTER_4 não tem o Config Sync instalado.
• MANAGED_CLUSTER_5 está sincronizando com dois repositórios Git. A fonte de verdade <root> pertence ao administrador do cluster, e a fonte de verdade bookstore pode pertencer a uma equipe de desenvolvimento de aplicativos

Status de recursos gerenciados

O status dos recursos gerenciados pode ser um dos seguintes valores:

• InProgress: o estado real do recurso ainda não atingiu o estado especificado no manifesto do recurso. Isso significa que a reconciliação de recursos ainda não está concluída. Recursos recém-criados geralmente começam com esse status, embora alguns recursos, como ConfigMaps, sejam Current imediatamente.

• Failed: o processo de reconciliar o estado real com o estado que você quer encontrou um erro ou fez progresso insuficiente.

• Current: o estado real do recurso corresponde ao estado que você quer. O processo de reconciliação é considerado concluído até que haja alterações no estado pretendido ou real.

• Terminating: o recurso está em processo de exclusão.

• NotFound: o recurso não existe no cluster.

• Unknown: o Config Sync não determina o status do recurso.

Para desativar a exibição do status no nível do recurso, adicione --resources=false ao comando nomos status.

Sobre a última confirmação sincronizada

O comando nomos status exibe o hash de confirmação do mais recente aplicado ao cluster na saída, em status.sync.commit. Para receber esse valor, consulte o objeto RootSync ou RepoSync e observe o campo status.sync:

Por exemplo, para consultar um objeto RootSync, execute o seguinte comando:

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

Exemplo de saída:

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

Para consultar um objeto RepoSync, execute o seguinte comando:

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

Substitua NAMESPACE pelo namespace em que você criou a fonte de verdade do namespace.

Exemplo de saída:

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

Essa confirmação representa a confirmação mais recente no cluster. No entanto, nem todos os recursos no cluster são afetados por cada confirmação. Para ver a confirmação mais recente de um recurso específico, consulte o recurso específico e procure metadata.annotations.configmanagement.gke.io/token. Exemplo:

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Substitua CLUSTER_ROLE_NAME pelo nome do papel de cluster que quer consultar.

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

sinalizações de status nomos

Para personalizar o nomos status a seguir, adicione as seguintes sinalizações:

Sinalizar	Descrição
--contexts	Aceita uma lista separada por vírgulas de contextos para usar em comandos de vários clusters. O padrão é todos os contextos. Não use "" para nenhum contexto.
-h ou --help	Ajuda para o comando nomos status.
--namespace	Aceita uma string. Use a sinalização namespace para limitar o comando a uma fonte de verdade específica do namespace. Não defina essa configuração para acessar todas as fontes. Essa sinalização só estará disponível se você tiver ativado a sincronização de mais de uma fonte de verdade.
--poll	Use a sinalização poll para executar nomos status continuamente e solicitar que ela reimprima a tabela de status em um intervalo regular. Exemplo:3s Deixe essa sinalização não configurada para executar nomos status uma vez
--resources	Aceita true ou false. Se for true, nomos status vai mostrar o status no nível do recurso para sua fonte de verdade raiz ou de namespace ao sincronizar de mais de uma fonte de verdade. O valor padrão é true.
--timeout	Tempo limite para se conectar a cada cluster. O valor padrão é 3s.
--name	Aceita uma string. Use essa sinalização para filtrar o Root e o Repo Sync com o nome fornecido. Essa sinalização pode ser usada com a sinalização namespace.

Permissões necessárias

Se você é proprietário de um projeto, tem o papel RBAC cluster-admin e pode usar nomos status para qualquer cluster do projeto sem adicionar outras permissões. Se você não tiver o papel cluster-admin, poderá usar nomos status criando o seguinte ClusterRole:

1. Crie um arquivo chamado nomos-status-reader.yaml e copie o seguinte ClusterRole nele. As regras necessárias variam de acordo com o uso de objetos RootSync e RepoSync.

   Usar objetos 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"]
   

   Não usar objetos 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. Aplique o arquivo nomos-status-reader.yaml:

   kubectl apply -f nomos-status-reader.yaml
   

Verificar se há erros na fonte da verdade

Antes de confirmar uma configuração na fonte de verdade, use o comando nomos vet para verificar a sintaxe e a validade das configurações:

nomos vet

Se forem encontrados erros de sintaxe, o comando nomos vet sairá com um status diferente de zero e registrará mensagens de erro em STDERR.

Sinalizações do nomos vet

Para personalizar o comando nomos vet, adicione as seguintes sinalizações:

Sinalizar	Descrição
--clusters	Aceita uma lista separada por vírgulas de nomes de cluster para usar em comandos de vários clusters. O padrão para todos os clusters. Use "" para nenhum cluster.
-h ou --help	Ajuda para o comando nomos vet.
--namespace	Aceita uma string. Se definido, valida a fonte da verdade como uma fonte de verdade do namespace com o nome fornecido. Define --source-format=unstructured automaticamente.
--no-api-server-check	Aceita um booleano. Se true, desativa a comunicação com o servidor da API para descoberta. Para mais informações sobre essa sinalização, consulte a seção Validação do lado do servidor.
--path	Aceita uma string. O caminho para o diretório raiz da fonte da verdade do Config Sync. O padrão é ".".
--source-format	Aceita hierarchy ou unstructured. Se hierarchy ou não for definido, valida a fonte da verdade como uma fonte hierárquica da verdade. Se unstructured, valida a fonte da verdade como uma fonte de verdade não estruturada. Essa sinalização é necessária se você estiver usando uma fonte de verdade não estruturada.
--keep-output	Aceita um booleano. Se for true, a saída renderizada será salva no local que pode ser especificado com a sinalização --output.
--output	Aceita uma string. Caminho para a saída renderizada. O padrão é o diretório compiled. Se --keep-output estiver definido como false, essa sinalização será ignorada.
--format	Aceita yaml ou json. Formato da saída. O valor padrão é yaml.

Validação do lado do servidor

Se o comando nomos vet não conseguir determinar se o tipo tem namespace, a ferramenta nomos se conectará ao servidor da API. Como, por padrão, a ferramenta nomos entende os principais tipos do Kubernetes e os CRDs do Config Sync, ela só tentará se conectar ao servidor da API se houver respostas automáticas que não tenham um CRD declarado correspondente. Nesse caso, se o servidor da API não tiver o CRD aplicado, o comando nomos vet retornará o erro KNV1021. Para desativar essa verificação e suprimir os erros de CRDs ausentes, transmita a flag --no-api-server-check.

Como armazenar em cache os metadados do servidor da API

Em vez de suprimir as verificações do servidor da API, você pode armazenar em cache os dados no servidor da API para o comando nomos vet. Para armazenar seu api-resources em cache, conclua as seguintes etapas:

1. Conecte-se a um cluster que tenha todos os CRDs necessários para sua fonte de informações. Ele não precisa ter o Config Sync ativado.
2. Acesse o policyDir da sua fonte de informações. Esse é o mesmo diretório especificado no recurso ConfigManagement ou RootSync.
3. Execute o seguinte comando: kubectl api-resources > api-resources.txt. Ele cria um arquivo chamado api-resources.txt que contém a saída exata do kubectl api-resources.

De agora em diante, as execuções de nomos vet na fonte da verdade reconhecem essas definições de tipo. Se o arquivo api-resources.txt for removido ou renomeado, nomos vet não será capaz de encontrá-lo. nomos vet ainda tentará se conectar ao cluster se encontrar manifestos para tipos não declarados no api-resources.txt (a menos que --no-api-server-check seja transmitido).

O arquivo api-resources.txt afeta apenas o funcionamento da ferramenta nomos. Ele não modifica o comportamento do Config Sync de maneira alguma.

Não há problema em ter entradas extras no arquivo api-resources.txt para tipos que não estão na fonte de verdade que está sendo validada. nomos vet importa as definições, mas não faz nenhuma alteração.

Cuidado: os tipos personalizados em uma fonte de verdade precisam ter namespace ou sem namespace. O comando nomos vet não aceita tipos com escopo de namespace em alguns clusters e com escopo de cluster em outros.

Atualizar api-resources.txt

Depois de garantir que todos os CRDs que você quer inserir estão no cluster, execute o seguinte comando:

kubectl api-resources > api-resources.txt

Cuidado: evite editar api-resources.txt diretamente, porque é fácil formatar incorretamente e causar erros.

Verificar automaticamente erros de sintaxe na confirmação

Se você confirmar um arquivo com erros JSON ou YAML, o Config Sync não aplicará a alteração. No entanto, é possível evitar que esses tipos de erros cheguem à fonte da verdade usando hooks do lado do cliente ou do lado do servidor.

Usar nomos vet em um hook de pré-confirmação

É possível configurar um hook de pré-confirmação que executa nomos vet para verificar se há erros de sintaxe quando você faz uma alteração no clone do Git local do seu repositório. Se um hook de pré-confirmação sair com um status diferente de zero, a operação git commit falhará.

Observação: os hooks de pré-confirmação são executados no cliente, e não no servidor. Eles precisam ser adicionados manualmente a cada cliente, e o usuário pode ignorar ou desativá-los a qualquer momento.

Para executar o comando nomos vet como um hook de pré-confirmação, edite o arquivo .git/hooks/pre-commit na sua fonte de verdade. Observe que .git começa com um caractere .. Talvez seja necessário criar o arquivo manualmente. Adicione o comando nomos vet a uma nova linha no script. O argumento --path é opcional.

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

Verifique se o arquivo pre-commit é executável:

chmod +x .git/hooks/pre-commit

Agora, quando você executar um comando git commit no clone da sua fonte da verdade, o nomos vet será executado automaticamente.

O conteúdo do diretório .git/ não é rastreado pela fonte da verdade e não pode ser confirmado para a fonte da verdade no mesmo local. Você pode criar um diretório na fonte da verdade para hooks do Git, e as pessoas que usam a fonte de verdade podem copiar os hooks para o local apropriado em seu clone local.

Usar nomos vet em um hook do lado do servidor

O Git fornece um mecanismo para executar verificações no servidor, e não no cliente, durante uma operação de git push. Se a verificação falhar, o git push também falhará. Esses hooks do lado do servidor não podem ser ignorados pelo cliente. O método para configurar os ganchos do lado do servidor depende de como seu servidor Git está hospedado. Consulte um dos links a seguir para mais informações ou consulte a documentação do serviço de hospedagem do Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Servidor Git auto-hospedado

Conferir todas as configurações na fonte de verdade

É possível usar o comando nomos hydrate para visualizar o conteúdo combinado da fonte de verdade em cada cluster registrado.

Se você executar nomos hydrate sem opções, ele criará um diretório compiled/ no diretório de trabalho atual. Nesse diretório, um subdiretório é criado para cada cluster registrado, com as configurações totalmente resolvidas que o Operator aplicaria ao cluster.

Esse comando também pode converter uma fonte hierárquica da verdade em uma ou mais fontes não estruturadas, usando o conteúdo no diretório compiled/.

sinalizações nomos hydrate

Para personalizar o comando nomos hydrate, adicione as seguintes sinalizações:

Sinalizar	Descrição
--clusters	Aceita uma lista separada por vírgulas de nomes de cluster. Use esta sinalização para limitar a saída a um único cluster ou a uma lista de clusters. O padrão para todos os clusters. Use "" para nenhum cluster.
--flat	Se ativado, imprimir toda a saída em um único arquivo. Use essa sinalização se quiser emular o comportamento de nomos view.
-h ou --help	Ajuda para o comando nomos hydrate.
--format	Aceita um yaml ou um json. Formato da saída. O valor padrão é yaml.
--no-api-server-check	Aceita um booleano. Se true, desativa a comunicação com o servidor da API para descoberta. Para mais informações sobre essa sinalização, consulte a seção Validação do lado do servidor.
--output	Aceita uma string. O local em que a configuração hidratada será gravada. O padrão é o diretório compiled. Se --flat não estiver ativado, gravará cada manifesto de recurso como um arquivo separado. Se --flat estiver ativado, gravará em um único arquivo que contenha todos os manifestos de recursos.
--path	Aceita uma string. O caminho para o diretório raiz da fonte da verdade do Config Sync. O padrão é ".".
--source-format	Aceita hierarchy ou unstructured. Se hierarchy ou não for definido, valida a fonte da verdade como uma fonte hierárquica da verdade. Se unstructured, valida a fonte da verdade como uma fonte de verdade não estruturada. Essa sinalização é necessária se você estiver usando uma fonte de verdade não estruturada.

Criar um relatório do bug

Se você tiver um problema com o Config Sync que requer ajuda do suporte do Google Cloud, forneça informações importantes de depuração usando o comando nomos bugreport. É possível usar esse comando para uma única fonte de verdade e vários repositórios.

nomos bugreport

Esse comando gera um arquivo zip com carimbo de data / hora com informações sobre o cluster do Kubernetes definido no contexto kubectl. O arquivo contém registros dos pods do Config Sync. Ele não contém informações dos recursos sincronizados com o Config Sync. Para mais informações sobre o conteúdo do arquivo ZIP, consulte a referência de relatórios de bugs do Nomos.

Limitações

O comando nomos bugreport falha e produz um arquivo ZIP incompleto se qualquer arquivo individual exceder 1 GiB. Isso geralmente ocorre devido a arquivos de registro grandes.

A tabela a seguir inclui as causas mais comuns de arquivos de registro grandes e como você pode resolvê-los:

Causa	Ação recomendada
Maior nível de detalhes dos registros	Redução do nível de detalhes do registro com log level overrides
Objetos muito grandes	Não gerenciar o objeto grande ou reduzir o tamanho dele
Muitos objetos	Divida seu repositório em vários repositórios
Lutas entre controles	Resolver a briga

Migrar de um objeto ConfigManagement para um objeto RootSync

Observação: a partir da versão 1.19.0, o campo spec.enableMultiRepo é definido como true por padrão. Se você fez upgrade para a versão 1.19.0 ou posterior antes de executar nomos migrate, o valor de enableMultiRepo pode ter mudado de false para true. Se esse for o caso, verifique se spec.enableMultiRepo está definido explicitamente como false antes de executar nomos migrate.

É possível executar o comando nomos migrate para migrar do objeto ConfigManagement para um RootSync, para ativar as APIs RootSync e RepoSync.

Se você usou spec.enableLegacyFields para inicializar um RootSync, siga o guia para desativar campos legados em vez de usar nomos migrate. Não há mais suporte a campos legados a partir da versão 1.19.0.

O nomos migrate é compatível com simulação para a visualização prévia do processo de migração.

nomos migrate modifica diretamente seu objeto ConfigManagement no cluster. Para evitar que as alterações feitas por meio de nomos migrate sejam revertidas, verifique se o objeto ConfigManagement não está verificado na fonte de verdade.

Observação: passar a sinalização --contexts especifica os contextos a serem migrados. Isso só é necessário se você quiser migrar clusters além do contexto atual.

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

Se o resultado de simulação parecer bom, será possível migrar o objeto ConfigManagement usando nomos migrate:

nomos migrate --contexts=KUBECONFIG_CONTEXTS

A saída será assim:

--------------------
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`.

Observação: nomos migrate salva o objeto ConfigManagement original, o objeto ConfigManagement atualizado e o objeto RootSync convertido em um diretório temporário. Se nomos migrate falhar ou for encerrado inesperadamente, será possível recuperar manualmente a migração executando os comandos fornecidos na saída nomos migrate.

Reverter para a configuração anterior

Se você precisar reverter após a migração com o nomos migrate, aplique o objeto ConfigManagement original. nomos migrate salva o objeto ConfigManagement original em um arquivo e imprime o nome no terminal. O nome do arquivo tem o formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Se você quiser reverter para a configuração anterior, copie o caminho do arquivo de cm-original.yaml e aplique o arquivo ao cluster:

kubectl apply -f CM_ORIGINAL_PATH

sinalizações nomos migrate

Para personalizar o comando nomos migrate, adicione as seguintes sinalizações:

Sinalizar	Descrição
--connect-timeout	Aceita uma duração. Duração do tempo limite para se conectar a cada cluster. O padrão é 3s.
--contexts	Aceita uma lista separada por vírgulas de contextos para usar em ambientes de vários clusters. O padrão é o contexto atual. Use "all" para todos os contextos.
--dry-run	Aceita um booleano. Se true, exibe apenas a saída da migração.
-h ou --help	Ajuda para o comando nomos migrate.
--wait-timeout	Aceita uma duração. Duração do tempo limite para aguardar que as condições dos recursos do Kubernetes sejam verdadeiras. O valor padrão é 10m.

Inicializar uma fonte hierárquica de verdade

Você pode organizar sua fonte de verdade arbitrariamente se estiver usando uma fonte não estruturada de verdade. Se você estiver usando uma fonte hierárquica de verdade, precisará executar o comando nomos init para inicializar um diretório hierárquico:

nomos init

Isso cria a estrutura de diretórios básica de uma fonte hierárquica de verdade, incluindo os diretórios system/, cluster/ e namespaces/.

sinalizações nomos init

Para personalizar nomos init, adicione as sinalizações a seguir:

Sinalizar	Descrição
--force	Gravar no diretório mesmo se não estiver vazio, substituindo arquivos conflitantes
-h ou --help	Ajuda para o comando nomos init.
--path	Aceita uma string. O diretório raiz a ser usado como sua fonte de verdade. O valor padrão é "."

Solução de problemas

No Linux, talvez você veja o seguinte erro ao executar um comando nomos:

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

Para corrigir esse problema, crie uma variável de ambiente USER:

export USER=$(whoami)

A seguir

• Primeiros passos com o Config Sync