Концепция — развертывание приложения

Завершено

Перед развертыванием приложения в Kubernetes давайте рассмотрим развертывания Kubernetes и обсудим их ограничения в нашем сценарии.

Что такое развертывания Kubernetes?

Развертывание Kubernetes — это эволюция объектов pod. Развертывания упаковывают модули pod в интеллектуальный объект, который позволяет масштабировать их. Вы можете легко дублировать и масштабировать приложение для поддержки большей нагрузки без необходимости настраивать сложные сетевые правила.

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

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

Этот сценарий включает в себя приложение на основе событий, которое получает большое количество событий в разное время. Без объекта KEDA Scaler или HPA необходимо вручную настроить количество реплика для обработки количества событий и уменьшения масштаба развертывания при возврате нагрузки в нормальное состояние.

Пример манифеста развертывания

Ниже приведен пример фрагмента манифеста развертывания:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

В примере манифеста replicas установлено значение 10, что является самым большим числом, которое можно задать для необходимых реплика, доступных для обработки пикового числа событий. Однако это приводит к тому, что приложение будет использовать слишком много ресурсов во время неписаного времени, что может привести к нехватке других развертываний в кластере.

Одним из решений является использование автономной HPA для мониторинга использования ЦП модулей pod, что является лучшим вариантом, чем масштабирование вручную в обоих направлениях. Однако HPA не фокусируется на количестве событий, полученных в списке Redis.

Лучше всего использовать KEDA и масштабировщик Redis для запроса списка и определить, требуется ли больше или меньше модулей pod для обработки событий.