You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scope the webhookconfiguration more narrowly so the server isn't called unnecessarily. Possibly use an annotation or label on the namespace as well as on the pod/deployment. It's also not clear if we need to be called for deployments. This provides two things. Minimizes the frequency with which the Kube API server calls the webhook server. Has some performance and latency advantages, but also minimizes the surface area if the webhook server has bugs. It can also allows the user/admin more controls over what will be injected. For example a label on a namespace would be a courser knob than annotations on the Pods.
Use a configmap for injection - which allows more flexibility as you can change without changing the image. This is a pattern used by Istio (probably other projects as well). The idea is that the actual mutation code in the server is kept relatively general but some of the mutation rules get encoded int he configmap. For example the set of ENVs to add could be gleaned from a configmap vs. a set of code constants. It is a bit more flexible in that you can change the mutation without changing the server version.
Consider consolidating the log. There are currently 2 levels passed to the webhook one of which is passed one via
mutation. Maybe 2 aren't needed?
The text was updated successfully, but these errors were encountered:
Scope the webhookconfiguration more narrowly so the server isn't called unnecessarily. Possibly use an annotation or label on the namespace as well as on the pod/deployment. It's also not clear if we need to be called for deployments. This provides two things. Minimizes the frequency with which the Kube API server calls the webhook server. Has some performance and latency advantages, but also minimizes the surface area if the webhook server has bugs. It can also allows the user/admin more controls over what will be injected. For example a label on a namespace would be a courser knob than annotations on the Pods.
Use a configmap for injection - which allows more flexibility as you can change without changing the image. This is a pattern used by Istio (probably other projects as well). The idea is that the actual mutation code in the server is kept relatively general but some of the mutation rules get encoded int he configmap. For example the set of ENVs to add could be gleaned from a configmap vs. a set of code constants. It is a bit more flexible in that you can change the mutation without changing the server version.
Consider consolidating the log. There are currently 2 levels passed to the webhook one of which is passed one via
mutation. Maybe 2 aren't needed?
The text was updated successfully, but these errors were encountered: