A single-namespace deployment of PKO is one where the operator serves only its own namespace, and doesn't require the installation of a ClusterRole or ClusterRoleBinding.
PKOv2 is designed to natively support multi-tenancy across namespaces without needing to deploy separate instances of the operator into each namespace. Looking back at https://github.com/pulumi/pulumi-kubernetes-operator/pull/328, we see that the ability to deploy to multiple namespaces was added to address a lack of isolation: https://github.com/pulumi/home/issues/2330. So, single-namespace mode isn't needed for the multi-tenancy use-case anymore.
Aside from multi-tenancy, a reasonable use-case is for non-admins to be able to install the operator into their own namespace.
Implementation-wise, we need to:
add code to the manager to scope its cache and its watches to a WATCH_NAMESPACE.
optional: make a deploy app that can target a specific namespace. We might need a different kustomization overlay for this, or might need to port the manifests into Pulumi code.
cleverguy25
commented
3 weeks ago
A single-namespace deployment of PKO is one where the operator serves only its own namespace, and doesn't require the installation of a
ClusterRoleorClusterRoleBinding.PKOv2 is designed to natively support multi-tenancy across namespaces without needing to deploy separate instances of the operator into each namespace. Looking back at https://github.com/pulumi/pulumi-kubernetes-operator/pull/328, we see that the ability to deploy to multiple namespaces was added to address a lack of isolation: https://github.com/pulumi/home/issues/2330. So, single-namespace mode isn't needed for the multi-tenancy use-case anymore.
Aside from multi-tenancy, a reasonable use-case is for non-admins to be able to install the operator into their own namespace.
Implementation-wise, we need to:
WATCH_NAMESPACE.