KazDevOps

🚀 «Мой кейс недостаточно интересный» Так думает почти каждый спикер перед первым докладом. Если вы прочитали про поиск спикеров на Cloud Native Community Day и подумали «звучит круто, но мне-то нечего рассказать» — это та мысль, которая приходите половине инженеров. И почти всегда она неверна. Нам не нужен «прорыв года», а лишь реальный случай из прода. Узнаете себя? ⚪️ Чинил кластер ночью и понял причину только под утро — расскажи, как искал ⚪️ Внедрял service mesh или ArgoCD и набил шишек — твои грабли сэкономят кому-то недели ⚪️ Резал счёт за облако — как нашел причину оверкостов ⚪️ Мигрировал на K8s, и половина пошла не по плану — это и есть лучший доклад ⚪️ Настроил observability и впервые увидел, что реально творится в проде Если хоть один пункт про вас — доклад может получиться. Структуру и подачу поможем довести до ума на прогонах. 👈 Подать заявку как спикер @DevOpsKaz 😛

⚡️ Ловушка самодельных платформ Многие IT-руководители считают, что их внутренняя инфраструктура уникальна, и поэтому единственно верный путь — заняться Platform Engineering своими силами с нуля. Но ловушка в том, что вместо решения бизнес-задач компания неосознанно начинает создавать собственный огромный продукт, который требует бесконечной поддержки. Проблемы самодельных платформ: ⚪️ Обслуживание франкенштейна. Платформа, собранная из множества скриптов, open-source инструментов и связок, требует постоянных обновлений, исправления багов и адаптации. Со временем команда инженеров платформы тратит 100% своего времени просто на то, чтобы поддерживать систему «на плаву», вместо того чтобы развивать её. ⚪️ Выгорание команды. Инженеры платформы оказываются заложниками ситуации. Они перегружены рутиной, а разработчики (внутренние клиенты) постоянно недовольны качеством, багами и сложным интерфейсом платформы. Это приводит к сильному выгоранию сотрудников и высокой текучести кадров. ⚪️ Иллюзия уникальности. Компании часто переоценивают уникальность своих процессов. На самом деле около 80% потребностей в оркестрации, деплое и управлении инфраструктурой стандартны для большинства. И куда быстрее закрыть эти потребности готовыми инструментами. К созданию IDP стоит подходить с точки зрения продуктового менеджмента и учитывать главные моменты: ⚪️ Платформа должна приносить ценность конечным пользователям, делать их жизнь проще, а деплой — быстрее. ⚪️ Если платформа неудобна, разработчики будут искать обходные пути, разрушать безопасность и стандарты компании. Какое решение более правильное? ⚪️ Использовать готовый фундамент. Довериться проверенным open source технологиям или коммерческим оркестраторам и базовым платформенным решениям для закрытия стандартных 80% задач (например, управление конфигурациями, базовые пайплайны). ⚪️ Создавать только ключевые отличия. Фокусировать силы своих инженеров исключительно на оставшихся 20% — тех уникальных бизнес-требованиях и специфических интеграциях, которые действительно отличают вашу компанию от конкурентов.

Мы в Core 24/7 готовы снять с вашей организации огромный пласт работы и заточить платформу под вас с вашим минимальным участием. Организуем Platform Engineering — и создадим внутренние платформы для ускорения разработки.

@DevOpsKaz 😛

🔥 IBM и Red Hat защитят open source ПО от киберугроз нового поколения

Передовые ИИ-модели (типа Claude Mythos) научились мгновенно находить уязвимости в коде. Например, в рамках недавнего исследования Anthropic ИИ проверил более 1000 open-source проектов и всего за месяц обнаружил 23 019 уязвимостей, из которых более 6 тысяч оказались критического или высокого уровня опасности.

