➡️ Общественный транспорт

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

А еще многие крупные вокзалы довольно красивые.

Например, центральный вокзал Амстердама.

➡️ Аэропорты

Главный аэропорт страны — Схипхол (Schiphol), один из крупнейших в Европе. Он находится всего в 20-30 минутах езды от центра Амстердама, что делает его максимальнно удобным для путешествий. Также есть и другие аэропорты, например, в Эйндховене и Роттердаме.

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

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

Но проверки безопасности, сканирование багажа и пассажира, запрет провозить воду, все аналогично как и в РФ.

На этом закончим с транспортом, а в следующей части расскажу школы/детсады, парки, музеи и про многое другое.

Как изучать 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 Мега» стартует совсем скоро.

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