Сколько должно быть мастеров в Kubernetes

1️⃣ Как кратко ответить

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

2️⃣ Подробное объяснение темы

В Kubernetes мастер-узлы (или control plane) отвечают за управление кластером. Они выполняют такие задачи, как планирование подов, управление состоянием кластера, поддержание конфигурации и контроль за жизненным циклом приложений. Важно обеспечить их высокую доступность, чтобы кластер оставался работоспособным даже при сбоях.

Зачем нужно несколько мастеров

1. Отказоустойчивость: Если один мастер-узел выходит из строя, другие могут продолжать управлять кластером.
2. Высокая доступность: Наличие нескольких мастеров позволяет распределить нагрузку и избежать единой точки отказа.
3. Кворум: Для принятия решений в распределенной системе требуется кворум — большинство узлов должны согласиться с изменением. Нечетное количество узлов помогает избежать тупиковых ситуаций.

Почему нечетное количество

Использование нечетного количества мастеров (например, 3 или 5) позволяет системе достичь кворума при сбое одного или нескольких узлов. Например, в кластере из 3 мастеров кворум достигается при наличии 2 работающих узлов. Если бы мастеров было 2, то при сбое одного из них кворум был бы потерян, и кластер не смог бы принимать решения.

Пример конфигурации

Рассмотрим пример конфигурации кластера с 3 мастерами:

• Мастер 1: Управляет частью задач, таких как планирование подов.
• Мастер 2: Дублирует функции мастера 1 и может взять на себя его задачи в случае сбоя.
• Мастер 3: Также дублирует функции и участвует в принятии решений.

Как это работает

1. Этcd: Это распределенное хранилище данных, используемое Kubernetes для хранения всей информации о кластере. Оно требует кворума для работы. В кластере из 3 мастеров этcd будет работать, если доступны хотя бы 2 узла.

2. Компоненты мастера: Каждый мастер-узел содержит компоненты, такие как kube-apiserver, kube-controller-manager и kube-scheduler. Эти компоненты работают в активном/резервном режиме, где один узел может взять на себя задачи другого в случае сбоя.

Пример кода

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver:v1.20.0
    command:
    - kube-apiserver
    - --etcd-servers=http://etcd-0:2379,http://etcd-1:2379,http://etcd-2:2379

• apiVersion и kind: Определяют тип ресурса Kubernetes, в данном случае это Pod.
• metadata: Содержит метаданные, такие как имя пода и пространство имен.
• spec: Определяет спецификацию пода, включая контейнеры.
• containers: Список контейнеров, которые будут запущены в поде.
• name: Имя контейнера.
• image: Образ контейнера, который будет использоваться.
• command: Команда, которая будет выполнена при запуске контейнера.
• --etcd-servers: Параметр, указывающий на адреса серверов etcd, которые используются для хранения данных кластера.

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