-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Reference implementation for sharded system #1064
Comments
@brendandburns maybe can we turn the flake finder into this? :) |
This is probably a dupe (or variation) of #260 |
Adding more details: Sharding requires assignment of data to servers that are typically of finer granularity than pods, and some means for the client to find the server that has the desired data item. One could also replicate shards for availability or hot-spot migitation, and/or cache them in multiple pods. Target affinity would likely be useful in the scenario that shard discovery were handled by the load balancer. Sharding isn't necessarily incompatible with auto-scaling, though shard reassignment would be necessary. Consistent hashing could potentially be used to assign shards, as could fine-grain locks or a work queue, as proposed above. |
While I generally advocate dynamic work allocation, for simple use cases, a static shard assigner could statically map shards to the predictable hostnames generated for the cardinal service (#260). |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
Fix subnet.env saved path
A system where data is sharded among several pods will be a common pattern (that is, each pod handles a different chunk or chunks of some data that is too large for any one pod). As mentioned in #1007, the preferred way to tell each pod to do this is to have a work queue or work lease system. The not-preferred way to do this is to generate a different config for each pod which tells it which shard to handle.
It would be good to have a example application that follows the preferred pattern, to show users how we think k8s should be used, and to confirm that it is as easy to do as we think it will be.
A good example could be a search application. Maybe someone could get Apache Solr running on K8s.
The text was updated successfully, but these errors were encountered: