confusion around namespace replacement

[donbowman]

kustomize has an ability to replace all namespaces in one config, setting namespace: XXX

Naively I thought this meant all unset namepaces, but it actually overwrites all.

This creates a challenge when you have something that uses >1 namespace (e.g. cert-manager, it installs 1 thing into kube-system, rest into cert-manager).

I think maybe we want either:

• namespace sets unset only
• namespace works somewhat like image, e.g. oldNS: X -> newNS: Y

Although technically possible to json/strat patch all objects, this is exceptionally tedious when there are many of them.

[Liujingfang1]

namespac overwrites .metadata.namespace in all resources, it provides easy separation of resources between different environments. For some type of resources, namespace is not needed or users don't want to overwrite the namespace. Thus we need to be able to skip certain types of resources.

Currently, Kustomize skips adding namespace for some hard-coded types, https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/gvk/gvk.go#L154.
This need to be extended to allow user specify a skip type.

[donbowman]

here it would not be a skip type, it would be a named entity.
e.g. I might have a setup that installs 1 pod into kube-system and the rest into its own namespace.

[iamsaso]

I have the same problem and I would like to use bases to link to dependencies but not change the dependency namespace. @donbowman were you able to get around this issue?

[rcrowe]

I've just hit the same problem when using a role binding, where the subject is in a different namespace than metadata.name. The subject namespace is being overwritten.

[donbowman]

another example. when using istio, i need to be able to have a certificate and ingressgateway in namespace istio-system, but have the rest of the material (including the config generator) in its own.

so e.g. I have:

• deployment
• secretGenerator
• certificate
• ingressgateway

if i do not set a namespace in kustomization.yaml, I end up w/ the Secret from the secretGenerator in the root namespace, but the deployment that would ref it is not, so it doesn't work.
If i do set a namespace in kustomization.yaml, then my ingressgateway and certificate are rewritten to be in the wrong namespace.

it seems there is no way to make this work.

[quentinleclerc]

Hello,
I've been facing issues with the namespace override also.

Wouldn't it be possible to add an option to the namespace key in kustomization.yaml to specify if we want it to override or not ?

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: 
  overwrite: <true | false>
  name: <namespace>

[Russell-IO]

Wouldn't it be possible to add an option to the namespace key in kustomization.yaml to specify if we want it to override or not ?
As long as it defaults to false to observe current behaviour

[donbowman]

For interest, I created a transformer to do this for me:

#!/usr/bin/env /usr/bin/python3

import sys
import yaml

with open(sys.argv[1], "r") as stream:
    try:
        data = yaml.safe_load(stream)
    except yaml.YAMLError as exc:
        print("Error parsing NamespaceTransformer input", file=sys.stderr)

# See kubectl api-resources --namespaced=false
blacklist = [
    "ComponentStatus",
    "Namespace",
    "Node",
    "PersistentVolume",
    "MutatingWebhookConfiguration",
    "ValidatingWebhookConfiguration",
    "CustomResourceDefinition",
    "APIService",
    "MeshPolicy",
    "TokenReview",
    "SelfSubjectAccessReview",
    "SelfSubjectRulesReview",
    "SubjectAccessReview",
    "CertificateSigningRequest",
    "ClusterIssuer",
    "BGPConfiguration",
    "ClusterInformation",
    "FelixConfiguration",
    "GlobalBGPConfig",
    "GlobalFelixConfig",
    "GlobalNetworkPolicy",
    "GlobalNetworkSet",
    "HostEndpoint",
    "IPPool",
    "PodSecurityPolicy",
    "NodeMetrics",
    "PodSecurityPolicy",
    "ClusterRoleBinding",
    "ClusterRole",
    "ClusterRbacConfig",
    "PriorityClass",
    "StorageClass",
    "VolumeAttachment",
]

try:
    for yaml_input in yaml.safe_load_all(sys.stdin):
        if yaml_input['kind'] not in blacklist:
            if "namespace" not in yaml_input["metadata"]:
                yaml_input["metadata"]["namespace"] = data["namespace"]
        print("---")
        print(yaml.dump(yaml_input, default_flow_style=False))
except yaml.YAMLError as exc:
    print("Error parsing YAML input\n\n%s\n\n" % input, file=sys.stderr)

[flunderveiko]

Can you please describe how you put the transformer in the kustomize build ... run !

[donbowman]

1. put the transformer in ~/.config/kustomize/plugin/agilicus/v1/namespacetransformer/
2. add a yaml file as below as e.g. 'set-ns.yaml'
3. add 'transformers:\n - set-ns.yaml' to kustomization.yaml

---
apiVersion: agilicus/v1
kind: NamespaceTransformer
metadata:
  name: not-used-ns
namespace: foobar

I need to get around to creating a github repo w/ my generator + transformers.

edit: they are here

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[invidian]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[invidian]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[invidian]

/remove-lifecycle stale

[harindaka]

I just hit this issue with my ingress as well. Is there an ETA for a fix?

[benjamin-wright]

FWIW, I've had this problem and the best workaround I could find was to patch over the overridden namespace:

patchesJson6902:
  - target:
      group: ""
      version: v1
      kind: ConfigMap
      name: my-config-name
    patch: |-
      - op: replace
        path: /metadata/namespace
        value: other-namespace

Not great if you've got a ton of resources but works in a pinch for a couple

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[paullryan]

/remove-lifecycle stale

[vvatlin]

I have the same issue, when I have Istio Gateway, VirtualService in one namespace and I have to have certificate in the Istio-ingress namespace.
Can't do it right now with Kustomize

[stianlagstad]

I found this issue while trying to figure out why Kustomize wasn't overriding the namespace for a MutatingWebhookConfiguration resource. I'm using https://github.com/influxdata/telegraf-operator/blob/v1.3.6/deploy/dev.yml, and the namespace for the mutating webhook configuration wasn't being updated by Kustomize. I ended up solving it like this, thanks to benjamin-wright above:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: observability

# For some reason the above `namespace: observability` doesn't update the namespace for the MutatingWebhookConfiguration
# resource, so we do that with a patch:
patchesJson6902:
  - target:
      group: ""
      version: v1
      kind: MutatingWebhookConfiguration
      name: telegraf-operator
    patch: |-
      - op: replace
        path: /metadata/namespace
        value: observability

[Moulick]

@stianlagstad unless I am mistaken, MutatingWebhookConfiguration is a cluster scoped object hence adding a namespace there is incorrect and hence why kustomize ignores it.

[RyanSquared]

@Moulick you're right, I've found an alternative solution: https://github.com/james-callahan/cert-manager-kustomize/tree/main/webhook#usage

[mathe-matician]

As @benjamin-wright mentioned, the following works:

patchesJson6902:
  - target:
      group: ""
      version: v1
      kind: ConfigMap
      name: my-config-name
    patch: |-
      - op: replace
        path: /metadata/namespace
        value: other-namespace

When adding this, I get the output:

# Warning: 'patchesJson6902' is deprecated. Please use 'patches' instead. Run 'kustomize edit fix' to update your Kustomization automatically.

Using patches, though, doesn't work:

patches:
  - target:
      group: ""
      version: v1
      kind: ConfigMap
      name: my-config-name
    patch: |-
      - op: replace
        path: /metadata/namespace
        value: other-namespace

Has anyone found a work around for this using patches?

[quixoten]

@mathe-matician

using the transformers field to do the patch seems to work:

transformers:
- |-
  apiVersion: builtin
  kind: PatchTransformer
  metadata:
    name: fix-cert-namespace
  patch: '[{"op": "replace", "path": "/metadata/namespace", "value": "istio-system"}]'
  target:
    group: cert-manager.io
    kind: Certificate