место для рекламы
Хотите вместе создать новую бессерверную систему исследований и разработок? Добро пожаловать в команду беспроводных серверов Alibaba CBU, мы ищем старших инженеров / технических экспертов по исследованиям и разработкам, отправьте свое резюме на yuanyan.lmh@alibaba-inc.com
предисловие
Автоматическое масштабирование — одна из самых захватывающих возможностей, которую нам предоставила современная платформа планирования контейнеров. В крупномасштабных бизнес-системах мы постоянно сталкиваемся с такой проблемой: пользовательский трафик часто колеблется во времени, и даже иногда случаются непредсказуемые пики (burr traffic), и приложения необходимо вручную расширять всякий раз, когда трафик увеличивается. , после пикового трафика исчезает, необходимо утилизировать расширенную машину, что требует много времени и труда для эксплуатации и обслуживания.
К счастью, платформы планирования контейнеров, такие как k8s, постепенно помогают нам решать такие проблемы.Функция AutoScaler, которую она предоставляет, в настоящее время поддерживает эластичное масштабирование в нескольких измерениях и может быть адаптирована в соответствии с нагрузкой приложения. Хотя в некоторых более требовательных сценариях из-за ограничения скорости запуска контейнера и других причин эффект от AutoScaler неудовлетворителен, но я считаю, что в ближайшем будущем схема автоматического масштабирования и расширения будет полностью отработана, и тогда мы будет легко получить сильную эластичность способный сервисный кластер.
Теперь давайте попробуем использовать связанные с Scale функции k8s.
Ручная настройка размера службы
мы можем использоватьkubectlпредоставляет команды для ручной настройкиDeploymentРазмер пода, то есть количество подов, которые он содержит.В качестве примера возьмем сервис HelloWorld, созданный в предыдущем разделе.Текущее состояние развертывания выглядит следующим образом:
- DISIRED указывает желаемое количество реплик, объявленных во время настройки.
- CURRENT указывает количество запущенных в данный момент реплик.
- UP-TO_DATE указывает количество реплик, которые соответствуют ожидаемому состоянию (например, если реплика не работает, эта реплика здесь не будет учитываться).
- AVAILABLE указывает количество реплик, доступных в настоящее время.
мы можем использоватьkubectl scaleкоманду, чтобы вручную настроить размер развертывания, а теперь попробуйте увеличить количество реплик службы helloworld до 4:
После выполнения команды k8s быстро создал для нас еще 3 копии helloworld.В это время запущено несколько экземпляров всего сервиса, и вступит в силу функция балансировки нагрузки, соответствующая сервису.Вы можете увидеть статус Обнаружено несколько конечных точек:
Когда мы постоянно вызываем службу, мы видим, что фактически вызываемые модули каждый раз разные (в исходный код службы вносятся некоторые изменения, и имя хоста выводится):
Точно так же мы можем уменьшить масштаб службы таким же образом, например, уменьшив количество наборов реплик до двух:
Автоматическое масштабирование: чрезвычайная гибкость?
В предыдущем примере мы вручную настроили масштаб службы через командную строку. Очевидно, что мы не можем сделать это в условиях реального онлайн-трафика. Мы надеемся, что платформа планирования сможет разумно настроить масштаб в соответствии с нагрузкой на службу. Эластичное масштабирование. Теперь настала очередь k8sAutoScalerвышел
На данный момент k8s предоставляет в общей сложности 3 различных измерения AutoScaler, как показано ниже:
k8s делит эластичное масштабирование на две категории:
- Измерение ресурсов: убедитесь, что размер пула ресурсов кластера соответствует общему плану.Когда ресурсов в кластере недостаточно для поддержки производства новых модулей, граница активируется для расширения.
- Измерение приложения: убедитесь, что нагрузка приложения находится в пределах ожидаемого плана мощности.
Соответствует двум стратегиям масштабирования:
-
Горизонтальное расширение
- Измерение кластера: автоматически настраивайте размер пула ресурсов (добавляйте/удаляйте рабочие узлы)
- Измерение Pod: автоматическая настройка количества наборов реплик для Pod.
-
Вертикальное расширение
- Измерение кластера: не поддерживается
- Размер модуля: автоматическая настройка распределения ресурсов приложения (увеличение/уменьшение использования процессора и памяти модуля).
Одной из наиболее зрелых и часто используемых стратегий масштабирования являетсяHPA (горизонтальное масштабирование pod), поэтому давайте возьмем его в качестве примера, чтобы сосредоточиться на анализе, официальный документ находится здесь:Что особенного.IO/docs/tasks/…
Основной процесс
Масштабирование и масштабирование любой эластичной системы — это не что иное, как следующие шаги:
- Соберите индикаторы мониторинга
- Совокупные индикаторы мониторинга для определения необходимости масштабирования или расширения
- Выполнение действий по масштабированию
Давайте проанализируем метод работы HPA в этом порядке.Вот общая схема архитектуры HPA:
Показатели мониторинга
Согласно описанию в официальном документе, HPA использует механизм цикла управления для сбора данных об использовании ресурсов Pod.Интервал сбора данных по умолчанию составляет 15 секунд, которые можно собирать с помощью диспетчера контроллеров (процесс на узле Master).--horizontal-pod-autoscaler-sync-periodпараметры ручного управления.
Текущая реализация метрик сбора HPA по умолчанию:Heapster, он в основном собирает использование ЦП; бета-версия также поддерживает сбор настраиваемых индикаторов мониторинга, но он нестабилен и не рекомендуется
Следовательно, можно просто считать, что HPA использует использование ЦП в качестве индикатора мониторинга.
Алгоритм агрегации
После сбора показателей ЦП k8s использует следующую формулу, чтобы определить, сколько модулей необходимо расширить.
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
ceil означает округление.Например, предположим, что служба запускает 4 модуля, текущая загрузка ЦП составляет 50%, а ожидаемая загрузка ЦП составляет 25%, тогда фактическое количество модулей, которые соответствуют ожиданиям, равно4 * (50% / 25%) = 8, то есть вам нужно удвоить емкость Pod и добавить 4 Pod для удовлетворения спроса.
Конечно, приведенные выше показатели не являются абсолютно точными.Во-первых, k8s постарается сделать показатели максимально близкими к ожидаемому значению, а не полностью равными.Во-вторых, HPA задает понятие допуска, которое позволяет показателям отклоняться от ожидаемое значение в определенном диапазоне.По умолчанию 0,1, что означает, что если вы установите политику планирования как ожидаемое использование ЦП = 50%, фактическая политика планирования будет меньше 45% или больше 55% для масштабирования и расширения, HPA попытается контролировать показатели в этом диапазоне (допуск может быть превышен--horizontal-pod-autoscaler-toleranceнастроить)
Следует отметить еще две детали:
Одним из них является интервал, в котором k8s принимает решения.Он не выполняет непрерывно действия расширения и сжатия, а имеет определенный cd.В настоящее время cd действия расширения составляет 3 минуты, а сжатия - 5 минут.
Во-вторых, у k8s есть максимальное ограничение на расширение, и количество подов для каждого расширения не будет превышать текущее количество реплик более чем в 2 раза.
Практика HPA
Наконец, давайте попробуем использовать HPA, по-прежнему используя командную строку kubectl для создания:
kubectl autoscale deployment helloworld --cpu-percent=10 --min=1 --max=5
После выполнения приведенной выше команды вы увидите, что HPA был создан на панели инструментов.Политика заключается в использовании 10% загрузки ЦП в качестве порога, минимальное количество наборов реплик равно 1, а максимальное — 5:
использоватьkubectl get hpaТакже см:
Но здесь есть исключение: текущее использование ЦП целей всегда отображается как неизвестное, что, как говорят, вызвано тем, что ресурсы не настроены в наборе реплик. Нам нужно найти соответствующий набор реплик в дашборде, а затем объявить значения запросов и лимитов в spec.containers.resources:
вrequestsУказывает квоту ресурсов, которую модуль должен выделить.limitsУказывает максимальную квоту ресурсов, которую может получить один модуль.
После настройки индикатор по-прежнему отсутствует, перейдите в Baidu и обнаружите, что он не установлен.heapsterПоддержите, затем установите, конкретный метод можно увидетьэта статья, обратите внимание, что вам нужно установить чужой образ gcr через агента Alibaba Cloud (если вы не очень разбираетесь в этом, вы можете использовать меня для его переноса, см.github),influxDB,grafanaиheapsterПосле установки всех трех компонентов не забудьте установить еще одинheapster rbac(существуетkubeconfig/rbacкаталог), и, наконец, перезапустите волну миникуба, откройте консоль, вы можете увидеть, что на странице узла уже есть изображение индикатора:
kubectl topКоманды также могут возвращать значения в обычном режиме:
Тем не мение,kubectl get hpaОн показывает, что текущий индекс процессора все еще неизвестен, подавлен, перейдите к развертыванию, чтобы увидеть журнал:
Видно, что HPA сообщает об ошибке, что запрошенный ресурс не может быть получен из API метрик, github прошел волну и нашел похожуюissue, причина в том, что дефолтный источник индикатора мониторинга k8s после версии 1.9 сменился с heapster на metrics-server (я использую 1.0, pit), но ставить другой набор metrics-server слишком хлопотно, можно модифицироватьkube-controller-managerчтобы отключить эту новую функцию.
minikube sshЗайдите внутрь виртуальной машины и найдите/etc/kubernetes/manifests/kube-controller-manager.yamlДобавьте этот файл в параметры запуска--horizontal-pod-autoscaler-use-rest-clients=false, в это время соответствующая группа контейнеров автоматически перезапустится и обновится, а затем выполнитсяkubectl get hpa, вы можете видеть, что индикатор процессора, наконец, в порядке:
Оставив позади тронутые слезы, я наконец могу начать проверять воду, поторопитесьbuzyboxНажмите вверх:
kubectl run -i --tty load-generator --image=busybox /bin/sh
Напишите цикл для доступа к нашему сервису helloworld (для более быстрого результата я уменьшил масштаб сервиса до одного набора реплик и напрямую нажал на ip этого пода)
/ # while true; do wget -q -O- http://172.17.0.5:8080; done
Вы можете увидеть результат примерно через минуты 2 или 3. Проверьте состояние hpa в это время, вы можете увидеть, что горизонтальное расширение было запущено, и количество наборов реплик было добавлено с 1 до 4:
Эффект также можно увидеть на приборной панели:
Отключите сценарий стресс-теста, дайте ему поработать некоторое время, а затем посмотрите на состояние HPA:
Автоматически сжимайте до 1 набора реплик, после чего практическое использование HPA на этом заканчивается.
обновить, опубликовать, откатить
Сервисный код должен часто изменяться, когда код изменяется, вы должны переупаковывать сгенерированный образ, затем выпускать и развертывать, посмотрите на k8s, как справиться с этими шагами.
Теперь мы вносим некоторые изменения в код, добавляем вывод имени хоста и упаковываем его в2.0Новая версия образа, необходимо развернуть эту новую версию образа в контейнерном кластере k8s, используйтеkubectl set imageУкажите новый образ в развертывании:
kubectl set image deployments/helloworld helloworld=registry.cn-qingdao.aliyuncs.com/gold-faas/gold-demo-service:2.0
После выполнения этой команды вы можете видеть из kubectl и панели инструментов, что создаются новые группы контейнеров, а старые группы контейнеров перерабатываются:
В конце концов все старые версии pod’ов будут переработаны, и останется только новая выпущенная версия набора реплик группы контейнеров:
Чтобы проверить, обновлена ли служба:
Предположим, возникла фатальная проблема с нашей версией, выпущенной онлайн, и нам нужно срочно откатить сервис на предыдущую версию, что нам делать? использоватьkubectl rollout undoЗатем давайте посмотрим на эффект:
Видно, что после выполнения команды отката pod новой версии начинает перерабатываться, а pod, соответствующий образу предыдущей версии, пробуждается (скорость здесь очень быстрая, чувствую, что k8s может не уничтожить историю сразу после выпуска новой версии службы экземпляра модуля, но будет кэшироваться в течение определенного периода времени, так что откат будет очень быстрым, пока балансировщик нагрузки службы указывает на историческую версию модуля)
После завершения отката снова запросите службу, и вы обнаружите, что служба вернулась к содержимому предыдущей версии:
Вышеуказанные возможности освобождения и отката называются в k8sскользящее обновление, что позволяет нам постепенно обновлять модуль в соответствии с определенной пропорцией (процент можно установить вручную), чтобы добиться плавного обновления и отката, а также добиться функций, аналогичных сине-зеленому выпуску и канареечному выпуску.
резюме
В ходе фактической работы я испытал механизм масштабирования, расширения и освобождения k8s.Хотя я столкнулся с несколькими ямами, в целом он по-прежнему очень удобен.Основные функции k8s почти изучены здесь, и я начну из следующей статьи Продолжайте подробно разбирать принцип k8s, так что следите за обновлениями!
исходный адресmarklux.cn/blog/107, Пожалуйста, укажите источник