contour
contour copied to clipboard
Contour deployment docs / tooling
Contour has an examples folder in the root of the repo which shows different ways to deploy Contour in some various scenarios. Depending on requirements these might be deploying Envoy with hostNetworking for performance, or as a daemonset to horizontally scale the network data plane.
We've also had the community ask for other deployment options other than just yaml (as exists today in the examples directory). Those could be helm, kustomize, or any other style of tooling to assist with deploying Contour to a cluster.
We should also create some documentation on the various examples and discuss why one version is preferable over another and the trade-offs included.
- [ ] Create deployment docs
- [ ] Create helm chart or other tooling
Here is a use case for an officially supported helm chart.
To operate my kubernetes clusters, I use a combination of helmfile and helm to store the whole cluster configuration in a git repository. In this context, I usually use upstream charts for the dependencies in order to reduce the surface of resources to maintain internally.
Without an officially provided chart, I would create one myself exactly for my needs, but it would most certainly not contain the best practices to deploy contour and also I wouldn't be very confident to know if I am deploying it correctly. This especially as time goes by: maybe practices change and I miss the information and stay with an incorrect way of deploying contour.
So I feel like the contour team is the best person to maintain an up to date chart ;)
I was thinking about this, and an alternative to provide an helm chart would be to provide a self-sufficient contour operator that have CRDs to describe the envoy deployments on top of the IngressRoute.
In this case, if the operator has zero configuration because everything happens via declarative resources, it could make sense to deploy it by hand without the need for an helm chart (or other packaging solution).
In the end, the use case is always to be able to easily describe and configure the deployments as an ops and to be able to store it in git.