Когда 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 мск

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

Liveness probe of death

У вас есть приложение, которое активно использует БД. Liveness probe проверяет коннект к БД каждую секунду.

Уже поняли, что не так?

Кажется логичным: если приложение не может подключиться к БД, значит, оно не работает. Разберемся, почему это плохая идея.

Что произойдет, если БД отвалится на 3+ секунд, а ваша liveness probe говорит, что после 3-х проверок нужно под рестартовать?

🟠Получаем рестарты подов. Приложение могло бы пережить недоступность БД, но вместо этого начало рестартовать, усугубляя и без того проблемную ситуацию.
🟠 Увеличение нагрузки на БД. После рестарта подов они начинают ломиться в БД, создавая новые коннекты.

Особо внимательные читатели скажут, что и без рестарта подов можно получить такую ситуацию, и в каких-то ситуациях это может быть так. Но если у нас используется промежуточный прокси (например, pgbouncer стоит перед PostgreSQL), эти коннекты могут и не разорваться, если под не рестартовал. Тут все зависит от настроек connection pooling как в приложении, так и в pgbouncer.

🟠 Часть приложения может работать без БД, потому что могут использоваться кеши. Можно отдавать fallback данные, можно имплементировать gracefull degradatation и прочие умные слова.

➡️ Summary

Проверять доступность любой зависимости вашего сервиса в корне неправильный подход, потому что сервис за доступность зависимости не отвечает. Но, как всегда, it depends. «Неправильный» liveness probe может «чинить» ошибки в плохо написанных приложениях путем их рестарта. Классический пример — меряем потребление памяти своего процесса и отвечаем в liveness, что мы недоступны и пора бы рестартануть, потому что не можем найти утечку памяти.

Более детально можно прочитать в статье. А кто отвечает за запуск probes? Конечно же kubelet. Разбираться можно начать отсюда, если хочется увидеть работу изнутри. За что еще отвечает kubelet можно посмотреть в недавнем посте.

А завтра на вебинаре мы разберем еще более коварные ошибки и неочевидные проблемы k8s, которые вы могли пропустить.

Ну и напоследок предлагаю посмотреть, как реплики сервиса Маркус обслуживают ваши потребности в котиках ⬇️

Привет! Это Маркус.

Сурово смотрю на тех, кто еще не зарегистрировался на вебинар по неочевидным проблемам k8s. Он, кстати, уже через час.

➡️ Специальный гость: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех
Ну и я, возможно, тоже приду.

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

Ссылки, как всегда, придут в бота. Подключайтесь! 🐈

Гранты Слёрма добрались и до нас с вами 🔥

Объявляю конкурс грантов на летний поток курса «Kubernetes Мега», который стартует 28 июля.

🐈 1 место — скидка 100%
🐈 2 места — скидка 70%
🐈 3 места — скидка 50%

Условия участия:
➡️ Быть подписанным на мой канал
➡️ Заполнить анкету участника и пройти тестирование до 21 июля — по ссылке

Итоги мы с Маркусом подведем 23 июля. Удачи!

GitOps: не все так просто

Вы наверняка слышали что-то вроде «просто поставь argocd». И все, кажется, что все проблемы раскатки изменений в кластер решены, у вас есть больше времени пить кофе, смотря на автоматическую синхронизацию изменений.

Но все не так однозначно :)

➡️ Начнем с плюсов:

🟠 Единая точка правды: все изменения можно ревьювить и откатывать при необходимости.

🟠 Иммутабельность и воспроизводимость: в идеально выстроенной системе накатить все приложения в кластер с нуля не составит больших проблем. Подняли кластер, накатили argocd, применили базовые настройки для связки с git → argocd сделает все остальное.

🟠 Избегаем configuration drift: любые ручные изменения в кластере автоматически откатываются. Если у вас разработчики могут править задеплоенное в кластере в обход репозиториев, у меня для вас не очень хорошие новости.

