kubectl apply -k vs kustomize build "env" and "envs" error

[tamipangadil]

Hi,

I'm trying to simplify the structures of my yaml files. I segregated the common configs and secrets so I can re-use it into my deployment manifests.

I used:

# sample file.yaml
configMapGenerator:
   name: my-config 
   envs: #env
       - config.env

Then I ran:

$ kubectl apply -k .

error: AccumulateTarget: couldn't make target for path/to/config/folder: json: unknown field "envs"
couldn't make target for path/to/config/folder: json: unknown field "envs"

AccumulateTarget: couldn't make target for base: json: unknown field "envs"

After changing it from envs to env then ran:

$ kustomize build .

Error: accumulating resources: recursed accumulation of path 'path/to/configs/folder': accumulating resources: couldn't make target for path 'path/to/configs/folder/subfolder': json: unknown field "env"

[tamipangadil]

/help

[k8s-ci-robot]

@tamipangadil:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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.

[tamipangadil]

/bug

[pwittrock]

Seems like this may be a backwards compatibility issue with the 2 version of kubectl

[bcmedeiros]

The same thing happens with other commands such base.. How can we find documentation in regards to compatibility between kustomize build and kubectl apply -k?

[tamipangadil]

I didn’t rely on kubectl anymore to have a fix the differences. I just run ‘kustomize build . | kubectl apply -f -‘ whenever I want to deploy.

…

On Sat, 28 Mar 2020 at 21:57, Marián Hlaváč ***@***.***> wrote: Had similar error message, it seems that there might be some kind of issue with YAML parsing. I had this in my kustomization.yaml: secretGenerator: - name: platform env: secrets/platform.env - name: database env: secrets/database.env Which resulted in correctly processed through kubectl apply -k ..., but failed when ran kustomize build ... on Error: accumulating resources: couldn't make target for path '.../platform/spec/base': json: unknown field "env". After changing the contents of the file to (notice the indentation): secretGenerator: - name: platform env: secrets/platform.env - name: database env: secrets/database.env it goes through without a problem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ727EJJF6YRILBBDTBZXLRJZXC7ANCNFSM4KWUIOBA> .

[kkweon]

So, what is the proposed solution here?
I just ran into this issue as well and didn't realize until I created #2378.

• Fix kubectl apply -k to use envs instead of env
  or
• Fix kustomize build to use env instead of envs
  or
• Make both support env and envs

I think it makes sense to fix kubectl apply -k to use envs but then this issue now belongs to kubectl?

[hermanbanken]

To the maintainers...

I really don't know what the desired state is, but kubectl and kustomize differ:

• in kustomize 3.5.5 (2020-05-12) this is 'envs' which is an array
• in kubectl 1.18.0 (2020-03-26) this is 'env' which is a string

Can we easily see which kustomize module is part of kubectl?

Why don't we finalize v1 of the kustomize spec (still v1beta1) if we are already advertising the use of kustomize in normal Kubernetes kubectl operations?

I can find this: https://github.com/kubernetes/kubectl/blob/master/go.mod#L46 which shows that kubectl is still using 2.0.3 of kustomize. Seems very old!

[nimda7]

The latest kustomize version that understands "env" in configMapGenerator is 3.2.3

[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

[Shell32-Natsu]

Please take a look at this issue for the reason that latest kustomize cannot be shipped with kubectl.

[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

[zoltantarcsay]

this is still broken...

[k8s-ci-robot]

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

In response to this:

/reopen
this is still broken...

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.

[Shell32-Natsu]

@zoltantarcsay Please see #1500 and #2506

[zoltantarcsay]

@zoltantarcsay Please see #1500 and #2506

thanks!

[jleach]

Still an issue. Looks like ppl keep creating issue after issue but the issue never gets addressed.

➜  devops git:(master) ✗ kubectl kustomize ./k8s/env/test
Error: json: unknown field "envs"
➜  devops git:(master) ✗ kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-13T21:37:31Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:41:49Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

[rauno56]

It's interesting that kustomize v3.0.0 and v3.5.4 seem to autocorrect the env to envs, why doesn't later versions have it?

[Zeioth]

I'm just gonna revert my kustomize version and pretend this never happened.

[changemyminds]

I still have problem on kubectl v1.19.x version. Finally, I use other solution to solve problem . I think this may help someone.

# check kubectl version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.16", GitCommit:"e37e4ab4cc8dcda84f1344dda47a97bb1927d074", GitTreeState:"clean", BuildDate:"2021-10-27T16:25:59Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:23:04Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

# use kubectl kustomize will get error
$ kubectl kustomize .
Error: json: unknown field "envs"

# use kubectl apply -k will get error, too.
$ kubectl apply -k .
error: json: unknown field "envs"

# install kustomize
$ curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
$ sudo mv kustomize /usr/local/bin

# check kustomize version
$ kustomize version
{Version:kustomize/v4.5.7 GitCommit:56d82a8378dfc8dc3b3b1085e5a6e67b82966bd7 BuildDate:2022-08-02T16:35:54Z GoOs:linux GoArch:amd64}

# use kustomize build to know envs and use kubectl apply to execute (apply)
$ kustomize build . | kubectl apply -f -

# use kustomize build to know envs and use kubectl delete to execute (delete)
$ kustomize build . | kubectl delete --ignore-not-found=true -f -