Use a ferramenta de linha de comandos nomos

A ferramenta de linha de comandos nomos é uma ferramenta opcional para o Config Sync que pode usar para obter o estado do Config Sync e o estado de sincronização da sua fonte de informações fidedignas. A ferramenta nomos oferece-lhe os seguintes comandos:

Comando	Utilização
nomos status	Verifique o estado do Config Sync
nomos vet	Verifique se existem erros na fonte de dados fidedigna
nomos hydrate	Veja todas as configurações na fonte de confiança
nomos bugreport	Crie um relatório de erro
nomos migrate	Migre do objeto ConfigManagement para o RootSync
nomos init	Inicialize uma fonte hierárquica de informações fidedignas

Pré-requisitos

Antes de poder usar a ferramenta nomos para interagir com um cluster, o Config Sync tem de estar instalado no cluster de destino. Também tem de instalar e configurar a kubectlferramenta de linha de comandos. Se estiver a interagir com clusters do Google Kubernetes Engine, certifique-se de que também instala o gke-gcloud-auth-plugin.

A ferramenta nomos suporta a pré-visualização e a validação de configurações do Kustomize e gráficos do Helm. Antes de poder usar esta funcionalidade, instale o Kustomize e o Helm na sua estação de trabalho local. Se a sua fonte de dados fidedignos contiver apenas configurações totalmente renderizadas, o Kustomize e o Helm são opcionais.

Instale a ferramenta nomos

A ferramenta nomos é um ficheiro binário compilado a partir de código Go e pode instalá-lo localmente, por exemplo, numa estação de trabalho ou num portátil.

A ferramenta nomos não está incluída quando instala o Config Sync. Pode instalar a ferramenta nomos instalando a CLI do Google Cloud. Se usar o Cloud Shell, a CLI do Google Cloud é pré-instalada.

Se não tiver a CLI do Google Cloud, recomendamos que use gcloud components install nomos para instalar a ferramenta nomos. A instalação da ferramenta nomos com a CLI Google Cloud permite-lhe usar gcloud components update para atualizar a ferramenta nomos para a versão mais recente.

Para obter informações sobre formas alternativas de instalar a ferramenta nomos, consulte a secção Transferências.

Utilização básica

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 de informação fidedigna. Use a flag --path para especificar a localização do nível superior da fonte de dados fidedignos. Por predefinição, --path está definido como . ou o diretório atual. Por exemplo:

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

Verifique o estado da sincronização de configuração

Pode monitorizar o estado da sincronização de configuração em todos os clusters inscritos através do comando nomos status. Para cada cluster, nomos status comunica o hash da confirmação que foi aplicada mais recentemente ao cluster e quaisquer erros que ocorreram ao tentar aplicar alterações recentes.

Também pode usar o comando nomos status para verificar se os recursos geridos pela sincronização de configuração estão prontos. nomos status comunica o estado de cada recurso individual na coluna STATUS da secção Managed resources da saída.

O exemplo seguinte mostra algumas das diferentes condições que o comando nomos status pode comunicar:

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

Neste resultado:

• MANAGED_CLUSTER_1 sincronizou a alteração mais recente à fonte prioritária e todos os recursos geridos têm o estado Current. Um estado de Current significa que o estado do recurso corresponde ao estado pretendido.
• MANAGED_CLUSTER_2 ainda está a sincronizar.
• MANAGED_CLUSTER_3 tem um erro que impediu a aplicação da alteração. Neste exemplo, MANAGED_CLUSTER_3 tem o erro KNV1021 porque lhe falta uma CustomResourceDefinition (CRD) que os outros clusters têm instalada.
• O cluster MANAGED_CLUSTER_4 não tem o Config Sync instalado.
• O MANAGED_CLUSTER_5 está a ser sincronizado a partir de dois repositórios Git. A <root>fonte de informação pertence ao administrador do cluster e a bookstore fonte de informação pode pertencer a uma equipa de desenvolvimento de aplicações.

Estados dos recursos geridos

O estado dos seus recursos geridos pode ter um dos seguintes valores:

• InProgress: o estado real do recurso ainda não atingiu o estado que especificou no manifesto de recursos. Este estado significa que a sincronização de recursos ainda não está concluída. Os recursos recém-criados começam normalmente com este estado, embora alguns recursos, como os ConfigMaps, sejam Current imediatamente.

• Failed: o processo de conciliação do estado real com o estado pretendido encontrou um erro ou não progrediu o suficiente.

• Current: o estado real do recurso corresponde ao estado pretendido. O processo de conciliação é considerado concluído até haver alterações ao estado pretendido ou real.

• Terminating: o recurso está a ser eliminado.

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

