This topic tells you how to use Namespace Provisioner to provision developer namespaces in Tanzu Application Platform (commonly known as TAP).
Example secret creation, exported to all namespaces:
tanzu secret registry add registry-credentials --server REGISTRY-SERVER --username REGISTRY-USERNAME --password REGISTRY-PASSWORD --export-to-all-namespaces --yes --namespace tap-install
ImportantNamespace Provisioner creates a secret called registries-credentials in each managed namespace which is a placeholder secret filled indirectly by secretgen-controller with all the registry credentials exported for that managed namespace.
There are two ways to manage the list of developer namespaces that are managed by Namespace Provisioner.
tap-values.yaml
configuration example:
namespace_provisioner:
controller: true
The imperative way is to create the namespace using kubectl or using other means and label it using the default selector.
Create a namespace using kubectl or any other means
kubectl create namespace YOUR-NEW-DEVELOPER-NAMESPACE
Label your new developer namespace with the default namespace_selector apps.tanzu.vmware.com/tap-ns=""
.
kubectl label namespaces YOUR-NEW-DEVELOPER-NAMESPACE apps.tanzu.vmware.com/tap-ns=""
Run the following command to verify the default resources have been created in the namespace:
kubectl get secrets,serviceaccount,rolebinding,pods,workload,configmap,limitrange -n YOUR-NEW-DEVELOPER-NAMESPACE
For example:
NAME TYPE DATA AGE
secret/app-tls-cert kubernetes.io/tls 3 19s
secret/registries-credentials kubernetes.io/dockerconfigjson 1 26s
secret/scanner-secret-ref kubernetes.io/dockerconfigjson 1 20s
NAME SECRETS AGE
serviceaccount/default 1 4h7m
serviceaccount/grype-scanner 2 20s
NAME ROLE AGE
rolebinding.rbac.authorization.k8s.io/default-permit-deliverable ClusterRole/deliverable 26s
rolebinding.rbac.authorization.k8s.io/default-permit-workload ClusterRole/workload 26s
NAME DATA AGE
configmap/kube-root-ca.crt 1 38h
NAME CREATED AT
limitrange/dev-lr 2023-03-08T04:18:58Z
tap-values.yaml
configuration example:
namespace_provisioner:
controller: false
gitops_install:
ref: origin/main
subPath: ns-provisioner-samples/gitops-install
url: https://github.com/vmware-tanzu/application-accelerator-samples.git
This GitOps configuration does the following things:
controller: false
- the Namespace Provisioner package does not install the controller. The list of namespaces is managed in a GitOps repository instead.
The gitops-install
directory specified as the subPath
value includes two files:
desired-namespace.yaml contains the list of developer namespaces in a ytt data.values format.
namespaces.yaml contains a Kubernetes namespace object.
If you have another tool like Tanzu Mission Control or some other process that is taking care of creating namespaces for you, and you don’t want a Namespace Provisioner to create the namespaces, you can delete this file from your GitOps install repository.
The tap-values.yaml
configuration example above creates the following two namespaces: dev
and qa
. If these namespaces already exist in your cluster, remove them or rename the namespaces in your GitOps repository so they do not conflict with existing resources.
Run the following command to verify the default resources are created in the namespace:
kubectl get secrets,serviceaccount,rolebinding,pods,workload,configmap,limitrange -n dev
For example:
NAME TYPE DATA AGE
secret/app-tls-cert kubernetes.io/tls 3 52s
secret/registries-credentials kubernetes.io/dockerconfigjson 1 59s
secret/scanner-secret-ref kubernetes.io/dockerconfigjson 1 53s
NAME SECRETS AGE
serviceaccount/default 1 59s
serviceaccount/grype-scanner 2 53s
NAME ROLE AGE
rolebinding.rbac.authorization.k8s.io/default-permit-deliverable ClusterRole/deliverable 59s
rolebinding.rbac.authorization.k8s.io/default-permit-workload ClusterRole/workload 59s
NAME DATA AGE
configmap/kube-root-ca.crt 1 59s
NAME CREATED AT
limitrange/dev-lr 2023-03-08T04:22:20Z
For more information, see the GitOps section of Customize Installation of Namespace Provisioner.
Namespace Provisioner does not support enabling additional users with Kubernetes RBAC. Support is planned for an upcoming release. Until Namespace Provisioner support is provided, follow the instructions in Enable additional users with Kubernetes RBAC.