[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-01。"],[],[],null,["# Use an unstructured repository\n\nUsing an *unstructured repository* lets you organize your repository in the way that is most\nconvenient to you. This flexibility lets you sync your existing Kubernetes\nconfiguration to your Config Sync repository. For example, if you want to sync a\n[Helm](https://helm.sh/) chart to your cluster, you can run the\n[`helm template`](https://helm.sh/docs/helm/helm_template/) command\nand commit the rendered manifest to your repository. For more information,\nsee the [Using Config Sync with Helm](/kubernetes-engine/enterprise/config-sync/docs/tutorials/config-sync-helm)\ntutorial.\n\nWe recommend unstructured repos for most use cases. However, you can also create\na [hierarchical repository](/kubernetes-engine/enterprise/config-sync/docs/concepts/hierarchical-repo) to\nseparate configs into distinct categories.\n\nLimitations\n-----------\n\nUnstructured repositories have the following limitations:\n\n- You cannot use the\n [`HierarchyConfig`](/kubernetes-engine/enterprise/config-sync/docs/how-to/namespace-scoped-objects#disabling_inheritance_for_an_object_type)\n Kubernetes object in an unstructured repository.\n\n- [Abstract namespaces](/kubernetes-engine/enterprise/config-sync/docs/concepts/hierarchical-repo#namespace-inheritance) are not\n supported in unstructured repositories.\n\n- If you are using the\n [`nomos vet` command](/kubernetes-engine/enterprise/config-sync/docs/how-to/nomos-command#vet), add\n the `--source-format=unstructured` flag. For example:\n\n nomos vet --source-format=unstructured\n\nNamespace-scoped objects\n------------------------\n\nYou can declare NamespaceSelectors in an unstructured repository. To declare a\nNamespaceSelector, add either the `metadata.namespace` or the `NamespaceSelector`\nannotation. Declaring both annotations is invalid. If namespace-scoped\nresources don't declare `metadata.namespace` or the `NamespaceSelector`\nannotation, then Config Sync uses the \"default\" namespace of the cluster.\nTo learn more, see [Limit which namespaces a config affects](/kubernetes-engine/enterprise/config-sync/docs/how-to/namespace-scoped-objects#namespaceselectors).\n\nCluster-scoped objects\n----------------------\n\nIn an unstructured repository, `ClusterSelectors` function normally.\n\nConfigure an unstructured repository\n------------------------------------\n\nTo configure an unstructured repository, set the value of `spec.sourceFormat` to\n`unstructured` in your RootSync object: \n\n # root-sync.yaml\n apiVersion: configsync.gke.io/v1beta1\n kind: RootSync\n metadata:\n name: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eROOT_SYNC_NAME\u003c/span\u003e\u003c/var\u003e\n namespace: config-management-system\n spec:\n sourceFormat: unstructured\n git:\n repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples\n branch: main\n dir: config-sync-quickstart/multirepo/root\n auth: ssh\n secretRef:\n name: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eSECRET_NAME\u003c/span\u003e\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eROOT_SYNC_NAME\u003c/var\u003e: add the name of your RootSync object. The name should be unique in the cluster and have no more than 26 characters.\n- \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e with the name of the Secret.\n\nConvert a hierarchical repository to an unstructured repository\n---------------------------------------------------------------\n\nIf you're using a [hierarchical repository](/kubernetes-engine/enterprise/config-sync/docs/concepts/hierarchical-repo)\nand want to convert it to an [unstructured repository](/kubernetes-engine/enterprise/config-sync/docs/how-to/unstructured-repo),\nin your repository, run: \n\n```\nnomos hydrate PATH\n```\n\nReplace \u003cvar translate=\"no\"\u003ePATH\u003c/var\u003e with the path to your directory.\n\nThis command creates a `compiled/` directory in the current working directory. Within\nthat directory, a subdirectory is created for each enrolled cluster, with the\nfully resolved configs, and each subdirectory can be used in an unstructured\nrepository.\n\nFor more details, see [`nomos` commands](/kubernetes-engine/enterprise/config-sync/docs/how-to/nomos-command#hydrate).\n\nIf you prefer converting your repository manually, complete the following\ninstructions:\n\n1. Remove `Repo` configs in the `system/` directory from your Git repository.\n The `Repo` resource is not needed for an unstructured repository.\n\n2. The [abstract namespace directory](/kubernetes-engine/enterprise/config-sync/docs/concepts/hierarchical-repo#namespace-inheritance)\n isn't supported in an unstructured repository. Therefore, you must declare the\n namespace of all resources originally included in the `namespaces/` directory and\n its subdirectories.\n\n3. [Namespace inheritance](/kubernetes-engine/enterprise/config-sync/docs/concepts/hierarchical-repo#namespace-inheritance)\n isn't supported in the unstructured repository. Therefore, you must declare all\n resources that are originally inherited in descendant namespaces, namely the\n ones originally under the `namespaces/` directory.\n\nExample format for an unstructured repository\n---------------------------------------------\n\nThe following example demonstrates how you might organize your configs\n(including Google Cloud resources) in an unstructured repository: \n\n ├── manifests\n │ ├── access-control\n │ │ ├── ...\n │ ├── change-control\n │ │ ├── ...\n │ ├── git-ops\n │ │ └── ...\n │ ├── logging-monitoring\n │ │ └── ...\n │ ├── networking\n │ │ └── ...\n │ ├── project-factory\n │ │ └── ...\n │ └── resource-hierarchy\n │ │ └── ...\n ├── raw-configs\n │ ├── access-control\n │ │ └── ...\n │ ├── change-control\n │ │ └── ...\n │ ├── git-ops\n │ │ └── ...\n │ ├── logging-monitoring\n │ │ └── ...\n │ ├── networking\n │ │ └── ...\n │ ├── project-factory\n │ │ └── ...\n │ └── resource-hierarchy\n │ │ └── ...\n └── scripts\n └── render.sh\n\nIn this example, the raw configs are in a `raw-configs` directory. You could\nthen use a script or an automated pipeline to render the raw configs and store\nthe output in the `manifests` directory. When you\n[configure Config Sync](/kubernetes-engine/enterprise/config-sync/docs/how-to/installing-config-sync#configuring-config-sync),\nyou'd configure it to sync from your `manifests` directory.\n\nWhat's next\n-----------\n\n- Create [cluster-scoped objects](/kubernetes-engine/enterprise/config-sync/docs/how-to/cluster-scoped-objects)\n- Create [namespace-scoped objects](/kubernetes-engine/enterprise/config-sync/docs/how-to/namespace-scoped-objects)\n- [Install Config Sync](/kubernetes-engine/enterprise/config-sync/docs/how-to/installing-config-sync)\n- [Configure syncing from multiple repositories](/kubernetes-engine/enterprise/config-sync/docs/how-to/multiple-repositories)"]]