nomos bugreport 内容

nomos 命令行工具可帮助执行 Config Sync 的常见管理任务，例如生成诊断归档。归档的确切输出和布局随时可能变化，因此不会被视为 API。Config Sync 代码库中提供了 nomos 的代码。

您可以通过运行 kubectl get 或 kubectl logs 从集群中获取类似信息，但 nomos bugreport 的优势在于它会创建有关 Config Sync 系统的关键信息的归档。与 Google Cloud 支持团队联系时，提供 nomos bugreport 输出会很有帮助。

您还可以将 nomos bugreport 的输出用于您自己的调试或内部支持。

nomos bugreport 输出文件结构如下所示：

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

您可以从 nomos bugreport 获取的信息：

  1. Nomos 版本显示 Config Sync 版本，即 nomos version 的输出。
  2. Nomos 状态显示 nomos status 状态的输出，例如同步的提交以及任何错误。
  3. 有关 Config Sync 自定义资源的信息：
    1. 对于集群范围资源（例如 ConfigManagement 和 ClusterSelector），位于以下位置：raw/cluster-1/cluster/configmanagement/。
    2. 对于命名空间范围资源（例如 RootSync、RepoSync 和 ResourceGroup），位于以下位置：raw/cluster-1/namespaces/namespace-1。
  4. 由 Config Sync 同步和管理的资源：
    1. 如果您已启用 RootSync 和 RepoSync API，则它位于 ResourceGroup 的规范中。您可以获取这些资源的数量及其种类、命名空间和名称。
    2. 如果您未启用 RootSync 和 RepoSync API，并且在 ConfigManagement 对象（已弃用）中指定了 git 字段，则资源的完整内容位于 ClusterConfigs 和 NamespaceConfigs 中。您应该迁移 ConfigManagement 对象。
  5. 所有 Config Sync Pod 的日志都位于 raw/cluster-1/namespaces/pod-namespace-1/pod-name-1/container-name.txt 下。
  6. 所有 Config Sync Pod 的完整内容：位于 raw/cluster-1/namespaces/pod-namespace-1/pods.txt 下
  7. 是否启用了 Config Sync RootSync 和 RepoSync API（即使用多代码库模式）？
    1. 检查 ConfigManagement 资源，如果看到 spec.enableMultiRepo: true，则说明已启用 RootSync API 和 RepoSync API。
    2. 如果看到 RootSync、RepoSync 或协调器 Pod 等组件，则说明您已启用 RootSync 和 RepoSync API。
    3. 如果看到 git-importer Pod 等组件，则说明 RootSync 和 RepoSync API 未启用，并且您需要迁移 ConfigManagement 对象。