➡️ Минусы:

🟣 Управление секретами: секреты не защищены — хранение в git строгое no-no (про то, как хранить секреты безопасно, подробно говорим на «Kubernetes Мега» — уделили этому целый модуль).

🟣 Сложная организация репозиториев: с ростом числа сервисов и окружений резко увеличивается сложность структуры репозиториев. Монорепа или множество инфра-репозиториев — каждая компания решает по-своему.

🟣 Конфликты: при частых выкатках нередки конфликты pull request-ов при одновременном обновлении конфигураций нескольких сервисов. Сломать при неправильном разрешении конфликтов инфраструктуру становится так же просто, как сделать git commit.

🟣 Ограниченная валидация: без дополнительных инструментов легко получить конфигурации с ошибками, начиная от неправильных отступов в yaml, заканчивая неприменяемыми манифестами, потому что ваш kyverno запретил запрашивать 100 cpu (упс, хотели же 10 написать).

🟣 Вопросы масштабирования: при больших масштабах (десятки–сотни кластеров, разные среды) нагрузка на devops/sre/infra/k8s инженеров (или как у вас называются люди, отвечающие за инфру) резко увеличивается из-за необходимости поддерживать множество раздельных конфигураций, не обязательно совместимых друг с другом.

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

➡️ Cложные кейсы использования GitOps

🟠 Мультикластерное управление и гибридные инфраструктуры: управление множеством кластеров в разных облаках требует сложных решений по структурированию репозиториев, разграничения доступа и автоматизации disaster recovery.

🟠 Разграничение прав и политики безопасности: при большом количестве команд и сервисов приходится тщательно разделять доступы к файлам конфигураций, а для policy-as-code внедрять дополнительные инструменты валидации.

🟠 Промежуточные среды (stage, production): применение изменений между окружениями может стать нетривиальным из-за различий в настройках и необходимости поддерживать множество веток с разными настройками.
Применили изменения в stage, а в production применили немного отличающиеся? Привет, различие окружений.

🟠 Масштабируемость CI/CD в монорепозиториях: при большом количестве сервисов и команд нужно детально проработать логику автоматических запусков пайплайнов и раздельного деплоя, чтобы не было конфликтов и чрезмерной загрузки на раннеры, создающей очередь деплоя на часы вперед.

➡️ Важные нюансы

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

🟣 Дополнительные инструменты: необходима интеграция secret провайдеров (vault, но не обязательно, но это и без gitops нужно делать), внешних валидаторов (например, OPA или kyverno), управление множеством pipeline-ов (например, через merge train)

GitOps отлично подходит для k8s как инструмент стандартизации, аудита и автоматизации изменений, но требует грамотной архитектуры pipeline-ов, дисциплины разработки и интеграции дополнительных средств безопасности, мониторинга и валидации.

k8s обучение

Привет руководителям, менеджерам всех уровней и им сочувствующим! Сегодня хочу обсудить с вами, как понять, что команде пора на обучение.

➡️ Симптомы проблем при работе с k8s:

- Инженеры часто копаются в StackOverflow/ChatGPT/Google, чтобы понять, как работает или как настроить какую-то абстракцию в k8s
- Фиксят проблемы методом научного тыка, опираясь на рандомные статьи
- Не уверены, как проверить корректность применяемых изменений в инфраструктуре

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

➡️ Почему это важно?

- Вместо чтения блогов и общения с ChatGPT, ваш инженер получает структурированные знания по Kubernetes от практиков
- Вместо страха сломать прод — уверенность во внесении изменений в инфраструктуру
- Вместо вопросов, ответы на которые не может проверить, опыт инженеров, внедряющих k8s много лет

➡️ Важно!

1. Обучение должно быть целевым.

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

2. Время на обучение желательно выделять из рабочих часов.

Мало кто захочет учиться вечером или в выходные, так что вопрос об эффективности остается открытым.

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