Раньше у компаний были недели или месяцы на то, чтобы найти баг и выпустить патч, теперь счет идет на часы. Но у команд объективно не хватает сил, чтобы вручную разбирать тысячи отчетов, проверять их и писать патчи. Project Lightwell на $5 млрд. создается, чтобы помочь с этим. Более 20 000 инженеров и современные ИИ-технологии трудятся, чтобы автоматизировать защиту. Как это работает? ⚪️ Специальная коммерческая платформа-хаб станет своеобразным фильтром. ИИ-системы будут автоматически проверять и тестировать исправления для огромных объемов открытого кода, гарантируя, что патчи безопасны и готовы к работе в реальных корпоративных системах. ⚪️ Взаимодействие с сообществом. Компании смогут отправлять в этот хаб найденные уязвимости, оперативно внедрять проверенные патчи в свои экосистемы и передавать эти исправления обратно разработчикам оригинальных проектов, чтобы защитить весь интернет. ⚪️ Агентный ИИ. IBM планирует использовать свои новые методы ИИ-агентов, которые могут автономно выполнять сложные цепочки задач по анализу кода, приоритизации угроз и укреплению зависимостей между библиотеками. Этот проект — попытка перевести валидацию и выпуск защитных патчей на промышленные рельсы. @DevOpsKaz 😛

🔥 Вайбкодинг, AI-агенты в проде и ИБ: как прошла beetech conf 2026 Состоялась шестая beetech conf, где инженеры и продакты делились чистым практическим опытом внедрения ИИ в реальный прод. Казахстанский IT-экспорт уже пробил $1 млрд, так что экспертизы там насыпали плотно. Собрали главное из стримов Engineering, Data & AI, что точно стоит взять на заметку: ⚪️ Пайплайны, архитектура и инфраструктура - Поиск в госзакупках на AI-стероидах. Виталий Тренкеншу (CEO bids.do) разложил трехстадийный пайплайн Retrieve-Enrich-Rerank. Настроили архитектуру так, что обработка гигантских массивов данных сократилась с десятков тысяч позиций до точного шорт-листа всего за пару минут. - Безопасность AI-агентов. Кутлымурат Мамбетниязов (BTS Digital) поднял больную тему: как деплоить и защищать сами LLM-системы, и как использовать ИИ для автоматического поиска уязвимостей в инфре, пока это не сделали хакеры. ⚪️ Бизнес-логика и метрики - Почему AI в продакшене не взлетает? Виктория Татарикова (QazCode) разобрала 5 ключевых ошибок внедрения ИИ, когда пилоты жрут бюджеты, но не приносят ценности. Дала готовую модель перехода от простых чат-ботов к автономным AI-агентам с измеримыми метриками. - Юнит-экономика головного мозга. Известный продуктовый аналитик Илья Красинский (Rick.ai) на пальцах объяснил, почему стартапы с крутым стеком и сильной командой всё равно закрываются. Спойлер: надо принимать решения на основе жестких данных и юнит-экономики, а не интуиции. ⚪️ Главный кайф — Epic Fails микрофон Помимо классических докладов, завезли формат "квартирников" и разбор факапов. Участники со сцены честно рассказывали, из каких костылей, упавших баз и кривых архитектурных решений в итоге выросли стабильно работающие продукты.

Резюме: рынок меняется каждые полгода. Оставаться на "старых дрожжах" и просто настраивать CI/CD по старым мануалам больше не получится — приходится лезть под капот MLOps, AI-агентов и вайбкодинга.

@DevOpsKaz 😛

