Нюансы запуска приложений в Kubernetes Новиков Андрей, Злые марсиане Trampoline meetup #8 24 февраля 2022

Нет войне!

Нюансы запуска приложений в Kubernetes Новиков Андрей, Злые марсиане Trampoline meetup #8 24 февраля 2022

No content

No content

Марсианский Open Source Yabeda: Ruby application instrum entation fram ework Lefthook: git hooks m anager AnyCable: Polyglot replacem ent for ActionCable server PostCS S : A tool for transform ing CS S with JavaS cript Im gproxy: Fast and secure standalone server for resizing and converting rem ote im ages Logux: Client-server com m unication fram ework based on Optim istic UI, CRDT, and log Overm ind: Process m anager for Procfile-based applications and tm ux И многие другие на evilmartians.com/oss

No content

Kubernetes 101 Шо, какой ещё Kubernetes?

Зачем разработчику знать Kubernetes? TL;DR: Чтобы быстрее деплоить новые фичи самим и не ждать админов/девопсов. Kubernets’а бояться — в деплой не ходить от марсианского SRE. Кирилл Кузнецов - Кирилл Кузнецов - … … Вечерняя школа Kubernetes для разработчиков от Slurm.io Урок 1: Введение в Урок 1: Введение в … …

Что такое Kubernetes… Кластерная операционная система для деплоя приложений Абстрагирует приложение от нижележащего железа/облаков* Декларативная конфигурация и встроенный control loop Использует (Docker-)контейнеры для запуска приложений… …и свои абстракции для их оркестрации и запуска * https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/

…и из чего он состоит Источник: Kubernets’а бояться — в деплой не ходить (слайды)

Pod минимальная и главная единица в k8s — «атом» ⚛️ логически неделимая группа контейнеров (но обычно 1 основной) запускаются вместе на одной машине делят между собой localhost и сеть есть внутрикластерный IP-адрес с точки зрения приложения — как будто отдельный сервер Документация: kubernetes.io/docs/concepts/workloads/pods Картинка: kubernetes.io/docs/tutorials/kubernetes- basics/explore/explore-intro

Service Абстракция для логической группировки pod’ов Service discovery — есть внутрикластерное DNS-имя Балансируют трафик между своими подами (round robin) Реализованы как набор правил iptables Позволяет нам масштабировать приложения горизонтально Документация: kubernetes.io/docs/concepts/services- networking/service Картинка: kubernetes.io/docs/tutorials/kubernetes- basics/expose/expose-intro

Healthcheck’и зачем их столько и в чём разница?

Kubernetes health probes У каждого отдельного контейнера внутри каждого пода: liveness Контейнер убивается и перезапускается, если он не отвечает на «ты жив?». readiness Под исключается из балансировки трафика через сервис, если не отвечает на «ну что, готов?» и включается обратно, когда отвечает утвердительно. startup (k8s 1.20+) Позволяет отсрочить начало liveness и readiness проверок для долгозапускающихся приложений Важно: и liveness и readiness выполняются параллельно всё время жизни пода. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Просто (и неправильно) Одинаковые пробы для веб-приложения: path: /health port: 80 path: /health port: 80 containers: - name: app livenessProbe: httpGet: timeoutSeconds: 3 periodSeconds: 10 readinessProbe: httpGet: timeoutSeconds: 3 periodSeconds: 10 Картинка: behance.net/gallery/35173039/Stickers-for- another-one-IT-conference-(DUMP2016)

А какая разница?

Очереди запросов Запросы ждут свободного воркера/бэкенда в Nginx или апп-сервере. Картинка: https://railsautoscale.com/request-queue-time/

Приходит нагрузка 🏋️ 1. Медленные запросы попадают на один под и «забивают» его 2. «Забитый» контейнер в поде перестаёт отвечать на liveness 🥀 3. Kubernetes убивает контейнер 💀 4. И тут же запускает его заново, но это занимает какое-то время… ⌚ 5. На время перезапуска на другие поды приходит больше запросов. 6. GOTO 1 🤡 Неправильно настроенная liveness-проба под нагрузкой убьёт приложение, под за подом!

Картинка: https://knowyourmeme.com/photos/1901279-death-knocking-on-doors

Что же делать? Пустить liveness пробу в обход! port: 8080 # ← другой порт containers: - name: app livenessProbe: httpGet: path: /health timeoutSeconds: 3 periodSeconds: 10 readinessProbe: httpGet: path: /health port: 80 timeoutSeconds: 3 periodSeconds: 10 Картинка: behance.net/gallery/35173039/Stickers-for- another-one-IT-conference-(DUMP2016)

