Creating an unstructured repo lets you organize your repo arbitrarily, without following the default repo directory structure. Config Sync syncs the same set of Kubernetes objects to your cluster as in the default, hierarchical, repo.
This feature lets you sync your existing Kubernetes configuration to your
Config Sync repo. For example, if you want to sync a
Helm chart to your cluster, you can run
helm template
and
commit the rendered manifest to your repo. An unstructured repo also lets you
create subfolders of resources.
Limitations
Unstructured repos have the following limitations:
You cannot use the
Repo
orHierarchyConfig
Kubernetes objects in an unstructured repo.Abstract namespaces are not supported in unstructured repos.
Unstructured mode does not support a repo in the root directory of your Git repository. You must declare
policyDir
to be a directory within your repository. For example, if your Git repository on your local machine is atfoo-corp/
, you can place your configs infoo-corp/policies
and declarepolicyDir: policies
.
Namespace-scoped objects
You can declare NamespaceSelectors in an unstructured repo. To declare a
NamespaceSelector, add either the metadata.namespace
or the NamespaceSelector
annotation. Declaring both annotations is invalid. If namespace-scoped
resources don't declare metadata.namespace
or the NamespaceSelector
annotation, then Config Sync uses the cluster's "default" namespace.
Unlike with an hierarchical repo, an unstructured repo does not have to declare
all namespaces for the namespace-scoped objects in the repo. An object can
define a metadata.namespace
without having a matching namespace object in the
repo. If the namespace already exists on the cluster, Config Sync
creates the object within that namespace. If the namespace does not exist on the
cluster yet, Config Sync creates the namespace implicitly.
In an unstructured repo, Objects that declare the NamespaceSelector
annotation
are applied to all namespaces that satisfy the NamespaceSelector's
conditions.
Before you create an unstructured repo with Objects that were previously used in
a hierarchical repo, verify that your NamespaceSelectors
do not apply to
additional resources.
When you remove namespace-scoped objects from an unstructured repo, Config Sync deletes those objects, but it does not remove any namespaces that might have been created implicitly for those objects. This behavior happens because Config Sync can't infer when it's safe to delete a namespace that was created implicitly, so it's always left on the cluster.
Cluster-scoped objects
In an unstructured repo, ClusterSelectors
function normally.
Configuring an unstructured repo
To configure an unstructured repo, set the value of spec.sourceFormat
to
unstructured
in config-management.yaml
.
For example, the following config-management.yaml
sets up a Continuous
Integration pipeline.
# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
name: config-management
spec:
# clusterName is required and must be unique among all managed clusters
clusterName: my-cluster
git:
syncRepo: https://github.com/GoogleCloudPlatform/csp-config-management/
syncBranch: 1.0.0
secretType: ssh
policyDir: ci-pipeline-unstructured
sourceFormat: unstructured
What's next
- Create cluster-scoped objects
- Create namespace-scoped objects