🔥 Как похоронить SRE в компании, пытаясь его масштабировать Бывает, что мимолетный успех затуманивает трезвый взгляд на вещи. Когда одна продуктовая команда видит «классный результат» после внедрения SRE, велик соблазн сразу масштабировать этот результат на другие команды. В итоге хорошая SRE-практика быстро превращается в несовместимые друг с другом варианты. Разбираем классические ошибки хаотичного масштабирования и то, как сделать это по уму. ⚪️ Парад кастомных велосипедов. Без единых стандартов у всех свои форматы алертов, разные метрики SLO и уникальные плейбуки. ⚪️ Размытие экспертизы. Топовых инженеров, которые запускали первые SRE-практики, начинают размазывать тонким слоем по компании и кидать на дежурства в незнакомые системы. В итоге они превращаются в «пожарных» на full-time. ⚪️ Платформа без инвестиций. Пока SRE-шники тушат локальные пожары в продуктовых командах, общие инфраструктурные инструменты остаются без внимания. Техдолг растет, команда топчется на месте. ⚪️ Лучшие люди выгорают и уходят. Компания теряет экспертизу из-за кривого менеджмента, а не из-за того, что «SRE не масштабируется». Как масштабировать SRE, ничего не сломав ⚪️ Вводим критерии готовности. Нельзя просто так взять и прийти к SRE. Продуктовая команда сначала должна сама сделать домашку: настроить базовую инструментацию, определить SLO и написать минимальные инструкции для дежурств. ⚪️ Гибкие модели взаимодействия. Выделенный SRE нужен далеко не всем. Миксуйте форматы: используйте консалтинг со стороны SRE и Self-Service для зрелых команд. ⚪️ Защищаем правило 50/50. Помните классику из Google SRE book? Не более 50% времени на эксплуатацию (ops). Остальное время — строго на проектную работу и автоматизацию. Иначе выгорание неизбежно. ⚪️ Инвестируем в платформу (IDP). Вместо раздувания штата автоматизируйте стандарты. Нужны единые библиотеки логирования, общие конфигурации PagerDuty и готовые инструменты для работы с SLO. ⚪️ Алерт на онколл. Если нагрузка на дежурствах зашкаливает — это не кадровая проблема, которую можно решить наймом джунов. Это архитектурная проблема системы. Масштабировать нужно не людей, а стандарты и платформенные решения. @DevOpsKaz 😛

⚡️ Как улучшить дежурства DevOps Улучшение ситуации с дежурствами не требует масштабной и болезненной трансформации. Все начинается с базового шага: готовности посмотреть проблеме в глаза. Типичные факапы в On-Call и их решения: ⚪️ Недоукомплектованные ротации. Бывает, что один инженер дежурит непомерно долго. Это не всегда приводит к катастрофе, но система нежизнеспособна в долгую. Регулярные ревью должны подсветить проблему, чтобы ответственный перестроил графики и вернул нагрузку в гуманное русло. ⚪️ Привыкание к «шуму» алертов. Инженеры порой месяцами живут в потоке ложных и некритичных уведомлений, просто потому что не знают, «разрешено» ли им что-то отключать. В качестве решения — закрепление ответственности и карт-бланш от руководства на то, чтобы гасить мусорные алерты, чистить каналы оповещений или переходить на алертинг на основе SLO. ⚪️ «Инженеры-герои». Например, когда некий senior-инженер неформально разруливает большинство крупных факапов вместо дежурного. В таком случае следует снижать зависимость от одного человека через передачу знаний и оптимизацию документации. Что можно улучшить уже завтра: ⚪️ Фиксируйте простые KPI дежурств. Один из самых эффективных показателей может быть банальным: сколько алертов получила каждая команда за прошлую неделю? Новое поколение инструментов предлагает более глубокий анализ. Они объединяют операционные сигналы из GitHub, Jira и др. источников с кратким фидбеком от самих инженеров. ⚪️ Регулярно разбирайте эти KPI на встречах с техлидами. Менеджмент выделяет время и ресурсы только на те проблемы, которые он видит. Как только руководители начинают обращать на это внимание, самые жесткие и токсичные кейсы устраняются мгновенно, а посредственные ситуации постепенно выправляются, так как инвестиции в надежность получают более высокий приоритет.

Лайфхак из практики: чтобы разбор KPI стал регулярным, отчеты должны быть адаптированы под культуру управления вашей компании. Например, можно генерировать автоматические отчеты в Google Docs и изучать их во время митингов в режиме «молчаливого чтения» в начале встречи.

@DevOpsKaz 😛