В итоге, обученные инженеры — это не просто знающие инженеры. Это люди, которые меньше косячат, быстрее внедряют, и, главное, горят желанием делать крутые вещи.

А как вы оцениваете потребность в обучении у ваших сотрудников?

Сегодня хочу познакомить вас с одним из наших студентов

🐈 Павел Елецков, руководитель направления Kubernetes компании «СБЕР Спасибо», проходил обучение на курсе «Kubernetes Мега» и поделился с нами подробным видеоотзывом. В нем он рассказывает, кому подойдет курс, как организован процесс обучения, плюсы, минусы и чего ему не хватило внутри в программы.

Где посмотреть:

➡️ YouTube
➡️ VK Видео

Старт следующего потока уже 28 июля. Узнать подробности и занять место — по ссылке.

Итоги конкурса грантов 💥

В тестировании приняли участие 108 человек. Выбрать было сложно — мы с командой ориентировались на мотивацию каждого из вас и правильность ответов в техническом скрининге.

Список победителей:

🐈 Скидка 100%
@Alex_Gureev

🐈 Скидка 70%
@qwaldo
@glycosupport

🐈 Скидка 50%
@Ms1blast
@justaleksy
@samkilanoff

Поздравляю! 🥳

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

Как перестать бояться оркестрации и полюбить k8s

Задумываетесь о нырянии с головой в бездны k8s? 28 июля стартует новый поток курса «Kubernetes Мега», где мы с коллегами разбираем k8s по полочкам и учим не просто деплоить ямлы, а рассказываем, как оно работает внутри.

➡️ «Kubernetes Мега» может быть вашим выбором, если:

🔷 Вы устали изучать тонны yaml. Курс погружает в архитектуру k8s, раскрывая внутренние механизмы работы Control Plane, kubelet и других компонентов.

🔷 Вам нужно глубокое понимание для поддержки сложных инсталляций. Качественный курс часто является отличным способом систематизировать знания и подготовиться к более сложным и интересным задачам.

🔷 В вашей команде не хватает экспертов по Kubernetes, и вы хотите поднять общий уровень. Коллективное обучение может быть отличным способом выровнять знания в команде ваших k8s инженеров.

➡️ «Kubernetes Мега» не подойдет вам, если:

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

🔷 Вы ищете готовые рецепты и «серебряные пули». k8s — сложная платформа, и универсальных решений не существует. Курс научит вас самостоятельно выбирать подходящие решения в зависимости от контекста, а не просто копировать готовые конфиги.

🔷 У вас нет базовых знаний о контейнеризации и DevOps-практиках. k8s — это не для новичков. Перед курсом стоит изучить основы Docker, Linux и попрактиковаться с базовыми инсталляциями k8s. Для этого можно пройти k8s база.

На днях делился с вами подробным отзывом от выпускника курса Павла Елецкова, руководителя направления Kubernetes компании «СБЕР Спасибо». Дублирую ссылки для тех, кто пропустил, чтобы вы могли получить представление о курсе не только со стороны спикера, но и со стороны студента:

➡️ YouTube
➡️ VK Видео

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

Kubernetes Мега: 3 дня до старта

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

После курса вы сможете:

🔷 Привести «зоопарк» инструментов к управляемой экосистеме, повысить отказоустойчивость продукта и автоматизировать развёртывания

🔷 Использовать все возможности k8s при проектировании платформенных решений и уверенно переводить продукты компании на k8s

🔷 Сдать сертификацию и получить свидетельство установленного образца, которое можно прикрепить к резюме

Первым трем, кто пройдет курс на 80% и сдаст сертификацию, дарим эксклюзивную сессию 1-1 с Павлом Елецковым, Teamlead k8s в СберСпасибо и ментором курса.

На ней вы сможете:
➡️ Разобрать свой рабочий кейс и получить прикладные советы
➡️ Прокачать резюме для топовых вакансий
➡️ Пройти mock-интервью, чтобы быть готовым к реальным вызовам

