-
Notifications
You must be signed in to change notification settings - Fork 827
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
Umbrella issue: k8s.gcr.io => registry.k8s.io solution #1834
Comments
Correct link as Github parsed wrong I guess: https://hackmd.io/@TKToYPauRJ-u_mNRBOh4HQ/HJBH3QF4_ |
This finally forced me to disassemble the registry protocol a bit. Interesting. I picked a simple image I know:
I picked the last blob:
So maybe this is not so hard as I feared? If we catch URLs of the form Then we catch URLs of the form What I don't know is what tools or public IP databases or other resources are available for the 2nd part. The more we can outsource, the better. But a proof-of-concept would be cool! I spent a bit of time trying to coax the Google cloud LB to distinguish I suspect that a model which requires providers to answer our DNS will be more difficult overall. |
@stp-ip, thank you. I've updated the description |
Great to see this discussion happening! A few things I'd like to see:
These discussions/decisions impact release delivery, so I'd really love to see them happening in venues where @kubernetes/release-managers are hanging out. |
@thockin, thank you for your input!
I suspect that clients may be fine with redirects
I'm unsure the capability of Google CloudDNS or the use of LoadBalancers to achieve this, community-hosting it might be the option (I'm still investigating otherwise).
This would mean declaring a rule to rewrite the URL that redirects to a DNS host that uses split-horizon DNS which will then go to a blobs server at the nearest cloud provider? |
@justaugustus, appreciate your comments!
Thank you, I'll take a read of the KEP.
Totally [epic], I'll check it out as well
Absolutely! I've got the two proposals for either Distribution or Harbor. Both are wonderful pieces of software.
That would be lovely!
I'll get in contact regarding this issue with folks. I look forward to coordinating a solution with ya'll 😃 |
> I spent a bit of time trying to coax the Google cloud LB to distinguish
/v2/<name>/manifests/<ref> from /v2/<name>/blobs/<digest> so the 1st part
could simply be a cloud LB rule. Alas it only matches on prefixes. It might
be possible to use Content-Type or Accept headers to tell the difference
(suggested: match Accept header with blob mime type). If we could do that,
then the only thing we'd have to own would be the 2nd part.
This would mean declaring a rule to rewrite the URL that redirects to a
DNS host that uses split-horizon DNS which will then go to a blobs server
at the nearest cloud provider?
Either 302 redirect to `blob.k8s.io` which uses DNS split horizon (which
requires the backends to host certs for that SAN) or 302 to `blob.k8s.io`
which is code we host that does the GeoIP lookup, picks a best backend, and
then 302s again to that backend. The advantage of the latter is that the
backends don't need special certs.
If we can't coax the cloud LB to do this for us, it starts to look more
like:
1) User pulls foo:bar
2) Client hits `reg.k8s.io/v2/foo/manifests/bar`
3) Receive that at a program we run (nginx or bespoke or ...)
4) Redirect to `k8s.gcr.io/v2/foo/manifests/bar`
5) Metadata fetched
6) Client hits `/v2/foo/blobs/<digest>`
7) Received at same program as step 3
8) GeoIP lookup, backend select
9) Redirect to `<backend>/v2/foo/blobs/<digest>`
10) Repeat steps 6-10 for each blob
11) Image is pulled
…On Mon, Mar 29, 2021 at 12:39 PM Caleb Woodbine ***@***.***> wrote:
@thockin <https://github.com/thockin>, thank you for your input!
If we catch URLs of the form https://reg.k8s.io/v2/<name>/manifests/<tag>
we can redirect those to k8s.gcr.io (which has global replicas) or some
other "canonical" source for metadata. I don't know if docker clients would
trip over a literal redirect or what, so worst case we'd have to proxy that
data (yuck).
I suspect that clients may be fine with redirects
Then we catch URLs of the form https://reg.k8s.io/v2/<name>/blobs/<digest>
and redirect to one of the backends. As you point out, we have to do the
split-horizon (geo IP) ourselves (yuck).
I'm unsure the capability of Google CloudDNS or the use of LoadBalancers
to achieve this, community-hosting it might be the option (I'm still
investigating otherwise).
I spent a bit of time trying to coax the Google cloud LB to distinguish
/v2/<name>/manifests/<ref> from /v2/<name>/blobs/<digest> so the 1st part
could simply be a cloud LB rule. Alas it only matches on prefixes. It might
be possible to use Content-Type or Accept headers to tell the difference
(suggested: match Accept header with blob mime type). If we could do that,
then the only thing we'd have to own would be the 2nd part.
This would mean declaring a rule to rewrite the URL that redirects to a
DNS host that uses split-horizon DNS which will then go to a blobs server
at the nearest cloud provider?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1834 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKWAVBO573V2ZMDD27MCCLTGDJQTANCNFSM4Z2H3FUQ>
.
|
Would you say that a small webserver to do 302 redirects may be easier or more maintainable than split-horizon?
This is a really clear flow! @thockin, thank you! |
Can I do an attempt into Cloud Run and check if instead we run a machine, running a function that does the redirect wouldn't be cheaper (probably not!) and better? :D Edit: @justinsb was fair enough saying that we probably can run this inside the AAA and have not so much problems as well, so yeah, let's see how we can use a redirector inside Kubernetes |
I've been searching out a few ASNs for larger cloud providers that likely hit our existing infra.
|
There are a few other providers that could result in traffic, but above felt like a good additional selection of the bigger ones. So depending on how much traffic is done by those above we could always dig deeper. Let's see what the stats say for the listed providers and then happy to dig into the smaller providers. |
I believe this is the list of ASNs for Equinix Metal:
- 8545
- 9989
- 12085
- 12188
- 14609
- 15734
- 15830
- 15830
- 15830
- 15830
- 15830
- 15830
- 15830
- 16243
- 16397
- 16553
- 17819
- 17941
- 19930
- 21371
- 23637
- 23686
- 24115
- 24121
- 24989
- 24990
- 26592
- 27224
- 27272
- 27330
- 27566
- 29154
- 29884
- 32323
- 32550
- 34209
- 35054
- 43147
- 47886
- 47886
- 54588
- 54825
- 62421
- 64275
- 137840
- 139281
- 264220
- 265376
- 266849
- 270119
- 394749
|
ASNs in k8s.io repo: #1914 |
Yes. My thinking is mostly around TLS - if we do split horizon, the real backends have to offer certs for our names. If we 302, they do not. There are a number of GeoIP libs for Go that could be viable. Other than that, the logic seems simple enough to prototype. We could throw it into the aaa cluster as a quick test. |
Thank you @thockin for your comments. Regarding using a service to perform a redirect, the behavour of something like
ref: https://ii.coop/blog/rerouting-container-registries-with-envoy/#the-implementation |
Do you mean deploying https://github.com/kubernetes/k8s.io/tree/main/artifactserver as a test? |
related: #1758 |
I deployed Envoy as well as Distribution on a cluster in the k8s-infra-ii-sandbox project from this Org file |
@BobyMCbobs can we try deploying artifactserver as well? |
Yes! I've deployed it to https://artifacts.ii-sandbox.bobymcbobs-oitq.pair.sharing.io at the moment I am currently trying to adapt the source to provide the same 302 functionality as what Envoy is providing. |
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 |
see: https://docs.google.com/document/d/1yNQ7DaDE5LbDJf9ku82YtlKZK0tcg5Wpk9L72-x2S2k/ (shared with dev@kubernetes.io mailinglist and the SIG mailing list) for some recent discussion on this topic. |
Related: - kubernetes/k8s.io#1834 Test different AWS AMI with registry-sandbox.k8s.io Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Related: - kubernetes/k8s.io#1834 Test different AWS AMI with registry-sandbox.k8s.io Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Update 📰 🎉 The redirecting from registry.k8s.io to k8s.gcr.io and prod-registry-k8s-io-$REGION.s3.dualstack.us-east-2.amazonaws.com is instantiated and there is automated replication between the buckets. cc @kubernetes/sig-k8s-infra |
I think we can close this. This is at https://registry.k8s.io now and is generally implemented. What remains is phasing over users, which we're tracking elsewhere. |
/close |
@BenTheElder: Closing this issue. In response to this:
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/test-infra repository. |
Umbrella issue: k8s.gcr.io => registry.k8s.io solution #1834
This markdown is synced from https://hackmd.io/gN-1GeSpSgyNSvmjKSULbg?edit to #1834 (comment) manually by @BobyMCbobs
Scope: https://github.com/kubernetes/k8s.io/wiki/New-Registry-url-for-Kubernetes-(registry.k8s.io)
Design Doc: https://docs.google.com/document/d/1yNQ7DaDE5LbDJf9ku82YtlKZK0tcg5Wpk9L72-x2S2k/edit (shared w/ dev@kubernetes.io and SIG mailing list)
Board: https://github.com/orgs/kubernetes/projects/77
DRAFT AIs that need filled turned into tickets:
https://github.com/orgs/kubernetes/projects/77/views/2?filterQuery=is%3Adraft
What exactly are you doing? (and how?)
#39
The text was updated successfully, but these errors were encountered: