-
Notifications
You must be signed in to change notification settings - Fork 76
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
Add more S3 regions #172
Comments
/assign /area infra/aws |
@ameukam: The label(s) 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. |
We should ideally have:
We started with a good approximation of 1) in #39 / #72, but it might be worth revisiting. For 2) we have an okay approximation reusing the same set from 1), but we know there's at least the South America gap and should definitely re-evaluate and select the remaining regions that would most closely match now that we've moved to sending non-AWS-non-GCP traffic to S3 generally. |
List of remaining regions we can add:
|
There's an inflection point where adding a region is wasteful. If we are matching the IP to region with 1) for users within AWS and it only represents a very small amount of traffic within AWS then it's probably not worth it for 1), more regions than Cloud Run is not useful for 2) since we lean on the GCLB routing to determine approximate region for external traffic. |
OK so we looked at the costs today and storage costs are likely going to be smaller than traffic in basically any AWS region with actual traffic. So just adding them for 1) is going to be generally worthwhile. xref: https://kubernetes.slack.com/archives/CCK68P2Q2/p1678915249434949 |
ref: #181 for hold a bit on production changes |
cc @rothgar |
New AR regions added:
|
xref - some data from @TerryHowe here: |
Adding more regions would be easy, but cloudfront should maybe be considered. |
There's another issue tracking CloudFront. I think the idea is we still want to route in-AWS traffic with S3 in any region where cost to store < cost to serve cross region / cloud front. Which should be many regions. CloudFront is probably the right answer for egress otherwise? |
Agree it should be easy, but we've avoided anything altering production behavior through securing the GCR redirect #181 |
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 |
Related: - kubernetes/registry.k8s.io#172 Attach a policy ensuring non-TLS connections are denied. Ensure bucket ownership for each bucket. Ensure account policy for public buckets are disabled. Change logic to generate bucket name. Signed-off-by: Arnaud Meukam <[email protected]>
Related to: - kubernetes/registry.k8s.io#172 Define and attach a policy that make a S3 bucket world-readable. Signed-off-by: Arnaud Meukam <[email protected]>
Related to: - kubernetes/registry.k8s.io#172 Define permissions needed to use S3 replication in the same account. Signed-off-by: Arnaud Meukam <[email protected]>
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 |
The Kubernetes project currently lacks enough active 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 rotten |
South America is the obvious missing one, but we should also consider adding others.
xref: kubernetes/k8s.io#4739 (comment) and discussion in https://kubernetes.slack.com/archives/CCK68P2Q2/p1678504635523609
/sig k8s-infra
/priority important-soon
When we add a bucket it will have to be added to the terraform config in k8s.io including the s3 to s3 replication, then once the bucket is reasonably well populated we'll want to add it to both https://github.com/kubernetes/registry.k8s.io/blob/8408d0501a88b3d2531ff54b14eeb0e3c900a4f3/cmd/archeio/app/buckets.go (AWS clients) and https://github.com/kubernetes/k8s.io/blob/5821271f875cc970b5701983e5695a025b5d952f/infra/gcp/terraform/k8s-infra-oci-proxy-prod/terraform.tfvars (non-GCP non-AWS clients)
This is much more relevant after #147
The text was updated successfully, but these errors were encountered: