-
Notifications
You must be signed in to change notification settings - Fork 791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate and migrate away from gs://kubernetes-release #2396
Deprecate and migrate away from gs://kubernetes-release #2396
Comments
/cc @kubernetes/release-engineering |
Blocked on #1375 |
/milestone v1.24 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
/milestone clear |
/milestone v1.30 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
/milestone v1.31 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Part of umbrella issue to migrate the kubernetes project away from use of GCP project google-containers: #1571
This issue covers the deprecation of and migration away from the following google.com assets:
gs://kubernetes-release
living in GCP projectgoogle-containers
, in favor of the community-owned GCS bucketgs://k8s-release
living in GCP project TBD (currentlyk8s-release
)gs://kubernetes-release-asia
andgs://kubernetes-release-eu
, same as above butgs://k8s-release-eu
andgs://k8s-release-asia
insteadThese are not labeled as steps just yet because not everything needs to be completed to full fidelity in strict sequential order. I would prefer that we get a sense sooner rather than later what the impact of shifting dl.k8s.io traffic will be, in terms of how much budget, and what percentage of traffic that represents vs. hardcoded traffic.
Determine new-to-deprecated sync implementation and deprecation window
There are likely a lot of people out there that have
gs://kubernetes-release
hardcoded. It's unreasonable to stop putting new releases there without some kind of advance warning. So after announcing our intent to deprecategs://kubernetes-release
, we should decide how we're going to sync new releases back there (and its region-specific buckets)gsutil rsync
As for the deprecation window itself, I think it's fair to treat this with a deprecation clock equivalent to disabling a v1 API.
Determine gs://k8s-release project location and geo-sync implementation
gs://k8s-release
and its other buckets to prevent someone else from grabbing the name-eu
and-asia
buckets are not actually region-specific, and should be recreated as suchUse dl.k8s.io where possible and identify remaining hardcoded bucket name references across the project
The only time a kubernetes release artifact GCS bucket name needs to show up in a URI is if gsutil is involved, or someone is explicitly interested in browsing the bucket. For tools like
curl
orwget
that retrieve binaries via HTTP, we havehttps://dl.k8s.io
, which will allow us to automatically shift traffic from one bucket to the next depending on the requested URIsI started doing this for a few projects while working on #2318, e.g.
TODO: a cs.k8s.io query and resulting checklist of repos to investigate
Shift dl.k8s.io traffic to gs://k8s-release-dev
TODO: there is a separate issue for this.
We will pre-seed gs://k8s-release with everything in gs://kubernetes-release, and gradually modify dl.k8s.io to redirect more and more traffic to gs://k8s-release.
The idea is not to flip a switch, just in case that sends us way more traffic than our budget is prepared to handle. Instead, let's consider shifting traffic gradually for certain URI patterns, or a certain percentage of requests, etc. It's unclear whether this will be as straightforward as adding lines to nginx, or whether we'll want GCLB changes as well.
Change remaining project references to gs://k8s-release
/area artifacts
/area prow
/area release-eng
/sig release
/sig testing
/wg k8s-infra
/priority important-soon
/kind cleanup
/milestone v1.23
The text was updated successfully, but these errors were encountered: