Что происходит во время сбоя плоскости управления Kubernetes?

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

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

Понимание плоскости управления

Плоскость управления Kubernetes отвечает за глобальные операции вашего кластера. Он координирует действия, влияющие на ваши рабочие узлы. Плоскость управления также предоставляет хранилище данных etcd для кластера, а также сервер API, с которым вы взаимодействуете, используя такие инструменты, как Kubectl.

Вот некоторые из основных обязанностей плоскости управления:

На
• kube-apiserver размещен сервер API Kubernetes.
• kube-controller-manager запускает и запускает контроллеры в вашем кластере, позволяя обнаруживать и применять изменения состояния, запрашиваемые сервером API.
• kube-scheduler назначает поды рабочим узлам, определяя, какой узел лучше всего оснащен для поддержки каждого нового пода.
• etcd – это хранилище данных типа ключ-значение, в котором хранятся все данные кластера Kubernetes и информация о состоянии.

Архитектура Kubernetes полагается на постоянную доступность этих компонентов. Они работают вместе, чтобы создать нормальное рабочее состояние, в котором все работает гладко, а ваш кластер соответствует ожиданиям.

Что происходит при отказе плоскости управления?

Плоскость управления не застрахована от сбоев. Большое количество задействованных компонентов означает, что отдельные части могут перестать работать и вызвать эффект домино в вашем кластере. Может произойти сбой компонента или аппаратный сбой физического хоста, на котором запущена плоскость управления.

Фактические последствия для вашего кластера будут различаться в зависимости от компонента с проблемой. Однако сбой уровня управления обычно не позволяет вам администрировать кластер и может помешать существующим рабочим нагрузкам реагировать на новые события:

• Если сервер API выйдет из строя, Kubectl, панель инструментов Kubernetes и другие инструменты управления перестанут работать.
• В случае сбоя планировщика новые модули не будут распределяться по узлам, поэтому они будут недоступны и будут отображаться как застрявшие в состоянии ожидания. Это также повлияет на поды, которые необходимо перепланировать из-за того, что у узла закончились ресурсы или был отправлен запрос на масштабирование.
• В случае сбоя диспетчера контроллера изменения, которые вы применяете к своему кластеру, не будут приняты, поэтому ваши рабочие нагрузки сохранят свое прежнее состояние.

Сбои плоскости управления не позволяют эффективно изменять состояние кластера. Изменения либо вообще не пройдут, либо не повлияют на кластер.

Как насчет рабочих узлов и работающих модулей?

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

Это означает, что сбои в плоскости управления не обязательно выведут из строя рабочие нагрузки, которые уже находятся в работоспособном состоянии. Часто вы можете продолжать получать доступ к существующим подам, даже если не можете подключиться к своему кластеру с помощью Kubectl. Пользователи не обязательно заметят кратковременный сбой плоскости управления.

Более длительные периоды простоя увеличивают вероятность того, что рабочие узлы также начнут сталкиваться с проблемами. Узлы не смогут согласовать свое состояние, поэтому могут возникнуть несоответствия. Сеть также может начать разрушаться, если DNS не работает, а содержимое кэшированных запросов истекает.

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

Предотвращение отказа уровня управления

Вы можете защититься от сбоя уровня управления, настроив высокодоступный кластер, который реплицирует функции уровня управления на нескольких машинах. Точно так же, как вы используете Kubernetes для распространения и масштабирования собственных контейнеров, вы можете применить высокую доступность (HA) к самому Kubernetes для повышения отказоустойчивости.

Kubernetes предлагает два механизма для настройки реализации уровня управления высокой доступностью:

1. Использование «стековых» узлов плоскости управления. Этот подход требует меньше инфраструктуры и работает как минимум с тремя машинами. Каждая машина будет запускать свою собственную плоскость управления, которая копирует данные с других. Один хост возьмет на себя ответственность за кластер, будучи назначенным лидером. Если лидер отключится, другие узлы заметят его отсутствие и будет выбран новый лидер. В идеале вам нужно нечетное количество хостов, например 3, 5 или 7, чтобы оптимизировать процесс выборов.
2. Использование внешнего хранилища данных etcd. Этот подход похож на многоуровневую модель, но с одним ключевым отличием. Он зависит от внешнего экземпляра etcd, который будет совместно использоваться вашими узлами уровня управления. Это позволяет избежать напрасной репликации данных. Вам следует вручную настроить репликацию кластера etcd, чтобы он не стал отдельной точкой отказа.

Kubernetes теперь имеет хорошую поддержку кластеров с несколькими плоскостями управления. Если вы администрируете свой собственный кластер, вы можете добавить еще один узел плоскости управления, просто включив флаг --control-plane при выполнении команды kubeadm join:

$ kubeadm join <cluster-control-plane-leader-ip>:6443 \
    --token <cluster-join-token>
    --discovery-token-ca-cert-hash sha256:<cluster-discovery-token-ca-cert-hash> \ 
    --certificate-key <cluster-certificate-key> \
    --control-plane

Краткое содержание

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

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

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