kustomize labels with includeTemplates get applied to StatefulSet volumeClaimTemplates

What happened?

Trying to set datadog version labels on pods of a statefulset using

labels:
  - includeSelectors: false
    includeTemplates: true
    pairs:
      tags.datadoghq.com/version: r1
      app.kubernetes.io/version: r1

causes the labels to also be applied to volumeClaimTemplates which cannot be modified after initial creation and thus preventing updates.

What did you expect to happen?

volumeClaimTemplates should not be modified

How can we reproduce it (as minimally and precisely as possible)?

labels:
  - includeSelectors: false
    includeTemplates: true
    pairs:
      tags.datadoghq.com/version: r1
      app.kubernetes.io/version: r1

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name:test
  serviceName: test-headless
  replicas: 3
  template:
    metadata:
      name: test
      labels:
        app.kubernetes.io/name: test
    spec:
      containers:
        - name: pod
          image: test:r1
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - mountPath: /usr/src/app/data/usercontent
              name: userdata
      restartPolicy: Always
  volumeClaimTemplates:
    - metadata:
        name: userdata
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: gp3
        resources:
          requests:
            storage: 10Gi

Expected output

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test
  labels:
      tags.datadoghq.com/version: r1
      app.kubernetes.io/version: r1
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name:test
  serviceName: test-headless
  replicas: 3
  template:
    metadata:
      name: test
      labels:
        app.kubernetes.io/name: test
        tags.datadoghq.com/version: r1
        app.kubernetes.io/version: r1
    spec:
      containers:
        - name: pod
          image: test:r1
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - mountPath: /usr/src/app/data/usercontent
              name: userdata
      restartPolicy: Always
  volumeClaimTemplates:
    - metadata:
        name: userdata
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: gp3
        resources:
          requests:
            storage: 10Gi

Actual output

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test
  labels:
      tags.datadoghq.com/version: r1
      app.kubernetes.io/version: r1
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name:test
  serviceName: test-headless
  replicas: 3
  template:
    metadata:
      name: test
      labels:
        app.kubernetes.io/name: test
        tags.datadoghq.com/version: r1
        app.kubernetes.io/version: r1
    spec:
      containers:
        - name: pod
          image: test:r1
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - mountPath: /usr/src/app/data/usercontent
              name: userdata
      restartPolicy: Always
  volumeClaimTemplates:
    - metadata:
        name: userdata
        labels:
          tags.datadoghq.com/version: r1
          app.kubernetes.io/version: r1
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: gp3
        resources:
          requests:
            storage: 10Gi

Kustomize version

5.1.1

Operating system

Linux

Oct 17 '23 14:10 hameno

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Oct 17 '23 14:10 k8s-ci-robot

I have observed the same thing. I want to customize labels in the pods, but the labels are also applied to the volumeClaimTemplates, making it impossible to update the stateful set.

As a workaround until (if ever) this is fixed, inspired by this answer, you can first delete the StatefulSet without deleting its pods (so there won't be any downtime) and then apply the kustomization, for example:

$ kubectl delete statefulset your-stateful-set --cascade=orphan
$ kubectl apply -k .

Jan 18 '24 10:01 babinos87

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle stale

Apr 17 '24 14:04 k8s-triage-robot

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle rotten

May 17 '24 14:05 k8s-triage-robot

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

This bot triages issues 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:

Reopen this issue with /reopen
Mark this issue as fresh with /remove-lifecycle rotten
Offer to help out with Issue Triage

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

/close not-planned

Jun 16 '24 14:06 k8s-triage-robot

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

Reopen this issue with /reopen

Mark this issue as fresh with /remove-lifecycle rotten

Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Jun 16 '24 14:06 k8s-ci-robot

/reopen I contributed the includeTemplates flag some time ago. The motivation was to add metadata without causing downtime, which is not achieved in the case of StatefulSets with volumeClaimTemplates defined. I'll try to contribute an additional includeVolumeClaimTemplates flag so that we can disable this undesired behavior.

@KnVerey @natasha41575 thoughts?

Sep 24 '24 19:09 aibarbetta

@aibarbetta: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen I contributed the includeTemplates flag some time ago. The motivation was to add metadata without causing downtime, which is not achieved in the case of StatefulSets with volumeClaimTemplates defined. I'll try to contribute an additional includeVolumeClaimTemplates flag so that we can disable this undesired behavior.

@KnVerey @natasha41575 thoughts?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sep 24 '24 19:09 k8s-ci-robot