Мы настроили кластер Kubernetes на машинах EC2 в нашей учетной записи AWS с помощью инструмента kops (https://github.com/kubernetes/kops) и на основе сообщений AWS (https://aws.amazon.com/blogs/compute/kubernetes-clusters-aws-kops/), а также других ресурсов.
Мы хотим настроить кластер мастера и подчиненных устройств K8s таким образом, чтобы:
Мы пытались настроить кластер следующими способами, чтобы добиться вышеизложенного.
Создан кластер K8s на машинах AWS EC2, используя следующую конфигурацию kops: количество узлов = 3, количество мастеров = 3, зоны = us-east-1c, us-east-1b, us-east-1a. Мы заметили, что кластер K8s был создан с 3 ведущими и 3 ведомыми узлами. Каждый из главного и подчиненного серверов находился в каждой из 3 зон доступности.
Затем мы попытались изменить размер узлов / ведомых устройств в кластере, используя (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 по умолчанию, созданных во время установки) ведомые узлы, и они действительно присоединились к кластер в различных АЗ. Это сработало, как и ожидалось. Здесь нет вопросов.
Мы также хотели настроить кластер таким образом, чтобы количество мастеров увеличивалось в зависимости от нагрузки на систему. Есть ли способ добиться этого? Мы попробовали несколько подходов, и результаты представлены ниже:
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 (группой экземпляров) для каждого мастера. Мы обнаружили, что были созданы новые экземпляры. Однако они не присоединились к главному кластеру. Есть ли способ добиться этого?
Не могли бы вы указать нам шаги и ресурсы о том, как это сделать правильно, чтобы мы могли настроить количество мастеров для автоматического изменения размера в зависимости от загрузки системы и в режиме Multi-AZ?
С уважением, Шаши
В настоящее время у нас есть один мастер, и мы наблюдаем высокую загрузку ЦП. С другой стороны, потребление ЦП на узлах / подчиненных серверах не так велико. Производительность приложения для конечного пользователя снизилась. Следовательно, мы чувствуем, что увеличение числа Мастеров решит нашу проблему. Теперь мы не хотим настраивать новый кластер с большим количеством мастеров каждый раз, когда сталкиваемся с такой проблемой. Следовательно, мы рассматривали варианты автоматического масштабирования или динамического изменения размера кластера.
это зависит от типа экземпляра, который вы используете для своего мастера, если только у вас нет чего-то, что делает много запросов api к вашему мастеру, у меня есть 3 мастера t2.medium, и у меня нет проблем с kubernetes 1.9 .ИКС





Нет необходимости масштабировать узлы Master.
Master components provide the cluster’s control plane. Master components make global decisions about the cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller’s ‘replicas’ field is unsatisfied).
Master components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all master components on the same machine, and do not run user containers on this machine. See Building High-Availability Clusters for an example multi-master-VM setup.
кубе-аписервер
Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane.
etcd
Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.
кубе-планировщик
Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.
Кубе-контроллер-менеджер
Component on the master that runs controllers.
облачный диспетчер-диспетчер
runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
Для более подробного объяснения, пожалуйста, прочтите документацию Компоненты Kubernetes. Также, если Вы думаете о HA, можете прочитать о Создание высокодоступных кластеров с помощью kubeadm
В настоящее время у нас есть один мастер, и мы наблюдаем высокую загрузку ЦП. С другой стороны, потребление ЦП на узлах / подчиненных серверах не так велико. Производительность приложения для конечного пользователя снизилась. Следовательно, мы чувствуем, что увеличение числа Мастеров решит нашу проблему. Теперь мы не хотим настраивать новый кластер с большим количеством мастеров каждый раз, когда сталкиваемся с такой проблемой. Следовательно, мы рассматривали варианты автоматического масштабирования или динамического изменения размера кластера.
Вы можете установить, например, Prometheus и посмотреть, что вызывает такую высокую загрузку ЦП.
Я думаю, вы предполагаете, что, как и в случае с узлами Kubernetes, мастера распределяют работу между собой. Это не так, ведь основная задача мастеров - достичь консенсуса между собой. Это делается с помощью etcd, который представляет собой распределенное хранилище значений ключей. Проблема с поддержанием такого хранилища легка для 1 машины, но становится все труднее, чем больше машин вы добавляете.
Преимущество добавления мастеров состоит в том, что они способны выдержать большее количество отказов мастера за счет того, что им придется сделать все мастера толще (больше ЦП / ОЗУ ...), чтобы они работали достаточно хорошо.
автоматическое масштабирование кластера помогает размещать рабочие узлы, для мастеров вам нужно создать только 3 основных по зоне доступности, я не вижу смысла размещать количество мастеров, потому что на мастере у вас есть только системные модули, ваши пользовательские приложения работать на рабочих узлах