ALB Ingress Controller.

[errm]

To make the cluster batteries included we should/could ship an ingress controller.

I guess the ALB ingress controller seems like the best AWS native option...

https://github.com/kubernetes-sigs/aws-alb-ingress-controller/

[ettiee]

Currently the release tags for terraform-aws-eks map to EKS versions. As we are shipping technologies with terraform-aws-eks how would we upgrade a version of e.g. ALB Ingress Controller should we want to upgrade those individual technologies?

[errm]

Currently the release tags for terraform-aws-eks map to EKS versions.

The patch version number can be bumped if/when we want to change something ...

We would only do this though:

• If the upgrade was not a breaking change
• or Included a very important bugfix
• or Included a security fix

The idea is to keep each release fairly stable, and bundle big upgrades of the cluster level components into the k8s version upgrade cycle. Then we only have to worry about handling any upgrade issues on a ~ quarterly basis

[errm]

Further to this ... @ettiee have you found a need to upgrade the ALB ingress controller outside of bumping the k8s version?

[ettiee]

Further to this ... @ettiee have you found a need to upgrade the ALB ingress controller outside of bumping the k8s version?

No, but we have found the need to upgrade flux outside of bumping the k8s version

[errm]

No, but we have found the need to upgrade flux outside of bumping the k8s version

I was thinking that flux is not a per cluster component ... so we possibly wouldn't want to manage it in the k8s module anyhow... wdyt?

[ettiee]

No, but we have found the need to upgrade flux outside of bumping the k8s version

I was thinking that flux is not a per cluster component ... so we possibly wouldn't want to manage it in the k8s module anyhow... wdyt?

Yeah fine by me, we have it in every cluster atm but other teams might not want it. I'm keen to only have components managed from terraform-aws-eks which are absolutely required by everyone so that we keep flexibility to choose components within our team if we want to

[errm]

The current stratergy is to install everything by default... then provide flags to disable if required:

https://github.com/cookpad/terraform-aws-eks/tree/master/modules/cluster#cluster-critical-add-ons

Does this line up with:

I'm keen to only have components managed from terraform-aws-eks which are absolutely required by everyone so that we keep flexibility to choose components within our team if we want to

Or would you prefer the default config to be a bare-bones cluster... and require stuff to be enabled?

[dan-slinky-ckpd]

I really would prefer to have feature flags. Whilst having batteries included can be useful I would really dislike be constrained if there was a bug or feature that we could deal with through a version upgrade but couldn't because another part of the business is dependent on what's provided by the module.

[errm]

I really would prefer to have feature flags.

All of the addons have flags to disable them if required... we will continue this pattern.

As to if they are on or off by default... I have just been trying to do whatever makes most sense as a happy path!