Hierarchy Controller replicates selected Kubernetes objects from parent namespaces to their descendants within a cluster. It provides a way to define a Secret or configuration once without checking the Secret into Git. section 11.5
A HierarchyConfiguration in a namespace names its parent. This namespace relationship is separate from a hierarchy repository: the repository organizes configuration files, while Hierarchy Controller uses declared parent relationships to propagate objects. section 11.2.2
Propagation is limited by default to RBAC Roles and RoleBindings. To replicate ConfigMaps and Secrets as well, configure those object types with mode: propagate in an HNCConfiguration. section 11.3.2
apiVersion: hnc.x-k8s.io/v1alpha1
kind: HNCConfiguration
metadata:
name: config
spec:
types:
- apiVersion: v1
kind: ConfigMap
mode: propagate
- apiVersion: v1
kind: Secret
mode: propagate
The HNCConfiguration declares ConfigMap and Secret as additional propagated types. section 11.3.2
apiVersion: hnc.x-k8s.io/v1alpha2 kind: HierarchyConfiguration metadata: name: hierarchy spec: parent: central
The HierarchyConfiguration sets central as a namespace’s parent. section 11.3.2
Replicating shared application configuration
An organization runs GKE in Google Cloud and GKE on VMware in its data center. In each cluster, it uses Hierarchy Controller to propagate Secrets and ConfigMaps from a central namespace to application and project namespaces. A Secret can be applied to central and copied to descendants without being committed to the policy repository; this is replication within each cluster, not between the two clusters. section 11.3.2 section 11.5
When using Anthos Config Management, the cluster’s ConfigManagement object determines whether Hierarchy Controller is active. Define parent relationships and propagation types separately; choosing a hierarchy repository alone does not enable namespace inheritance. section 11.2.2 section 11.3.2
