Kustomize: StatefulSet volumeclaimtemplates added when base did not include it

[msau42]

This might be caused to https://github.com/kubernetes-sigs/kustomize/pull/483

I have a StatefulSet spec that doesn't use volumeClaimTemplates, but when I kustomize it with common labels, it adds it to the spec, which causes it to fail validation:

My base spec:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: test
spec:
  serviceName: "test"
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - name: nginx
          image: nginx

After kustomize:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: test
spec:
  serviceName: "test"
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - name: nginx
          image: nginx
  volumeClaimTemplates:
    metadata:
      labels:
        app: my-label

Error:

error validating data: ValidationError(StatefulSet.spec.volumeClaimTemplates): invalid type for io.k8s.api.apps.v1.StatefulSetSpec.volumeClaimTemplates: got "map", expected "array"; if you choose to ignore these errors, turn validation off with --validate=false

[Liujingfang1]

I'll look into this issue. Before we have a fix, you can unblock yourself with following steps to modify the transformer configurations.

kustomize config save -d ~/.kustomize/config

In ~/.kustomize/config/commonlabel.YAML, remove ollowing block or change create from true to false

-path: spec/volumeClaimTemplates/metadata/labels
  create: true
  group: apps
  kind: StatefulSet

When you run kustomize build, using -t to pick up the updated transformer configs.

kustomize build <die> -t ~/.kusotmize/config

[robbyt]

@Liujingfang1 Thank you for the workaround. I also have this same issue, after upgrading to release 1.0.9.

[twz123]

I also hit this one. Interestingly, kustomize replaces absent volumeClaimTemplates - which are usually an array - with a map. Note the missing hyphen in the above example. I think kustomize's transformer configs miss a distinction between something that is an array vs something that is an object.

In my use case, overriding transformer configs is not helping much, since I have a kustomization that has both statefulsets with and without volumeClaimTemplates. I use a patch instead that explicitly sets volumeClaimTemplates: [].

[turbotankist]

put

spec:
 volumeClaimTemplates: []

in your StatefulSet yml

[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

[schweikert]

The workaround described in https://github.com/kubernetes-sigs/kustomize/issues/504#issuecomment-433502027 doesn't work anymore with kustomize 2.0.3 because the -t option is not supported anymore. Also, it seems that it is not possible to override the configuration of the commonLabels transformer (using configurations:...)

The other workaround of using "volumeClaimTemplates: []" doesn't work for me because kubectl apply complains about a forbidden change.

In other words: we need this fix :) Right now we are stuck with kustomize 1.0.8

[gysel]

We're also struggling with this issue.

The workaround using volumeClaimTemplates: [] kind of works but results in for: "STDIN": StatefulSet.apps "xxx" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden. for every deployment.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

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.

[Djabx]

The issue is always here.
/reopen

[k8s-ci-robot]

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

In response to this:

The issue is always here.
/reopen

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.

[HenriTEL]

As pointed out by @gysel you can set volumeClaimTemplates: [] to make kustomize not generate a wrong StatefulSet.
You can try a kubectl patch to work around the Forbidden: updates to statefulset spec error when the StatefulSet is already deployed.

[arianvp]

This issue is still very relevant though right? Kustomize generates a manifest that isn't even valid. Which is kind of the exact opposite of the promise that kustomize tries to make. Can we reopen this?

[Shell32-Natsu]

I cannot reproduce this issue with latest kustomize. If you are using kustomize shipped with kubectl, please take a look at #1500 and #2506.

[arianvp]

Yep you're right. I cant reproduce either on latest kustomize. Feel free to close this issue then in favour of the other two you just linked.