Что внутри контейнера: спикеры Kuber Community Day 2026 — о вызовах в области Kubernetes

Открывая конференцию, исполнительный директор «Лаборатории Числитель» Владимир Беляевский отметил, что профессиональное сообщество вокруг Kubernetes разрастается: это видно как по количеству регистраций на Kuber Community Day, так и по количеству подписчиков в ТГ-канале комьюнити.

Исполнительный директор «Лаборатории Числитель» Владимир Беляевский
Фото: архив конференции Kuber Community Day

«Круто, когда понимаешь, что ты не один: многие люди тебе помогают, другие — нуждаются в твоей помощи. Все они объединяются на подобных мероприятиях. У нас большое активное комьюнити из специалистов в области DevOps, микросервисов и контейнеров. Kuber Community Day создает сообщество для сообщества. Это открытое мероприятие для всех, здесь нет никакой рекламы, каждый может подать доклад и поделиться опытом», — рассказал он.

По данным организаторов, в конференции приняли участие около 1200 человек: 400 специалистов посетили мероприятие очно, а 800 — посмотрели онлайн-трансляцию. 

Программа конференции состояла из двух параллельных треков: Value (с акцентом на бизнес-ценность) и Techno (с фокусом на инженерный опыт). За ее содержание отвечал программный комитет, объединивший ведущих экспертов из таких компаний, как МТС-Банк, «Боцман», Yandex Cloud, Ænix, РТК ИТ, «Лаборатория Числитель», «Инфосистемы Джет». Всего на конференции выступили 26 спикеров из «Лаборатории Числитель», «Инфосистемы Джет», MWS, «СберЗдоровья», «Райффайзенбанка», OpsMaster, «Почтатех» и других компаний.

ИИ как помощник DevOps-инженера

Senior DevOps компании МТС Web Services (MWS) Анастасия Калугина рассказала о том, как в компании выбирали и внедряли ИИ-инструменты для автоматизации одной из рутинных задач: анализа состояния K8s-кластеров. По ее словам, интеллектуальные помощники экономят время специалистов и компенсируют дефицит DevOps-инженеров в небольших командах. При этом все решения, которые принимает нейросеть, обязательно валидируются инженерами.

Для выбора оптимального решения специалисты провели R&D: определили самые частые кейсы в рамках поддержки Kubernetes-кластера, выбрали наиболее популярные модели (внешнюю Grok 4 и внутреннюю Gwen 2.5) и протестировали различные инструменты (K8sGPT, kubectl-ai, DevX Agent). По итогам этого этапа в MWS начали использовать связку из K8sGPT и kubectl-ai на внутренней модели (по соображениям безопасности).

«Работа K8sGPT основана на встроенных шаблонах, которые, в свою очередь, базируются на самых распространенных кейсах. Для данного элемента поддержка ИИ опциональна: он может анализировать и без ИИ, просто согласно этим шаблонам. Kubectl-ai предназначен не только для анализа, но и для управления кластером Kubernetes. Анализ происходит непосредственно через модель: задается промпт, и модель действует с помощью стандартных kubectl-ai-команд. Эти инструменты дополняют друг друга, и в результате мы получаем более полный анализ. Наш инструмент прошел успешный пилот, был получен положительный фидбек, и мы собираемся дальше развивать и внедрять наш пайплайн в команды», — пояснила Анастасия Калугина.

Senior DevOps компании МТС Web Services Анастасия Калугина
Фото: архив конференции Kuber Community Day

Мастер-класс по созданию оператора

Настоящий аншлаг собрал CTO компании Hilbert Team Алексей Цыкунов, который провел мастер-класс по созданию оператора — программного расширения для Kubernetes — на примере оператора резервного копирования Vault. Он объяснил назначение и принцип работы таких инструментов.

В теоретической части спикер коснулся компонентов кластера Kubernetes: управляющего слоя kube-apiserver, инструмента управления kube-controller-manager, исполняющего компонента kubelet и других.

CTO компании Hilbert Team Алексей Цыкунов
Фото: архив конференции Kuber Community Day

Эта база обеспечивает основную функциональность Kubernetes. Оператор, в свою очередь, расширяет возможности платформы. Для этого применяется механизм CRD (Custom Resource Definition). Контроллер/оператор — это код, который пишется в основном на Go и нужен для того, чтобы обрабатывался CRD.

Спикер объяснил разницу между контроллером и оператором: controller — это любой процесс, реализующий control loop над ресурсом Kubernetes; operator — контроллер, кодирующий операционную экспертизу: установку, обновление, бэкап, восстановление. «Термин Operator был введен в 2016 году, под ним подразумевался некий домен действий, которые осуществляются над объектом. То есть если вы делаете оператор для базы данных, то он устанавливает базу данных, делает бэкапы, реплики и так далее. В рамках одного оператора может быть реализовано много контроллеров».

