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

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"

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 21
  • Comments: 20 (5 by maintainers)

Most upvoted comments

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?

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!

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?

The latest kustomize version that understands “env” in configMapGenerator is 3.2.3

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

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"}

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

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áč notifications@github.com 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 https://github.com/kubernetes-sigs/kustomize/issues/2205#issuecomment-605524839, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ727EJJF6YRILBBDTBZXLRJZXC7ANCNFSM4KWUIOBA .

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