Kubernetes — всё. Что вместо него?

Kubernetes стал стандартом де-факто в мире контейнеров и DevOps. Но может ли его что-то заменить?

Принес вам свежий выпуск подкаста {между скобок} — коллеги обсуждают, есть ли жизнь после k8s, куда движется индустрия и стоит ли разработчику вникать в k8s.

➡️ Внутри есть мини-интервью со мной, рассказываю про service mesh: что это, как устроено и кому нужно. А ещё делюсь промокодом на скидку 10% на интенсив по service mesh.

Но своим подписчикам готов отдать его прямо в посте: SM_SKOBKI

Смотреть интервью — по ссылке.

BARE METAL PROVISIONING

Вы, конечно, читали документацию Kubernetes. Следуйте инструкции, и получите кластер. Но есть одна маленькая деталь, когда дело касается автоматизации добавления воркер нод — нужно сначала установить ОС!

Как только у вас появилась ОС, её можно настраивать по сети. Ansible? Кастомные скрипты по SSH? Выбирайте свой любимый инструмент, который приносит меньше всего боли! В облаках, конечно, все проще. Создали AMI со всем необходимым, засунули kubeadm join в userdata, и готово! Хотя, конечно, проще взять EKS.

Бывают разные кейсы, и, например, здесь описано, как при помощи синей изоленты, AWS SSM, userdata и EC2 metadata API (169.254.169.254/latest/meta-data) автоматизировать добавление новых воркер нод, поднятых через terraform на EC2.

Но это все еще недостаточно интересно, мы же тут про настоящий bare metal говорим! Как автоматизировать процесс подключения новых воркер нод на bare metal?

🐈 Ответ: PXE (будьте здоровы!)
PXE — Preboot Execution Environment.

➡️ Что нам понадобится?

🟠 DHCP-сервер: будет выдавать машинам IP-адреса, а также сообщать, с какого TFTP-сервера нужно тянуть образ.

🟠 TFTP-сервер: TFTP (Trivial File Transfer Protocol) — это такой очень простой (до неприличия) протокол передачи файлов, который используется, чтобы отдать образ по сети на машину, у которой еще нет даже намека на операционную систему. TFTP-сервер раздаст загрузочные файлы, необходимые для старта установки.

➡️ Как это работает?

1. DHCP Discovery: PXE-клиент, вшитый в прошивку сетевой карты, отправляет DHCP DISCOVER.
2. DHCP Offer: DHCP-сервер отвечает с IP, TFTP сервером (option 66) и bootfile (option 67), используя MAC-адрес для кастомизации.
3. TFTP Download: клиент качает bootloader (например, pxelinux.0 или ipxe.efi) через TFTP (по UDP!, вот где UDP используется в реальном мире, не всем же по TCP ходить).
4. Bootloader Config: Bootloader ищет конфигурационный файл (например, MAC-адрес-специфичный, или default), определяющий kernel и initrd.
5. Kernel & Initrd: скачиваются kernel (vmlinuz) и initrd через TFTP.
6. OS Install: ядро загружается, initrd монтируется, и запускается установщик ОС. Здесь уже важно сделать образ, который «сам» поставится, вплоть до успешного kubeadm join.

➡️ Кастомизация?

Вся кастомизация может быть основана на MAC-адресе добавляемой ноды. DHCP-сервер может выдавать разные параметры в зависимости от MAC-адреса, а TFTP-сервер может отдавать разные файлы конфигурации PXELINUX. Это позволяет автоматизировать установку разных операционных систем и конфигураций на разные машины. Но все же лучше делать единообразно.

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

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

А что насчет медведя? Отсылаю к другому посту про музыку для работы. Slaughter to Prevail как раз недавно выпустили новый трек RUSSIAN GRIZZLY IN AMERICA.

Две взрывных шутки из комментариев:

You can't make typical animal noises in the breakdown
Alex : hold my BEAR

Режиссёр: Сколько отсылок к России вы хотите добавить?
Саня: Да

А как вы автоматизируете процесс поднятия воркер нод, если у вас bare metal?

Архитектурные диаграммы для вашего k8s

Разобраться в инфраструктуре проще, когда она нарисована. И в этом нам поможет kubediagrams.

➡️ Что это такое?

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

➡️ Пример использования с проектом opentelemetry demo.

Этот проект был выбран, потому что для него нет готовой картинки в README на github (а там есть разные примеры, начиная от простых деплоев wordpress, заканчивая более сложными проектами типа cassandra).

Добавим репозиторий opentelemetry demo и поставим в кластер:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install my-otel-demo open-telemetry/opentelemetry-demo

Поставим kubediagrams прямо из github и запустим через python virtualenv:

git clone https://github.com/philippemerle/KubeDiagrams.git
python3 -m venv myenv; source myenv/bin/activate
pip install PyYAML diagrams

И получим ошибку 😟

Понадобилось доустановить graphviz для создания картинок. На macos ставится так:

brew install graphviz

Результат для opentelemetry demo:

kubectl get all -o yaml | ./KubeDiagrams/bin/kube-diagrams -o /tmp/otel.png -

Warning: картинка огромная, потому что компонентов много, и все они развернуты в одном namespace.

🐈 Дайджест материалов июня 🐈

Сегодня последний день месяца, а это значит, что пришло время подвести итоги и собрать в одном посте все полезные материалы.

➡️ Оптимизация запуска тяжелых образов для ML

➡️ Разгружаем etcd

➡️ Cloud native практики, которые постоянно нарушаются

➡️ Что почитать, чтобы отвлечься от кластеров

➡️ Атаки на инфраструктуру через забытые ресурсы

➡️ Заметки про публичные облака, или что можно узнать, если внимательно читать документацию

➡️ Неожиданные ошибки в k8s, или imagePullPolicy, который вас обманывал

➡️ Зоны ответственности kubelet

➡️ BARE METAL PROVISIONING

➡️ Архитектурные диаграммы для вашего k8s

Видеоматериалы:

🟣 Rancher в продакшен: вебинар с Вячеславом Федосеевым
→ YouTube
→ VK Видео
→ Rutube

🟣 Kubernetes — всё. Что вместо него? Свежий выпуск подкаста {между скобок}
→ YouTube

В комментариях под этим постом можно написать, какую тему вы хотели бы разобрать в июле ⬇️

Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов

👉 воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.

Что будет на воркшопе:

Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала.

Практика:

🔹 Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
🔹 Создание и отладка IaC (Kubernetes YAML, Ansible) с помощью AI-ассистентов: выявление и исправление ошибок;
🔹 Генерация понятной и структурированной документации к проектам с помощью AI;
🔹 Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.

А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.

Когда: в субботу, 5 июля

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

Когда docker-compose подводит

Привет, это Маркус. Сегодня замещаю своего человека и хочу рассказать вам, почему переход на k8s стоит того.

Вы могли видеть такие проекты: один docker-compose отвечает за всю инфраструктуру сервиса:

🟣Контейнер с приложением
🟣БД
🟣Кеш

Таких сервисов может быть несколько, они еще будут взаимодействовать друг с другом путем открытия внешних портов на серверах (и хорошо, если это будет внутренняя сеть облака, а не машины с публичными IP без правильно настроенного файрвола). Каждому из них нужны зависимости в виде БД, кешей, очередей и т.д.

Все это деплоится по ssh (или через gitlab runner с executor=shell, где runner крутится на той же машине, что и сервис).

И работает до поры, до времени.

Что может пойти не так?

➡️ Падение ноды

Сервер с проектом падает. Что происходит с вашим сервисом, БД и кешем? Правильно, они все недоступны. docker-compose в этой ситуации бесполезен. Он не умеет автоматически перезапускать контейнеры на другой ноде, обеспечивая непрерывность работы.

Особо дотошные скажут, что есть же docker swarm, и да, он может закрыть часть потребностей с точки зрения отказоустойчивости, но есть один нюанс: продукт больше активно не поддерживается и иногда получает багфиксы. Если вы супер дотошны, то можно сказать, что он уже закрывает все потребности и просто работает, так что там нечего развивать. И в разрезе небольших проектов это может быть валидно.

➡️ Обновления без даунтайма

Пришло время обновить ваш сервис. Используя docker-compose, вам придется остановить контейнер, обновить образ и запустить его снова. Это приводит к неизбежному даунтайму, даже если он длится всего 5 секунд.