Инфраструктурная основа для Kubernetes

DevOps-инженер и независимый эксперт Юлия Брунер рассказала о преимуществах специализированной операционной системы Talos для запуска и стабильной работы кластеров Kubernetes. 

Так, Talos, по сравнению с Kubespray, позволяет увеличить скорость развертывания и настройки Bootstrap-кластера, исключить необходимость доступа к SSH, снизить риски человеческих ошибок. Также с помощью Talos можно перейти от полуавтоматизированного обновления к применению API и производить апгрейд атомарно: если на узле во время обновления произойдет ошибка, система откатит программу к стабильной версии. Кроме того, Talos имеет преимущества в плане защиты от уязвимостей. В то же время эта система требует более высокого порога входа и наличия определенной экспертизы. 

DevOps Engineer, независимый эксперт Юлия Брунер
Фото: архив конференции Kuber Community Day

«Talos отлично подойдет, если у вас много кластеров и нод, вы «живете в кубах» и у вас нет Docker. На малых масштабах он тоже работает, просто в этом случае это может стать overhead. Talos — это идеальное решение, если у вас высокие требования к безопасности кластера, и вы ожидаете, что надежность будет обеспечена по умолчанию. Если для вас важно уметь управлять кластерами и узлами как кодом, централизованно, с общими современными подходами. И в том числе, если вы устали от беспорядка, который может происходить от каких-то несогласованных действий», — подвела итог Юлия Брунер.

В то же время Talos не подойдет или с ним могут возникнуть трудности, если в компании один кластер с небольшой нагрузкой, существует много legacy-приложений с нестандартными CSI, слабая команда инженеров. Также он пока практически неприменим в случаях, когда необходимо сертифицировать программный продукт или подготовить его к включению в реестр российского ПО.

Альтернативную точку зрения высказал Максим Белый, DevOps Engineer компании Ænix, в докладе «NixOS вместо Talos: когда хочется Kubernetes, но не хочется терять Linux».

Обеспечение надежности через мониторинг

О комплексном мониторинге защищенности Kubernetes говорили специалисты «СберЗдоровья» — CISO Дмитрий Тараненко и DevSecOps Илья Кукшинов. Эксперты уверены, что внедрение определенных инструментов еще не означает, что система готова предотвращать реальные атаки.

Так, в «СберЗдоровье» для обеспечения безопасности Kubernetes-кластеров применяются два инструмента. Kyverno охраняет admission-шлюз и срабатывает только на API-запросы (CREATE/UPDATE/DELETE). Falco — смотрит syscalls на нодах. Он мониторит процессы, файлы, сеть внутри контейнеров. Эти продукты не взаимодействуют, так как работают на совершенно разных уровнях, поэтому между ними появляется некая «слепая зона», которую невозможно отследить: например, API-действия, не проходящие через admission (list/get/delete/exec), изменения RBAC.

В компании провели детальный анализ уязвимостей, сформировали матрицу угроз и оценили, какие из этих угроз покрываются инструментами безопасности, а какие — нет.

Задачей специалистов было выстроить мониторинг API-запросов к Kubernetes-кластеру, выявлять и регистрировать несанкционированные запросы, получить возможность при необходимости блокировать подозрительные действия. Вариантами решения были настройка логирования для SaaS-кластера в облаке и работа с логами, использование проксирующего веб-сервера перед kube-api или написание собственного webhook-сервиса, который бы валидировал API-вызовы.

CISO «СберЗдоровья» Дмитрий Тараненко
Фото: архив конференции Kuber Community Day

В итоге был выбран последний вариант: в компании разработан kube-webhook-сервис, который запущен как сервис в кластере. Он валидирует запросы CREATE/DELETE/EXEC и другие, находит username пользователя в облаке и сообщает о его действиях. Механизм Dynamic Admission Control перехватывает и обрабатывает запросы к API до того, как они будут сохранены в системе, позволяет проверять запросы на соответствие правилам или автоматически изменять их «на лету» без перезагрузки основного сервиса.

Как уберечься от «кривого деплоя»

Один из круглых столов назывался «Цена кривого деплоя в K8s». Участники вместе с модератором Владимиром Утратенко, руководителем продукта «Штурвал», подтвердили, что все преимущества Kubernetes могут быть нивелированы из-за плохой архитектуры и других ошибок DevOps-команд, и дали рекомендации по сокращению рисков.

Участники круглого стола «Цена кривого деплоя в K8s»
Фото: архив конференции Kuber Community Day

Эксперты подчеркнули, что уровень автоматизации не должен опережать зрелость процессов. Команды можно наделять большей автономией, если они умеют быстро обнаруживать проблемы и откатываться, а платформа должна автоматически блокировать потенциально опасные изменения.

Особенности Kubernetes из облака

