conteúdo do relatório de bug nomos

A ferramenta de linha de comando nomos ajuda com tarefas administrativas comuns do Config Sync, como a produção de um arquivo de diagnóstico. A saída e o layout exatos do arquivo estão sujeitos a alterações e não são considerados uma API. O código de nomos está disponível no repositório do Config Sync.

É possível conseguir informações semelhantes do cluster executando kubectl get ou kubectl logs, mas a vantagem de nomos bugreport é que ele cria um arquivo de informações importantes sobre o sistema Config Sync. Quando você entrar em contato com o suporte do Google Cloud, será útil fornecer a saída nomos bugreport.

Também é possível usar a saída de nomos bugreport para sua própria depuração ou compatibilidade interna.

A estrutura do arquivo de saída nomos bugreport tem esta aparência:

- raw/
  - cluster/
    - configmanagement/
  - namespaces/
    - config-management-monitoring/
    - config-management-system/
    - gatekeeper-system/
    - resource-group-system/
    - kube-system/
- processed/
  - status.txt
  - version.txt

As informações que você pode receber de nomos bugreport:

1. A versão do Nomos mostra a versão do Config Sync, a saída de nomos version.
2. O status de Nomos mostra a saída do status nomos status, por exemplo, qual commit é sincronizado e os erros.
3. Informações sobre os recursos personalizados do Config Sync:
   1. Para recursos com escopo de cluster, como ConfigManagement e ClusterSelectors, estão localizados aqui: raw/cluster-1/cluster/configmanagement/.
   2. Para escopos com escopo de namespace, como RootSync, RepoSync e ResourceGroup, estão localizados aqui: raw/cluster-1/namespaces/namespace-1.
4. Recursos sincronizados e gerenciados pelo Config Sync:
   1. Se você tiver as APIs RootSync e RepoSync ativadas, ele está na especificação do ResourceGroup. Você pode ver a contagem desses recursos e os tipos, namespaces e nomes deles.
   2. Se você não tiver as APIs RootSync e RepoSync ativadas e especificar campos git no objeto ConfigManagement (descontinuado), o conteúdo completo dos recursos estará em ClusterConfigs e NamespaceConfigs. Migre o objeto ConfigManagement.
5. Os registros de todos os pods do Config Sync estão em raw/cluster-1/namespaces/pod-namespace-1/pod-name-1/container-name.txt.
6. O conteúdo completo de todos os pods do Config Sync: em raw/cluster-1/namespaces/pod-namespace-1/pods.txt.
7. As APIs RootSync e RepoSync do Config Sync estão ativadas (ou seja, usando o modo de vários repositórios)?
   1. Verifique o recurso ConfigManagement e, se você vir spec.enableMultiRepo: true, as APIs RootSync e RepoSync estão ativadas.
   2. Se você vir componentes como RootSync, RepoSync ou pods de reconciliação, isso significa que as APIs RootSync e RepoSync estão ativadas.
   3. Se houver componentes como o pod git-importer, as APIs RootSync e RepoSync não estão ativadas e você precisa migrar seu objeto ConfigManagement.