• Unknown: o Config Sync não consegue determinar o estado do recurso.

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

Acerca da última consolidação sincronizada

O comando nomos status apresenta o hash de confirmação mais recente que foi aplicado ao cluster na respetiva saída em status.sync.commit. Para obter este valor, consulte o objeto RootSync ou RepoSync e procure 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 espaço de nomes no qual criou a sua fonte de dados fidedigna do espaço de nomes.

Exemplo de saída:

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

Esta confirmação representa a confirmação mais recente em relação ao 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 veja metadata.annotations.configmanagement.gke.io/token. Por exemplo:

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Substitua CLUSTER_ROLE_NAME pelo nome da função de cluster que quer consultar.

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

nomos status flags

Para personalizar o comando nomos status, adicione as seguintes flags:

Bandeira	Descrição
--contexts	Aceita uma lista de contextos separados por vírgulas para usar em comandos de vários clusters. Predefinição para todos os contextos. Use "" para não ter contextos.
-h ou --help	Ajuda para o comando nomos status.
--name	Aceita uma string. Use esta flag para filtrar a sincronização de repositórios e raiz com o nome fornecido. Esta flag pode ser usada juntamente com a flag namespace.
--namespace	Aceita uma string. Use a flag namespace para limitar o comando a uma origem de dados fidedignos de espaço de nomes específica. Deixe a opção não definida para obter todas as fontes. Esta flag só está disponível se tiver ativado a sincronização a partir de mais do que uma fonte de informação fidedigna.
--poll	Use a flag poll para executar o comando nomos status continuamente e fazer com que volte a imprimir a tabela de estado a um intervalo regular. Por exemplo, 3s. Deixe esta flag não definida para executar nomos status uma vez
--resources	Aceita true ou false. Se true, nomos status mostrar o estado ao nível do recurso para a sua origem de dados ou espaço de nomes quando sincroniza a partir de mais de uma origem de dados. O valor predefinido é true.
--timeout	Limite de tempo para a ligação a cada cluster. O valor predefinido é 3s.

Autorizações necessárias

Se for proprietário de um projeto, tem a função RBAC e pode usar o comando nomos status para quaisquer clusters no seu projeto sem adicionar mais autorizações.cluster-admin Se não tiver a função cluster-admin, pode usar o nomos status criando o seguinte ClusterRole:

1. Crie um ficheiro com o nome nomos-status-reader.yaml e copie o seguinte ClusterRole para o mesmo. As regras de que precisa variam consoante esteja a usar 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 ficheiro nomos-status-reader.yaml:

   kubectl apply -f nomos-status-reader.yaml
   

Verifique se existem erros na fonte de confiança

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

nomos vet --source-format unstructured

Se forem encontrados erros de sintaxe, o comando nomos vet termina com um estado diferente de zero e regista mensagens de erro em STDERR.

nomos vet flags

Para personalizar o comando nomos vet, adicione as seguintes flags:

Bandeira	Descrição
--api-server-timeout	Aceita uma string de duração. Define o limite de tempo do lado do cliente para comunicar com o servidor da API Kubernetes. A predefinição é 15s.
--clusters	Aceita uma lista de nomes de clusters separados por vírgulas para usar em comandos de vários clusters. A predefinição é todos os clusters. Use "" para não ter clusters.
--format	Aceita yaml ou json. O formato da saída. O valor predefinido é yaml.
-h ou --help	Ajuda para o comando nomos vet.
--keep-output	Aceita um valor Booleano. Se true, o resultado renderizado é guardado na localização que pode especificar com a flag --output.
--namespace	Aceita uma string. Se estiver definido, valida a origem de dados como uma origem de dados de espaço de nomes com o nome fornecido. Define automaticamente --source-format=unstructured.
--no-api-server-check	Aceita um valor Booleano. Se true, desativa a comunicação com o servidor da API Kubernetes para deteção. Para mais informações sobre esta flag, consulte a secção Validação do lado do servidor.
--output	Aceita uma string. O caminho para a saída renderizada. A predefinição é o diretório compiled. Se --keep-output estiver definido como false, este sinalizador é ignorado.
--path	Aceita uma string. O caminho para o diretório raiz da sua fonte de informações verdadeiras do Config Sync. A predefinição é "."
--source-format	Aceita hierarchy ou unstructured. Se hierarchy ou não estiver definido, valida a fonte de informações verdadeiras como uma fonte de informações verdadeiras hierárquica. Se unstructured, valida a fonte de informações fidedignas como uma fonte de informações fidedignas não estruturada. Esta flag é obrigatória se estiver a usar uma fonte de informações fidedignas não estruturada.
--threshold	Aceita opcionalmente um número inteiro. Define o número máximo de objetos permitidos por repositório; gera um erro se for excedido. Omita a flag ou use --threshold=0 para desativar a validação de objetos máximos. Indique a flag sem um valor para usar o valor predefinido 1000 ou use --threshold=N para definir um limite específico.

Validação do lado do servidor

Se o comando nomos vet não conseguir determinar se o tipo tem espaço de nomes, a ferramenta nomos estabelece ligação ao servidor da API do contexto kubectl atual. Uma vez que a ferramenta nomos compreende por predefinição os tipos principais do Kubernetes e os CRDs do Config Sync, só tenta estabelecer ligação ao servidor da API se os CRs não tiverem um CRD declarado correspondente. Neste caso, se o servidor da API não tiver o CRD aplicado, o comando nomos vet devolve error KNV1021. Para desativar esta verificação e suprimir erros de CRDs em falta, transmita a flag --no-api-server-check.

Colocar em cache os metadados do servidor da API

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

1. Faça a ligação a um cluster que tenha todos os CRDs de que precisa para a sua fonte de verdade. O cluster não precisa de ter o Config Sync ativado.
2. Aceda ao policyDir da sua fonte prioritária. Este é o mesmo diretório especificado no recurso ConfigManagement ou RootSync.
3. Execute o seguinte comando: kubectl api-resources > api-resources.txt Este comando cria um ficheiro denominado api-resources.txt que contém o resultado exato de kubectl api-resources.

A partir de agora, as execuções de nomos vet na fonte de informação fidedigna têm conhecimento dessas definições de tipos. Se o ficheiro api-resources.txt for removido ou tiver o nome alterado, nomos vet não consegue encontrar o ficheiro. nomos vet continua a tentar estabelecer ligação ao cluster se encontrar manifestos para tipos não declarados em api-resources.txt (a menos que --no-api-server-check seja transmitido).

O ficheiro api-resources.txt afeta apenas o funcionamento da ferramenta nomos. Não modifica o comportamento da sincronização de configuração de forma alguma.

Não há problema em ter entradas adicionais no ficheiro api-resources.txt que sejam para tipos que não estão na fonte de dados fidedignos que está a ser validada. nomos vet importa as definições, mas não faz nada com elas.

Aviso: os tipos personalizados numa fonte de dados fidedigna têm de ter um espaço de nomes ou não ter um espaço de nomes. O comando nomos vet não suporta tipos com âmbito de espaço de nomes em alguns clusters e âmbito de cluster noutros.

Atualize o ficheiro api-resources.txt

Depois de garantir que todas as CRDs pretendidas estão no cluster, execute o seguinte comando:

kubectl api-resources > api-resources.txt

Atenção: evite editar diretamente api-resources.txt, pois é fácil formatar incorretamente e causar erros.

Verificar automaticamente se existem erros de sintaxe ao confirmar

Se confirmar um ficheiro com erros JSON ou YAML, o Config Sync não aplica a alteração. No entanto, pode impedir que estes tipos de erros entrem na fonte de dados fidedignos usando hooks do lado do cliente ou do lado do servidor.

Use nomos vet num comando pre-commit

Pode configurar um comando pre-commit que execute o comando nomos vet para verificar se existem erros de sintaxe quando confirma uma alteração no clone local do Git do seu repositório. Se um comando pre-commit terminar com um estado diferente de zero, a operação git commit falha.

Nota: os hooks de pré-commit são executados no cliente e não no servidor. Têm de ser adicionados manualmente a cada cliente, e o utilizador pode ignorá-los ou desativá-los em qualquer altura.

Para executar o comando nomos vet como um gancho de pré-commit, edite o ficheiro .git/hooks/pre-commit na sua fonte de verdade (tenha em atenção que .git começa com um caráter .). Pode ter de criar o ficheiro manualmente. Adicione o comando nomos vet a uma nova linha no guião. O argumento --path é opcional. Defina o argumento --source-format para o formato de origem do repositório.

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

Certifique-se de que o ficheiro pre-commit é executável:

chmod +x .git/hooks/pre-commit

Agora, quando executa um comando git commit no clone da sua fonte de dados fidedigna, o nomos vet é executado automaticamente.

O conteúdo do diretório .git/ não é monitorizado pela própria fonte de dados fidedignos e não pode ser confirmado na fonte de dados fidedignos na mesma localização. Pode criar um diretório na fonte de informação para os comandos Git e as pessoas que usam a fonte de informação podem copiar os comandos para o local adequado no respetivo clone local.

Use nomos vet num gancho do lado do servidor

