Move the deployment YAML to kustomize

[jpeach]

trafficstars

The current Contour deployment YAML builds from the fragments in examples/contour and doesn't give any help to operators that need to modify the deployment in any way.

If we move this across to a kustomize configuration, we have the opportunity to be able to modify the YAML for different deployment targets (e.g. AWS, GCP, Kind), as well as generate the same consolidated YAML file that we document for the Contour quickstart. Other people that deploy Contour may be able to consume the kustomize configuration if we structure it correctly.

Pros of kustomize:

• Gives some deployment flexibility we don't have today
• Built in to kubectl

Cons on kustomize:

• Documentation leaves a something to be desired
• Limited configuration flexibility (e.g. hard or impossible to remove components)

Proof of concept: https://github.com/jpeach/contour/commit/1c575c772e9fd747fba72ae41ab99bdae7a01864

Related to #1190, #2050

[jpeach]

One problem the just bit me is that kustomize and kubectl kustomize releases are not aligned. This means that it is possible to use syntax that kustomize will accept but kubectl won't. I'm currently in this situation with fieldRef expressions and I have:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-13T11:52:32Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

$ kustomize version
{Version:3.5.3 GitCommit:5ba90fe5ef1dc4599e359edd41d1d0e6373b247d BuildDate:2019-12-18T03:07:49+00:00 GoOs:darwin GoArch:amd64}

[stevesloka]

My first thought was to default to using the version of kustomize in kubectl, but there's no way to know what version of kubectl a user has.

I think we just need to pick a version of kustomize and document it.

[jpeach]

On 11 Jan 2020, at 4:16 am, Steve Sloka [email protected] wrote:

My first thought was to default to using the version of kustomize in kubectl, but there's no way to know what version of kubectl a user has.

I think we just need to pick a version of kustomize and document it.

The Kustomize YAML format is versioned (in the Kubernetes API sense), but AFAICT that versioning is not granular enough to ensure the right version of the tooling.

[stefanprodan]

This would be very helpful, Contour could expose a remote base for each release branch so that patching could target a specific release, see an example here https://github.com/stefanprodan/eks-contour-ingress/tree/master/contour

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack