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

➡️ История 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.

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

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

Podlodka PHP Crew

Недавно приложил руки к Techlead Crew — там не только помогал спикерам делать доклады лучше и полезнее, но и провел экспериментальный формат System Design Interview, где кандидату не нужно было изобрести велосипед с нуля, а даже совсем наоборот — как-то жить с тем, что уже едет, скрипит, интегрировано бог знает с чем, и при этом не развалить всё к чертям, а ещё как-то развивать и поддерживать. Неудивительно, ведь обсуждали межсервисное взаимодействие — ту самую вещь, которая выглядит красиво на архитектурных диаграммах, а на деле превращается в танцы под названием «Почему вендор сломал нам интеграцию?».

Да вы и сами наверняка встречались и не раз с проблемами согласования контрактов даже между системами внутри одной компании. А когда нужно договориться между разными вендорами, все становится ещё веселее 😭

Теперь залечу ещё и на Podlodka PHP Crew, где буду вещать на тему «Performance-тюнинг PHP: от кода до инфраструктуры». Залезем под капот PHP  (совсем немного), но не будем ограничиваться магическим твиком pm.max_children и надеждой, что opcache спасёт мир. Поговорим и про то, как выжать побольше из nginx, когда RPS растет, а запускать ещё один сервис может быть накладно (не все проекты живут в k8s, вот это да!). Вместо этого — будем колдовать на Lua в nginx. Потому что если можно усложнить, зачем упрощать?) Шутка, конечно. Писать отдельный сервис, когда достаточно простые (но требующие перформанса), может быть оверкилл, а проблему нагрузки надо решать.

А еще в программе много интересного, и не только про php:

➡️ Павел Вирский (Ozon)

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

➡️ Олег Мифле (Altenar)

— покажет, как индексы в БД могут навредить, и что делать, когда «оптимизация» приводит к регрессу производительности 💥

➡️ Ярослав Тарасов (Skyeng)

— проведёт разбор оптимизации Symfony-приложения через RoadRunner: от архитектуры до конкретных замеров ⚙️

➡️ Александр Макаров (Yii, Twindo)

— расскажет о низкоуровневой оптимизации PHP: от мелких улучшений до AI, который сам оптимизирует ваш код 🧩

Приглашаю на конференцию всех, кто пришёл в разработку через PHP — в те славные времена, когда mysql_query() был нормой, а если не работало — «поставь 777, брат, и всё полетит».

Залетайте и те, кто PHP до сих пор любит и те, кто его ненавидит всем сердцем.

И, конечно, welcome те, кто относится к PHP как к инструменту: «работает — и хорошо, бизнесу же всё равно, на чём ты там шаманишь, лишь бы выкатилось и не упало, да приносило деньги».

Давайте поностальгируем и признаем — php с современными фреймворками все еще чертовски удобен.

➡️ А мой промкод deeperPHP дает скидку в 500р 🥳

А с чего вы начинали свой путь в IT и с каким жутким проектом пришлось столкнуться в своей карьере?