Как изучать k8s правильно?

И главное — зачем?

Существует хитрая ловушка, выбраться из которой бывает сложно: опыта с K8s вроде бы хватает, но хочется большего. Нужно использовать актуальные инструменты, которые сейчас на острие CNCF, просто потому что именно этот тулинг применяется в компаниях. И даже если конкретное решение не близко по духу, так или иначе можно с ним столкнуться в работе. А у всего, как известно, есть своя кривая обучения, свои best practices и прочие радости.

Все это сопряжено с кучей сложностей:

➡️ Чтобы найти крутой проект, где можно развернуться, нужно неплохо знать K8s.
➡️ Чтобы неплохо знать K8s, нужно найти хороший проект, где можно практиковаться.

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

k8s развивается быстро, так что приходится пробовать и изучать что нового привносят, чтобы потом блеснуть знаниями на собеседовании в проект мечты. Но и делать это нужно с толком, потому что сегодня добавили фичу X, а через 2 года от нее отказались, а вы в проекте на нее уже завязались. Упс.

В этот момент java-разработчики из банковской сферы, которые до сих пор сидят на Java 8 (привет из 2014-го!), смотрят на вас с сочувствием. И в чем-то они правы. Инструмент должен решать задачи. А внедрение всего этого «нового» зачастую превращается в адскую бюрократию, полную проверок безопасности и рисков сломать то, что и так работает. Особенно в банках!

Хотя погодите, а может, все же перепишем ядро процессинга на Rust? Сарказм.

➡️ Инструмент либо решает задачи, либо нет — с разной степенью эффективности, удобства использования и скоростью траблшутинга возникающих факапов (обязательно будут, и не раз).

Это я все к чему?

K8s есть. Многие компании научились его готовить. А чтобы его изучить, нужно очень глубоко погружаться в его возможности и, конечно, нарабатывать практику (куда ж без нее).

🔷 Проблема в том, что k8s пятилетней давности и современный k8s — это два довольно разных продукта. За эти годы многое полечили (и, само собой, нагенерили новых проблем). Поэтому приходится постоянно изучать, что добавили, и при этом не перегрузиться от потока информации.

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

➡️ Но самое ценное здесь — это не только уроки и практика, а суперполезные AMA-сессии. Можно принести реальные проблемы со своих проектов, разобрать в деталях механизмы и инструменты, а заодно узнать, как с ними работают в других компаниях.

🔷 Старт нового потока — 21 апреля. Подробности — по ссылке.

Ну а если ничего не поможет, всегда можно просто сказать, что «это k8s, он так работает». Сарказм, но с долей правды.

Типичные и не очень факапы в k8s.

Готовлю для вас большой полезный материал. Расскажу завтра, как строили, строили и наконец построили 1-2-5-10 кластеров, которые работали до поры до времени, а потом неожиданная мелкая проблема вылилась в часы даунтайма.

➡️ А пока я пишу, расскажите, какой неожиданный факап в Kubernetes доставил вам больше всего боли?

Почему полезно читать постмортемы по утрам

Вероятно, вы хотите стать действительно крутым инженером.

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

➡️ Учиться на чужих ошибках здорово и весело.

В этом смысле публичные постмортемы лучшее, что случилось с интернетом с точки зрения профессионального роста.

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

Рассмотрим несколько невыдуманных историй с этого ресурса.

➡️ История 1. SNAT нам все сломал, или сначала нужно проверить на staging.

Ключевой симптом: Все сетевое взаимодействие внутри кластера работало, а все запросы наружу из кластера не работали должным образом.

🟠 Что пошло не так:

Проблема заключалась в механизме SNAT, реализованном в AWS VPC CNI плагине. По умолчанию, при отправке трафика из подов на адреса за пределами VPC, CNI плагин выполняет SNAT, заменяя исходный IP-адрес пода на основной IP-адрес сетевого интерфейса ноды. Поскольку нужно было обращаться в другой VPC, SNAT приводил к сбоям в сетевом взаимодействии. Включение параметра AWS_VPC_K8S_CNI_EXTERNALSNAT=true отключило этот механизм, позволив трафику из подов выходить напрямую без трансляции, что решило проблему.

🟠 Что следовало сделать по-другому:

Тестирование в staging-среде: Перед развертыванием изменений в production необходимо проводить обширное тестирование в изолированной среде, имитирующей production, чтобы выявить потенциальные проблемы.

➡️ История 2. Удобный GitOps позволит удобно удалить всю инфраструктуру

Ключевой симптом: Все сервисы во всех кластерах были удалены.

🟠 Что пошло не так:

Инженер внёс изменение в систему конфигурации, которое предполагалось как несущественное. Изменение было заапрувлено другими инженерами. Однако из-за отсутствия двойных фигурных скобок ({{ }}) в шаблоне, переменные не были интерполированы корректно. Это привело к тому, что ArgoCD попыталась привести кластеры в соответствие с новой конфигурацией и удалила 478 сервисов во всех namespaces и во всех AZ, что вызвало глобальный сбой на 4.5 часа.

🟠 Что следовало сделать по-другому:

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

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

История 3. conntrack всему виной

Ключевой симптом: После изменений в архитектуре сервиса, уменьшения объема оперативной памяти на узлах и увеличения числа соединений с downstream-сервисами, начали проявляться проблемы с подключениями и сильно вырос фон ошибок.

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

Основной причиной инцидента стало исчерпание таблицы conntrack на нодах k8s. Параметр conntrack_max, определяющий максимальное количество отслеживаемых соединений, устанавливается пропорционально объему RAM на ноде. Уменьшение объема памяти на нодах привело к снижению значения conntrack_max, что, в сочетании с увеличением числа соединений, вызвало превышение лимита и, как следствие, сбои соединений и тайм-ауты.

➡️ Что следовало сделать по-другому:

Только гранулярные изменения: Не следует менять сразу несколько критичных параметров, потому что сложнее будет идентифицировать root cause в случае проблем. Поменяли один (уменьшили RAM на нодах), помониторили 1-2 дня, поменяли второй параметр.

Мониторинг использования conntrack: Настроить мониторинг метрик node_nf_conntrack_entries и node_nf_conntrack_entries_limit для отслеживания текущего использования и лимита таблицы conntrack.

Оптимизация размещения подов: Ограничить количество подов высоконагруженных сервисов на одной ноде, чтобы снизить нагрузку на таблицу conntrack каждого узла, путем механизма tains/tolerations.

Настройка параметров conntrack: В случаях, когда сервисы работают на выделенных нодах, увеличить значения conntrack_max с помощью sysctl. Однако следует учитывать, что это может привести к увеличению потребления памяти.

➡️ Больше историй разбирали на вебинаре «Мифы о надёжности Kubernetes: Ошибки, которые стоят вам продакшена».

Как попросить работодателя оплатить обучение?

Коллеги из Слёрма выпустили классный материал, в котором разобрали, с кем обсуждать обучение, что говорить и как подать заявку. Делюсь и очень советую изучить, тем более, что «Kubernetes Мега» стартует совсем скоро.

Если вы искали, куда потратить бюджет на обучение, это — тот самый знак🐈

Как изучать новое с пользой и с доставкой прямо в ваш inbox?

Конечно, можно листать Habr (иногда там попадаются годные технические статьи с детальным погружением). Можно заглянуть на Reddit: сабреддиты по Kubernetes, DevOps, SRE и другим темам иногда приносят интересные находки.

Но сегодня речь пойдёт не об этом (хотя блоги тоже затронем). Делюсь тем, откуда черпаю интересное и полезное.

🟠 Книги, которые стоит прочитать

— Brendan Gregg – Systems Performance 2nd edition
Он много сделал для eBPF и вообще понимает в Linux-перфомансе так, что после его книг в ядро заглядываешь как в свой .bashrc.

— K8s изнутри
Хорошая книга, если хочется не просто «кластер поднять», а понять, как траблшутить, потому что в книге разбирается устройство кластера.

🟠 Подкасты

— LinkMeUp – начинали как сетевики, но теперь говорят и про Kubernetes, и про eBPF. Например очень годно про eBPF.

— DevOps Kitchen Talks – иногда лучше смотреть с видео, но в целом можно слушать и как подкаст. Например, выпуск про karpenter — инструмент для масштабирования кластеров k8s в облаках. Лучше смотреть с видео.

— Kubernetes Podcast from Google — конечно же, куда без него!

— Podlodka Podcast – они ещё и кучу конференций проводят, так что контента там завались (и довольно хорошего). Помогает сильно расширить кругозор за пределами уютного (или не очень) мирка k8s.

— Тысяча фичей – не про Kubernetes, но очень круто о базах данных. Особенно классные выпуски про индексы и внутренности СУБД, практически в формате аудиокниги. Без картинок, но всё понятно. Все выпуски с 21-го по 33-й просто золото и лютый хардкор про внутрянку СУБД.

🟠 Полезные email-рассылки

Да-да, вы не ослышались. Старый добрый email, который попадает прямо в почту (только настройте фильтры, чтобы не шло в inbox).

— Learn Kubernetes weekly
— SRE Weekly

Дополнительно советую поискать «ваш_тулинг Weekly». Например, Golang Weekly, если хотите быть в курсе новостей по Go.

Как жаль, что RSS практически умер... но email живее всех живых.

🟠 Курсы

Из последнего, что проходил сам — CKA от Mumshad Mannambeth.

CKA (Certified Kubernetes Administrator) – это всемирно признанный экзамен по Kubernetes. Подтверждает, что ты не просто YAML-файлы копипастишь, а действительно разбираешься в кластере.

Прикол в том, что можно годами работать с Kubernetes и всё равно завалить экзамен — из-за непривычной среды, тормозящего терминала и жёсткого надзора во время экзамена. Было бы больше времени (а дают всего 2 часа на 15 задач) –— справились бы многие с первого раза (нужно просто уметь работать с k8s на среднем уровне). Но время давит, и это часть челленджа.

Ну и, само собой, советую приглядеться к курсам на факультете Kubernetes в Слёрме — ближайшие потоки стартуют в апреле-мае.

➡️ Важный дисклеймер ⬅️

Этот список — сильно сокращённая версия того, что стоит изучить. Но если внедрить хотя бы часть, уже будет мощный буст в понимании Kubernetes и других технологий.

Если есть годные рекомендации — делитесь, пополним список вместе!

Kubernetes Мега: старт потока через неделю

Покажу вам примеры задач, которые мы реешаем на курсе:

🔷  Настраиваем webhook аутентификацию. Особенно полезно, когда нужно строить важные динамические интеграции с внешними системами аутентификации/авторизации.

🔷  Настраиваем связку k8s и vault через vault injector, чтобы доставлять секреты в приложение безопасным образом, ставить vault-operator и доставлять секреты в кластер. Настраиваем bank vaults secret injection webhook для более безопасной доставки секретов в приложение.

🔷  Реализуем грамотный Resource Management и работу в коммунальном кластере с помощью LimitRange, ResourceQuota, PriorityClass, PodDisruptionBudget.

🔷  Автоматизируем управление сетевыми политиками через GitOps, используя репозиторий для версионирования и CI/CD для развертывания.

🔷  Настраиваем масштабирование сервисов относительно количества очередей в RabbitMQ через KEDA.

Программа рассчитана на 7 недель — 44 часа теории и 78 часов практики и работы со стендами.

➡️ Занять место на потоке — по ссылке. ⬅️

Инженерной зрелости пост

Перед стартом потока «Kubernetes Мега» мы всегда спрашиваем студентов, какие темы из программы они ждут больше всего. Лидерство обычно занимают такие направления, как:

➡️ Kubernetes Networking — потому что когда «оно само как-то ходит» перестаёт работать, навыки использования tcpdump могут ой как пригодиться.

➡️ Создание отказоустойчивого кластера изнутри — ведь все любят high availability… пока не приходит 3 часа ночи, падает etcd, и ты впервые в жизни слышишь фразу «quorum loss».

➡️ Безопасные и высокодоступные приложения в кластере — потому что «у нас всё через секреты» звучит красиво, пока не выясняется, что это секрет с type: Opaque, закоммиченный в git.

Одна из моих любимых тем — это «создание отказоустойчивого кластера изнутри».

Все совпадения с реальностью случайны.

Представьте, что в одном проекте все control-plane ноды были положены в одну зону. Потому что ну не может же она прям взять и упасть. Может. И упадет обязательно.

Другой гипотетический случай — это миграция etcd между узлами с минимальным даунтаймом. Казалось бы, ну что там, просто снести pod и запустить на другой ноде. Но потом ты понимаешь, что вот этот один маленький под — это не твой микросервис, а сердце кластера. И когда миграция идёт не так, ты учишься быстро запускать etcdctl snapshot save и молиться, чтобы restore сработал.

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

Я к вам с новостями

В новом потоке «Kubernetes Мега» мы добавили менторство. Рассказываю, что это такое и зачем нужно ⬇️

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

🟠 Эксперты по конкретным темам курса — проводят онлайн-встречи со студентами
🟠 Куратор группы — информирует студентов о мероприятиях и дедлайнах, поддерживает групповую динамику и взаимодействует с командой курса.

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

1. Отвечать на вопросы
2. Делиться дополнительными материалами, задачами, кейсами и best practices.

Так что обучение станет ещё плодотворнее, а взаимодействие с экспертами и другими студентами — комфортнее.

Старт потока уже на следующей неделе. Занять место — по ссылке.