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

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 и получить востребованные скиллы.

Сколько зарабатывает SRE в Нидерландах?

Рассказал на интервью для пилотного выпуска спецпроекта «DevOps про деньги».

Ведущий: Всеволод Севостьянов, Staff engineer в Lokalise.

Что обсуждали:
➡️ Какие навыки нужны SRE в бигтехе?
➡️ Требования в вакансии vs реальные рабочие задачи: есть ли разница?
➡️ Главный вопрос: сколько получает SRE в Амстердаме, и за что столько платят?

Посмотреть можно тут:
🟠YouTube
🟠Rutube
🟠VK Видео

А всех, кто после просмотра захочет двигаться в направлении подобных задач (и подобных зарплат, конечно же) — приглашаю на «Kubernetes База». Старт 4 августа!

Отзывы студентов

Принес вам отзыв на курс «Kubernetes База» от сотрудника Т-Банка:

От pod'а до prod'a за 1.5 месяца

Только что закончил обучение на курсе от Slurm. Полтора месяца и я освоил навыки работы в Kubernetes и даже прошёл сертификацию. Экзамен для которой длился аж 6 часов.

Зачем мне к8s?

Моей главной целью на курсе было научиться деплоить приложение в кластер, чтобы затем настроить СІ/СD pipeline, который бы сам поднимал стенд с новой версией приложения, запускал имеющиеся автотесты и принимал решение о деплойменте приложения.

Стоит ли тебе его проходить?

В курсе разобрано множество тем k8s, начиная с основных компонентов и устройства кластера, заканчивая непрерывным деплойментом приложения с помощью Gitlab-Cl и helm- чартов.

Для каждой темы курса предлагается выполнить практическое задание на реальном к8ѕ кластере (battery included), с автоматической проверкой решения, что в свою очередь помогает быстрее закрепить знания на практике. (Отмечу, что опыт решения этих задач уже пригодился мне в реальных задачах).

На курсе есть возможность обратиться в тех-поддержку slurm, если возникают сложности с решением заданий. (Мне отвечали в течение 5 минут.) Дополнительно, для потока был создан tg-канал, где куратор и ведущие курса, а иногда студенты потока помогают с решением возникших вопросов.

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

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

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

🔷 Старт ближайшего потока «Kubernetes База» уже в понедельник. Подробности — на сайте.

*Орфография и пунктуация автора отзыва сохранены.

Kubernetes База: старт уже в понедельник!

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

Что внутри:

🟣 6 недель обучения, 63 часа практики и 23 часа теории
🟣 73% программы — работа со стендами для отработки практических навыков
🟣 5 Q&A-встреч со спикерами курса
🟣 Сертификация по итогу обучения, закрепляющая весь пройденный материал

Присоединяйтесь к потоку, чтобы уже в сентябре уметь работать k8s, кластерами и CI/CD.

➡️ Подробности — на странице курса.

Kubernetes База: поток стартовал!

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

Ближайшие 6 недель будем разбираться с основами работы с k8s, базовыми абстракциями кластера, запуском приложений в кластере и принципами их работы.

➡️ Сегодня еще можно присоединиться к потоку. Ссылка для опоздавших: https://to.slurm.io/4EbSIQ

А для тех, кто хочет сразу прокачать свои навыки до продвинутого уровня и получить полный контроль над своей контейнерной инфраструктурой, мы с командой подготовили комплект:

Kubernetes База (поток) + Kubernetes Мега (видеокурс) со скидкой 20%.

Подробности — на сайте.