-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Introduce Kubernetes interface to etcd client #16333
Conversation
Hello! I'm not a developer of etcd or Kubernetes, asking just out of curiosity. From what I can see in the API you've provided, it appears that Kubernates never modifies multiple keys within a transaction. Is it true? |
It's not supposed to, it breaks the watch protocol. See this doc for more details. |
I see, thank you! I'm a little bit confused about it, since I've read multiple times that etcd is a bottleneck for Kubernates scalability. If there are no multi-keys transactions why isn't is possible to just partition all keys by hash for example, run multiple instances of etcd with each instance handling requests for a given subset of keys and get scalable Kubernates? |
It's not, K8s scalability limits are mostly hit by badly written operators that do not use proper API machinery. People are sharding etcd under Kubernetes (for example events are frequently separated due their different nature event vs state). Note; This is an PR and not a discussion about the K8s API design. Please leave any follow up questions on this document. Any further questions will be removed to avoid cluttering the PR comments |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
Doing a second iteration based on kubernetes/kubernetes#125258 ping @ahrtr for feedback |
98c5b1c
to
61005d1
Compare
/hold |
8d42d04
to
8fa70e1
Compare
/retest |
I'm testing this PR by running K8s tests on it in kubernetes/kubernetes#125258. Would prefer to defer unit test to separate PR to ensure we are compatible with K8s first. |
client/v3/kubernetes/client.go
Outdated
return resp, nil | ||
} | ||
|
||
func (k Client) optimisticTxn(ctx context.Context, key string, expectRevision int64, onSuccess, onFailure *pb.RequestOp) (*pb.TxnResponse, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func (k Client) optimisticTxn(ctx context.Context, key string, expectRevision int64, onSuccess, onFailure *pb.RequestOp) (*pb.TxnResponse, error) { | |
func (k Client) optimisticTxn(ctx context.Context, key string, expectedRevision int64, onSuccess, onFailure *pb.RequestOp) (*pb.TxnResponse, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, serathius The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Would like to get review from SIG-api-machinery too. |
// | ||
// If opts.GetOnFailure is true, the modified key-value pair will be returned if the put operation fails due to a revision mismatch. | ||
// If opts.LeaseID is provided, it overrides the lease associated with the key. If not provided, the existing lease is cleared. | ||
OptimisticPut(ctx context.Context, key string, value []byte, expectedRevision int64, opts PutOptions) (PutResponse, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potential alternative designs:
- Just use
Put
for this, but acceptexpectedRevision
as an optional option inPut
, maybe in aprecondition
section. - Put expectedRevision in an OptimisticPutOptions here. (OptimisticPutOptions could embed PutOptions and extend it...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kubernetes doesn't do Put without condition, and don't think it ever will. Don't understand why we would separate it.
Considered having expectedRevision in options, however I consider options, being optional while expectedRevision needs to be always provided because even zero has a semantic meaning.
ad516c3
to
a26d984
Compare
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files
... and 409 files with indirect coverage changes @@ Coverage Diff @@
## main #16333 +/- ##
=========================================
+ Coverage 0 68.71% +68.71%
=========================================
Files 0 418 +418
Lines 0 35423 +35423
=========================================
+ Hits 0 24341 +24341
- Misses 0 9665 +9665
- Partials 0 1417 +1417 Continue to review full report in Codecov by Sentry.
|
Signed-off-by: Marek Siarkowicz <[email protected]>
/retest |
/retest |
Matching ticket on Kubernetes side kubernetes/kubernetes#125258
cc @ahrtr @logicalhan
Design: https://docs.google.com/document/d/1-nIpoW87qqQ9FxINOzXPkhu7CD_FWW1piYqHZDr39nU/edit?usp=sharing
Part of #15820