Skip to content
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

Closed
erictune opened this issue Aug 27, 2014 · 7 comments
Closed

Reference implementation for sharded system #1064

erictune opened this issue Aug 27, 2014 · 7 comments
Labels
area/api Indicates an issue on api area. area/downward-api kind/design Categorizes issue or PR as related to design. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/network Categorizes an issue or PR as relevant to SIG Network.

Comments

@erictune
Copy link
Member

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.

@lavalamp
Copy link
Member

@brendandburns maybe can we turn the flake finder into this? :)

@smarterclayton
Copy link
Contributor

This is probably a dupe (or variation) of #260

@bgrant0607 bgrant0607 added sig/network Categorizes an issue or PR as relevant to SIG Network. area/downward-api area/api Indicates an issue on api area. kind/design Categorizes issue or PR as related to design. labels Oct 2, 2014
@bgrant0607
Copy link
Member

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.

@bgrant0607 bgrant0607 added this to the v0.9 milestone Oct 4, 2014
@bgrant0607
Copy link
Member

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).

@bgrant0607 bgrant0607 added status/closed/invalid priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. and removed status/closed/invalid labels Dec 3, 2014
@bgrant0607 bgrant0607 removed this from the v0.9 milestone Dec 3, 2014
@bgrant0607 bgrant0607 added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Feb 28, 2015
@bgrant0607 bgrant0607 added team/ux and removed sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. labels May 13, 2016
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 21, 2017
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 20, 2018
b3atlesfan pushed a commit to b3atlesfan/kubernetes that referenced this issue Feb 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. area/downward-api kind/design Categorizes issue or PR as related to design. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/network Categorizes an issue or PR as relevant to SIG Network.
Projects
None yet
Development

No branches or pull requests

7 participants