Kubernetes и кот Лихачева

Всем привет!🐈 Мы подвели итоги гранта на курс Kubernetes: продвинутый уровень и спешим поделиться результатами. Это было непросто — мы с командой учитывали вашу мотивацию и точность ответов в техскрининге. Полностью бесплатно курс получает: ➡️@dev_ooops Скидка 50% ➡️@AndrewElvis ➡️@alexei_emelin Скидка 30% ➡️@Oleg_Belsky ➡️@traveleronmoto ➡️@lehuspohus Поздравляем победителей!🔥 В ближайшее время с вами свяжется менеджер и расскажет, что делать дальше. Спасибо всем за участие!⚡️

Любите ли вы «Властелина колец» так, как его любят в Нидерландах?🔥 Боромир всё равно любит сильнее ➡️Пруфы, кстати, вот: https://maps.app.goo.gl/vsT342xTodAKnp5S8

Когда открыл документацию Kubernetes впервые — знакомая картина? Глаза разбегаются, в голове каша из Pod'ов, Service'ов, Ingress'ов и сотен других терминов. Именно эта ошибка новичков — пытаться объять необъятное в первый же день — и убивает всё желание разбираться дальше. Интенсив по погружению в Kubernetes мы строим ровно наоборот. За 7 дней вы соберёте чёткую, стройную картину: 🟠как устроен кластер и зачем все эти компоненты; 🟠как читать и писать YAML-манифесты, а не копипастить их с риском; 🟠как управлять конфигурациями через Helm без головной боли; 🟠как K8s вписывается в реальные DevOps-процессы (и где вы — в этой схеме). ➡️Формат — ежедневные подкасты, короткие гайды, задания с проверкой, закрытый чат с экспертом. ➡️Стоимость — 5 000 ₽ Приходите, и через неделю ваше лицо будет удивлённым уже от того, как это оказалось просто.

Все еще не переехали на gateway api? Тогда этот гайд для вас Вы наверняка слышали про CNCF. Крошечный консорциум, в рамках которого развиваются, наверное, все популярные и не очень cloud native инструменты. Они выпустили пост о том, как натолкнулись на разные проблемы в процессе миграции на gateway api. Разбираем https://www.cncf.io/blog/2026/04/13/ingress-nginx-to-envoy-gateway-migration-on-cncf-internal-services-cluster/ В чём боль? В ingress-nginx всё было просто: один LoadBalancer-сервис принимает весь трафик и рулит им на основе Ingress`-объектов. В Gateway API концепция сложнее. Если создавать по одному объекту `Gateway на каждый чих (`HTTPRoute` / `TLSRoute`), облако наплодит вам кучу Load Balancer. Для CNCF это означало бы рост расходов. Решение очевидное: подняли один общий Gateway (один внешний IP и один балансировщик), к которому цепляются разные роуты. Но при самом переезде вылезли разные косяки. 1. externalTrafficPolicy При значении Local трафик принимают только те ноды кластера, на которых физически крутятся поды Envoy. Облачный балансировщик честно пошел проверять healthchecks на всех нодах. Ноды без подов Envoy, естественно, не ответили. Балансировщик решил, что всё сломалось, и не слал трафик. Пришлось явно переключать на режим Cluster . 2. Каскадное удаление сертификатов Решили использовать старые SSL-сертификаты, но и них был ownerReference, указывающий на старыйа gateway a Удалишьне переехал- k8s выпилит и секреты. Пришлось на ходу чистить метаданные, удаляя ownerReference . 3. Кросс-неймспейс доступ Так как Тогда этотлежит в системном неймспейсеway api? Тогда эт а секреты с сертификатами размазаны по приложениям, Envoy Gateway из коробки их не увидит. Сесурити! Чтобы это разрулить, теперь нужно явно описывать ReferenceGrant в каждом неймспейсе приложения. Больше деталей и проблем можно найти в оригинальном посте.

Всем привет! Открываем прием заявок на гранты для потока Kubernetes: продвинутый уровень. Делали такое для базового, но на продвинутом работа глубже. Учить поднимать контейнеры не будем. Идем глубоко под капот: KEDA, написание своих операторов, отказоустойчивость БД в кластере. 🔥 Разыгрываем шесть мест: Одно со скидкой 100% Два со скидкой 50% Три со скидкой 30% ⚡️ Как принять участие: 1. Технический тест. Вопросы сложные, времени на поиск ответов в сети не будет. Сразу отсекаем тех, кому пока рано лезть в дебри. 2. Анкета. Забудьте про абстрактные фразы про желание развиваться. Опишите конкретную боль на вашем проде, которую сейчас не получается решить, и как знания с курса помогут закрыть эту проблему. 🔗 ССЫЛКА НА ФОРМУ Выделяйте время с запасом, быстро прокликать тест не выйдет. Ждем тех, кому нужен хардкор.

