Replica set что это
Виды репликации в MongoDB
Привет, хабровчане! Расшифровали для вас часть урока по MongoDB от Евгения Аристова, разработчика с 20-летним стажем и автора онлайн-курса «Нереляционные базы данных». Материал, как и сам курс, будет полезен специалистам, сталкивающимся в работе с NoSQL, желающим научиться оптимизировать свои базы данных и работу с ними.
Зачем нужна репликация?
№1. Запись и чтение с основного сервера
У нас есть драйвер клиентского приложения, который читает и пишет на Primary-ноду. Дальше по протоколу репликации информация, которая записывается на Primary-ноду, отправляется на Secondary-ноды.
№2. Чтение с реплики
Альтернативой чтению и записи с Primary является вариант, когда драйвер может читать информацию с Secondary. При этом настройки могут быть разными, например, «читать информацию предпочтительнее с Secondary, а потом с Primary» или «читать информацию с ближайшего по карте сети нода» и т.д. Такие варианты настроек используются чаще, чем первый вариант репликации, где все идет через Primary.
3 способа сделать реплику доступной для чтения:
Проблемы чтения с реплики
Настроен процесс репликации может быть двумя способами
А) Ноды «слушают» друг друга, эта связь называется Heartbeat. То есть каждая нода постоянно проверяется другими на предмет «живая/ неживая», для того, чтобы предпринимать какие-то действия, если что-то случилось.
Б) Одна Secondary-нода меняется на Arbiter. Это очень легковесное приложение, запускается как Mongo, практически не ест ресурсов и отвечает за то, что определяет, какую ноду в момент голосования признать главной. И это в целом рекомендуемая конфигурация.
Основные особенности этой конфигурации
Изучение возможностей MongoDB входит в программу онлайн-курса «Нереляционные базы данных». Курс предназначен для разработчиков, администраторов и других специалистов, которые сталкиваются в работе с NoSQL. На занятиях студенты на практике осваивают наиболее актуальные сегодня инструменты: Cassandra, MongoDB, Redis, ClickHouse, Tarantool, Kafka, Neo4j, RabbitMQ.
Старт уже 30 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь!
Kubernetes блог
Контроллеры в Kubernetes: ReplicaSet
Как работает ReplicaSet
ReplicaSet задается полями, включая селектор (selector), который указывает, как идентифицировать Pod’ы, которые он может приобрести, количество реплик (replicas), указывающих, сколько Pod’ов он должен поддерживать, и шаблон (template) Pod’ов, указывающий данные новых Pod’ов, которые он должен создать для соответствия критерию количества реплик. Затем ReplicaSet выполняет свое предназначение, создавая и удаляя Pod’ы по мере необходимости для достижения желаемого числа. Когда ReplicaSet нуждается в создании новых Pod’ов, он использует свой шаблон Pod’ов для их создания.
Ссылка, которую ReplicaSet имеет на свои Pod’ы, осуществляется через поле metadata.ownerReferences Pod’ов, которое указывает, какому ресурсу принадлежит текущий объект. Все Pod’ы, приобретенные ReplicaSet, имеют свою идентификационную информацию ReplicaSet в своем поле ownerReferences. Именно по этой ссылке ReplicaSet знает о состоянии Pod’ов, которые он поддерживает, и планирует соответственно.
ReplicaSet идентифицирует новые Pod’ы для приобретения с помощью своего селектора. Если есть Pod, у которого нет OwnerReference или OwnerReference не является контроллером, и он соответствует селектору ReplicaSet, он будет немедленно получен указанным ReplicaSet.
Когда использовать ReplicaSet
Фактически это означает, что вам, возможно, никогда не понадобится манипулировать объектами ReplicaSet: вместо этого используйте Deployment и определите свое приложение в разделе спецификаций.
Пример ReplicaSet
Сохранение этого манифеста в frontend.yaml и отправка его в кластер Kubernetes создаст определенный ReplicaSet и Pod’ы, которыми он управляет.
Затем вы можете развернуть текущий ReplicaSets:
И увидите frontend, который вы создали:
Вы также можете проверить состояние репликации:
И вы увидите вывод, похожий на:
И, наконец, вы можете проверить, какие Pod’ы были выведены:
Вы должны увидеть информацию, похожую на:
Вы также можете убедиться, что для владельца в этих Pod’ах задан frontend ReplicaSet. Для этого получите yaml одного из Pod’ов:
Вывод будет выглядеть примерно так: информация frontend ReplicaSet установлена в поле ownerReferences в metadata:
Приобретение не шаблонного Pod’а контроллером
Возьмем предыдущий пример frontend ReplicaSet и Pod’ы, указанные в следующем манифесте pods/pod-rs.yaml:
Поскольку эти Pod’ы не имеют контроллера (или какого-либо объекта) в качестве ссылки на своего владельца и соответствуют селектору frontend ReplicaSet, они сразу же будут им получены.
Предположим, что вы создали Pod’ы после того, как frontend ReplicaSet был развернут и настроил свои начальные реплики Pod’ов для выполнения требований к количеству реплик:
Новые Pod’ы будут получены ReplicaSet, а затем немедленно завершены (terminated), так как ReplicaSet превысит желаемое количество реплик.
Вывод показывает, что новые Pod’ы либо уже завершены, либо находятся в процессе завершения:
Если вы сначала создаете Pod’ы:
А затем создайте ReplicaSet:
Вы увидите, что ReplicaSet получил Pod’ы и создал новые только в соответствии со своей спецификацией до тех пор, пока количество новых Pod’ов и оригинал не совпадут с желаемым количеством. Запрос Pod’ов:
Покажет в своем выводе:
Таким образом, ReplicaSet может владеть неоднородным набором Pod’ов.
Написание манифеста ReplicaSet
Как и для всех других объектов API Kubernetes, для ReplicaSet нужны поля apiVersion, kind и metadata. Для ReplicaSets, kind всегда просто ReplicaSet. В Kubernetes 1.9 версия API apps/v1 типа ReplicaSet является текущей версией и включена по умолчанию. Версия API apps/v1beta2 устарела.
ReplicaSet также нуждается в разделе .spec.
Pod шаблон (Pod Template)
Pod Selector
Replicas (Реплики)
Работа с ReplicaSets
Удаление ReplicaSet и его Pod’ов
Чтобы удалить ReplicaSet и все его Pod’ы, используйте kubectl delete. Сборщик мусора автоматически удаляет все зависимые Pod’ы по умолчанию.
Удаление только ReplicaSet
Изоляция Pod’ов из ReplicaSet
Вы можете удалить Pod’ы из ReplicaSet, изменив их метки. Этот метод может использоваться для удаления Pod’ов из службы для отладки, восстановления данных и т.д. Pod’ы, которые удалены таким образом, будут заменены автоматически (при условии, что количество реплик также не изменилось).
Масштабирование ReplicaSet
ReplicaSet как Horizontal Pod Autoscaler Target (цель для автоматического горизонтального сервиса масштабирования Pod’ов)
ReplicaSet также может быть целью для Horizontal Pod Autoscaler (сервиса автоматического горизонтального масштабирования Pod’ов) (HPA). То есть ReplicaSet может быть автоматически масштабирован HPA. Вот пример HPA, нацеленный на ReplicaSet, который мы создали в предыдущем примере. controllers/hpa-rs.yaml
Сохранение этого манифеста в hpa-rs.yaml и отправка его в кластер Kubernetes должны создать определенный HPA, который автоматически масштабирует целевой ReplicaSet в зависимости от использования CPU реплицированными Pod’ов.
В качестве альтернативы, вы можете использовать команду kubectl autoscale, чтобы сделать то же самое (и это проще!)
Альтернативы ReplicaSet
Deployment (Развертывание) (рекомендуется)
Голые Pod’ы
В отличие от случая, когда пользователь непосредственно создал Pod, ReplicaSet заменяет Pod’ы, которые были удалены или прерваны по любой причине, например, в случае сбоя узла или прерывистого обслуживания узла, такого как обновление ядра. По этой причине рекомендуется использовать ReplicaSet, даже если вашему приложению требуется только один Pod. Думайте об этом подобно руководителю процессов (process supervisor), только он контролирует несколько Pod’ов в нескольких узлах, а не отдельные процессы в одном узле. ReplicaSet делегирует перезапуск локального контейнера некоторому агенту на узле (например, Kubelet или Docker).
Используйте Job вместо ReplicaSet для Pod’ов, которые должны завершаться самостоятельно (например, пакетные задания).
DaemonSet
Используйте DaemonSet вместо ReplicaSet для Pod’ов, которые обеспечивают функцию уровня машины, такую как мониторинг машины или ведение журнала машины. Срок службы этих Pod’ов зависит от срока службы машины: Pod должен быть запущен на машине до запуска других Pod’ов, и его можно безопасно завершить, когда машина готова к перезагрузке/выключению.
ReplicationController
ReplicaSets являются преемниками ReplicationControllers. Они служат одной и той же цели и ведут себя одинаково, за исключением того, что ReplicationController не поддерживает требования селектора на основе набора. Таким образом, ReplicaSets предпочтительнее, чем ReplicationControllers.
Установка и настройка MongoDB на Debian, а также ReplicaSet и пара других мелочей
Это руководство описывает пошаговую установку и настройку реплики из 3 узлов mongoDB на базе движка WiredTiger. А также несколько полезных мелочей для людей, впервые столкнувшихся с MongoDB.
Важное уточнение:
Немного о движке WiredTiger
Engine WiredTiger — новый движок mongoDB, использующийся по умолчанию вместо MMAP, начиная с версии 3.4. Хорош тем, что работает с данными на уровне коллекций и отдельных документов, а не полностью базой. Также устраняет проблему Global lock по вышеуказанной причине, из-за чего и был выбран в продакшен.
Установка OS и компонентов
Ставим Debian любой удобной вам версии, у меня использовался 8.6.0.
Для упрощения масштабирования узлов и баз данных, рекомендую использовать lvm.
Из компонентов понадобится только ssh для более удобного доступа к серверу.
Установка MongoDB.
У меня используется бесплатная Community Edition, руководство будет на её основе.
По необходимости допишу Enterpise версию, т.к. она тоже крутилась и разбиралась.
Данное руководство описывается для варианта 3-х серверов (master, slave, arbiter).
Копируем репозиторий и сохраняем изменения.
Обновляем список доступных пакетов
Повторяем процедуру для 3(трех) серверов,
На этом первоначальная настройка завершена.
Теперь переходим к настройке mongoDB.
Настройка и добавление серверов в Replica Set
В начале было слово
Давайте для начала разберемся, что такое replica set.
Replica Set — это кластер серверов MongoDB, реализующий механизм репликации master-slave и автоматическое переключение между ними. Это рекомендуемый механизм репликации от разработчиков MongoDB. ссылка на офф. документацию.
Мы используем механизм репликации, приведенный на картинке:
мастер, два вторичных и арбитр.
Primary — основной сервер mongoDB.
Secondary — точные копии баз(ы) данных с real-time синхронизацией.
Arbiter — сервер выбора вторичной реплики с высшим приоритетом, которая станет главной в случае падения сервера.
ОЧЕНЬ ВАЖНО:
Arbiter отвечает только за выборы преемника, сам стать преемником он не может, поэтому рекомендуется отдавать под арбитра минимальные ресурсы.
ЕЩЁ БОЛЕЕ ВАЖНО:
Технически можно вообще жить без арбитра, однако с ним выборы будут происходить в разы быстрее, соответственно время простоя будет минимизировано. Плюс есть ненулевая вероятность потерять ReplicaSet целиком.
Primary
Настройки пишем в файл /etc/mongod.conf У меня файл выглядит следующим образом:
Указываемые значения переменных:
dbPath — путь к базе данных. При указании на пустое место, создаст там базы. При разворачивании бэкапа подцепит существующую.
journal — включает журналирование.
replSetName — название реплики. Должно быть идентичным у всех узлов внутри реплики.
bindIp — список адресов, с которых можно принимать соединения по порту 27017.
Далее для конфигурирования я использовал саму mongoDB:
попадаем внутрь и первым делом проверяем статус:
Начальный статус должен быть 0 — startup. Означает что узел не является членом ни одной реплики.
Инициализируем реплику.
Выполняем в MongoShell на первичном узле
Сразу после добавления в реплику узел будет в статусе 5 — Startup2, это означает что он присоединился к реплике и в данный момент синхронизируется. Может занять продолжительное время.
Добавляем следующие узлы:
Статусы в rs.status() будут:
1 — Primary
2 — Secondary
7 — Arbiter
Приоритеты
Первый:
Необходимо проставить приоритеты (цифры member id берем из статуса):
Чем выше цифра приоритета, тем ниже сам приоритет при выборе Primary узла.
Второй:
Добавляем узлы с заранее прописанным приоритетом:
Проверяем что все узлы доступны и выставлены с правильными приоритетами:
В моем случае конфиги и статусы приобрели следующий вид:
При добавлении узла в уже существующую реплику она какое-то время будет недоступна в связи с синхронизацией.
На этом установка и настройка MongoDB в режиме ReplicaSet завершена и можно с чистой совестью наполнять базу данными.
Другие полезные команды
Сбрасывание PRIMARY. Смена первичного узла и переназначение приоритетов
60 секунд — время, в течение которого сервер, с которого запущено выполнение команды, не может стать Primary; 40 секунд — время перевыборов нового Primary.
30 секунд — время отключения Primary и перевыборы. Выполнение команды допустимо с любого из серверов mongoDB.
Узел, с которого запущена команда, в течение 60 секунд не сможет стать Primary.
/var/lib/mongodb/ — Тут лежат файлы баз.
Восстановление из дампа:
Восстанавление базы в каталог по умолчанию. Если файл в с таким именем есть, то он перезаписывается:
Восстановление всех баз из указанного каталога:
Восстановление отдельной таблицы(коллекции):
Создание дампа
создание бэкапа всех баз в папку Backup:
создание бэкапа отдельной базы:
создание бэкапа отдельной таблицы:
Запуск от имени root, создание бэкапа указанной базы в указанный каталог + текущая дата:
Учимся разворачивать микросервисы. Часть 2. Kubernetes
Это вторая часть из серии статей «Учимся разворачивать микросервисы». В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Ключевые слова: Helm 3, chart deployment
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Что конкретно мы попытаемся добиться с помощью Kubernetes:
Kubernetes — сложный механизм, призванный сделать нашу систему масштабируемой, отказоустойчивой и простой в развертывании. Он включает в себя множество настроек и возможностей. В статье основной акцент будет сделан на создании Kubernetes-конфигурации для конкретного учебного проекта.
Код проекта доступен на GitHub по ссылке.
Среда Kubernetes
Minikube — это удобный инструмент для экспериментов с Kubernetes на локальной машине. Изначально мы создадим конфигурацию для работы именно в этой среде. Далее мы поговорим, какие корректировки нужно внести, чтобы задеплоить систему в GKE. Google Cloud Platform был выбран из-за бесплатных 300$ на эксперименты в первый год. Для приведенной в статье конфигурации стоит использовать кластер из 2+ стандартных машин (n1-standard-1).
Ссылки по настройке среды:
Объекты Kubernetes
При работе с Kubernetes инженер описывает желаемое состояние системы через определение объектов и связей между ними. А конкретные действия для достижения нужного состояния оркестратор волен выбирать сам. То есть можно сказать, что настройка носит декларативный характер.
Рассмотрим некоторые объекты Kubernetes:
Namespace — пространство имен. Объекты могут взаимодействовать, только если находятся в одном неймспейсе. С помощью неймспейсов возможно развернуть несколько виртуальных кластеров на одном физическом.
Pod — минимальный юнит развертывания. В большинстве случаев включает в себя один контейнер. Множество настроек пода делегируются непосредственно контейнеру докера, например, управление ресурсами, политики рестартов, управление портами.
ReplicaSet — контроллер, позволяющий создать набор одинаковых подов и работать с ними, как с единой сущностью. Поддерживает нужное количество реплик, при необходимости создавая новые поды или убивая старые. На самом деле в большинстве случаев вы не будете работать с ReplicaSet напрямую — для этого есть Deployment.
Deployment — контроллер развертывания, являющийся абстракцией более высокого уровня над ReplicaSet’ом. Добавляет возможность обновления управляемых подов.
Service — отвечает за сетевое взаимодействие группы подов. В системе обычно существует несколько экземляров одного микросервиса, соответственно каждый из них имеет свой IP-адрес. Количество подов может изменяться, следовательно набор адресов также не постоянен. Другим частям системы для доступа к рассматриваемым подам нужен какой-то статичный адрес, который Service и предоставляет.
Во избежание путаницы здесь и в дальнейшем под словом «сервис» я буду подразумевать именно объект Kubernetes, а не экземпляр приложения.
Существует несколько видов сервисов. Перечисленные ниже типы для простоты понимания можно рассматривать, как матрешку. Каждый последующий оборачивает предыдущий и добавляет некоторые правила маршрутизации. Создавая сервис более высокого уровня, автоматически создаются сервисы нижележащего типа. Типы сервисов:
Также Kubernetes из коробки предоставляет поддержку DNS внутри кластера, позволяя обращаться к сервису по его имени. Более подробно про сервисы можно почитать тут.
ConfigMap — объект с произвольными конфигурациями, которые могут, например, быть переданы в контейнеры через переменные среды.
Secret — объект с некой конфиденциальной информацией. Секреты могут быть файлами (№ SSL-сертификатами), которые монтируются к контейнеру, либо же base64-закодированными строками, передающимися через те же переменные среды. В статье будут рассмотрены только строковые секреты.
HorizontalPodAutoscaler — объект, предназначенный для автоматического изменения количества подов в зависимости от их загруженности.
Minikube configuration
Namespace:
Установим его как текущий:
Далее все объекты будут создаваться в неймспейсе ‘msvc-ns’. Если этот шаг пропустить, то будет использоваться неймспейс ‘default’.
Обычно конфигурация для Kubernetes представляет собой обычный yaml-файл с описанием объектов, но также есть возможность создавать эти объекты и через CLI. В дальнейшем все объекты будут описываться в yaml-формате.
ConfigMap
Объект, предоставляющий свойства для подов. В нашем случае шлюзу для связи с подами бекенда необходимо знать URL-адрес их сервиса. Наш ConfigMap будет содержать адреса внутренних сервисов нашего кластера, и его можно будет заинжектить во все заинтересованные микросервисы (в нашей системе это только шлюз).
Как я говорил ранее, в кластере Kubernetes сервисы доступны по их именам. Как мы увидим далее, сервис бекенда будет иметь имя ‘backend’ и использовать 8080 порт.
Secret
Тип Opaque подразумевает, то что секрет задается парами ключ-значение. Для особых секретов, например, паролей реестров Docker-образов, существуют отдельные типы. В данном конфиге мы указываем пароль в открытом виде в блоке stringData. Так как секреты хранятся в кодировке base64, то наши данные будут закодированы автоматически. Секрет можно указать в уже закодированном виде:
Deployments
У нас будет два деплоймента — для бекенда и шлюза.
metadata.labels
Эти поля служат для настройки связей между объектами, а также для их уникальной идентификации. В нашем случае мы отмечаем, что наш деплоймент принадлежит приложению с названием ‘microservices’ и слою ‘gateway’.
Дополнительно хочется отметить похожий по смыслу блок metadata.annotations — он используются исключительно для предоставления метаинформации, которая может быть интроспектирована внешними инструментами.
spec.replicas
В этом поле задается количество реплик нашего микросервиса.
spec.selector.matchLabels
Этот элемент устанавливает связь между деплойментом и управляемыми подами. Так в нашем случае деплоймент будет управлять только теми подами, у которых есть метка tier, равная ‘backend’. Далее в spec.template мы зададим шаблон для создания подов, причем для корректной работы у каждого из них в поле metadata.labels должна быть та же метка, что и здесь.
spec.strategy
Блок spec.strategy описывает стратегию обновления подов. Тип ‘rollingUpdate’ подразумевает, что будет создан новый ReplicaSet, старые поды постепенно будут удаляться из старого ReplicaSet’а, а обновленные добавляться в новый. Скорость замены подов (максимальное количество добавляемых/удаляемых реплик от нужного количества) можно регулировать параметрами maxSurge и maxUnavailable. Эта стратегия позволяет плавно обновить деплоймент, избежав даунтайма. В данном контексте блок spec.strategy приведен только в демонстрационных целях, так как полностью совпадает с дефолтным значением.
spec.templates
Блок spec.templates содержит информацию о создаваемых деплойментом подах.
spec.templates.metadata.labels
Как уже было сказано выше, это поле должно коррелировать с spec.selector.matchLabels, чтобы создаваемые поды могли быть «подхвачены» деплойментом.
spec.templates.spec.containers.image
Используемый образ. Тег latest будет присвоен Docker-образу, если мы его запушим в реестр, явно не указав другой тег. Хоть по смыслу этот тег и обозначает самый свежий образ, однако его использование — не лучшая практика в Kubernetes. В случае чего мы не сможем откатиться к предыдущей версии пода, если его образ был перезаписан в реестре. Как минимум поэтому лучше использовать образы с уникальными тегами. Сейчас же мы умышленно используем ‘latest’ образ и поправим это в 4 части этого цикла статей, когда будем настраивать пайплайн в Jenkins.
spec.templates.spec.containers.envFrom.configMapRef
Ссылаемся на уже созданный ConfigMap и помещаем все значения из него в переменные среды.
spec.templates.spec.containers.env
В этом блоке создаем переменную среды ‘SECRET’, равную значению из нашего объекта-секрета под ключом ‘secret’.
spec.templates.spec.containers.readinessProbe
Проверка готовности пода принимать трафик. Здесь мы указываем эндпойнт, предоставляющий информацию о состоянии микросервиса. Kubernetes будет периодически делать запросы на этот адрес, и если 3 раза подряд статус ответа будет не 200, то проблемный под будет исключен из балансировки нагрузки.
initialDelaySeconds — задежка перед первой проверкой.
periodSeconds — интервал между проверками.
Также существует проверка жизнеспособности пода livenessProbe, но я сомневаюсь в рациональности ее применения здесь (хорошая статья на эту тему).
spec.templates.spec.containers.resources
Ограничения контейнера по ресурсам. limits — максимально доступное количество, а requests — количество ресурсов, предоставляемое контейнеру единовременно при старте. 200m — 200 миллиядер (одна пятая ядра), Mi — мегабайты.
Деплоймент микросервиса бекенда имеет аналогичную конфигурацию, за исключением того, что мы не должны сообщать ему секрет через переменную среды.
Services
Так как мы работаем с Minikube, и у нас нет внешнего балансировщика нагрузки, то выберем тип сервиса NodePort. spec.ports.nodePort — порт на хосте. Если его не указать, то будет выбран рандомный порт из интервала 30000-32767.
Итоговый файл конфигурации для Minikube
Запуск
Подождем пока все объекты Kubernetes запустятся и получим URL нашего приложения:
Далее сгенерируем трафик:
Вывод команды (будет отличаться в вашем случае):
Запросы поступают бекендам равномерно, и каждый бекенд принимает запросы именно от своего шлюза. Признаюсь, я несколько раз проводил запуск, чтобы получить такую картину. Если запустить команду повторно через какое-то время, то шлюзы и бекенды могут быть связаны уже по-другому, причем есть вероятность, что все шлюзы будут слать запросы одному бекенду. Это связано с тем, что имеет место балансировка между клиентами, а не запросами. Например, если один клиент будет слать 1 запрос в секунду, а другой 1000, и они будут изначально «привязаны» к разным репликам, то это приведет к разнице в нагрузке в 1000 раз. Это, безусловно, не лучший вариант балансировки трафика, однако дальнейшее исследование этой темы оставим за рамками данной статьи. Подробнее можно прочитать здесь.
Управление кластером
Здесь я перечислю несколько полезных команд для управления кластером.
Извлечение информации
Изменение конфигурации кластера
Дебаг
GKE configuration
Как я уже говорил, далее мы обсудим, как можно изменить конфигурацию, чтобы задеплоить систему в Google Kubernetes Engine.
Services
Инфраструктура GKE предоставляет нам внешний балансировщик нагрузки, который нам нужен для получения статичного внешнего IP-адреса. Чтобы подключить балансировщик, изменим тип сервиса шлюза на LoadBalancer:
HorizontalPodAutoscalers
HorizontalPodAutoscaler будет автоматически масштабировать деплоймент в зависимости от нагрузки на его поды. Мне не удалось заставить работать этот компонент на Minikube (какие-то странные неполадки с сервером метрик), но в GKE он работает из коробки.
В spec.scaleTargetRef мы указываем, что мы собираемся автомасштабировать деплоймент под именем backend. Далее сообщаем, что собираемся содержать от 1 до 3 реплик и планируем держать поды загруженными на 50%. Отмечу, чтобы задавать планируемую загрузку в процентах (можно указывать и в абсолютных величинах), то надо обязательно указать requests.cpu у управляемых контейнеров.
Конфигурация HorizontalPodAutoscaler’а шлюза аналогична.
Quotas
Квоты позволяют настроить максимальное потребление ресурсов всем кластером. Это обычно нужно, если несколько команд используют один кластер (multitenant environment). Давайте ограничим ресурсы, доступные объектам нашего неймспейса:
Если мы проставляем жесткие ограничения квот по какому-либо параметру, то для каждого из создаваемых подов этот параметр становится обязательным. Это может вызывать неудобства, например, при создании контейнеров из CLI (см. kubectl run ), поэтому установим дефолтные параметры с помощью объекта LimitRange:
Так как конфигурация квот напрямую не относится к нашему приложению, то лучше оформить ее в отдельный файл.