🔥 Конкурс с Yandex Cloud продолжается: участвуйте и выигрывайте мерч! Ещё есть время поделиться идеями и забрать подарки. Подарки: 3 набора с мерчом — рюкзак, чехол для ноутбука, термос и облачный стикерпак. 👈 Все подробности здесь

Также от лица Core 24/7 и KazDevOps поздравляем казахстанцев с праздником Курбан-айт и желаем здоровья, мира и благополучия!

@DevOpsKaz 😛

🔥 Бесплатные курсы по Git / GitHub К концу 2025 года на GitHub было зарегистрировано более 180 миллионов разработчиков. Значительная часть мировой коммерческой разработки проходит именно через эту платформу.

Публикуем подборку курсов, для тех, кто только заходит в сферу или по какой-то причине еще не работал с Git. Все они бесплатные, все доступны онлайн, все запускаются в любое время.

⚪️ Слёрм: Git для начинающих 22,5 часа практики помогут эффективно управлять проектами, облегчать себе процесс разработки и минимизировать возможные ошибки. ⚪️ Хекслет: Основы Git Курс рассчитан на месяц неспешного погружения с практическими заданиями, которые проверяются автоматически. Программа охватывает работу с системами контроля версий в целом, базовые команды Git, синхронизацию с GitHub и основы коллаборативной работы в репозиториях. ⚪️ Stepik: Основы Git и GitHub Программа покрывает работу с репозиториями, коммитами, удаленными серверами и отдельно разбирает GitHub Copilot. ⚪️ Академия Эдюсон: Тестировщик ПО free Это бесплатный тест-драйв полного платного курса по тестированию ПО. За три дня вы посмотрите, как Git и GitHub применяются в работе тестировщика наряду с Postman, Fiddler, тестированием API и мобильных приложений. Сохраняйте себе и делитесь с теми, кому будет полезно 🫡 @DevOpsKaz 😛

🔥 Релиз GitLab 19.0 21 мая вышел мажорный релиз, переосмысляющий то, как платформа управляет жизненным циклом от идеи до деплоя. Теперь платформа берёт на себя операционную работу, оставляя командам только решения, требующие человеческого размышления. ⚪️ Автономное ведение Merge Request (MR): Duo Developer теперь может самостоятельно вести MR от первого коммита до слияния. ИИ-агента можно активировать через @assign в issue, по кнопке «Generate MR» или через @mention. Агент умеет запускать тесты и линтеры перед коммитом (настраивается через файлы AGENTS.md и agent-config.yml). ⚪️ Разрешение конфликтов слияния (Beta): появилась функция автоматического разрешения конфликтов с помощью ИИ (Resolve with Duo). ИИ анализирует конфликтующие файлы, правит их с учетом контекста обеих веток и делает коммит в source-ветку (правила protected branches строго соблюдаются). ⚪️ Групповые инструкции для ИИ-ревью: теперь правила для ИИ-кода можно задавать глобально на уровне группы. Они каскадно наследуются и дополняются проектными инструкциями, избавляя от необходимости дублировать файлы конфигурации в каждом репозитории. ⚪️ GitLab Secrets Manager: главная архитектурная особенность — принцип наименьших привилегий. Секреты больше не «прилетают» во все job'ы пайплайна автоматически как обычные CI/CD переменные, конкретный job должен явно запросить нужный секрет через конфигурацию secrets: vault:.... ⚪️ SBOM-подход в Dependency Scanning: обновленный сканер зависимостей (v2) строит полный граф программных компонентов (Software Bill of Materials), что позволяет находить уязвимости глубоко внутри транзитивных зависимостей, которые старый сканер не видел. Если lock-файла нет, анализатор пытается сгенерировать его автоматически. ⚪️ Шаблоны заголовков MR: добавлена долгожданная фича — возможность жестко задать шаблон заголовка Merge Request на уровне проекта с использованием динамических переменных (например, Resolve %{issue_id} "%{issue_title}"). ⚪️ Массивы в CI/CD Inputs: теперь можно обращаться к элементам по индексу ($[[ inputs.services[0] ]]), а при ручном запуске пайплайна в UI можно выбирать несколько значений из выпадающего списка, которые автоматически объединятся в массив. ⚪️ HMAC-подписи для Webhooks: вместо передачи статического токена в открытом виде (X-Gitlab-Token), GitLab теперь вычисляет и отправляет безопасную подпись HMAC-SHA256, защищая интеграции от перехвата и replay-атак.

