/cc @wojtek-t

/sig api-machinery

你好，@linxiulei
我喜欢你使用手表连接来同步租约与kube-apiserver的想法。
这可以通过减少对kube-apiserver的请求数量、节省kube-apiserver的资源消耗以及避免获取过期租约的风险来提高集群性能和可靠性。

然而，我也看到了在做这件事时遇到的一些困难和成本。例如，如果手表连接断开或掉落怎么办？这可能会导致领导者选举失败或延迟。一个可能的解决方案是使用重试机制或备用连接来恢复同步。为了确保手表连接不会增加更多的负载或复杂性(以免影响集群的性能和可靠性),我们可以使用轻量级协议或压缩技术来减少数据传输和处理。

你对这些建议有什么看法？
我认为这个问题很有趣，值得进一步探讨。我希望我们能一起找到一个好的解决方案。
感谢你对Kubernetes的宝贵贡献和兴趣！

关于使用watch作为领导者的补充：

1. 我对使用watch作为领导者持-1态度。我们需要尽力确保在已经获取到领导者锁之后，不会丢失领导者锁，而且如果租约面临更高的watch延迟(我们在过去观察到的情况),这种情况就更有可能发生。
2. 对于领导者，我们知道只有领导者应该更新租约。因此，我们可以通过以下最简单的方法来实现：

• 乐观地假设我们之前的写入操作的结果是当前版本
• 如果发生冲突，回退到“GET + PUT”再次尝试

我对上述观点表示赞同。

1. 我想我可能可以接受仅对非领导者使用watch 前提是我们只对非领导者这样做。
   在这种情况下，滞后的watch效应仅影响给定组件无法接管领导者锁或在锁已经被不同示例在同时获取的情况下的一些额外调用。
   话虽如此，在我同意这个观点之前，我想看到一些回退到“GET+PUT”的机制，并希望了解它是如何工作的。
   请注意，我为非领导者看到的额外优势是，由于默认的RetryPeriod=2s和默认的LeaseDuration=10s,平均每2.5次调用中只有1次是有用的(其他次调用都是无用的，因为在此期间没有发生变化),因此我们实际上也可以节省处理这些请求时的一些资源。
   @liggitt - 仅供参考

你的建议大致符合我的设想，并采取了额外的安全措施。谢谢！
我制作了一个 PR ,需要一些润色。PTAL!

/assign @wojtek-t
谢谢。
/triage accepted

感谢贡献'
请避免在未将问题分配给自己的情况下发起PR!