search

redpanda-data / helm-charts

Redpanda Helm Chart
http://redpanda.com
Apache License 2.0
77 stars 97 forks source link

Create a Kubernetes Versioning/Support Policy #1146

Open chrisseto opened 6 months ago

chrisseto commented 6 months ago

Internal Slack Thread

In short, what versions (1.20, 1.21, etc)and flavors (EKS,GKE, etc) of Kubernetes do we support, certify, and test against? The current state of affairs is quite vague.

We currently test against v1.27.3 but this is a side effect of using kind v0.20.0 more than being an explicit choice.

JIRA Link: K8S-142

chrisseto commented 6 months ago

Suggestion from @tmgstevens:

we should probably aim to support 4 Kubernetes versions each for a period of 12 months as is common with upstream Kubernetes.

Could we get to a point where nightlies run on the latest, weeklies on 1.n through 1.n-3 and where we’re willing to support any CNCF certified K8S distribution but perhaps certify (as in actively test) perhaps EKS, GKE, AKS, OpenShift and Rancher?

chrisseto commented 6 months ago

The biggest blocker to testing against EKS, GKE, AKS, OpenShift, and Rancher is the need to support the infrastructure that creates those clusters. We don't have the bandwidth right now to be testing on all of them. In my experience, as long as we can test or lint the Kubernetes versions of EKS/GKE/ETC, there's no much benefit from testing on them (Save OpenShift because it's a ❄️ ). The issues with specific distributions will generally stem from trying to provide integrations with cloud specific resources which we currently do not do.

As for testing on a range of K8s versions, it's probably fine to test on the head and tail of the version range we support? There's certainly some historical cases where problems would pop up but we'll get ~80% of the coverage with half the runtime (Assuming a 4 version window).

alejandroEsc commented 6 months ago

The biggest blocker to testing against EKS, GKE, AKS, OpenShift, and Rancher is the need to support the infrastructure that creates those clusters. We don't have the bandwidth right now to be testing on all of them. In my experience, as long as we can test or lint the Kubernetes versions of EKS/GKE/ETC, there's no much benefit from testing on them (Save OpenShift because it's a ❄️ ). The issues with specific distributions will generally stem from trying to provide integrations with cloud specific resources which we currently do not do.

As for testing on a range of K8s versions, it's probably fine to test on the head and tail of the version range we support? There's certainly some historical cases where problems would pop up but we'll get ~80% of the coverage with half the runtime (Assuming a 4 version window).

Yes, very true that different clouds support different versions. I believe they usually support n-2 in general and usually stick to a version before jumping to newest, like eks that is usually lagging IIRC. We should probably just stick to 3 versions imho, and probably follow eks or use a min supported model among the cloud providers and try not to lag too far behind. The problem is we do not have the testing in place to test nightly or weekly for that matter the deployment among different versions.

chrisseto commented 6 months ago

We should probably just stick to 3 versions imho, and probably follow eks or use a min supported model among the cloud providers and try not to lag too far behind. The problem is we do not have the testing in place to test nightly or weekly for that matter the deployment among different versions.

I think that makes a lot of sense. We probably want to shoot for the middle or the most recent version though so we don't have to scramble to do updates if we happen to be behind. WDYT?