GitLab 19.0 переходит от концепции «ИИ как ассистент, пишущий код» к концепции «ИИ как полноценный участник процессов», способный самостоятельно тестировать, проверять безопасность, разрешать конфликты веток и управлять инфраструктурными секретами, снижая нагрузку на инженеров.

@DevOpsKaz 😛

🔥 Конкурс совместно с Yandex Cloud Kazakhstan Автоматизация — наше всё. И за одну идею автоматизации у вас есть шанс выиграть крутой походный набор. 💥 Призы: 3 набора с мерчем: рюкзак, чехол для ноутбука, облачный стикерпак и термос ☁️ Как участвовать: ⚪️ Подпишитесь на @DevOpsKaz и @yandexcloudkazakhstan ⚪️ Перейдите в конкурсный пост Yandex Cloud Kazakhstan по ссылке ⚪️ В комментариях под тем же постом ответьте на вопрос:

Какую рутинную задачу в IT / DevOps вы мечтаете полностью автоматизировать с помощью облаков и ИИ?

📅 Сроки: Старт — 22 мая Итоги — 29 мая (объявят в канале Yandex Cloud Kazakhstan) Победителей объявят с помощью рандомайзера — из числа тех, кто ответит на вопрос. @DevOpsKaz 😛

🔥 Вакансия в CORE 24/7 — Middle DevOps-инженер

Алматы, офис Требуемый опыт работы: 1-2 года Полная занятость, полный день Заработная плата: до 1 000 000 тг net Контакты: Telegram @issaika

⚪️ Что нужно делать • Поддерживать production так, чтобы бизнес мог быть спокоен • Спасать клиентов в случае аварий: быстро, решительно, профессионально • Выстраивать процессы CI/CD • Переносить приложения клиента (на любом языке, фреймворке и технологии) в Kubernetes с помощью различных инструментов. Запускать и настраивать их • Искать способы сделать более надежными и быстрыми базы данных, серверы очередей и прочий софт • Разрушать стену между разработкой и системным администрированием; консультировать разработчиков клиента, вместе приходить к лучшим решениям и практикам ⚪️ С кем будете работать • Со своей командой увлеченных профессионалов • С тимлидом и ПМом, которые всегда помогут, обучат и направят • Напрямую с клиентом, но в этом будут помогать тимлид и ПМ • С внутренними командами, разрабатывающими инструменты, сервисы и технологии для упрощения работы ⚪️ Требования • Отличные знания Linux-систем — ежедневная эксплуатация от 3 лет; опыт в DevOps — от 1 года • Понимание того, как функционируют современные веб-приложения, и опыт их эксплуатации — от 3 лет • Понимание веб-стека (HTTP, TCP/IP), устройства и работы сетей, базовые умения работы с iptables • Понимание принципов работы СУБД, а также построения и эксплуатации распределенных систем • Умение сформулировать алгоритм и уверенно писать скрипты • Понимание того, что удалёнка — это серьёзная работа, а не оплачиваемый отдых ⚪️ Будет плюсом • Опыт использования современных NoSQL-решений (особенно MongoDB и Redis) • Опыт в Kubernetes • Опыт настройки реляционных баз данных для отказоустойчивых/высоконагруженных систем • Опыт разработчика • Хорошие знания основ системы виртуализации KVM и контейнеров Docker • Опыт работы с облачными платформами (Yandex clod, AWS, GCP, Azure и др) • Знание Prometheus/Grafana • Знание Elasticsearch (ELK) • Знание RabbitMQ

