Урок 17: Автоскейлинг в кластере Kubernetes. Вечерняя школа «Kubernetes для разработчиков»

• Приветствие и объяснение, почему видео называется "регулярная шизофрения".  

• Объявление темы видео: горизонт автоскейлер в Kubernetes.  

• Обещание рассказать о полезности горизонта автоскейлера для разработчиков.  

• Горизонт автоскейлер автоматически масштабирует поды в кластере Kubernetes.  

• Полезен не только для облачных, но и для локальных кластеров.  

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

• Видео разделено на уровни сложности для разных уровней подготовки.  

• Новый уровень: понимание горизонта автоскейлера и его применения.  

• Продвинутый уровень: детали реализации горизонта автоскейлера и кастомные метрики.  

• Kubernetes как конструктор для создания и модификации приложений.  

• Демонстрация возможностей Kubernetes для реализации бизнес-фич.  

• Переход к обсуждению горизонта автоскейлера.  

• Горизонт автоскейлер увеличивает или уменьшает количество подов на основе параметров.  

• Горизонт автоскейлер является контроллером в рамках контроллер-менеджера.  

• Пример использования: автоматическое масштабирование для балансировки нагрузки.  

• Введение в метрик сервер и его роль в автоскейлинге.  

• Запуск тестовой лаборатории для демонстрации работы горизонта автоскейлера.  

• Инструкции по запуску метрик сервера и настройке кластера.  

• Рекомендации по очистке пространства Kubernetes перед началом практики.  

• Использование команд kubectl для проверки состояния кластера и подов.  

• Демонстрация загрузки нод и подов в кластере.  

• Обсуждение проблем с кластером и API-версией.  

• Рекомендация проверить актуальную версию API для кластера.  

• Указание на необходимость исправления версии API в конфиге.  

• Обсуждение запуска кода на общем кластере.  

• Указание на сложность настройки кластеров у каждого пользователя.  

• Рекомендация использовать команду `kubectl get pod -o wide` для проверки ноды кластера.  

• Обсуждение проблем с метриками на мини-кубе.  

• Рекомендация использовать мини-куб для метрик сервера.  

• Указание на необходимость выполнения инструкций по метрикам.  

• Запуск тестового приложения с использованием `kubectl apply -f`.  

• Обсуждение использования `kubectl get` для наблюдения за изменениями.  

• Указание на важность наличия реквеста для горизонтального автоскейлинга.  

• Создание сервиса для приложения с использованием `kubectl expose`.  

• Обсуждение быстрого способа создания сервиса.  

• Указание на необходимость использования системы контроля версий для управления кластерами на продакшене.  

• Обсуждение проблем с лимитом ресурсов и реквестом.  

• Рекомендация добавить лимит ресурсов в манифест.  

• Указание на необходимость соответствия лимита и реквеста ресурсов.  

• Применение лимита для работы приложения.  

• Запуск нагрузки на приложение с помощью лод генератора.  

• Лод генератор выполняет бесконечные запросы на сервис.  

• Наблюдение за метриками приложения и лод генератора.  

• Горизонтальный автоскалер увеличивает количество подов при достижении 50% нагрузки.  

• Проблемы с масштабированием и возможные решения.  

• Проблемы с метриками и их влияние на масштабирование.  

• Обсуждение возможных причин ошибок и их исправление.  

• Использование различных образов для решения проблем.  

• Горизонтальный автоскалер увеличивает количество подов при нагрузке.  

• Обсуждение задержки перед снижением количества подов.  

• Настройка тайм-аута для более точного управления масштабированием.  

• Сбор метрик с помощью куплета и кадвизора.  

• Метрик сервер собирает метрики и предоставляет их раз в минуту.  

• Метрик сервер не хранит данные, а предоставляет актуальную информацию.  

• Опи сервис как абстракция для работы с метриками.  

• Возможность запуска дополнительных опи серверов.  

• Опи сервис позволяет управлять запросами на метрики.  

• Kubernetes перенаправляет запросы на метрики в специальный сервис.  

• Запросы от горизонтального автоскейлера направляются на метрик сервер.  

• Метрик сервер обрабатывает запросы и возвращает данные.  

• Kubernetes позволяет расширять свои возможности через API-сервисы.  

• Можно создавать и регистрировать служебные абстракции, такие как блог.  

• Kubernetes позволяет строить полноценные системы на основе API-сервисов.  

• Горизонтальный автоскейлер работает в общем кластере.  

• Количество подов возвращается к минимальному значению при снижении нагрузки.  

• Kubernetes обрабатывает запросы к сервисам, включая метрик сервер.  

• Kubernetes перенаправляет запросы на метрик сервер по порту 443.  

• Метрик сервер агрегирует данные со всех кубернетов.  

• Горизонтальный автоскейлер может не справляться с нагрузкой.  

• Горизонтальный автоскейлер версии 1 использует только нагрузку по CPU.  

• Горизонтальный автоскейлер версии 2 поддерживает более сложные метрики.  

• Версия 2 позволяет использовать различные метрики, такие как использование памяти.  

• Версия 2 поддерживает конкретные значения метрик для автоскейлинга.  

• Можно использовать любые метрики, которые приложение может предоставить.  

• Важно контролировать количество реплик в манифестах, чтобы избежать конфликтов с горизонтальным автоскейлером.  

• Мини-куб может не видеть метрики из-за ошибок в контроллере.  

• Метрики полов включают тип, ресурс и метрику.  

• Для всех типов метрик, кроме ресурсов, можно указывать только эвери.  

• Горизонтальный автоскейлинг работает на основе метрик.  

• Можно настроить приложение для отправки метрик.  

• Горизонтальный автоскейлинг может создавать новые поды при превышении определенного порога.  

• Горизонтальный автоскейлинг может использовать метрики объектов.  

• Пример: метрики ingress контроллера для определения количества запросов.  

• Можно использовать метрики из других систем мониторинга.  

• В таргете нельзя указывать математические операции.  

• Prometheus может производить математические операции с метриками.  

• Можно создавать искусственные метрики для автоматического скейлинга.  

• Горизонтальный автоскейлинг может использовать метрики из внешних систем.  

• Пример: метрики очередей для определения количества сообщений.  

• Можно запускать новые поды при превышении определенного порога.  

• Пример сервиса для перевода видео в текст.  

• Горизонтальный автоскейлинг запускает новые поды при поступлении новых сообщений.  

• Это позволяет динамически масштабировать ресурсы в зависимости от нагрузки.  

• Вопрос о запросе метрик у Prometheus.  

• Метрики для горизонтального автоскейлинга собираются через API сервиса.  

• Prometheus адаптер помогает форматировать метрики для горизонтального автоскейлера.  

• Prometheus позволяет регистрировать искусственные метрики на основе календаря.  

• Можно настроить метрику, которая будет равна нулю в будние дни и единице в выходные.  

• Это позволяет автоматически масштабировать количество подов в зависимости от метрики.  

• Можно написать собственный адаптер для генерации метрик на основе крон правил.  

• Это позволяет избежать использования системы мониторинга Prometheus.  

• Практика директория 02 требует установки Prometheus и Prometheus адаптера.  

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

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

• Если в кластере уже установлен Prometheus, можно использовать его метрики для автоматического масштабирования.  

• Админы кластера могут установить Prometheus адаптер для использования метрик.  

• Разработчикам нужно только описать параметры скейлинга в YAML-файле.  

• Пример описывает скейлинг на основе метрик Prometheus.  

• Метрика должна быть типа object и называться определенным образом.  

• Параметры скейлинга включают минимум и максимум реплик, а также метрику для скейлинга.  

• Разработчикам предлагается самостоятельно настроить Prometheus и Prometheus адаптер.  

• Можно использовать утилиту для генерации нагрузки, например, WRC.  

• После настройки можно экспериментировать с автоматическим масштабированием на основе метрик.  

• Обсуждение автомасштабирования в Kubernetes.  

• Практика по автомасштабированию возможна на мини-кубе или другом кластере с административным доступом.  

• Презентация о кластерном автомасштабировании.  