➡️ Управление секретами

API-ключи, токены, etc. в любом случае окажутся на сервере, например, в виде .env файла, который хорошие мальчики не коммитят в git, и хранят в защищенных переменных в gitlab. И здесь возникает другая проблема: сложно выполнить аудит, кто к чему имеет доступ (в отличие от хорошо подготовленного vault).

docker-compose не виноват. Нужна смена парадигмы. Переход от серверов вида pets к серверам вида cattle.

При чем тут животные, можно прочитать в статье.

docker-compose отлично справляется с задачей локального запуска, но совершенно не подходит для оркестрации (да и деплой через gitlab runner c executor=shell, прямо скажем, тоже костыль).

Какие проблемы закрывает k8s

➡️ Self-healing
Если нода выходит из строя, k8s автоматически перезапускает ваши контейнеры на живых нодах, обеспечивая доступность сервиса.

➡️ Обновления без даунтайма
k8s поддерживает стратегии деплоя, такие как rolling update, позволяющие обновлять приложения постепенно, без прерывания обслуживания трафика. Приложение должно правильно завершаться, в соответствии с The Twelve-Factor App, но это уже такое же базовое требование, как и то, что любой сервис должен корректно работать в docker.

➡️ Управление секретами
k8s предоставляет встроенные механизмы для безопасного хранения и управления секретами, но будем честны, по-настоящему безопасно процесс работы с секретами можно выстроить через vault, полностью обходя механизм секретов в k8s (если есть такая необходимость)

➡️ Масштабирование
k8s позволяет автоматически масштабировать ваши приложения в зависимости от нагрузки (если настроите).

🐈 Переход на k8s — это инвестиция в стабильность и надежность, которая окупается не сразу.

Порог вхождения может показаться высоким, но результаты часто стоят того. k8s позволит вам сосредоточиться на разработке и развитии продукта, не беспокоясь о рутинных задачах по управлению инфраструктурой:

🔷 Перенести сервис на другую ноду
🔷 Добавить больше реплик для обслуживания выросшей нагрузки (но БД он вам магическим образом не отскейлит)
🔷 Легко и непринужденно ставить мониторинг
🔷 Запрещать запускать небезопасные вещи
🔷 Выполнять аудит изменений в кластере
И многое. многое другое.

Можно встретить мнения, что k8s сделал для оркестрации то, что сделал в свое время linux для серверов. k8s — это новая ОС, но не в классическом понимании операционных систем.

Карго-культ в инфраструктуре, или когда «делай как Google» создает проблемы

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

Итог: постоянные потери коннектов, потому что был настроен HPA, который новому сервису как собаке пятая нога, потому что в нормальный graceful shutdown он не умеет, клиенты плохо умеют ретраить и все остальное, что мы так любим (нет) в плохо написанных проектах.

Другой пример: у нас есть SRE, они пусть и чинят.

Разработчик сломал прод, SRE починил, и так несколько раз. Разработчики не интересуются метриками и доступностью. Идея shared ownership умерла, не успев зародиться. SRE занимаются тушением пожаров, а не внедряют лучшие практики и не доносят до разработчиков, как надо делать.

SRE курильщика — это когда создается пожарная команда, а не культура отказоустойчивости с SLO, error budgets, capacity planning, postmortems и прочими умными словами.

➡️ Карго-культ — это не только про инженеров, копирующих без понимания конфигурации, решения, архитектуры. Это про любой уровень, где берут нечто без понимания, как оно работает.

Чем выше уровень ответственности, тем дороже обходятся ошибки. Архитектурные решения, принятые на веру, могут привести к инцидентам спустя месяцы после внедрения.

🐈 Хотите как у Google? Сначала разберитесь, действительно ли у SRE занимаются тем, что описано в книгах, а не играют роль спасательного круга для разработчиков.

🐈 Хотите как у Cloudflare? Окей, тогда и инциденты разбирайте, как у Cloudflare — публично, в деталях и с обозначением всех причин, приведших к даунтайму.

История одного факапа, или как kubectl edit deployment стоил компании много денег

🟠 Контекст: компания разрабатывает платформу для онлайн-платежей. Сервис Transaction Processor (TP) отвечает за обработку транзакций и напрямую влияет на выручку компании. Любые перебои в его работе приводят к ощутимым финансовым потерям.

