-
Notifications
You must be signed in to change notification settings - Fork 34
Support envoy pod template with basic fields #378
Comments
@r0bj in my experience template-based approaches become very difficult to manage. Instead of exposing a "pod template" through the API, I would like to address each of the above bullets in a specific manner. Using labels as an example, we can have the operator append labels defined in the Contour to the operands:
A similar approach can be taken for custom annotations. We already have an issue for managing SCCs: #112. What do you think about these approaches? |
Sure, it would be less flexible but it would work. Partly my inspiration was prometheus-operator where you can define |
xref #373 for tolerations/nodeSelector support of Envoy pods. |
Allow setting custom security contexts for both contour deployments and envoy daemonsets. The default value is unpriviledged and is equivalent to the following: contourSecurityContext: runAsUser: 65534 runAsGroup: 65534 runAsNonRoot: true Fixes projectcontour#112 Updates projectcontour#378
Allow setting custom security contexts for both contour deployments and envoy daemonsets. The default value is unpriviledged and is equivalent to the following: contourSecurityContext: runAsUser: 65534 runAsGroup: 65534 runAsNonRoot: true Fixes projectcontour#112 Updates projectcontour#378 Signed-off-by: David Morgan <[email protected]>
Allow setting custom security contexts for both contour deployments and envoy daemonsets. The default value is unpriviledged and is equivalent to the following: contourSecurityContext: runAsUser: 65534 runAsGroup: 65534 runAsNonRoot: true Fixes projectcontour#112 Updates projectcontour#378 Signed-off-by: David Morgan <[email protected]>
Please describe the problem you have
[A clear, concise, description of the problem you are facing. What is the problem that feature X would solve for you?]
It would be useful to be able to specify envoy pod template with basic fields like:
etc.
In some environments/clusters there are specific requirements for pod labels (e.g. mandatory label team, owner, contact, etc.). Other use case is for specific annotation which can be used to define pod log destination or other parameters.
The text was updated successfully, but these errors were encountered: