Proposal: Change K8s version upgrade timing to be more flexible

[markmandel]

Coming out of the community meeting, we discussed how spread out Kubernetes versions are becoming across cloud providers.

For example, currently:

• EKS just recently added 1.15 support and supports 1.12 to 1.15
• GKE recently dropped 1.13 support and now only supports 1.14 and 1.15 with 1.16 in the rapid release channel
• AKS supports 1.14 to 1.16 with 1.17 in preview

The suggestion from the meeting would be to change the currently documented upgrade path from:

Agones will update its support to n-1 version of what is available across all major cloud providers - GKE, EKS and AKS

To:

Agones will update its support to n-1 version of what is available across the majority of major cloud providers - GKE, EKS and AKS, while also ensuring that all Cloud providers can support that version.

So for example, with the current versions supported, under the current rules, we can't upgrade to 1.15 until EKS catches up to GKE and AKS and releases 1.16.

In the new model, we could now move the supported Kubernetes version to 1.15, since it is the n-1 latest version available on two out of the three providers, while still also being available across GKE, AKS and EKS.

Currently we have sometimes ended up sitting just ahead of the drop off of when K8s versions are no longer available on a Cloud provider -- which would mean that those users would not be able to install Agones on a supported platform, so it would be ideal to move a little faster on our upgrades.

This also related to #1146, as its very hard for us to support versions of Kubernetes that are no longer supported by Cloud providers, and specifically GKE, which is where we do the majority of our testing.

[roberthbailey]

Speaking of cloud providers dropping support for older versions, the AKS documentation says that Microsoft "supports three minor versions of Kubernetes" and "aims to certify and release new Kubernetes versions within 30 days of an upstream release".

Given that they have 1.17 in preview and 1.18 was just released it seems like we are ~30 days from 1.14 being dropped from their supported list of versions.

[roberthbailey]

As I mentioned during the meeting, it seems like we have a few options here:

1. Keep up with the faster moving cloud providers (Microsoft leading and Google close behind) while hoping that EKS continues to add support for newer versions fast enough
2. Support different versions of Kubernetes on different providers (e.g. 1.15 on GKE, AKS and 1.14 on EKS)
3. Support multiple versions of Kubernetes for a given release

The latter two options impose a large testing burden on our project, so I think that the first option (this proposal) is currently our best path forward. And if EKS falls too far behind, we will need to decide how to proceed.

[roberthbailey]

I propose:

1. Update the supported version policy as suggested above
2. Move to Kubernetes 1.15 as soon as 1.5 is released, so that it will be the supported version for 1.6.

[markmandel]

I've added this to milestone 1.6.0, since it seems like this should be locked in with this milestone.

Unless anyone objects, I'll look to ratify this in the documentation after we release 1.5.0 stable next week.

[markmandel]

Pinned this, so we remember to jump on this. I'm pretty focused on trying to get a version of player tracking out in this release, so if someone else has cycles to make these changes to the documentation, I would appreciate it.

[roberthbailey]

/assign

[markmandel]

Thanks @roberthbailey !

[roberthbailey]

The documentation changes were submitted in #1477 and is live. Marking this as fixed.