-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support patches for containers #5354
Comments
Agreed. This would greatly increase efficiency in using replacements across multiple container / initContainer pods. |
I think we need some more information to further understand your issue and how to approach a solution. We have a few specific questions:
Could you provide a minimal example?
It's not clear to us why replacements doesn't work here. For example, we understand that appending to a list inside the target key does not work, but the recommended workflow in this case is to have placeholder values in the base kustomization file. For example:
Then, you can use replacements to update the placeholder value and get your desired output:
@koba1t If you have some more examples of how to use the
When you are patching a resource, the target is specified by the GVK, name, namespace, and/or label/annotation selectors. You can leave any of these fields out, and it functions like a wildcard, e.g. if you specify only the GVK, it will apply the patch to all resources matching that GVK, and there is no need to specify the name. If you are trying to patch a container within a podspec, again some examples would help us understand what it is you are trying to do. /triage needs-information |
I'm mainly talking about strategic merge patches, though I suspect the same issue applies to JSON patches too since JSON patches don't support patching multiple things in the same manifest (e.g. multiple containers in the same StatefulSet). Here's a good example of strategic merge patches at work, and which also demonstrates how attempting to achieve my initial request would be difficult: https://github.com/kubernetes-sigs/kustomize/blob/master/examples/patchMultipleObjects.md In that example, the patch defines a container with Now imagine that instead we wanted to patch the apiVersion: apps/v1
kind: Deployment
metadata:
name: not-important
spec:
template:
spec:
containers:
- name: nginx
env:
- name: NEWENV
value: newenv Except oops, now the second Deployment has an Now imagine that instead we wanted to patch every container, regardless of name. I tried removing the This is extremely fragile as the number of resources goes up, potentially controlled by different people who may not be as familiar with the menagerie of patches as I am. So it seems like patches are out. What about replacements? Thankfully, replacements do have a wildcard feature, so we no longer need to care about the container name (one slight complication: if we try to replace into Here's an example of when replacements aren't patches: what I want to describe is "add these To recap:
Right now in production, I am using replacements, which results in a few hundred lines of replacements, dummy resources that are just used as replacement sources, and a whole bunch of annotations to make sure I'm applying to the right resources. Not great, but workable. What I really want to describe is a strategic patch that applies to all sub-resources within an outer resource. Right now, I'm feeling the pain with containers and initContainers, which is why my issue focuses on that. |
Hi all, I am trying to implement pretty much the same as @RobinMcCorkell. As @RobinMcCorkell said:
I ended up writing a little plugin to initialize these fields so that I don't have to initialize them empty in all deployments, and I use json patch to add the items that I need, now that the lists are always defined. The plugin is pretty much for my specific use case, this does seem like a common use case, which basically translates to "add an item to a list, creating the list if it does not exist", which I know has been asked before and I know SMP does help for this when you know the name if the container/s in advance. However, when you don't know the names of the container in advance, neither SMP nor json patches seem to be able to "add an item to a list, creating the list if it does not exist", keeping the contents of the list when it does exist. |
I've also run in to the same problem that's described here and @leonardochaia described the issue very well
, however it bares mentioning, that In our case we want to have a certain |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale plz |
/lifecycle frozen
|
Hi, I need something like this too. I want to be able to add the following to all containers and initContainers of all deployments, which may not already have a security context defined:
Is there a workaround I can use? I have seen various mumblings on the internet about using |
/remove-lifecycle frozen |
Eschewed features
What would you like to have added?
Specify a container patch to be applied to all containers and initContainers inside a resource.
Why is this needed?
Patching multiple containers across multiple resources is currently awkward:
Horizontal patching across all containers is useful for cross cutting concerns, e.g. common environment variables.
Suggested syntax:
Can you accomplish the motivating task without this feature, and if so, how?
Two solutions exist today:
What other solutions have you considered?
Patches, JSON patches, replacements. All have limitations and shortcomings.
Anything else we should know?
It's tempting to try to design a solution that works for any sort of collection inside resources, e.g. ingress routes. This quickly becomes a tarpit of edge cases though, which is why I want to focus only on the "patch all containers" case.
Feature ownership
The text was updated successfully, but these errors were encountered: