Лизинговый Лизер высокой доступности Kubernetes - PullRequest
Новая
       30

Лизинговый Лизер высокой доступности Kubernetes

0 голосов
/ 28 сентября 2018

У меня есть вопрос, касающийся управления арендой лидера / последователя Kubernetes для kube-controller-manager и kube-scheduler: насколько я понимаю, Kubernetes отслеживает текущего лидера как конечные точки в пространстве имен kube-system.

Вы можете получить лидера через 

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

Мой вопрос:

Управление арендой, например приобретение аренды, возобновление аренды, время жизни и т. Д., Реализовано в leaderelection.go поверх конечных точек Kubernetes.Существует ли конкретная причина, по которой управление арендой не реализовано непосредственно в Etcd с помощью готовых примитивов Etcd, таких как операции сравнения и замены Etcd, а также время жизни на объектах?

Редактировать (s))

  • добавить сравнение Etcd и поменять местами
  • добавить время Etcd, чтобы жить

1 Ответ

0 голосов
/ 29 сентября 2018

Несколько причин:

  1. Возможно, Etcd работает вне сети Kubernetes, что означает, что сетевая задержка
  2. Etcd может быть занята / загружена и, следовательно, медленна
  3. В кластере etcd, скорее всего, меньше узлов, чем в мастере Kubernetes, что делает его менее надежным
...