Namespace Management

In a Kubernetes cluster, workloads are deployed into a namespace. Multi-cluster deployments mean each namespace must exists in multiple clusters. If you want to manage these namespaces in a unified manner, karmada-controller-manager namespace sync controller is a solution, which propagates namespaces from Karmada to member clusters.

Default namespace propagation

All namespaces, except those reserved, will be propagated to all member clusters. Reserved namespaces are karmada-system,karmada-cluster, karmada-es-*, kube-* (configured via cli option, see below), and default.

Skip namespace auto propagation

If you don’t want to propagate a namespace automatically:

  • Option A: Configure karmada-controller-manager
  • Option B: Label the namespace
  • Option C: use custom namespace propagation

Option A: Configure karmada-controller-manager

The flag --skipped-propagating-namespaces can skip namespace auto propagation in karmada-controller-manager which defaults to the regex “kube-.*“. Here is an example:

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: karmada-controller-manager
  5. namespace: karmada-system
  6. labels:
  7. app: karmada-controller-manager
  8. spec:
  9. ...
  10. template:
  11. metadata:
  12. labels:
  13. app: karmada-controller-manager
  14. spec:
  15. containers:
  16. - name: karmada-controller-manager
  17. image: docker.io/karmada/karmada-controller-manager:latest
  18. command:
  19. - /bin/karmada-controller-manager
  20. - --skipped-propagating-namespaces=ns1,ns2

With this change:

  • ns1 and ns2 will not be propagated to all the member clusters.
  • the previously ignored “kube-.*“ namespaces will be propagated to all the member clusters.

Option B: Label the namespace

Configure label namespace.karmada.io/skip-auto-propagation: "true" to skip namespace auto propagation. Here is an example:

  1. apiVersion: v1
  2. kind: Namespace
  3. metadata:
  4. name: example-ns
  5. labels:
  6. namespace.karmada.io/skip-auto-propagation: "true"

Note: If the namespace has been propagated to member clusters, labeling the namespace with namespace.karmada.io/skip-auto-propagation: "true" will not trigger member clusters to delete the namespace, but the namespace will not be propagated to newly joined member clusters.

Option C: use custom namespace propagation.

If you want to take full control of which namespaces get propagated this option offers the most flexibility, but also means you have to add new clusters to the propagation policy yourself.

Step 1: Disable the namespace-sync-controller (which is called “namespace” internally)

Change the karmada-controller-manager command to not run the “namespace” controller:

  1. command:
  2. - /bin/karmada-controller-manager
  3. - --controllers=*,-namespace

Step 2: Create a clusterpropagationpolicy to propagate namespaces

Example:

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: ClusterPropagationPolicy
  3. metadata:
  4. labels:
  5. role: namespace
  6. name: namespace
  7. spec:
  8. conflictResolution: Overwrite
  9. placement:
  10. clusterAffinity:
  11. clusterNames:
  12. - cluster-a
  13. - cluster-b
  14. resourceSelectors:
  15. - apiVersion: v1
  16. kind: Namespace
  17. labelSelector:
  18. matchExpressions:
  19. - key: kubernetes.io/metadata.name
  20. operator: NotIn
  21. values:
  22. - kube-system
  23. - kube-public
  24. - kube-node-lease
  25. - default
  26. - karmada-system
  27. - karmada-cluster
  28. - key: karmada.io/managed
  29. operator: NotIn
  30. values:
  31. - "true"