Писать сюда: 👈 aissabekova@core247.io 👈 @issaika

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить ⚪️ Istio v1.30 Главный фокус последних обновлений Istio (включая релиз 1.30) — на глубокую стабилизацию бессидекарной архитектуры Ambient Mesh и упрощение эксплуатации. Разработчики добавили гайд по бесшовной миграции с классических сайдкаров, внедрили поддержку CIDR-диапазонов для внешних сервисов и добавили передачу исходной идентичности клиентов через шлюзы-вейпоинты (XFCC). Кроме того, в тестовом режиме появился компонент agentgateway, оптимизированный под сетевой трафик AI-агентов и MCP-инфраструктуры. Istio получил полную нативную поддержку Helm v4 (включая Server-Side Apply), что устранило давние конфликты прав на вебхуках при апгрейдах. Для защиты управляющей панели istiod от OOM-киллов была интегрирована библиотека автоматического управления памятью (GOMEMLIMIT), а в прокси ztunnel добавлена поддержка списков отзыва сертификатов (CRL) для повышения безопасности. ⚪️ OpenBSD 7.9 Релиз с упором на архитектуру AMD64 (x86_64). Увеличили CPU процессора с 64 до 255 для поддержки серверов на Intel Xeon и AMD EPYC, исправили графический движок AMDGPU и обновили DRM до Linux v6.18.22. Поправили и сетевой стек со встроенным IPv6 SLAAC и отслеживанием source, state. ⚪️ Exam vouchers от Microsoft Возможность бесплатно получить сертификации по Azure, AI, Security, Cloud и DevOps. На каждый аккаунт по 2 ваучера. Проходите учебный путь и набираете 80% practice assessment, за это приходит ваучер. AI-900, AI-103, AI-300(MLOps), SC-500 и другие. Дедлайн — 31 мая. @DevOpsKaz 😛

🔥 Выступите с докладом на Cloud Native Community Day — в Алматы 13 августа Мы готовим новый митап на 100-150 человек — и ищем сильных инженеров, которые разбираются в технологиях CNCF и готовы выступить с докладом на основе своего реального опыта. Нам интересны любые технологии CNCF: ⚪️ Kubernetes ⚪️ Service Mesh ⚪️ Observability ⚪️ Storage ⚪️ CI/CD ⚪️ безопасность ⚪️ сетевое взаимодействие и др. 👈 Подайте заявку как спикер Какие доклады нам нужны: ⚪️ От инженеров, которые каждый день держат продакшн ⚪️ От инженеров, которые хотят поделиться реальным кейсом ⚪️ Как вы строили платформу и с чем столкнулись ⚪️ Как дебажили сложные инциденты ⚪️ Какие инструменты внедрили и как это убрало боль (или добавило новую) ​Что предлагаем спикерам: ⚪️ ​Официальный ивент CNCF — ваше выступление станет частью глобальной экосистемы ​⚪️ Аудитория: 100-150 инженеров (SRE, DevOps, Tech Leads) ​⚪️ Атмосфера: максимально теплая + фуршет, подарки и afterparty для нетворкинга Чувствуете, что у вас есть история, которая спасет кому-то часы дебага? 👈 Подайте заявку как спикер @DevOpsKaz 😛

⚡️ Масштабное партнерство для ИТ-рынка Казахстана: Core 24/7 и Softprom объединяют усилия Для казахстанского бизнеса растут требования к ИТ-инфраструктуре: высокая доступность, глубинная аналитика данных и жесткое соблюдение локального законодательства. Мы вместе с Softprom объединяем компетенции, чтобы предложить рынку РК новые технологические решения: ⚪️ Гибридные облачные архитектуры «под ключ» Создаем бесшовные и отказоустойчивые связки: надежный локальный on-premise контур в Республике Казахстан + масштабируемые мощности публичного облака AWS. ⚪️ AI/ML-решения мирового уровня (с официальной поддержкой лидеров рынка) Мы работаем в сфере ИИ с крупнейшими глобальными вендорами. Наше партнерство открывает бизнесу Казахстана доступ к технологиям от Google и Anthropic. Мы интегрируем продвинутые модели ИИ и машинного обучения в гибридные инфраструктуры, гарантируя главное — полное соблюдение требований регуляторов по локализации и хранению данных внутри страны. ⚪️ Готовые референс-архитектуры для РК Мы не просто консультируем — мы формируем библиотеку типовых решений и лучших практик, адаптированных под специфику, законы и масштабы казахстанского бизнеса.