Healthcheck’и: итого 1. Liveness ходит через «чёрный ход» Поднимите listener на отдельном порту, куда будет ходить только проба. Kubernetes не должен прибивать ваши поды под нагрузкой! 2. Readiness ходит вместе с клиентскими запросами Позвольте «забитому» поду выйти из балансировки и «остыть». Таймаут нужно подобрать эмпирически, он не должен быть слишком мал. Следите за наличием неготовых подов в мониторинге! Мораль: делайте стресс-тесты!

Следите за очередью запросов! Время ожидания запросов в очереди — это главная метрика, которая показывает, что приложение «на пределе». Выведите её себе в мониторинг. Если она ощутимо больше 0 — надо скейлиться вверх (в Kubernetes есть Horizontal Pod Autoscaler) Если она всегда строго 0 — можно подумать о скейлинге вниз. Следите за USE и RED метриками, когда дело касается производительности! Utilization: количество свободных воркера Saturation: время ожидания свободного воркера (95p) Errors: процент ошибок при обработке запросов Duration: время обработки запроса (95p) USE method: https://www.brendangregg.com/usemethod.html RED method: https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/

А как масштабироваться-то? Kubernetes Horizontal Pod Autoscaler! Разбираем автоске Разбираем автоске… … Видео Слайды Используйте USE-метрики для масштабирования! Слайды: https://speakerdeck.com/dragonsmith/razbiraiem-avtoskieilingh-v-kubernetes

Requests и limits Как (не)правильно просить ресурсы и у кого.

Requests и limits 101 Для каждого контейнера в Pod’е: requests и limits для Pod — сумма значений его контейнеров. requests — инструкции для планировщика k8s limits — инструкции для ядра ОС на нодах кластера cpu — измеряются в millicpu (тысячных долях процессорного ядра) memory — измеряются в байтах и кратных (мебибайты, гебибайты) resources: requests: cpu: 200m memory: 256Mi limits: cpu: 500m memory: 512Mi https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Requests 101 Инструкции для планировщика k8s для распределения Pod’ов на ноды: Не используются в рантайме* Не учитывают фактическое потребление*, только requests других подов requests: cpu: 200m memory: 256Mi resources: limits: cpu: 500m memory: 512Mi * Используются при настройке OOM, но про это дальше Картинка: Илья Черепанов, внутренняя школа k8s

Limits 101 Реализуются ядром ОС на нодах: cpu настраивает троттлинг CPU memory настраивает Out of Memory Killer limits: cpu: 400m memory: 512Mi resources: requests: cpu: 200m memory: 256Mi

Так, что там за milliCPU ещё? В случае limits настраивает CPU throttling — долю процессорного времени, которое можно использовать в течение 100мс. Админы, настройте алерт CPUThrottlingHigh ! Не указывайте дробные CPU limits для контейнеров, где важна скорость ответа! ` ` cpu: 400m resources: requests: cpu: 200m memory: 256Mi limits: memory: 512Mi Подробнее: https://engineering.indeedblog.com/blog/2019/12/unthrottled-fixing-cpu-limits-in-the-cloud/

Утилизируем ядра Процесс на языках с GIL (Ruby, Python) не может утилизировать процессорное ядро целиком! Максимум на 30-50%. Используйте и процессы и потоки: Запускайте 2-4 рабочих процесса на контейнер (работает CoW 🐮) По 4-6 потоков в каждом ➕ Улучшается утилизация воркеров за счёт раздачи запросов простаивающим воркерам. Подробнее: https://www.speedshop.co/2017/10/12/appserver.html

Requests × Limits = QoS В различных сочетаниях реквестов и лимитов поведение контейнера может меняться драматично: 1. Guaranteed — requests = limits гарантированно выдаётся CPU убиваются по OOM последними 2. Burstable — requests ≠ limits могут использовать CPU больше запрошенного убиваются после BestEffort, в порядке «жадности» 3. BestEffort — нет ни requests ни limits CPU выдаётся в последнюю очередь Первыми убиваются OOM-киллером Всегда указывайте и requests и limits! ` ` ` ` ` ` Подробнее: Управление ресурсами в Kubernetes — habr.com/ru/company/flant/blog/459326/

Ну всё Ну почти.

Нам нужны твои мозги! Ищем добровольцев, чтобы причинять добро на всей Земле и за её пределами: evl.ms/jobs

Внимание! Внимание! Спасибо за внимание! @Envek @Envek @Envek @Envek github.com/Envek @evilmartians @evilmartians_ru @evil.martians Вакансии: evilmartians.com/jobs Блог: evilmartians.com/chronicles Evil Mar tians: links