Дополнительные модули для всех, кто прйдет курс на 80% и сдаст сертификацию к последней встрече:

🐈 Мониторинг и трассировка сервисов с Istio
🐈 Безопасность в Kubernetes с Istio
🐈 Canary and A/B Deployments

Узнать подробности и занять место на потоке — по ссылке. Подключайтесь, прокачать свои навыки и вырасти в должности и зарплате!

База или мега? Всё сразу, и побольше!

Замахнулись на k8s? Отлично, их есть у нас! Но не спешите, тут нужен систематический подход.

Есть два стула пути:

🔷 Для тех, кто в теме

Если вы на k8s уже собаку съели, то вам прямая дорога на «Kubernetes Мега». Поток стартует уже сегодня, и присоединиться к нему можно до конца недели. Там такое покажут, что ваши кластера сами себя настраивать будут! Разберете внутренности scheduler, научитесь строить операторы одной левой и многое другое. Готовьтесь, будет хардкор, но оно того стоит. А детальнее про то, для кого мега, я уже рассказывал в этом посте.

🔷 Для тех, кто начинает свой путь в мир k8s

Если k8s для вас — это что-то страшное и непонятное, не паникуйте. Есть «Kubernetes База». Поток стартует 4 августа. Там вас за ручку проведут по основам: какие абстракции есть, как все это применяется, как деплоится и раскатывается в кластер, как мониторится, и, конечно же, как начать — раскатать ваш первый кластер и заботиться о нем, как я о Маркусе, чтобы не нашкодил.

🐈 На самом деле, есть еще третий путь — для тех, кто хочет сразу на двух стульях усидеть. Это комплект из потока «Kubernetes База» и видеокурса «Kubernetes Мега». С ним вы сможете прокачать свои навыки с нуля до уровня «Бог k8s» — со скидкой 20%.

Подробности — по ссылке.

И совет напоследок: k8s — это не rocket science, но и не игра. Не бойтесь копаться в YAML, экспериментировать, ломать и чинить (только не в проде, пожалуйста). Только так можно по-настоящему понять, как все работает.

k8s база: рассказываем то, что нельзя нагуглить

«Kubernetes База» — это не просто k8s для начинающих инженеров, которые решили связать свой профессиональный путь с эксплуатацией k8s.

Это путь от базовых понятий до работающего приложения, развернутого с учетом best practices. Мы не просто крутим kubectl apply, а выстраиваем понимание концепций, а не конкретных решений, чтобы применять на своих проектах с учётом особенностей проектов.

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

➡️ Вместо перечисления компонентов — погружение в то, как они взаимодействуют. Не «Node состоит из kubelet, kube-proxy, etc.», а «Почему kubelet нужен, чтобы Pod вообще запустился, и как kube-proxy разруливает трафик до этих Pod'ов, даже если их IP меняются».

➡️ Не просто «Deployment управляет Pod'ами», а «Как Deployment использует ReplicaSet для rolling updates?». Понимание StatefulSet'ов и DaemonSet'ов для специфических workload'ов.

Также обязательно рассмотрим, как раскатывать свой кластер на bare metal, и что нам это будет стоить с точки зрения дальнейшей поддержки.

Само собой, ни один production кластер не обойдется без выстроенных процессов доставки приложений и надежного мониторинга. Под эти темы выделены отдельные модули про CI/CD и про, что бы вы думали? Конечно, мониторинг.

А еще на курсе есть 5 Q&A сессий со спикерами, где вы сможете разобраться ваши кейсы от экспертов, которые крутят k8s уже много лет, и повидали всякого, о чем в приличном обществе не принято рассказывать, потому что темы строго 18+, и иногда такое увидишь, что волосы дыбом встают, как это вообще еще не сломалось. А всего лишь надо было следовать лучшим практикам и соблюдать требования, указанные в документации.

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

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