Redirect dl.k8s.io traffic to a community-owned GCS bucket instead of kubernetes-release

[spiffxp]

Part of umbrella issues:

• to deprecate and migrate away from gs://kubernetes-release: Deprecate and migrate away from gs://kubernetes-release #2396
• to migrate away from GCP project google-containers: Migrate away from google.com GCP project google-containers #1571

Traffic gets to gs://kubernetes-release in one of two ways:

• uri's that have the bucket name hardcoded (e.g. https://cs.k8s.io/?q=kubernetes-release%5B%5E-%5D&i=nope&files=&repos=)
• dl.k8s.io uri's that redirect to the bucket (too many matches for cs.k8s.io to display, but e.g. used in kubernetes/kubernetes CHANGELOGs)

We discussed the idea of cutting over dl.k8s.io traffic first:

• perhaps we could end up cutting over a large chunk of traffic sooner vs. later
• this will help us better plan how to migrate traffic that has the bucket name hardcoded

The sketch is something like:

• decide which project/bucket to use?
• sync from old bucket to new bucket
• change dl.k8s.io to use new bucket instead of old bucket
• see what the delta in traffic is
• decide how to keep buckets in sync?

Which project/bucket to use:

• we have k8s-release hosting gs://k8s-release
• we could choose to use a bucket hosted in k8s-artifacts-prod (simplifies billing)
• we could choose to block until we have similar staging/promotion process for GCS artifacts

How to sync:

• https://cloud.google.com/storage-transfer is pretty simple/fast to setup, I would at least use this for initial sync
  • There is currently no gcloud command, but there is an API and some bindings (ref: https://cloud.google.com/storage-transfer/docs/create-manage-transfer-program#cloud-to-cloud)
  • It supports recurring jobs, but no more frequent than hourly (ref: https://cloud.google.com/storage-transfer/docs/reference/rest/v1/transferJobs#TransferJob)
  • It supports one-time jobs, with a limit of 1K per day per project (ref: https://cloud.google.com/storage-transfer/quotas)
• For ongoing sync we could
  • rely on hourly sync
  • periodically create one-time sync jobs more frequently
  • use gcs pubsub notifications to create sync jobs
  • alter release tooling to publish to multiple buckets
  • alter release tooling to create sync jobs

Seeing the delta in traffic:

• we'll be able to see an influx of traffic in our billing report
• @thockin and I need to decide if/how to share the existing traffic gs://kubernetes-release is getting

My preferences would be:

• delete/recreate the gs://k8s-release bucket in k8s-artifacts-prod
• use sts, rely on hourly sync job first, then prowjob that periodically creates one-time syncs

/assign @thockin
since you were part of the discussion
/assign @justaugustus @hasheddan
For @kubernetes/release-engineering input

/wg k8s-infra
/sig release
/sig testing
/area artifacts
/milestone v1.21