Эффективным вариантом развертывания Kubernetes может стать Kubernetes as a Service (KaaS) — облачный сервис, помогающий создавать и поддерживать кластеры Kubernetes. Выступление ведущего инженера-разработчика K2 Cloud Алексея Ефимова было посвящено правилам построения отказоустойчивого KaaS.

По наблюдению спикера, KaaS-кластер сильно отличается от обычного кластера Kubernetes, в основном — в части эксплуатации: он может легко интегрироваться с другими облачными сервисами, его проще кастомизировать, масштабировать, обновлять версии Kubernetes. Не нужно обслуживать кластер и вообще глубоко разбираться в том, как он работает.

«В первую очередь, KaaS нужен для того, чтобы не думать о затратах на поддержку кластера в "живом" состоянии, о том, что у вас закончится нагрузка, что нужно срочно создавать еще виртуальные машины или закупать железо. Также бывают случаи, когда нужно развернуть кластер для нового разработчика, фичи или релиза», — отметил Алексей Ефимов. Он рассказал о том, как его компания реализует проект по размещению Kubernetes в облаке с 2018 года. В частности, она разработала собственный инструмент для мониторинга.

Легко ли стать сертифицированным специалистом по Kubernetes

Для специалиста, который только начинает путь в Kubernetes или хочет повысить уровень компетенций, важным вопросом является сертификация от некоммерческого фонда CNCF (Cloud Native Computing Foundation).

Руководитель отдела DevOps-решений компании «Инфосистемы Джет» Артем Горячев
Фото: архив конференции Kuber Community Day

Руководитель отдела DevOps-решений компании «Инфосистемы Джет» Артем Горячев на основе собственного опыта пояснил, что главная ценность сертификата — в системном изучении Kubernetes. Подготовка к экзамену помогает структурировать знания о технологии, последовательно разобраться в ее ключевых компонентах и проверить уровень освоения материала. Сам сертификат становится дополнительным подтверждением квалификации и дает преимущество при трудоустройстве в ИТ-компании, которые применяют Kubernetes.

Спикер рассказал о пяти существующих треках CNCF: Kubernetes and Cloud Native Associate (KCNA), Certified Kubernetes Administrator (CKA), Certified Kubernetes Application Developer (CKAD), Kubernetes and Cloud Native Security Associate (KCSA), Certified Kubernetes Security Specialist (CKS). Он дал инструкцию, с какого трека лучше начинать и как получить сертификаты наиболее выгодным способом.

«Сертификация — это прежде всего инструмент системного изучения Kubernetes. Технология включает большое количество взаимосвязанных компонентов и абстракций, поэтому при самостоятельном изучении не всегда просто выстроить последовательную программу подготовки. Сертификационные треки задают эту структуру: определяют набор тем и компетенций, которыми необходимо овладеть, а экзамен позволяет проверить полученные знания на практике. Сам сертификат при этом становится дополнительным подтверждением квалификации специалиста и может быть преимуществом при трудоустройстве», — отметил Артем Горячев.

Тонкости применения ИИ в Kubernetes

На круглом столе «ИИ как DevOps для K8s» эксперты обсудили возможности и риски применения ИИ-инструментов для автоматизации работы инженеров.

По рассказу Алисы Кириченко, руководителя команды разработки продукта «Штурвал» («Лаборатория Числитель»), в ее коллективе активно используют ИИ для автоматизации таких функций, как тюнинг пайплайнов, написание и анализ Helm-чартов. Платформа контейнерной оркестрации «Штурвал» состоит из более чем ста компонентов. При планировании обновления версий каждый компонент проходит анализ на наличие уязвимостей, а ИИ-агент помогает исследовать репозитории, выявлять «мусорные» элементы, библиотеки, которые нужно актуализировать, и прочее. Все это трудоемкие задачи, с которыми ИИ действительно хорошо справляется.

В то же время ИИ пока нельзя доверить задачи, грамотность, целесообразность и оптимальность выполнения которых пользователь не может перепроверить. «Если вы добавляете инструмент, имеющий в своей основе ИИ, в кластер, то мы не рекомендуем позволять ему делать что-либо самостоятельно. Правильный подход: ИИ исследует и дает рекомендации, а человек уже принимает решение. И ответственность за последствия лежит именно на специалисте», — пояснила эксперт.

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

«Не каждого специалиста можно допускать к управлению кластером в продакшене, и с ИИ ситуация будет такой же. Индустрия развивается, инструменты совершенствуются, поэтому ИИ будет все активнее входить в эксплуатацию. Но внедрять его нужно постепенно и грамотно: понимать, какие задачи мы ему доверяем, какие механизмы защиты используем и где проходит граница ответственности. В первую очередь нужно формировать культуру работы с ИИ и оценивать специфику конкретных проектов и систем. Есть системы, в которых ИИ еще долго не будет применяться или не появится вообще», — дополнил Андрей Воронков, главный системный администратор ПСБ.