Как изменить размер кластера K8s с помощью kops, cluster-autoscaler для динамического увеличения мастеров

Мы настроили кластер Kubernetes на машинах EC2 в нашей учетной записи AWS с помощью инструмента kops (https://github.com/kubernetes/kops) и на основе сообщений AWS (https://aws.amazon.com/blogs/compute/kubernetes-clusters-aws-kops/), а также другие ресурсы.

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

  1. Он будет автоматически изменять размер (как главных, так и узлов / подчиненных) в зависимости от загрузки системы.
  2. Работает в режиме Multi-AZ, т. Е. По крайней мере один ведущий и один ведомый в каждой AZ (зоне доступности) в одном регионе, например, для us-east-1a, us-east-1b, us-east-1c и т. д.

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

  1. Создан кластер K8s на машинах AWS EC2, используя следующую конфигурацию kops: количество узлов = 3, количество мастеров = 3, зоны = us-east-1c, us-east-1b, us-east-1a. Мы заметили, что кластер K8s был создан с 3 ведущими и 3 ведомыми узлами. Каждый из главного и подчиненного серверов находился в каждой из 3 зон доступности.

  2. Затем мы попытались изменить размер узлов / ведомых устройств в кластере, используя (https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-run-on-master.yaml). Мы установили node_asg_min на 3 и node_asg_max на 5. Когда мы увеличили рабочую нагрузку на ведомые устройства таким образом, что сработала политика автоматического масштабирования, мы увидели, что были созданы дополнительные (после 3 по умолчанию, созданных во время установки) ведомые узлы, и они действительно присоединились к кластер в различных АЗ. Это сработало, как и ожидалось. Здесь нет вопросов.

  3. Мы также хотели настроить кластер таким образом, чтобы количество мастеров увеличивалось в зависимости от нагрузки на систему. Есть ли способ добиться этого? Мы попробовали несколько подходов, и результаты представлены ниже:

A) Мы не были уверены, поможет ли здесь автоматическое масштабирование кластера, но тем не менее попытались изменить размер мастеров в кластере, используя (https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-run-on-master.yaml). Это полезно при создании нового кластера, но бесполезно для изменения размера мастеров в существующем кластере. Мы не нашли параметр для указания node_asg_min, node_asg_max для Master так, как он присутствует для подчиненных узлов. Есть ли способ добиться этого?

B) Мы увеличили количество MIN с 1 до 3 в ASG (группа автоматического масштабирования), связанном с одним или тремя IG (группой экземпляров) для каждого мастера. Мы обнаружили, что были созданы новые экземпляры. Однако они не присоединились к главному кластеру. Есть ли способ добиться этого?

Не могли бы вы указать нам шаги и ресурсы о том, как это сделать правильно, чтобы мы могли настроить количество мастеров для автоматического изменения размера в зависимости от загрузки системы и в режиме нескольких зон доступности?

С уважением, Шаши


person shashi    schedule 17.12.2018    source источник
comment
автомасштабирование кластера помогает размещать рабочие узлы, для мастеров вам нужно создать только 3 основных по зоне доступности, я не вижу смысла размещать количество мастеров, потому что на мастере у вас есть только системные модули, ваши пользовательские приложения работать на рабочих узлах   -  person c4f4t0r    schedule 17.12.2018
comment
В настоящее время у нас есть один мастер, и мы наблюдаем высокую загрузку процессора. С другой стороны, потребление ЦП на узлах и подчиненных серверах не так велико. Производительность приложения для конечного пользователя снизилась. Следовательно, мы чувствуем, что увеличение числа Мастеров решит нашу проблему. Теперь мы не хотим настраивать новый кластер с большим количеством мастеров каждый раз, когда сталкиваемся с такой проблемой. Следовательно, мы рассматривали варианты автоматического масштабирования или динамического изменения размера кластера.   -  person shashi    schedule 21.12.2018
comment
это зависит от типа экземпляра, который вы используете для своего мастера, если только у вас нет чего-то, что делает много запросов api к вашему мастеру, у меня есть 3 мастера t2.medium, и у меня нет проблем с kubernetes 1.9 .ИКС   -  person c4f4t0r    schedule 21.12.2018


Ответы (2)


Нет необходимости масштабировать Master узел.

Главные компоненты обеспечивают плоскость управления кластером. Главные компоненты принимают глобальные решения о кластере (например, планирование), а также обнаруживают события кластера и реагируют на них (запускают новый модуль, когда поле «реплики» контроллера репликации не задано).

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

Мастер-узел состоит из следующих компонентов:

кубе-аписервер

Компонент на главном сервере, который предоставляет Kubernetes API. Это интерфейс для уровня управления Kubernetes.

etcd

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

kube-scheduler

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

kube-controller-manager

Компонент на главном компьютере, который запускает контроллеры.

облачный контроллер-диспетчер

запускает контроллеры, которые взаимодействуют с базовыми поставщиками облака. Бинарный файл cloud-controller-manager - это альфа-функция, представленная в версии 1.6 Kubernetes.

Для более подробного объяснения прочтите документы Kubernetes Components. Также, если вы думаете о высокой доступности, вы можете прочитать о Создание высокодоступных кластеров с помощью kubeadm < / а>

person Crou    schedule 17.12.2018
comment
В настоящее время у нас есть один мастер, и мы наблюдаем высокую загрузку процессора. С другой стороны, потребление ЦП на узлах и подчиненных серверах не так велико. Производительность приложения для конечного пользователя снизилась. Следовательно, мы чувствуем, что увеличение числа Мастеров решит нашу проблему. Теперь мы не хотим настраивать новый кластер с большим количеством мастеров каждый раз, когда сталкиваемся с такой проблемой. Следовательно, мы рассматривали варианты автоматического масштабирования или динамического изменения размера кластера. - person shashi; 21.12.2018
comment
Вы можете установить, например, Prometheus и посмотреть, что вызывает такую ​​высокую загрузку ЦП. - person Crou; 21.12.2018

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

Преимущество добавления мастеров состоит в том, что они способны выдержать большее количество отказов мастера за счет того, что им придется сделать все мастера толще (больше ЦП / ОЗУ ...), чтобы они работали достаточно хорошо.

person herm    schedule 21.02.2019