Kubernetes *

Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито. 

В статье рассказываю, как мы строим ML-платформу на базе Kubeflow. От первых DevBox-решений мы пришли к набору небольших юнит-платформ, которые разные команды развивали под свои бизнес-задачи и связывали между собой. Со временем возникла задача объединить эти решения в единую платформу. Поделюсь, как мы это делали, с какими проблемами столкнулись и как их решили. И немного о том, как должны выглядеть агентские платформы, когда за управление инфраструктурой отвечают агенты. 

Статья будет полезна не только тем, кто разрабатывает и использует платформы в больших компаниях, но и тем, кто работает на DevBox-машинах или небольших платформах для юнит-команд от 10 до 100 человек.

Приглашаем на вебинар, где разберём, как с помощью Axiom JDK Certified внедрять криптографию по ГОСТ без сложной настройки и лишнего кода. На вебинаре покажем живую демонстрацию: как Java-сервисы внутри Kubernetes устанавливают защищённое mTLS-соединение с использованием Axiom JDK Certified, КриптоПро/JTLS (ГОСТ TLS).

Что будет на вебинаре:

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

Меня зовут Даниил Рахновский, я ведущий архитектор в Orion soft. В этой статье мы поговорим о том, почему опасно доверять секреты контейнерам, рассмотрим, как упорядочить работу с секретами в Kubernetes с помощью системы управления секретами и какие встроенные инструменты в этом помогают.

Схема входящего траффика в кластер Kubernetes простая: web → Envoy Gateway → Ingress Nginx → backend. За Ingress Nginx, помимо обычного HTTP, живут долгоживущие WebSocket-соединения. Штатная нагрузка - около 100 RPS. Ничего экзотического.

В один прекрасный день всё в кластере легло. Клиенты получают 503/500. В логах Envoy - флаг UF и upstream_reset_before_response_started{connection_timeout}. То есть ingress-nginx просто перестал отвечать.

Дальше - два часа разбора и довольно красивая цепочка причин, которая началась с банального reload, а закончилась на том, как ядро считает лимит потоков при старте виртуалки.

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

Хочу рассказать про несколько новых возможностей AWS Elastic Container Registry (ECR), о которых, как мне кажеться, знают немногие.

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

eBPF часто подают как кнопку «ускорить Kubernetes», но на практике всё сложнее. Он действительно помогает уйти от тяжёлых цепочек iptables, снизить задержки и получить наблюдаемость ближе к ядру Linux. Но стоит перейти от L4 к L7, включить глубокую инспекцию трафика или mTLS — и бесплатная магия заканчивается. Разбираем, где eBPF меняет правила игры, а где всё ещё приходится считать оверхед.

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

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

Сканер находил уязвимости, DefectDojo их послушно складировал. А мы каждый раз вручную разбирали кучу тикетов, отделяя реальные угрозы от ложных срабатываний. Особенно болезненно это ощущалось во время подготовки релиза, когда каждая минута на счету.

Проблема была не в инструментах — они исправно работали и возвращали отчеты о найденных уязвимостях — а в отсутствии «взаимопонимания». Нужно было как-то намекнуть Trivy, что конкретная уязвимость не эксплуатируется в нашем контексте, ее следует пометить как 'not_affected' и больше не отвлекать нас. Таким «мостиком» стал для нас OpenVEX.

Меня зовут Роман Корчагин, я занимаюсь процессами безопасной разработки в контейнерной платформе «Штурвал». В статье расскажу, как мы интегрировали генерацию VEX-файлов в пайплайн, и почему разработчики больше не вздрагивают при слове «сканирование».

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).

Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.

Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.

Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.

В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

Штатная ситуация оказалась задачей со звёздочкой: кластер кинул алерт о том, что заканчивается сеть подов, но ни одно решение «из методички» не подходило, а вытаскивать кластер из прода было нельзя.

В статье расскажу, как мы не просто расширили подсеть подов, но сделали это на работающем кластере и не потеряли при этом данные. Что важно — трюк сработает на любом дистрибутиве Kubernetes и CNI.

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

Одними из первых в России выпустили патчи безопасности в SELECTOS и закрыли уязвимости в ядре Linux. Расширили список моделей в FMC, чтобы вы могли автоматизировать больше задач. Больше деталей — под катом.

Немного практики для "пощупать" HPA в кластере, поиграться параметрами масштабирования. Можно было бы быстро перейти от теории к практике, ну или наоборот. В примерах используется масштабирование на основе очереди RabbitMQ. Можно использовать minikube, MicroK8s, или где вам удобно... Для удобства развёртывания примеры k8s-hpa-rabbitmq-demo.

Если вы запускаете GPU-нагрузки (графические ускорители) на Kubernetes — vLLM, Triton, обучающие задачи или более новые стеки агентного инференса, — вы наверняка сталкивались со знакомой проблемой: стандартный автоскейлинг по-прежнему мыслит в категориях CPU и памяти, а GPU, который реально делает работу, остается невидимым. Из-за этого простаивает дорогая емкость ускорителей, растет задержка инференса и расходуется лишняя энергия — ровно там, где компании пытаются ответственно масштабировать LLM и Agentic Ops (подходы к эксплуатации Agentic-систем).

VK Cloud перевела статью автора, который хотел бы, чтобы KEDA масштабировался по сигналам, которые важны для GPU-нагрузок: утилизации, памяти, температуре и энергопотреблению. На практике это не только вопрос стоимости. Это еще и вопрос GreenOps (экологичный подход к эксплуатации с минимизацией углеродного следа): впустую потраченные GPU-циклы напрямую превращаются в потраченную энергию и более высокие выбросы категории Scope 3 (косвенные выбросы в цепочке создания стоимости).

Оказалось, что это сложнее, чем кажется. Дальше повествование идет от его лица

Я реализовал свою первую задачу по замене «Яндекс Диска», довёл скорость до 1,1 ГБ/с и пошёл дальше — установил Kubernetes дома. Я не инженер DevOps, но на своём кластере из старых Mac mini я запустил полноценный K8s с Managed Services.

Сначала хотелось просто скрывать случайные токены по энтропии. Потом выяснилось, что UUID, trace id и номера карт ломают эту идею, и пришлось собирать более честный фильтр логов.

Когда Kubernetes-кластеров становится несколько, сложность быстро перестаёт ограничиваться самим развёртыванием. Приходится удерживать контекст сразу между инфраструктурой, инструментами и командами.

В Nova Container Platform для таких задач развивается Cluster Manager: он показывает список кластеров, хранит часть параметров и позволяет запускать операции через интерфейс и API.

Меня зовут Семен Месилов, я технический лидер Nova Container Platform. В статье расскажу, как мы подошли к этой задаче, и что уже получилось сделать в Cluster Manager.

Привет, я Сергей Истомин, DevOps-инженер в KTS. А ниже моя история про построение мультитенантного скоупа кластеров VictoriaMetrics с разными периодами хранения метрик.

Статья будет о том, как собрать систему одновременно и простую, и сложную. Простую потому, что каждый поток данных в ней лаконичный и линейный, и сложную потому, что совокупности этих потоков комбинируются и интегрируются в общие компоненты. Система будет построена на редакции Community Edition.

Надеюсь, что я вас хорошенько запутал и при этом заинтриговал.

На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.

Статья о том, почему любая «нерешаемая» проблема — это «пока недостаточно изученная» проблема. От случайных догадок — к системному исследованию и пул-реквесту с фиксом прямо в Linux.