❗️ Что это даст бизнесу в Казахстане? Гибкость и инновации ИИ-гигантов и AWS, сохраняя данные в периметре страны и под полным контролем. Скорость развертывания ИТ-проектов увеличивается, а риски комплаенса сводятся к нулю.

Делаем все, чтобы синергия Core 24/7 и Softprom стала мощным драйвером цифровой трансформации для финансового сектора, ритейла, логистики и enterprise-компаний Казахстана. Следите за нашими анонсами. В будущем мы поделимся первыми совместными кейсами и готовыми архитектурными шаблонами. @DevOpsKaz 😛

⚡️ Первый митап нового сезона Halyk Tech Sprints: Level Up Rocket Tech приглашает вас на Business & System Analysis Meetup. Расскажут о бизнес- и системном анализе в цифровых продуктах: как выстраивается взаимодействие между бизнесом и разработкой, как принимаются продуктовые решения и как избежать типичных ошибок в работе с требованиями. ⚪️ Эффективные партнёрства в продуктах ⚪️ Ошибки в бизнес- и системном анализе ⚪️ Взаимодействие бизнеса и разработки ⚪️ Работа с требованиями и принятие решений 📅 20 мая | 19:00 — Алматы, ТРЦ Forum, зал Event Space 👈 Участие бесплатное по регистрации @DevOpsKaz 😛

⚡️ Прощай, .spec.externalIPs В релизе Kubernetes v1.36 официально объявили старевшим (deprecated) поле .spec.externalIPs. Эта функция существовала с первых версий K8s. Исторически поле использовалось для ручной привязки внешних IP к сервису. Однако API Kubernetes не проверяет права владения IP-адресом, поэтому есть вероятность нарваться на атаку. ⚪️Вектор атаки: любой пользователь с правами на создание Service в любом Namespace может указать в externalIPs чужой IP (например, адрес внешнего DNS, шлюза или соседнего сервиса). ⚪️Результат: kube-proxy перехватит этот трафик внутри кластера, что позволяет провести атаку Man-in-the-Middle (MITM) или устроить DoS. Уязвимость признана архитектурной («исправление невозможно»), поэтому функционал полностью удаляют. Таймлайн удаления: — v1.36 (мы здесь): официальный deprecation. При отправке манифестов API возвращает предупреждения. Появился Feature Gate AllowServiceExternalIPs (пока true). ~ v1.40: Отключение по умолчанию. Флаг переводится в false. kube-proxy перестает обрабатывать externalIPs, если администратор не включит его принудительно. ~ v1.43: Полное удаление кода. Поддержка механизма полностью вырезается из kube-proxy. ~ v1.46: Финальная зачистка API-сервера. На что мигрировать? Если вы используете externalIPs, у вас есть 3 безопасные альтернативы: ⚪️для Bare-Metal: переход на Service.spec.type: LoadBalancer с использованием MetalLB или Kube-vip. Они выделяют IP строго из доверенных пулов с помощью ARP/BGP. ⚪️для L7/L4 трафика: использование Gateway API или классических Ingress-контроллеров. Доступ к публикации маршрутов здесь жестко разграничен через RBAC. ⚪️для простых задач: старый добрый Service.spec.type: NodePort (выделение портов строго контролируется кластером). Проверить кластер на наличие уязвимых сервисов:

kubectl get svc -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.externalIPs}{"\n"}{end}' | grep -v '\[\]'