Иллюзия надежности: когда много точек присутствия не означает независимость от сетевых проблем Статья на хабре https://habr.com/en/articles/1035620/ натолкнула на идею поста. Не столкнешься с такой проблемой, и даже не задумаешься о ее существовании, но благо есть добрые люди, на опыте которых можно учиться и стелить соломки в таких случаях. Когда ты проектируешь геораспределенную систему, кажется, что взял сервера/услуги у разных хостеров и получил отличную отказоустойчивость. Но если ты долго работаешь с большими системами, то знаешь главный закон: все абстракции текут. Краткая выжимка из статьи

Из 10 серверов на разных континентах 7 штук физически сидят в одной и той же автономной системе (AS209847).

Какие последствия этого? Даже при видимом разделении провайдеров, ошибки, например, в BGP на стороне этой AS затрагивают сразу несколько провайдеров. Disclaimer: Это, конечно же, не относится к большим провайдерам. У них может быть один ASN, но риски проблем там, в сравнении с мелкими хостингами, обычно ниже, в силу бОльшей взрослости инфраструктуры. Они просто падают громче в силу масштаба 🙂 Давайте разберем, какие сетевые грабли обязан знать любой инженер. Слой L3: Почему ASN важна Когда падает конкретная виртуалка, причин обычно несколько: 1. Хост-левел: Смерть гипервизора, Kernel Panic, OOM-киллер. Тут все понятно. 2. Физика: Экскаватор перебил магистральную оптику. Классика. 3. BGP-магия: route flapping, BGP leaks или когда два провайдера уронили стык. Первое - фигня, событие изолированное. А вот второе и третье намертво завязано на ASN (Autonomous System Number). Предположим, что вы заказали сервера в разных странах у абсолютно разных небольших локальных хостеров. Разные сайты, разные личные кабинеты, разная валюта оплаты. Но под капотом все они оказались обычными реселлерами, которые берут оптом IP-пулы у у одного крупного апстрима внутри одной AS. У них общая связность, общие транзиты - и как следствие единая точка отказа на уровне сети. Выводы, или как физика L1/L2 может сломать ваш k8s 1. Если твои k8s-ноды разнесены по «разным» хостерам (что само по себе плохая идея - делить один кластер на несколько регионов вместо развертывания N кластеров, по одному на регион), они общаются между собой через оверлейную сеть. Трафик инкапсулируется. Если эти хостеры сидят на одном физическом аплинке, и этот аплинк начинает «моргать», k8s-кластер сходит с ума. 2. Катастрофа репликации storage при потере питания Ты построил отказоустойчивое хранилище (например, Rook/Ceph, Longhorn) поверх дисков разных хостеров, рассчитывая на то, что при падении одного ЦОДа, данные останутся на двух других. Но если эти хостеры арендуют места в одном физическом машзале, то при масштабной аварии по питанию гаснут все три твоих «независимых» провайдера одновременно. Поэтому большие игроки выбирают крупных хостеров, которые гарантируют географическую независимость своих датацентров. Хотя и здесь бывают исключения. Вспомните пожар в OVH, например. https://habr.com/en/news/546264/

Всем привет! И с началом новой недели! Рад сообщить, что в Слёрм появилась автоматическая проверка устранения инцидентов 🔥 Система засчитывает инцидент только, когда все тесты пройдены. Это прямо как при работе с реальными задачами. Важен результат — устранение проблемы. Эта механика уже внутри практикума «Безопасность в Kubernetes». Что будет на практикуме: 🔸 Разбираем настоящие инциденты: Tesla Mining, SAP Secrets Leak и другие; 🔸 Учимся усиливать защиту, не ломая работающие сервисы; 🔸 Прокачиваем скорость реакции на проблемы; Приходите первыми — почувствуйте, как это, когда окружение проверяет вас так же, как в боевом кластере 👉🏻 узнать подробнее

