etcd v3.7 Docker image deprecations

[upodroid]

What would you like to be added?

Hi

I would like the project to announce the following changes from etcd 3.7+ onwards:

1. etcd images are now available at registry.k8s.io/etcd. Please update your manifests to pull from there. Lets update the previous github releases.
2. gcr.io/etcd-development & quay.io/etcd are now deprecated, and we will no longer push etcd 3.8 and newer versions there
3. per arch specific tags, such as etcd:v3.7.0-amd64 are now deprecated and will no longer be pushed, please switch to the main tagged version as it is a multi-architecture image. This one we can apply in 3.7
4. etcd has been available to download from GitHub releases for several releases. We will also stop publishing to https://storage.googleapis.com/etcd, so please ensure you download etcd from our GitHub releases page.

During 3.6, I'll be working on fixing the release pipeline and making it fully automated #20915

Why is this needed?

etcd is now a Kubernetes project, and the designated methods for serving release assets are:

• images are served from registry.k8s.io
• blobs are served from GitHub releases

[ahrtr]

1. etcd images are now available at registry.k8s.io/etcd

We discussed this multiple times, and already agreed to add it as one of the official etcd registries. Refer to #20756 (comment)

2. gcr.io/etcd-development & quay.io/etcd are now deprecated

The registries have already been used for about a decade. We should keep it if you don't have a strong justification (not including etcd is now a Kubernetes project)

3. per arch specific tags, such as etcd:v3.7.0-amd64 are now deprecated and will no longer be pushed, please switch to the main tagged version as it is a multi-architecture image. This one we can apply in 3.7

We also discussed this multiple times, and already agreed on it.

4. etcd has been available to download from GitHub releases for several releases. We will also stop publishing to https://storage.googleapis.com/etcd, so please ensure you download etcd from our GitHub releases page.

I have no objection on this. It should be good enough to download the binaries from github release page. Also It's high likely that most users are not aware of https://storage.googleapis.com/etcd

cc @hakman @ivanvc @joshjms

[serathius]

2. gcr.io/etcd-development & quay.io/etcd are now deprecated

The registries have already been used for about a decade. We should keep it if you don't have a strong justification (not including etcd is now a Kubernetes project)

+1, one possible justification would be ability to use image promoter to those registries.

[ivanvc]

2. gcr.io/etcd-development & quay.io/etcd are now deprecated

The registries have already been used for about a decade. We should keep it if you don't have a strong justification (not including etcd is now a Kubernetes project)

+1, one possible justification would be ability to use image promoter to those registries.

One of the issues we were exploring while trying to automate releases, is that we can push to the k8s registry, but in order to push to other registries, it could be more complex. A workaround we found was to have a periodic job cloning released images from the k8s registry to the other ones.

While I tink it may make sense to promote registry.k8s.io as the official, and possible later to the only one. I think this needs to be stages. Probably first we can start by marking registry.k8s.io as the official and our GCR and quay as secondaries.

3. per arch specific tags, such as etcd:v3.7.0-amd64 are now deprecated and will no longer be pushed, please switch to the main tagged version as it is a multi-architecture image. This one we can apply in 3.7

We also discussed this multiple times, and already agreed on it.

Do you have the links on when this was discussed, @ahrtr? What we're trying to achieve in this point is to use the multi-arch manifest, rather than pushing tags with the architecture as prefix. We are already pushing this manifest, but we push the individual tags, too.

i.e., v3.6.6-amd64, v3.6.6-arm64 vs. only v3.6.6, and letting the client select the architecture.

/retitle etcd v3.7 Docker image deprecations

[ahrtr]

One of the issues we were exploring while trying to automate releases, is that we can push to the k8s registry, but in order to push to other registries, it could be more complex. A workaround we found was to have a periodic job cloning released images from the k8s registry to the other ones.

While I tink it may make sense to promote registry.k8s.io as the official, and possible later to the only one. I think this needs to be stages. Probably first we can start by marking registry.k8s.io as the official and our GCR and quay as secondaries.

I suggest that you work with @hakman and @joshjms on this. I believe both of them have more context.

Do you have the links on when this was discussed, @ahrtr? What we're trying to achieve in this point is to use the multi-arch manifest, rather than pushing tags with the architecture as prefix. We are already pushing this manifest, but we push the individual tags, too.

I meant that we already agreed to use multi-arch image. We discussed in multiple places (not sure if @joshjms or @hakman have any links at hand). It's just a matter of time, either after K8s. 1.35 or etcd 3.7. Also let's work with @hakman and @joshjms and Kubernetes folks to finalize this.

[ivanvc]

@ahrtr, got it. We're all aligned. It's a matter of updating documentation and tagging everyone involved.