[Question] how to add an env to all containers in Deployment?

[Lwxiang]

origin resource

apiVersion: apps/v1
kind: Deployment
...
    spec:
      containers:
        - name: nginx
           image: nginx
           env:
           - name: foo
             value: bar
        - name: sidecar
           image: sidecar
           env:
           - name: hello
             value: world

As the origin resource above, I have 2 container in 1 pod, and each has its own env. Now I want to insert an env drink=coffee into the 2 container.

I can do this by json patch:

- op: add
  path: /spec/template/spec/containers/0/env/-
  value:
    name: drink
    value: coffee
- op: add
  path: /spec/template/spec/containers/1/env/-
  value:
    name: drink
    value: coffee

But if I don't want to do this with every index of containers or I just don't know how many the containers are. Can I have a batch method, to add env for all containers by one step?

[natasha41575]

I believe your use case will be supported by replacements after completion of this feature: https://github.com/kubernetes-sigs/kustomize/issues/4053. Unfortunately, this is not available yet. However, when this done, you will be able to do the following:

source: 
  kind: Pod
  name: pod-with-desired-env
  fieldPath: spec.template.spec.containers.0.env
targets:
- select:
    kind: Deployment
  fieldPaths: 
  - spec.template.spec.containers.*.env
  options:
    create: true

Would this resolve your issue?

/kind support/ /triage accepted

[k8s-ci-robot]

@natasha41575: The label(s) kind/support/ cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/kubernetes-sigs/kustomize/issues/4391#issuecomment-1018839652): >I believe your use case will be supported by `[replacements](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/replacements/)` after completion of this feature: https://github.com/kubernetes-sigs/kustomize/issues/4053. Unfortunately, this is not available yet. However, when this done, you will be able to do the following: > >``` >source: > kind: Pod > name: pod-with-desired-env > fieldPath: spec.template.spec.containers.0.env >targets: >- select: > kind: Deployment > fieldPaths: > - spec.template.spec.containers.*.env > options: > create: true >``` > >Would this resolve your issue? > >/kind support/ >/triage accepted Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[natasha41575]

/kind support /unlabel needs-kind

[natasha41575]

/close

Please reopen if https://github.com/kubernetes-sigs/kustomize/issues/4053 will not solve the issue for you. Otherwise please see that issue for updates.

[k8s-ci-robot]

@natasha41575: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/kustomize/issues/4391#issuecomment-1024606864): >/close > >Please reopen if https://github.com/kubernetes-sigs/kustomize/issues/4053 will not solve the issue for you. Otherwise please see that issue for updates. Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[jashandeep-sohi]

Wouldn't the proposed solution replace all env vars in all containers? Is there a way to append to the env list (or better yet to apply a patch to every item of a list)?

[znd4]

Wouldn't the proposed solution replace all env vars in all containers? Is there a way to append to the env list (or better yet to apply a patch to every item of a list)?

I think some design work would be needed to support that. Functionality probably shouldn't be added to RFC6902 patches lightly (b.c. then they couldn't be called RFC6902 patches), and it's hard to imagine how this could be implemented in strategic merge patches.