@DevOpsKaz 😛

📅 Call for Papers на DevOpsDays Almaty 2026 Следующий DevOpsDays Almaty состоится в октябре 2026 (точная дата и место уточняются) 👈 Регистрируйтесь спикером, если хотите выступить с докладом Какие доклады мы ждем:

⚪️Инструменты и платформы Практика использования ОС, СУБД, CI/CD пайплайнов, контейнеризации, Kubernetes и оркестрации, систем мониторинга, логирования и observability-стека.

⚪️Безопасность и DevSecOps Интеграция безопасности в процессы разработки, управление уязвимостями, защита инфраструктуры и данных, secure-by-design подходы.

⚪️Облака и инфраструктура Переход в облако, мульти- и гибридные архитектуры, serverless-подходы, оптимизация затрат и производительности.

⚪️Практические кейсы Реальные истории: что сработало, что нет, какие компромиссы пришлось принять и какие уроки вы извлекли.

⚪️Люди, процессы и культура Построение эффективных команд, развитие DevOps-культуры, взаимодействие между разработкой, эксплуатацией и бизнесом.

⚪️Новые подходы и будущее DevOps Тренды и эксперименты на практике, включая: – применение AI и ML в инфраструктуре; – использование агентов в продакшене (LLM-агенты, auto-remediation, AI-assisted ops); – MCP-серверы и их роль в DevOps-пайплайнах; – predictive autoscaling и адаптивные системы; – log clustering, noise reduction и интеллектуальный анализ логов; – автоматизация принятия решений и self-healing системы.

[Форма регистрации] @DevOpsKaz 😛

⚡️ Доклад с DevOpsDays Tashkent от Core 24/7 Для самых любознательных, как и обещали, целая куча материала с доклада "Ingress умер, да здравствует Gateway!" на DevOpsDays Tashkent от Байгашева Мираса. Несмотря на относительно небольшой срок работы в DevOps, Мирас уже активно выступает на площадках CNCF Kazakhstan и Yandex Cloud и фокусируется на современных подходах, стабильности и улучшении инфраструктуры. 👈 Смотреть доклад Мираса ⚪️Разбор CVE-2025-1974 от Fortinet — мирового лидера решений и систем по кибербезопасности ⚪️Что предоставил Nginx в мире Gateway API? Контроллер Nginx Gateway Fabric ⚪️Пример создания HTTPRoute с автоматическими Reference Grant в виде Helm чарта ⚪️Официальный скрипт Kubernetes для миграции манифестов Ingress-nginx в формат Gateway ⚪️Официальный гайд Kubernetes по миграции с Ingress-nginx ⚪️Больше про Service Mesh через Gateway API — Project GAMMA ⚪️Официальные гайды по переносу аннотаций Ingress-nginx в формат Gateway API ⚪️Интеграция Gateway API и cert-manager ⚪️Inference Extension для балансировки ИИ трафика в Gateway API ⚪️Результаты сравнения базовых Service и Inference Extension ресурсов для ИИ трафика ⚪️Реальный пример использования Inference Extension с моделью llama ⚪️Самый навороченный контроллер Gateway API — AgentGateway ⚪️Какие контроллеры уже имплементированы для Gateway API ⚪️Как выбрать контроллер — бенчмарки всех доступных контроллеров @DevOpsKaz 😛

🔥 DevOpsDays Tashkent 2026 — начинается 👈 Онлайн-трансляция В программе: ⚪️Metal3 – Kubernetes Provisioning on Baremetal ⚪️Amazon SQS за 5 минут ⚪️Эволюция надежности: как мы трансформировали SRE в Yandex Go за 6 лет ⚪️CI/CD для мобильных приложений (Android, iOS) ⚪️Gateway API: Ingress мёртв, да здравствует Gateway! ⚪️Dynamic Resource Allocation: от статических реквестов к гибкому планированию ⚪️А также воркшопы и другие активности Подключайтесь и смотрите доклады — это бесплатно. @DevOpsKaz 😛