Информация этой страницы может быть устаревшей

Оригинальная (английская) версия этого документа обновлялась с момента последнего перевода, поэтому информация может быть устаревшей. Если вы читаете на английском, посмотрите на оригинальную версию с наиболее актуальной информацией: Running Multiple Instances of Your App

Запуск нескольких экземпляров приложения

Отмасштабируйте существующее приложение вручную с помощью kubectl.

Цели

  • Научиться масштабировать приложение с kubectl

Масштабирование приложения

В предыдущих модулях мы создали деплоймент (Deployment), а затем открыли к нему публичный доступ через сервис (Service). Деплоймент создал только один под, в котором работает наше приложение. По мере увеличения трафика необходимо будет промасштабировать приложение, чтобы оно могло справиться с возросшим потоком пользователей.

Если вы не работали с предыдущими разделами документации, начните с использования minikube для создания кластера.

Масштабирование осуществляется за счёт изменения количества реплик в развёртывании.

Краткое содержание:

  • Масштабирование деплоймента

Количество экземпляров можно указать прямо при создании деплоймента, используя параметр --replicas команды kubectl create deployment


Обзор темы масштабирования


В случае масштабирования деплоймента создаются новые поды, которые распределяются по узлам с доступными ресурсами. Масштабирование увеличит количество подов в соответствии с новым требуемым состоянием. Kubernetes также поддерживает автоматическое масштабирование подов, но эта тема не рассматривается в данном уроке. Кроме этого, возможно масштабирование до нуля: в таком случае завершается работа всех подов в деплойменте.

При запуске нескольких экземпляров приложения нужно правильно распределить трафик между ними. У сервисов есть встроенный балансировщик нагрузки, который распределяет сетевой трафик на все поды деплоймента, доступного извне. Сервисы постоянно отслеживают запущенные поды через их эндпоинты (endpoints), чтобы направлять трафик только на доступные поды.

Масштабирование выполняется с помощью изменения количества реплик в деплойменте.


Если у вас есть несколько работающих экземпляров приложения, можно выполнять плавающие обновления (rolling updates) без простоев. С ними мы познакомимся в следующем модуле. А пока перейдём к терминалу и промасштабируем наше приложение.

Масштабирование деплоймента

Для вывода списка депойментов воспользуйтесь подкомандой get deployments: kubectl get deployments

Вывод будет примерно следующим:

               NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
               kubernetes-bootcamp   1/1     1            1           11m
               

У нас должен быть 1 под. Если его нет, выполните команду ещё раз. Вывод показывает следующую информацию:

  • NAME — названия деплойментов (Deployments) в кластере.
  • READY — соотношение CURRENT/DESIRED для его экземпляров (реплик).
  • UP-TO-DATE — количество реплик, которые были обновлены до желаемого состояния.
  • AVAILABLE — количество реплик, доступных для пользователей.
  • AGE — сколько времени приложение было запущено.

Чтобы увидеть ReplicaSet, созданные деплойментом, выполните: kubectl get rs

Обратите внимание, что название ReplicaSet всегда форматируется как [DEPLOYMENT-NAME]-[RANDOM-STRING]. Последний фрагмент генерируется случайным образом и использует pod-template-hash в качестве seed-значения.

Этот вывод будет содержать два важных столбца:

  • DESIRED — желаемое количество экземпляров (реплик) приложения. Это значение вы определяете, когда создаёте деплоймент.
  • CURRENT — количество реплик, которые работают в настоящий момент.

Далее отмасштабируем деплоймент до 4 реплик. Для этого воспользуемся командой kubectl scale, для которой укажем тип объекта (деплоймент), его название и количество желаемых экземпляров:

kubectl scale deployments/kubernetes-bootcamp --replicas=4

Снова выведем список деплойментов с помощью get deployments:

kubectl get deployments

Изменение применилось: теперь доступны 4 экземпляра приложения. Далее проверим, изменилось ли количество подов:

kubectl get pods -o wide

Теперь у нас 4 пода с разными IP-адресами. Это изменение было зафиксировано в логе событий деплоймента. Убедиться в этом можно подкомандой describe:

kubectl describe deployments/kubernetes-bootcamp

В выводе этой команды тоже видно, что теперь у нас 4 реплики.

Балансировка нагрузки

Проверим, что сервис балансирует трафик. Чтобы узнать внешний IP-адрес и порт, воспользуемся командой describe service, с которой уже познакомились в предыдущем модуле:

kubectl describe services/kubernetes-bootcamp

Объявим переменную окружения NODE_PORT со значением порта нашего узла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"

echo NODE_PORT=$NODE_PORT

Далее обратимся через curl к проброшенному IP-адресу и порту. Выполните эту команду много раз:

curl http://"$(minikube ip):$NODE_PORT"

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

Масштабирование вниз

Чтобы уменьшить деплоймент до 2 реплик, снова обратимся к подкоманде scale:

kubectl scale deployments/kubernetes-bootcamp --replicas=2

С помощью подкоманды get deployments выведем список деплойментов, чтобы убедиться, что изменение применилось:

kubectl get deployments

Количество реплик уменьшилось до 2. Выведем список подов с get pods:

kubectl get pods -o wide

Так мы убедимся, что работа 2 подов была остановлена.

Когда всё готово, переходите к разделу Выполнение плавающего обновления.

Изменено June 20, 2024 at 12:44 PM PST: Sync changest from andygol/k8s-website (36d05bc8a1)