🟠 Ситуация: обкатали новый релиз сервиса в проде. Все сделали по лучшим практикам: канарейки, авто откаты в случае ошибок на метриках, обратная совместимость между актуальной и предыдущей версией сервиса.

🟠 Инцидент: после деплоя новой версии сервиса на 100% трафика, постепенно, через несколько часов, стало понятно, что есть проблема с утечкой памяти.

Команда, решив временно исправить ситуацию, вручную отредактировала deployment TP в проде, используя kubectl edit deployment tp-deployment.

Отдельный вопрос, почему у разработчиков в проде есть такой уровень доступа в кластер, но это out of scope.

🟠 Все расслабились: пока разбирались с утечкой памяти и не выкатывали новые версии, пришла пятница. Старая версия сервиса уже день работала в проде без проблем, без утечек памяти и не создавала никаких причин что-то делать. По метрикам все было ровно.

🟠 Что было дальше: на выходных команда, отвечающая за обслуживание кластера, утром, во время минимального трафика решила начать обновление некоторых зависимостей с постепенной перевыкаткой сервисов, потому что в сайдкар контейнерах были обнаружены критические ошибки, из-за которых можно было провести атаку типа DoS (не путать с DDoS).

В качестве сайдкара был envoy или nginx, и весь входящий в под трафик проходил через него, а так же весь исходящий трафик. Все это в целях аудита, мониторинга, управления сетевой безопасностью внутри кластера и так далее. А сами сайдкары добавлялись через mutation admission webhook, так что команды разработки в это никогда не влезали и не думали о сайдкарах, пока все успешно работало.

🟠 Последствия: передеплой TP привел к выкатке новой версии (потому что в main ветке именно она), перезаписав версию во вручную отредактированном deployment.

Работы прошли беспроблемно и все ушли отдыхать.

По итогу через несколько часов все поды начали почти синхронно падать по out of memory, трафик начинал идти на оставшиеся поды, которые перестали справляться с нагрузкой. k8s любезно перезапускал упавшие поды, которые тут же начинали получать трафик, который они неспособны обработать, и по liveness пробе начинали рестартовать, и так в цикле.

➡️ Что пошло не так?

Основная причина инцидента — configuration drift. kubectl edit deployment создал разницу между задекларированным состоянием в git и реальным состоянием кластера.

Нарушение декларативного подхода: k8s спроектирован для работы с декларативным подходом. Мы описываем желаемое состояние системы в манифестах, и Kubernetes следит за тем, чтобы реальное состояние соответствовало задекларированному.

➡️ Какие выводы можно (и нужно) сделать?

🟠 Infrastructure as code: если состояние инфраструктуры отличается от сохраненного в git - оно может стрельнуть в любой момент.
🟠 GitOps: рассмотрите возможность использования инструментов GitOps (например, ArgoCD) для автоматической синхронизации конфигурации кластера с репозиторием. Это гарантирует, что кластер всегда находится в желаемом состоянии, задекларированном в Git. Даже если кто-то имеет права лезть в кластер и менять конфигурацию.
🟠 Обучение: убедитесь, что все члены команды понимают принципы работы k8s, декларативный подход и важность IaC.

Эта история — урок о том, что k8s требует понимания. Быстрое решение с помощью kubectl edit deployment может быть легким (при наличии прав в кластере), но последствия могут быть серьезными. Инвестируйте в автоматизацию, инфраструктуру как код и обучение команды. Это окупится с лихвой, предотвращая дорогостоящие инциденты и обеспечивая стабильную работу. Конечно же, если все это правильно приготовите 🙂

Уровни зрелости инженера

k8s уже давно стал отдельным миром со своими правилами игры. И, как и в любой профессии, уровень компетенций специалистов может очень сильно различаться:

🐈 Kubectl-инженер
- Знает kubectl apply, может развернуть Ingress, Service, Deployment, добавить базовый мониторинг (Prometheus + Grafana).
- Боится сложных helm-чартов и kustomize. ImagePullBackoff — один из кейсов, которые может решить самостоятельно без поиска в документации.

Основная цель: кластер жив, сервисы работают.
Точки роста: изучать helm/kustomize, углубляться в устройство кластера с целью повышения уровня понимания работы процессов внутри.

🐈 Инженер-пожарный
- Активно расследует инциденты: kubectl logs/describe, понимает работу controller manager, scheduler, может раскопать детали работы CSI и связанных с ними проблем.
- Внедряет GitOps подходы, улучшает observability.
- Боится звонков от мониторинга ночью.

Основная цель: минимизация простоев, повышение стабильности.
Точки роста: архитектура k8s, написание операторов, проектирование отказоустойчивой и безопасной инфраструктуры.

🐈 Платформенный инженер
- Управляет десятками кластеров через GitOps, автоматизирует развертывания/обновления с помощью helm/kustomize/terraform.
- Понимает SLA, проектирует платформу с учетом безопасности , стоимости и бизнес-требований.
- Боится неправильного выбора технологий, который ему аукнется через год.

Основная цель: скрыть сложность k8s за удобными абстракциями для разработчиков.
Точки роста: построение self healing системы, где все работает для того, чтобы поддерживать систему в рабочем состоянии, пока инженер спит.

🐈 k8s-архитектор
- Разрабатывает multi-cluster архитектуры с federation, внедряет service mesh для управления трафиком и безопасностью (и не внедряет там, где это не нужно).
- Оптимизирует CI/CD пайплайны с использованием GitOps, интегрирует платформу с облачными провайдерами и on-prem решениями.
- Строит безопасную систему с самого начала, минимизируя поверхность атаки путем внедрения distroless-контейнеров и контроля supply chain через инструменты сканирования на уязвимости.
- Ничего не боится, готов ответить за каждое принятое решение. Опасается высокой сложности создаваемых систем, скрытой за удобными абстракциями, потому что больше никто в компании не понимает, как работает вся система от и до.

Основная цель: баланс между требованиями бизнеса и стоимостью/сложностью полученной инфраструктуры.
Точки роста: повышение лидерских качеств, донесение важности принимаемых решений до бизнеса.

➡️ k8s — всего пять бинарей. Довольно старая шутка, которая не раскрывает основного. Вокруг этих бинарей строятся настолько витиеватые системы, что в случае отказа каких-то компонентов можно поплатиться очень долгим поиском root cause, теряя драгоценную отказоустойчивость, потому что от багов в коде и от человеческих ошибок никто не защищен.

Независимо от вашего текущего уровня, помните, что изучение k8s — это непрерывный процесс.

Reconciliation loop и informers

Догадайтесь с одного раза, как в k8s декларативные конфигурации материализуются в изменения состояния объектов в кластере. Конечно же за это отвечает reconciliation loop.

Начнем с простого.

🟠 ReplicaSet заявляет, что нужно 10 реплик пода. То, что ReplicaSet создается опосредованно через Deployment, оставляем за скобками.
Это наше Desired State.
🟠 ReplicaSet controller проверяет через k8s API, есть ли созданные поды.
Это Current State.
🟠 ReplicaSet controller отправляет запросы в k8s API на создание подов. И этот процесс никогда не завершается.
Это и есть Reconciliation loop.
🟠 Как только все поды созданы, постоянно происходит отслеживание состояния объектов и если один из подов пропадает по любым причинам (OOM, eviction, etc.) ReplicaSet controller выполнит запрос на создание нового пода.
Дальше там работает scheduler, выбирая на какую ноду назначить новый пока еще бесхозный под, но это уже совсем другая история.

Summary

➡️ Desired State: Вы описываете желаемое состояние. Например, кол-во реплик в deployment.

➡️ Current State: Ответственный контроллер постоянно следит за состоянием и если оно отклоняется от желаемого, выполняет требуемые действия.

Почему это важно знать, кроме как для собеседования?

Понимание Reconciliation Loop - это ключ к пониманию принципов работы всех компонентов k8s. Зная это, вы:

🟠 Лучше понимаете логи компонентов. Когда что-то идет не так, вы сможете быстрее понять, почему и как это исправить.
🟠 Умеете кастомизировать k8s. Вы сможете писать собственные операторы, расширяя функциональность k8s под свои нужды.

Как это работает?

ReplicaSet controller использует informers, чтобы отслеживать состояние объектов в кластере. Код контроллера здесь.

podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
    ...
    DeleteFunc: func(obj interface{}) {
      rsc.deletePod(logger, obj)
    },
  })

Рассмотрим на примере удаления пода.

Почему под может быть удален? Кто-то сказал kubectl delete pod pod-name, произошел eviction пода из-за недостатка ресурсов на ноде, под был завершен по out of memory и так далее.

ReplicaSet controller это увидел через informer и выполнил логику, создающую под (пока без назначения на ноду, потому что это не его забота).

Внутри контроллера есть очередь, которую он обрабатывает, что в итоге приводит к созданию пода. Здесь выполняется процесс синхронизации.

// syncReplicaSet will sync the ReplicaSet with the given key if it has had its expectations fulfilled,
// meaning it did not expect to see any more of its pods created or deleted. This function is not meant to be
// invoked concurrently with the same key.
func (rsc *ReplicaSetController) syncReplicaSet(ctx context.Context, key string) error {

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

err := rsc.podControl.CreatePods(ctx, rs.Namespace, &rs.Spec.Template, rs, metav1.NewControllerRef(rs, rsc.GroupVersionKind))

приводит к простому API вызову к k8s api, а там уже дальше scheduler будет разбираться, что делать с этим подом.

А как работают informers и зачем они нужны, чтобы не нагружать и без того загруженное k8s API, можно почитать, например, здесь.

Если кратко, процесс работы informer следующий:

🟠 List: информер запрашивает полный список ресурсов и сохраняет его в локальный кеш.

🟠 Watch: устанавливается постоянное соединение для получения изменений от API.

🟠 Reflector: получает события и кладёт их в очередь.

🟠 Обработка: информер читает из очереди и обновляет кеш.

🟠 EventHandlers: срабатывают обработчики при изменении кеша.

🟠 Восстановление: при сбое соединения повторяется list и watch.

🟠 Плюсы: меньше нагрузки на API и проще работа с событиями, без необходимости реализации этих деталей каждый раз при работе с k8s API.

Прикладываю схему с объяснением ⬇️

Оттенки сложности k8s

k8s как айсберг. На поверхности — деплойменты и сервисы. А в глубине такие бездны, что Ктулху и не снилось. Фхтагн!

🔷 Affinity & Anti-Affinity: Вы думаете, что раскидали свои поды по разным нодам? Если этого не описать явно, таких гарантий нет.

🔷 PodDisruptionBudget: Защищает сервисы от «внезапных» отключений при обновлениях нод. Звучит классно, пока PDB не начнет конфликтовать с HPA.

🔷 Resource Quotas & Limit Ranges: Защищают кластер от жадных разработчиков. Но! Если вы не продумали дефолтные значения, готовьтесь к жалобам «у меня ничего не работает!». А еще квоты могут конфликтовать с HPA, создавая проблемные ситуации.

🔷 ImagePullBackOff: kubelet просит container runtime скачать image, но по какой-то причине это не работает. Причин вагон: неправильный тег, приватный репозиторий, а секрет забыли добавить, лимиты на Docker Hub.

🔷 Отсутствие алертинга: мое любимое. Узнать, что поды попали в CrashLoopBackoff, можно только посмотрев в дашборд (если он есть), а алерты отсутствуют или сыпятся на email, который никто не смотрит 🙂 

Но это ладно, пользователи придут и сообщат, что что-то не работает, а вот узнать спустя месяц, что пара нод кластера not ready, но электричество успешно потребляют, не очень интересно. Не делайте так, вкладывайтесь в конфигурацию алертинга и в целом в мониторинг.

k8s — система сложная, но многие типовые ошибки уже давно решены и важно уметь их применить в своей инфраструктуре.

А с какими из перечисленных проблем вы сталкивались?

Неочевидные проблемы Kubernetes, которые вы могли пропустить

➡️ обсудим послезавтра на бесплатном вебинаре.

Специальный гость: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех

Вместе с Русланом мы поговорим про типовые ошибки, которые можно допустить при деплое сервисов в кластер, от некорректной настройки лимитов ресурсов, до более сложных кейсов с admission webhooks.

🐈 В конце вебинара — рекомендации по настройке вашего кластера и приложений для безотказной работы.

Когда: 16 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.