Хабрахабр

[Перевод] Как обеспечивается высокая доступность в Kubernetes

Прим. перев.: Оригинальная статья была написана техническим писателем из Google, работающим над документацией для Kubernetes (Andrew Chen), и директором по software engineering из SAP (Dominik Tornow). Её цель — доступно и наглядно объяснить основы организации и реализации high availability в Kubernetes. Нам кажется, что у авторов получилось, поэтому мы рады поделиться переводом.

В этих публикациях мы используем подход системного моделирования с целью улучшить понимание Kubernetes и его нижележащих концепций. Kubernetes — движок оркестровки контейнеров, созданный для запуска контейнеризированных приложений на множестве узлов, которые обычно называют кластером. Читающим рекомендуется уже иметь базовое представление о Kubernetes.

Масштабируемость здесь определяется отзывчивостью в присутствии нагрузки, а надёжность — отзывчивостью в присутствии отказов. Kubernetes — масштабируемый и надёжный движок оркестровки контейнеров.

Kubernetes — масштабируемая и надёжная платформа, однако каждому приложению в K8s ещё только предстоит пройти определённые этапы для того, чтобы стать таковыми и избегать узких мест и единых точек отказа. Заметьте, что масштабируемость и надёжность Kubernetes не означает масштабируемость и надёжность приложения, запущенного в нём.

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

Она рассказывает, как Kubernetes поддерживает отзывчивость в присутствии отказов. В фокусе этой публикации — надёжность Kubernetes.

Архитектура Kubernetes


Схема 1. Мастер и worker

На концептуальном уровне компоненты Kubernetes сгруппированы в два определённых класса: компоненты мастера (Master) и компоненты воркера (Worker).

Компоненты мастера включают в себя: Мастеры отвечают за управление всем кроме исполнения подов.

Воркеры отвечают за управление исполнением подов. У них один компонент:
Воркеры тривиально надёжны: временный или постоянный отказ любого воркера в кластере не затрагивает мастера или других воркеров кластера. Если приложение развёрнуто соответствующим образом, Kubernetes (пере-)планирует и (пере-)запускает любой под, затронутый отказом воркера.

Конфигурация с единственным мастером


Схема 2. Конфигурация с единственным мастером

Последние напрямую подключаются к kube-apiserver мастера и взаимодействуют с ним. В конфигурации с единственным мастером кластер Kubernetes состоит из одного мастера и множества воркеров.

В этой конфигурации отзывчивость Kubernetes зависит от:

  • единственного мастера,
  • подключения воркеров к единственному мастеру.

Поскольку единственный мастер — единая точка отказа, такая конфигурация не относится к категории высокой доступности.

Конфигурация с множеством мастеров


Схема 3. Конфигурация с множеством мастеров

Воркеры подключаются к kube-apiserver любого мастера и взаимодействуют с ним через высокодоступный балансировщик нагрузки. В конфигурации с множеством мастеров кластер Kubernetes состоит из множества мастеров и множества воркеров.

В этой конфигурации Kubernetes не зависит от:

  • единственного мастера,
  • подключения воркеров к единственному мастеру.

Поскольку единая точка отказа в такой конфигурации отсутствует, она считается высокодоступной.

Ведущий (leader) и ведомый (follower) в Kubernetes

В конфигурации с множеством мастеров задействованы многочисленные kube-controller-manager'ы и kube-scheduler'ы. Если два компонента будут модифицировать одни и те же объекты, могут возникнуть конфликты.

Каждая группа выбирает одного ведущего (или лидера), и остальные члены группы берут роль ведомых. Дабы избежать потенциальных конфликтов, для kube-controller-manager и kube-scheduler в Kubernetes реализован паттерн «ведущий-ведомый» (leader/follower). В любой момент времени активен лишь один ведущий, а ведомые пассивны.

Избыточный Deployment компонентов мастера в деталях
Схема 4.

Поскольку каждая группа выбирает своего ведущего, они вовсе не обязательно должны находиться на одном и том же мастере. На этой иллюстрации показан подробный пример, в котором kube-controller-1 и kube-scheduler-2 являются ведущими среди kube-controller-manager'ов и kube-scheduler'ов.

Выбор ведущего

Новый ведущий выбирается членами группы в момент запуска или в случае падения ведущего. Ведущий — член, обладающий так называемым leader lease («арендованным» на данный момент статусом лидера).

Процесс выбора ведущего компонента мастера
Схема 5.

Логика этого процесса такова: Эта иллюстрация демонстрирует процесс выбора ведущего для kube-controller-manager и kube-scheduler.

'Попытка получить статус лидера' успешна тогда и только тогда, когда:
- статусом лидера сейчас никто не обладает или
- время предыдущего лидера истекло

'Попытка обновить статус лидера' успешна тогда и только тогда, когда:
- leader lease существует и
- его время не истекло и
- его holderIdentity равен 'self'

Отслеживание ведущих

Текущие статусы лидеров для kube-controller-manager и kube-scheduler постоянно хранятся в объектном хранилище Kubernetes как endpoints objects в пространстве имён kube-system. Поскольку два объекта Kubernetes не могут одновременно иметь одинаковое название, тип (kind) и пространство имён, может существовать лишь один endpoint для kube-scheduler и для kube-controller-manager.

Демонстрация с использованием консольной утилиты kubectl:

$ kubectl get endpoints -n kube-system NAME ENDPOINTS AGE
kube-scheduler <none> 30m
kube-controller-manager <none> 30m

Endpoint'ы kube-scheduler и kube-controller-manager хранят информацию о лидере в аннотации control-plane.alpha.kubernetes.io/leader:

$ kubectl describe endpoints kube-scheduler -n kube-system Name: kube-scheduler
Annotations: control-plane.alpha.kubernetes.io/leader=

Хотя Kubernetes гарантирует, что в один момент времени будет один ведущий, Kubernetes не гарантирует, что два и более компонентов мастера не будут ошибочно полагать, что являются ведущими в данный момент, — это состояние известно как split brain.

Поучительное обсуждение темы split brain и возможных способов её устранения можно найти в статье «How to do distributed locking» от Martin Kleppmann.

Вместо этого он полагается на свою возможность стремиться к желаемому состоянию в течение времени, что смягчает последствия конфликтных решений. Kubernetes не применяет никакие контрмеры по защите от split brain.

Заключение

В конфигурации с множеством мастеров Kubernetes — масштабируемый и надёжный движок оркестровки контейнеров. В этой конфигурации Kubernetes обеспечивает надёжность, используя множество мастеров и множество воркеров. Множество мастеров работает по паттерну ведущий/ведомый, а воркеры функционируют параллельно. В Kubernetes реализован свой процесс выбора ведущего, в котором информация о ведущем хранится как endpoints objects.

Информацию о том, как подготовить к работе кластер Kubernetes высокой доступности, можно получить в официальной документации.

О публикации

Этот пост — часть совместной инициативы CNCF, Google и SAP, направленной на улучшение понимания Kubernetes и его нижележащих концепций.

P.S. от переводчика

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть