Как происходит сбой кластера Kubernetes HA в сценариях с разделением функций между стойками?

Меня интересует поведение Kubernetes с несколькими мастерами в случае сбоев разных типов, особенно если мастера находятся на разных стойках.

  • Сценарий:

    • 2 стойки, R1, R2.

    • Мастера API:

      • M1 on R1, M2 on R2.

    • Рабочие узлы:

      • W1 on R1, W2 on R2.

    • И т. Д.:

      • A completely separate HA Etcd cluster comprising 3 nodes (i.e. it's not running on the API Master nodes).

Мои вопросы о неудачах в основном связаны со сценариями расщепления мозга:

Что произойдет, если M1 является активным мастером и R1 теряет соединение с Etcd и R2, но R2 / M2 имеет подключение к Etcd? то есть что конкретно вызывает выборы руководства?

Если на R1 / W1 есть Pod P1, M1 является активным мастером, а R1 отключается от R2 и Etcd, что происходит? P1 продолжает работать или его убили? Запускает ли M2 отдельный экземпляр P (P2) на R2? Если да, могут ли P1 и P2 работать одновременно?

Если на R2 / W2 есть Pod P2 и M1 является активным мастером (т.е. модуль находится на отдельной стойке от мастера) и R1 теряет соединение с R2 и Etcd, что происходит с P2? Продолжается ли он, и М2 берет верх?


kubernetes openshift etcd splitbrain
person John    schedule 06.11.2017    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Хозяин арендует etcd. Если срок аренды истекает, активный мастер завершает процесс (ожидает перезапуска). Другой мастер будет наблюдать за истечением срока аренды и пытаться получить ее в etcd. Пока M2 может подключиться к etcd и у etcd есть кворум, второй мастер будет управлять им.

Что касается конкурирующих мастеров, в целом Kubernetes по-прежнему использует etcd для выполнения согласованных обновлений - то есть даже два мастера, активные одновременно, все еще борются за то, чтобы сделать то же самое с etcd, который имеет сильную согласованность, и поэтому обычный результат просто неудачен. обновления. Одним из примеров, когда это не так, являются наборы демонов и ReplicaSets - два активных мастера могут создавать несколько модулей, а затем уменьшать их, когда они понимают, что их слишком много на узел или сравнивают с желаемым масштабом. Но поскольку ни наборы демонов, ни наборы ReplicaSets в любом случае не гарантируют такого поведения (ReplicaSets могут иметь> модули масштабирования, работающие в любое время, демонсеты могут иметь два модуля на узел на короткое время), оно не нарушается само по себе.

Если вам нужно поведение не более X модулей, сегодня эту гарантию предоставляют только StatefulSets.

person Clayton    schedule 07.11.2017