Make "Bump etcd Version in Kubernetes" part of the etcd's release process

[ahrtr]

What would you like to be added?

sig-etcd owns the task of bumping etcd version in Kubernetes, and we also have an step by step guide on how to do this (Thanks @joshjms ).

I think we should make the task part of the etcd's release process, so that it won't be forgotten or significant delayed. The concern for now is that if there is any regression, it may affect all the end users who use kubeadm to install K8s cluster. But it might not be a big problem, because the etcd version should have already been verified in Kubernetes workflow checks when it being bumped, i.e. kubernetes/kubernetes#131144. Nonetheless, it still needs some soak time (i.e. 2 ~ 3 weeks); but we might want to bump the etcd image immediately if there are some major CVEs.

So after we release each patch, the proposed high level process is something like below,

• build & publish the etcd image;
• bump etcd image (i.e. Update etcd to 3.5.21 kubernetes/kubernetes#131144).
  • If there are some major CVE fixes, we just merge the PR (of course after all workflows green);
  • otherwise, we need to wait for some soak time (i.e. 2 ~ 3 weeks) before merging it.
• bump etcd client sdk

If the patch contains major bug fixes or CVE fixes, we should bump the etcd version for all K8s supported versions, from higher to lower version.

Also as mentioned in #19717 (comment), we bump etcd v3.5.x for K8s release-1.33 and lower versions, and bump etcd v3.6.x for release-1.34 (master for now) and higher versions.

cc @fuweid @serathius @liggitt @neolit123 @ivanvc @jmhbnz @joshjms @henrybear327

Why is this needed?

to have a smooth integration etcd with Kubernetes