How to deploy a single resource to a custom namespace with Spinnaker's namespaceOverride enabled?

Below is one strategy that aligns with Kubernetes’ approach to namespace scoping without a major refactor of your charts:

1. Separate the Out-of-Default Namespace Resource
   Since Spinnaker’s namespaceOverride setting forces all resources to the default namespace, you can separate the one resource that actually belongs in a different namespace into its own deployment stage or release. This lets you disable namespaceOverride (or set the desired namespace explicitly) for that stage while keeping the remaining resources on the default.

2. Customize Your Helm Chart
   For the isolated resource, you can template the namespace value conditionally. For example, in your Helm chart’s template for that resource, you could use a values key (say, targetNamespace) so that when deploying this release you supply the correct namespace:

   YAMLCopied
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: my-special-config
     namespace: {{ .Values.targetNamespace | default "default" }}
   data:
     key: value

   This way, when deploying via Spinnaker, you can set targetNamespace to your desired namespace for that resource. For all other resources, let them default to the overall namespace set in Spinnaker.

3. Use Separate Pipelines or Manifest Stages
   If modifying the Helm chart isn’t ideal, consider creating a dedicated Spinnaker pipeline (or separate manifest stage) for that one resource. In that separate pipeline, you can disable namespaceOverride or explicitly set the desired namespace so that the YAML’s namespace field isn’t overridden by the default.

Why This Helps

Kubernetes namespaces are designed to isolate resources, and the Kubernetes documentation recommends ensuring that each resource is placed in the intended namespace for clarity and security. By grouping resources that share the same namespace needs and separating the one outlier, you minimize changes while adhering to good namespace management practices.

This approach leverages Helm’s templating (or Spinnaker’s separate stages) to meet your requirements without a wholesale change across your entire chart or set of manifests.