Question

我对Kubernetes的kube-controller-manager和kube-scheduler的领导者/从属租赁管理有疑问：据我所知，Kubernetes在kube-system名称空间中将当前领导者作为端点跟踪。 / p>

您可以通过以下方式获取领导者

$ kubectl get endpoints -n kube-system

NAME                      ENDPOINTS                   AGE
kube-controller-manager   <none>                      20m
kube-scheduler            <none>                      20m

然后例如

$ kubectl describe endpoints kube-scheduler -n kube-system

Name:         kube-scheduler
Namespace:    kube-system
Annotations:  control-plane.alpha.kubernetes.io/leader={"holderIdentity":"controller-0", ...}

当前领导者是holderIdentity批注中的control-plane.alpha.kubernetes.io/leader。

我的问题：

在Kubernetes端点之上的leaderelection.go中实现了诸如获取租赁，续订租赁，居住时间等租赁管理。是否有特定原因导致未直接使用“开箱即用”的Etcd原语（例如Etcd的比较和交换操作以及对象上的生存时间）直接在Etcd上实施租约管理？

修改

添加Etcd比较和交换
增加Etcd的生存时间

Answer 1

一些原因：

Etcd可能在Kubernetes网络的外部运行，这意味着网络延迟
Etcd可能很忙/正在加载，因此很慢
etcd集群的节点很可能少于Kubernetes主节点，从而使其可靠性降低

Answer 2

出于安全原因，仅API服务器应有权访问etcd。请记住，如果按照惯例将etcd用于领导者租约，则使用领导者选举的自定义控制器和操作员也将需要访问etcd，考虑到etcd中存储的数据至关重要，因此不建议这样做。

参考：https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#securing-etcd-clusters

Kubernetes的高可用性领导者租约

2 个答案: