Автоматическое масштабирование Kubernetes с использованием режима отключения VPA или автоматического обновления?

# #kubernetes #google-kubernetes-engine #cluster-computing #recommendation-engine

Вопрос:

Для нужд проекта я создал 2 кластера Kubernetes на GKE.

Кластер 1: 10 контейнеров в одном контейнере

Кластер 2: 10 контейнеров в 10 разных контейнерах

Все контейнеры соединены и представляют собой приложение.

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

До сих пор, используя режим «Авто«, я заметил, что VPA меняет значения только один раз, в начале, а не во время создания нагрузки, и что верхняя граница очень высока, поэтому она не нуждается в каких-либо изменениях!

Не могли бы вы предложить мне:

1) использовать автоматический или рекомендательный режим?

и

2) создать 1 или 2 копии моего приложения?

Также я хотел бы сказать, что 2 из 10 контейнеров-это mysql и MongoDB . Итак, если мне нужно создать 2 реплики, я должен использовать наборы состояний или операторы, верно?

Большое спасибо!!

Ответ №1:

Не уверен, что ты это имеешь в виду, когда говоришь это

Кластер 1: 10 контейнеров в одном модуле

Кластер 2: 10 контейнеров в разных контейнерах

Поначалу вы не следуете рекомендациям, в идеале вы должны хранить один контейнер в одном модуле

Запуск 10 контейнеров в одном модуле-это слишком много, если есть взаимозависимость, ваш код должен использовать имя службы K8s для подключения друг к другу.

чтобы создать 1 или 2 копии моего приложения?

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

Также я хотел бы сказать, что 2 из 10 контейнеров-это mysql и MongoDB . Итак, если мне нужно создать 2 реплики, я должен использовать наборы состояний или операторы, верно?

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

Реализация репликации MySQL между репликами будет затруднена вручную, если у вас нет хорошего опыта в качестве администратора базы данных и вы не осведомлены.

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

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

Комментарии:

1. Спасибо вам за ваш ответ!! Я знаю, что это не лучшая практика, но это просто для проверки этого случая, и да, все контейнеры связаны со службами. Вы бы предложили мне использовать режим обновления «Авто» или «Рекомендация»?

2. в идеале вы должны использовать HPA для увеличения внезапного трафика при создании нагрузки. VPA предназначен для стабильной настройки, когда ваш кластер сокращается, а у вас избыточная память и все такое. Для запуска идеальной конфигурации VPA и HPA вам также понадобится несколько реплик в любом случае.

3. вы можете установить режим в зависимости от ваших требований, как вы хотите на самом деле работать. вы также должны прочитать ограничение в самом начале : cloud.google.com/kubernetes-engine/docs/concepts/…

4. хм, я понимаю!! Следующий шаг-использовать HPA и тоже проверить его.. Но сначала я должен протестировать VPA.. Возможно, в результате это не подходит для этой работы.. Так или иначе, верхняя граница настолько высока, что нет необходимости увеличивать мой модуль более одного раза.. Большое спасибо!!