k8s.io
k8s.io copied to clipboard
kubernetes
Cleanup registry.k8s.io
We have a few images present in registry.k8s.io that are non-used, with more recent versions on other registries or shouldn't be hosted on the Kubernetes official registry.
- cluster-api-aure
- etcd-version-monitor-shyamjvs
- etcd_monitor_shyamjvs
- etcd_probe_shyamjvs
- gke-certificates-controller
- gke-cloud-kms-plugin
- gke-cloud-kms-sync
- gke-launcher
- gke-master-backup
- gke-metadata-server
- gke-mpi-api-server
- gke-mpi-metadata-server
- gke-node-termination-handler
- google-containers-test-image
- kibana
- rethinkdb
- shyamjvs-logexp
- shyamjvs-prometheus-to-sd
- ubuntu
- update-demo
- ubuntu-slim-amd64
- visio-stencil-creator
List will be updated over time
We should remove them after freeze of k8s.gcr.io is in effect.
Update: A communication plan needs to be established and approved by Steering (according to the charter)
/area artifacts /area release-eng /milestone v1.28
cc @mrbobbytables @thockin
I'm hesitant on principle to be deleting things while we're telling people "we're redirecting k8s.gcr.io, everything will still be there". Can we revisit this at some later date?
After seeing the hpa-example:latest image with no other tags and no current sources/maintainers that is a substantial portion of our traffic, I don't want to make assumptions about what images our users are and aren't depending on in the midst of the fun moving users over.
xref: https://github.com/kubernetes/release/issues/2924#issuecomment-1454301010
I agree with Ben here, like....we're about to redirect everything, we're already giving users different pieces of messaging with the freeze on 4/3 and the redirect next week. The redirect should take care of our immediate cost issues and we can plan a more graceful clean up and sunsetting.
Can we revisit this at some later date?
Intented to be done after the freeze and probably during 1.28.
Some of those images are not critical to the lifecycle of k8s clusters regardless on how there are used. We should probably start to clean up tags for those images before we delete them completely and it's possible to restore them.
I would say even 1.28, please do not. The cost savings are not even a rounding error and we should not risk issues with the GCR redirect.
This can wait.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@ameukam: Closing this issue.
In response to this:
Let's close this and reopen a new issue if needed
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