O Git oferece um mecanismo para executar verificações no servidor, em vez de no cliente, durante uma operação git push. Se a verificação falhar, a git push também falha. Estes hooks do lado do servidor não podem ser ignorados pelo cliente. O método de configuração dos comandos do lado do servidor depende da forma como o seu servidor Git está alojado. Consulte um dos seguintes links para mais informações ou consulte a documentação do seu serviço de alojamento do Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Servidor Git com alojamento próprio

Aplique o número máximo de objetos a sincronizar

O Config Sync armazena uma referência a cada objeto que sincroniza num objeto de inventário ResourceGroup, juntamente com o estado atual do objeto. Uma vez que o Kubernetes tem um limite de tamanho em bytes para objetos de recursos, isto limita o número máximo de objetos que o Config Sync pode sincronizar com um único RootSync ou RepoSync.

Por predefinição, o limite de tamanho do etcd do lado do servidor é de 1,5 MiB. Para ver mais detalhes, consulte a documentação do etcd. A aplicação de um objeto superior a este limite provoca um dos seguintes erros, consoante o tamanho do objeto:

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

Para se proteger contra objetos ResourceGroup que excedam o limite de tamanho do Kubernetes, pode usar o comando nomos vet --threshold para validar o número de objetos no seu repositório de origem.

Por predefinição, quando usa o comando nomos vet, o limite não é aplicado. A transmissão da flag --threshold faz com que o comando vet apresente um erro se o número de objetos no repositório de origem exceder o limite.

O inventário ResourceGroup contém referências de objetos e o estado atual do objeto. Pode aumentar significativamente quando os objetos não são sincronizados ou reconciliados. Para evitar exceder o limite de tamanho do objeto Kubernetes, escolha um limite que deixe capacidade suficiente para registar erros de objetos. O valor predefinido de 1000 deve funcionar para quase todos os casos, mas pode aumentar ou diminuir o limite conforme necessário.

Este limite só é validado pelo comando nomos vet e não pela própria sincronização de configuração. Para aplicar o limite, use o comando nomos vet --threshold numa verificação de pré-envio de um repositório de origem ou no gancho de pré-commit do Git.

Veja todas as configurações na fonte de dados fidedigna

Pode usar o comando nomos hydrate para ver os conteúdos combinados da sua fonte de dados fidedigna em cada cluster inscrito.

Se executar nomos hydrate sem opções, cria um diretório compiled/ no diretório de trabalho atual. Nesse diretório, é criado um subdiretório para cada cluster inscrito, com as configurações totalmente resolvidas que o operador aplicaria ao cluster.

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

nomos hydrate flags

Para personalizar o comando nomos hydrate, adicione as seguintes flags:

Bandeira	Descrição
--api-server-timeout	Aceita uma string de duração. Define o limite de tempo do lado do cliente para comunicar com o servidor da API Kubernetes. A predefinição é 15s.
--clusters	Aceita uma lista de nomes de clusters separados por vírgulas. Use esta flag para limitar o resultado a um único cluster ou a uma lista de clusters. Predefinição para todos os clusters. Use "" para não ter clusters.
--flat	Se estiver ativada, imprime toda a saída num único ficheiro. Use esta flag se quiser emular o comportamento de nomos view.
--format	Aceita um yaml ou um json. O formato da saída. O valor predefinido é yaml.
-h ou --help	Ajuda para o comando nomos hydrate.
--no-api-server-check	Aceita um valor Booleano. Se true, desativa a comunicação com o servidor da API para a descoberta. Para mais informações sobre esta flag, consulte a secção Validação do lado do servidor.
--output	Aceita uma string. A localização para escrever a configuração hidratada. A predefinição é o diretório compiled. Se --flat não estiver ativado, escreve cada manifesto de recursos como um ficheiro separado. Se --flat estiver ativado, escreve um único ficheiro com todos os manifestos de recursos.
--path	Aceita uma string. O caminho para o diretório raiz da sua fonte de informações verdadeiras do Config Sync. A predefinição é "."
--source-format	Aceita hierarchy ou unstructured. Se hierarchy ou não estiver definido, valida a fonte de informações verdadeiras como uma fonte de informações verdadeiras hierárquica. Se unstructured, valida a fonte de informações fidedignas como uma fonte de informações fidedignas não estruturada. Esta flag é obrigatória se estiver a usar uma fonte de informações fidedignas não estruturada.

Crie um relatório de erro

Se tiver um problema com a sincronização de configuração que exija ajuda do Google Cloud apoio técnico, pode fornecer-lhe informações de depuração valiosas através do comando nomos bugreport. Pode usar este comando para uma única fonte de informação fidedigna e vários repositórios.