Интенсив по погружению в Kubernetes Слёрм запускает 7-дневный марафон «Kubernetes: Быстрый старт» На интенсиве вы: 🔺Разберетесь в ключевых концепциях Kubernetes 🔺Поймёте, как он работает в реальных проектах 🔺Выполните практические задания 🔺Получите понятную картину того, как развиваться дальше Короткий, но полезный формат: За 40-60 минут в день вы поймете как устроен Kubernetes, зачем он нужен современному инженеру и как начать использовать его на практике без перегруза и сложной теории Старт 13 июля. Стоимость — 5 000 рублей. 👉🏻 Подробности на сайте

Всем привет! Слёрму уже 8 лет. За это время было множество разных задач и трудностей, но благодаря этому, ребята выросли в профессионалов, которые продолжают радовать вас лучшими курсами и качественным контентом. И как положено в день рождения, подарки дарит Слёрм 15% на все курсы. Без исключений. Но я рекомендую вам курс: Kubernetes: продвинутый уровень 👉 Больше курсов — по ссылке Промокод: SLURMBD15 Действует до 5 июня, 12:00 *акция только для физлиц

Как один параметр сохранил 600 часов работы в год Cloudflare столкнулись с проблемкой: их инстанс Atlantis (крутится как StatefulSet для запуска Terraform) при каждом рестарте оживал по 30 минут. При сотне плановых перезапусков в месяц инженеры суммарно теряли 50 часов чистого времени, дожидаясь раскатки. 🔸Что пошло не так? Не будем ходить вокруг да около, детали вы можете прочитать в оригинальном посте, перейдем сразу к сути. В логах kubelet видим

[volume_linux.go:49] Setting volume ownership for /state/var/lib/kubelet/... and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow...

Виной всему безопасные дефолты Kubernetes. Если у пода в securityContext задан fsGroup (чтобы контейнер мог писать на диск под заданным для него пользователем), kubelet при каждом старте делает chgrp -R для всех файлов на монтируемом PersistentVolume. На диске Atlantis за годы скопилось, очевидно, много файлов. 🔸Решение: Есть параметр fsGroupChangePolicy. По дефолту он стоит в Always, но его можно (и нужно для больших PV) перевести в OnRootMismatch. Тогда kubelet проверит права только на корневой директории PV, и если они ок - скипнет сканирование миллионов файлов. 🔸Пофиксили одной строкой в манифесте:

spec:
  template:
    spec:
      securityContext:
        fsGroupChangePolicy: "OnRootMismatch"

🔸Дисклеймер: не пихайте это вслепую везде. Если файлы на PV создаются разными процессами с отличающимися GID, OnRootMismatch проверит только корень, и к части вложенных файлов приложение может потерять доступ. Это отличный пример того, как сложный кейс может решаться практически однострочным коммитом, но чтобы знать, где и какую строку поправить, придется потратить часы и дни на анализ, а почему собственно работает не так, как надо. 🔸Источник: https://blog.cloudflare.com/one-line-kubernetes-fix-saved-600-hours-a-year/

Как один параметр сохранил 600 часов работы в год Источник: https://blog.cloudflare.com/one-line-kubernetes-fix-saved-600-hours-a-year/ Cloudflare столкнулись с проблемкой: их инстанс Atlantis (крутится как StatefulSet для запуска Terraform) при каждом рестарте оживал по 30 минут. При сотне плановых перезапусков в месяц инженеры суммарно теряли 50 часов чистого времени, дожидаясь раскатки. Что пошло не так? Не будем ходить вокруг да около, детали вы можете прочитать в оригинальном посте, перейдем сразу к сути. В логах kubelet видим

[volume_linux.go:49] Setting volume ownership for /state/var/lib/kubelet/... and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow...

Виной всему безопасные дефолты Kubernetes. Если у пода в

`securityContext`задан

`fsGroup` (чтобы контейнер мог писать на диск под заданным для него пользователем), kubelet при каждом старте делает chgrp -R для всех файлов на монтируемом PersistentVolume. На диске Atlantis за годы скопилось, очевидно, много файлов. Решение Есть параметр fsGroupChangePolicy. По дефолту он стоит в Always, но его можно (и нужно для больших PV) перевести в OnRootMismatch. Тогда kubelet проверит права только на корневой директории PV, и если они ок - скипнет сканирование миллионов файлов. Пофиксили одной строкой в манифесте:

spec:
  template:
    spec:
      securityContext:
        fsGroupChangePolicy: "OnRootMismatch"

Дисклеймер: не пихайте это вслепую везде. Если файлы на PV создаются разными процессами с отличающимися GID, OnRootMismatch проверит только корень, и к части вложенных файлов приложение может потерять доступ. Это отличный пример того, как сложный кейс может решаться практически однострочным коммитом, но чтобы знать, где и какую строку поправить, придется потратить часы и дни на анализ, а почему собственно работает не так, как надо.

Всем привет! Побывал на днях на aws summit и, ожидаемо, везде AI. Но речь не об этом. Представляю диалог организаторов: - У нас событие происходит в Нидерландах, нужно сделать это максимально понятно. - Ни слова больше!

Хочешь повысить свой грейд? 29 июня стартует новый поток «Kubernetes Мега» — курс, который превратит тебя из оператора в архитектора платформ Что даст курс: 🔸Научишься строить отказоустойчивую и предсказуемую инфраструктуру в компании. 🔸 Поймёшь, как работает Control Plane, напишешь своего оператора и настроишь кастомный scheduler. 🔸Освоишь ротацию сертификатов, интеграцию с HashiCorp Vault и Service Mesh (Istio). 🔸Отработаешь реальные аварии (etcd, kubelet, сеть) — будешь находить причину за минуты. Почему стоит идти сейчас: 79% практики: 78 часов на стендах, близких к реальному production. В итоге получишь не просто сертификат, а навык проектирования надёжных систем, за который платят как старшему специалисту. 👉 Записывайся на поток

🚀 Хочешь повысить свой грейд? 29 июня стартует новый поток «Kubernetes Мега» — курс, который превратит тебя из оператора в архитектора платформ. Что даст курс: 🔸Научишься строить отказоустойчивую и предсказуемую инфраструктуру в компании. 🔸 Поймёшь, как работает Control Plane, напишешь своего оператора и настроишь кастомный scheduler. 🔸Освоишь ротацию сертификатов, интеграцию с HashiCorp Vault и Service Mesh (Istio). 🔸Отработаешь реальные аварии (etcd, kubelet, сеть) — будешь находить причину за минуты. Почему стоит идти сейчас: 79% практики: 78 часов на стендах, близких к реальному production. В итоге получишь не просто сертификат, а навык проектирования надёжных систем, за который платят как senior’у. 👉 Записывайся на поток!

Всем привет! Если вам нужен структурированный список того, что должен знать SRE, сохраняйте в закладки School of SRE. Это чеклист для тех, кто хочет понимать, как работают крупные системы под нагрузкой. Что там ценного: 🔸Linux Internals: Процессы, память, сигналы и файловые системы. То, что каждый инженер, обслуживающий большие системы, должен знать, потому что иногда может пригодиться навык копаться в низкоуровневых штуках (мне пригождался и не раз). 🔸Networking: Не общие слова, а конкретика про уровни OSI, протоколы и то, как трафик ходит внутри дата-центра. 🔸Troubleshooting: Логика поиска неисправностей. Помогает перестать тыкаться вслепую, когда всё упало, и действовать по методологии. 🔸System Design: База по архитектуре — как строить отказоустойчивые сервисы, работать с базами данных и очередями. Материал разбит на уровни (101 и 102). По нему удобно проверять себя: если видите незнакомый термин в оглавлении - значит, это потенциальная дыра в знаниях, которую стоит закрыть. 👉Идеально подходит как для подготовки к собеседованиям, так и для тех, кто переходит в SRE из чистой разработки или системного администрирования.

Как грамотно попросить у работодателя оплатить обучение? 🟠Команда Слёрма подготовила отличный материал: разобрали, с кем вести переговоры, какие аргументы приводить и как оформлять заявку. Сохраняю у себя и настоятельно рекомендую к прочтению — тем более что скоро стартует поток курса «Kubernetes Мега» Если вы всё ещё думаете, на что направить корпоративный бюджет на развитие, вот он, тот самый знак🐈 🟠Курс «Kubernetes Мега» — это углублённая программа для тех, кто хочет получить полный контроль над контейнерной инфраструктурой и научиться эффективно масштабировать. 🟠Курс будет особенно полезен DevOps и SRE-инженерам, системным администраторам и архитекторам, которые хотят уверенно строить отказоустойчивые кластеры и повышать свою экспертизу. Узнать подробности и записаться

