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

Мы настроили кластер 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, используя следующую конфигурацию: количество узлов = 3, мастерcount = 3, zone = us-east-1c, us-east-1b, us-east-1a.Мы наблюдали, что кластер K8s был создан с 3 главными и 3 подчиненными узлами. Каждый из главного и подчиненного серверов был в каждомиз 3 AZ.

  2. Затем мы попытались изменить размеры узлов/ slave в кластере, используя (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во время настройки) были созданы подчиненные узлы, и они присоединялись к кластеру в различных AZ.Это сработало, как и ожидалось.Здесь нет вопросов.

  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 (группа экземпляров) для каждого мастера.Мы обнаружили, что были созданы новые экземпляры.Однако они не присоединились к главному кластеру.Есть ли способ достичь этого?

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

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

Ответы [ 2 ]

0 голосов
/ 21 февраля 2019

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

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

0 голосов
/ 17 декабря 2018

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

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

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

Главный узел состоит из следующих компонентов:

kube-apiserver

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

etcd

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

kube-scheduler

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

kube-controller-manager

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

cloud-controller-manager

запускает контроллеры, которые взаимодействуют с базовыми поставщиками облачных услуг.Двоичный файл контроллера облака - это альфа-функция, представленная в выпуске Kubernetes 1.6.

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

...