nomos bugreport

Este comando gera um ficheiro ZIP com indicação de data/hora com informações sobre o conjunto de clusters do Kubernetes definido no seu contexto kubectl. O ficheiro também contém registos dos pods do Config Sync. Não contém informações dos recursos sincronizados com o Config Sync. Para mais informações acerca do conteúdo do ficheiro ZIP, consulte a referência do bugreport do nomos.

Limitações

O comando nomos bugreport falha e produz um ficheiro ZIP incompleto se qualquer ficheiro individual exceder 1 GiB. Isto ocorre frequentemente devido a ficheiros de registo grandes.

A tabela seguinte inclui as causas mais comuns de ficheiros de registo grandes e como pode resolvê-las:

Causa	Ação recomendada
Aumento da verbosidade do registo	Reduza a verbosidade dos registos com substituições do nível de registo
Objetos muito grandes	Anule a gestão do objeto grande ou reduza o respetivo tamanho
Muitos objetos	Divida o repositório em vários repositórios
Combates de controladores	Resolva a discussão

Migre de um objeto ConfigManagement para um objeto RootSync

Pode executar o comando nomos migrate para migrar do objeto ConfigManagement para um objeto RootSync para ativar as APIs RootSync e RepoSync.

O nomos migrate suporta a execução de teste para pré-visualizar o processo de migração.

nomos migrate modifica diretamente o objeto ConfigManagement no cluster. Para evitar a reversão das alterações feitas através do nomos migrate, certifique-se de que o objeto ConfigManagement não está registado na sua fonte de dados fidedigna.

Nota: a transmissão da flag --contexts especifica os contextos a migrar. Isto só é necessário se quiser migrar clusters para além do contexto atual.

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

Se o resultado do teste de execução parecer bom, pode migrar o objeto ConfigManagement usando nomos migrate:

nomos migrate --contexts=KUBECONFIG_CONTEXTS

O resultado é semelhante ao seguinte:

--------------------
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 guarda o objeto ConfigManagement original, o objeto ConfigManagement atualizado e o objeto RootSync convertido num diretório temporário. Se nomos migrate falhar ou for terminado inesperadamente, pode recuperar manualmente a migração executando os comandos fornecidos na saída de nomos migrate.

Reverta para a configuração anterior

Se precisar de reverter após realizar a migração com nomos migrate, aplique o objeto ConfigManagement original. nomos migrate guarda o objeto ConfigManagement original num ficheiro e imprime o nome no terminal. O nome do ficheiro tem o formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Para reverter para a configuração anterior, copie o caminho do ficheiro para cm-original.yaml e aplique o ficheiro ao cluster:

kubectl apply -f CM_ORIGINAL_PATH

nomos migrate flags

Para personalizar o comando nomos migrate, adicione as seguintes flags:

Bandeira	Descrição
--connect-timeout	Aceita uma duração. Duração do limite de tempo para a ligação a cada cluster. Predefinição para 3s.
--contexts	Aceita uma lista de contextos separados por vírgulas para usar em ambientes com vários clusters. A predefinição é o contexto atual. Use "all" para todos os contextos.
--dry-run	Aceita um valor booleano. Se true, imprime apenas o resultado da migração.
-h ou --help	Ajuda para o comando nomos migrate.
--remove-configmanagement	Aceita um valor booleano. Se true, migra para o Config Sync de OSS removendo o operador ConfigManagement e o CRD ConfigManagement.
--wait-timeout	Aceita uma duração. Duração do limite de tempo para aguardar que as condições dos recursos do Kubernetes sejam verdadeiras. A predefinição é 10m.

Inicialize uma fonte de informação hierárquica

Pode organizar a sua fonte de informações fidedignas arbitrariamente se estiver a usar uma fonte de informações fidedignas não estruturada. Se estiver a usar uma fonte prioritária hierárquica, tem de executar o comando nomos init para inicializar um diretório hierárquico:

nomos init

Isto cria a estrutura de diretórios básica de uma fonte de informação hierárquica, incluindo os diretórios system/, cluster/ e namespaces/.

nomos init flags

Para personalizar nomos init, adicione os seguintes sinalizadores:

Bandeira	Descrição
--force	Escrever no diretório mesmo que não esteja vazio, substituindo ficheiros em conflito
-h ou --help	Ajuda para o comando nomos init.
--path	Aceita uma string. O diretório raiz a usar para a sua fonte de dados tradicionais. O valor predefinido é "."

Resolução de problemas

No Linux, pode ver 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 este problema, crie uma variável de ambiente USER:

export USER=$(whoami)

O que se segue?

• Comece a usar o Config Sync