Всем привет!🐈 Недавно мы с Всеволодом Севостьяновым провели вебинар «Неочевидные проблемы Kubernetes, которые легко упустить» Если вы не успели на эфир, советую посмотреть запись: 🟠YouTube: https://www.youtube.com/live/lHxCCtiVBgQ 🟠VK Video: https://vkvideo.ru/video-59405817_456240106 А если хотите системно разобраться с Kubernetes, тогда буду ждать вас на курсе "Kubernetes: базовый уровень". За 6 недель освоите основы работы с Kubernetes: c системой автоматизации развертывания, масштабирования и управления приложениями в контейнерах Курс стартовал, но продажи открыты до 19 мая ➡️Специально для подписчиков канала: скидка 15% по промокоду KUB15

Погружаемся в недра сетевого программирования⚡️ Beej’s Guides: как на самом деле работают сети и сокеты Если вы занимаетесь бэкендом, DevOps или SRE, вы точно знаете, насколько важна сеть. Еще очень круто понимать, что происходить в сети и как это влияет на проектирование ваших систем. beej.us/guide/ - это коллекция руководств, где самое важное - Guide to Network Programming. В чем ценность: 🔹Работа с сокетами «под капотом»: Вместо абстракций высокоуровневых библиотек Бидж объясняет, как работают системные вызовы: socket(), bind(), listen(), accept() 🔹Сетевой стек: Понятное объяснение IPv4/IPv6, структур данных, теории сетевых протоколов и того, как данные физически перемещаются между хостами. 🔹IPC (Inter-Process Communication): Отдельный гайд по взаимодействию процессов (сигналы, очереди сообщений, разделяемая память). Незаменимо, если нужно разобраться в Linux Internals. 🔹Человеческий язык: Написано живым, местами ироничным языком, но с абсолютной технической точностью. Это редкий пример документации, которую реально интересно просто читать (на ночь). Зачем это инженерам? Мы же просто фигак, AI и в продакшн Это база для вдумчивого траблшутинга. Когда стандартные инструменты не помогают, нужно понимать, как ядро ОС обрабатывает соединения, почему висят сокеты в TIME_WAIT и прочие низкоуровневые нюансы. Кроме сетей, там есть отличные гайды по языку C и GDB - полезно, если приходится разбираться в работе ядра.

Погружаемся в недра сетевого программирования Beej’s Guides: как на самом деле работают сети и сокеты Если вы занимаетесь бэкендом, DevOps или SRE, вы точно знаете, насколько важна сеть. Еще очень круто понимать, что происходить в сети и как это влияет на проектирование ваших систем. **beej.us/guide/**](https://beej.us/guide/ - это коллекция руководств, где самое важное - Guide to Network Programming. 🔵В чем ценность: Работа с сокетами «под капотом»: Вместо абстракций высокоуровневых библиотек Бидж объясняет, как работают системные вызовы: socket(), bind(), listen(), accept() Сетевой стек: Понятное объяснение IPv4/IPv6, структур данных, теории сетевых протоколов и того, как данные физически перемещаются между хостами. IPC (Inter-Process Communication): Отдельный гайд по взаимодействию процессов (сигналы, очереди сообщений, разделяемая память). Незаменимо, если нужно разобраться в Linux Internals. Человеческий язык: Написано живым, местами ироничным языком, но с абсолютной технической точностью. Это редкий пример документации, которую реально интересно просто читать (на ночь). 🔵Зачем это инженерам? Мы же просто фигак, AI и в продакшн Это база для вдумчивого траблшутинга. Когда стандартные инструменты не помогают, нужно понимать, как ядро ОС обрабатывает соединения, почему висят сокеты в TIME_WAIT и прочие низкоуровневые нюансы. Кроме сетей, там есть отличные гайды по языку C и GDB - полезно, если приходится разбираться в работе ядра.

Курс «Kubernetes База» стартовал⚡️ Если вы присоединитесь к текущему потоку, то в ближайшие 6 недель изучите: 🟣основы работы с Kubernetes, устройство кластера и отказоустойчивость; 🟣продвинутые абстракции в Kubernetes; 🟣DNS в кластере; 🟣работа с stateful приложениями; 🟣CI/CD в Kubernetes. В конце — итоговая сертификация на стенде, где нужно последовательно привести кластер к определенному состоянию — запускать приложения, создавать абстракции. Присоединиться можно до 19 мая. Подробности — по ссылке