• Кластерный автомасштабирование добавляет новые узлы в кластер.  

• Работает только в облачных кластерах, не в локальных.  

• Пример использования в облаке VK Cloud Solutions.  

• Автомасштабирование может увеличивать и уменьшать количество узлов.  

• Совместно с горизонтальным автомасштабированием помогает справляться с пиковыми нагрузками.  

• Возможность использования для экономии затрат на инфраструктуру.  

• Использование для запуска раннеров CDI по требованию.  

• Экономия затрат на инфраструктуру за счет динамического управления узлами.  

• Пример с динамическими стендами и их экономией.  

• Вертикальное автомасштабирование увеличивает количество запросов на узлах.  

• Полезно для приложений, которые не могут масштабироваться горизонтально.  

• Рекомендация по лимитам запросов на основе метрик приложения.  

• Реклама чата VK Cloud Solutions для общения клиентов.  

• Подписка на канал новостей о Kubernetes.  

• Напоминание о домашнем задании и приглашение к обсуждению.  

• Если в дипломенте указано количество реплик, а в HPA одно, то HPA будет управлять репликами.  

• Если в дипломенте указано два реплики, а в HPA одна, то HPA вернет количество реплик к двум.  

• Рекомендуется убрать параметры реплик из манифестов и позволить HPA управлять репликами.  

• Читайте релиз-ноты для продуктов, которыми пользуетесь.  

• Перед обновлением кластера Kubernetes читайте релиз-ноты, чтобы понять изменения.  

• В Kubernetes часто предупреждают о деприкейтированных параметрах перед обновлением.  

• HPA работает как монитор загрузки подов, влияя на количество реплик дипломантов.  

• HPA не создает дипломанты и поды, а управляет их количеством реплик.  

• Метрики можно посмотреть в Prometheus или в системе мониторинга.  

• В HPA v1 доступна только метрика CPU.  

• OOM-killer — стандартный механизм Linux, не нужно его встраивать.  

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

• Автор проходил сертификацию по Kubernetes Administrator.  

• Сертификация оказалась простой для опытного пользователя Kubernetes.  

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

• Разработчики должны понимать архитектуру Kubernetes и уметь конфигурировать HPA.  

• Антиофинити позволяет создавать реплики на разных нодах.  

• Параметры реквайр и преферт управляют поведением HPA при нехватке ресурсов.  

• HPA v1 можно использовать из коробки, но HPA v2 требует настройки от администраторов.  

• Администраторы должны запустить и настроить мониторинг для HPA v2.  

• HPA является стандартной абстракцией Kubernetes.  

• Для работы HPA нужен плагин, так как Kubernetes не реализует механизм работы с метриками.  

• Для автоскейлера нужно объединить железные и облачные ноды в один кластер.  

• Необходимо самостоятельно настроить кластер автоскейлера.  

• Можно выделить две группы нод: железные и облачные, и настроить автоскейлер для каждой группы.  

• Масштабы кластера зависят от частоты изменений и нагрузки.  

• Верхний предел кластера Kubernetes составляет около 5000 нод.  

• В продакшне можно использовать кластеры с сотней железных нод и более 3000 подов.  

• Админы часто боятся новых технологий и не хотят использовать Kubernetes.  

• Kubernetes предназначен для упрощения работы разработчиков, а не для администраторов.  

• Автоматизация помогает предотвратить ошибки разработчиков.  

• Можно указать минимум две реплики для HAProxy.  

• HAProxy автоматически увеличивает количество реплик при необходимости.  

• Это позволяет поддерживать отказоустойчивость без необходимости ручного управления.  

• Метрики передаются через Prometheus адаптер.  

• Подготовка подов включает уменьшение размера образа и минимизацию действий в стартовом скрипте.  

• Миграции и другие операции лучше выполнять в отдельных джабах.  

• Вопросы о хранении метрик и увеличении лимита текста в слайдах.  

• Проблемы с доступом к Apache и PostgreSQL решаются созданием сервиса для основного приложения.  

• Метрики хранятся в системе мониторинга, обычно Prometheus или Victoria Metrics.  

• Завершение лекции и благодарность участникам.