Kubernetes *

В августе мы добавили аддоны в Managed Kubernetes, обновили конфигурации выделенных серверов и парольную политику в IAM. И не только. Все подробности — под катом.

На связи Борис Литвиненко из команды NOCDEV в Yandex Infrastructure — наша группа занимается автоматизацией сетей всего Яндекса. В прошлом году я уже рассказал о том, как и почему наши сетевые сервисы живут на отдельном железе с развёрнутым k8s‑кластером, избегая кольцевых зависимостей с остальной инфраструктурой компании. Среди прочего на тот момент мы использовали Calico VXLAN — с нашим разнообразным железом нам был нужен overlay, а Cilium тогда не умел работать с IPv6 для VXLAN. Однако всё меняется.

В 2025 году попытка включить Calico eBPF в нашем K8s‑кластере вылилась в запуск Cilium, в новом релизе которого как раз добавили поддержку IPv6 underlay для VXLAN. Поэтому сегодня я расскажу, как мы вместе с Кириллом Глушенковым @kglushen протестировали новый Cilium 1.18 — а заодно перешли с самописных salt‑рецептов для kubeadm на kubespray, столкнулись с не такими уж простыми особенностями dualstack, а ещё немного повайбкодили. Под катом — все наши приключения с нелинейным сюжетом.      

Мы не раз разбирали в своём блоге теорию и практику по разным стратегиям развёртывания новой версии приложения в Kubernetes. Сегодня рассмотрим ещё одну реализацию канареечного деплоя: с пассивными healthcheck и использованием Argo Rollouts и Istio. Этот вариант подойдёт, если к вашему приложению обращаются не через Ingress, а ходят внутри кластера по адресу service. Или если вы хотите видеть, что происходит с пользовательским трафиком на каждом из этапов обновления.

Sealos удалось сократить время активации доменов на Kubernetes с 10 минут до всего 5 секунд. В статье раскрыты технические детали оптимизации Ingress с помощью Higress, Istio и Envoy, а также оригинальные алгоритмы и подходы, которые помогли преодолеть узкие места и улучшить масштабируемость кластера. Читайте, как повысить производительность и надёжность своей инфраструктуры.

В начале июля мы в Linx Cloud запустили облачную платформу на OpenStack. В процессе работы мы изучали открытые решения в этой экосистеме. Некоторые из них, хотя и не были для нас актуальны на текущем этапе, показались нам интересными, и мы решили поделиться находками здесь.

Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. У нас высоконагруженный сервис торговых операций. И раз в неделю, как по расписанию, раздавался панический звонок: «Опять пропали запросы!». Мы неслись смотреть логи — а там... ничего. Ни ошибок, ни падений. Никаких пятисотых, только стабильные двухсотые. Стенды dev и prod молчали, как рыбы. Запросы загадочным образом появлялись через некоторое время, и всё работало, пока история не повторялась снова. Это был не баг, это был призрак. Призрак в сети.

Сегодня я расскажу, как мы его поймали.

Дисклеймер: сказанное ниже относится к ситуации, когда в компании нет отдела (или хотя бы архитектора), который занимается созданием и развитием внутренних технологий и продукты компании тоже не являются инфраструктурными технологиями.

Я много лет занимался тех. консалтингом и работал архитектором в компаниях с кучей внутренних команд со своими проектами и один из самых частых вопросов:

Можно ли запустить Kubernetes с Cluster API на Proxmox прямо на Orange Pi 5 Plus? Да, и это отличный способ собрать домашнюю лабораторию. В этой статье я описал как развернул Kubernetes-кластер с помощью Cluster API на Proxmox, установленном на Orange Pi 5 Plus ARM64 и получил компактное, но мощное решение для домашнего k8s-стенда

Привет, Хабр! Меня зовут Максим Уймин, в этой статье я расскажу про почту, про распределенные очереди, немножко про FUSE и файловые системы.

Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. Триггером масштабирования кластера может быть не утилизация, а события от внешних систем — например, очереди сообщений Kafka, системы мониторинга Prometheus или от платформы CI/CD.

Всем привет! Меня зовут Илья Смирнов, я архитектор решений в Cloud.ru. Расскажу, как лучше справляться с пиковыми нагрузками, если вы развернули свое приложение в кластере Kubernetes. Вместе запустим такое демо-приложение и посмотрим, как с ним работают классические подходы автомасштабирования — в этой части, а затем попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler) — в следующей. Не пропустите!

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

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

Сегодня официально выпустили новую версию Kubernetes — 1.34. Собрали обзор со всеми изменениями. Среди главных нововведений — отслеживание здоровья устройств при DRA, тонкая настройка рестарта контейнеров в подах, асинхронная обработка API-вызовов, нативная доставка сертификатов X.509 в поды и новая разновидность YAML для описания конфигураций.

Современные платформы для машинного обучения (ML)  — это комплексные системы. В их состав входит множество разнообразных инструментов — от средств обработки данных до систем развертывания моделей. А по мере увеличения масштаба и сложности таких платформ на первый план выходит вопрос эффективного управления доступом и безопасностью. Решить его можно, внедрив технологию Single Sign-On (SSO), которая позволяет пользователям получать доступ сразу ко всем компонентам платформы. 

Меня зовут Дмитрий Матушкин, я инженер платформы Nova Container Platfrom в Orion soft. В этой статье мы подробно рассмотрим процесс внедрения и настройки StarVault (аналог HashiCorp Vault, но все действия похожи на те, что нужно произвести в Vault) с использованием технологии OpenID Connect (OIDC) в качестве единой точки входа для популярных компонентов ML-платформы: MLflow, Airflow и JupyterHub.   

Все данные сервисы будут развернуты в кластере Kubernetes. Для удобства развертывания и настройки ванильного кластера я буду использовать решение Nova Container Platform, которое позволяет получить готовый кластер за 10 минут. Также будем считать, что в StarVault уже создан OIDC provider, например, с названием "some_provider".

Теперь ресурсы контейнеров в Kubernetes можно менять «на лету» — без перезапуска и простоев. В статье рассказываем, как работает in-place resize, где эта функция реально спасает приложения от перегрузки и какие ограничения стоит учитывать на практике.

Для сетевиков от сетевика

Там внизу, под катом, повествование о том, как сетевик кубернетес с Calico настраивал

Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.

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

HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

Многие инженеры теряются в нюансах настройки allowPrivilegeEscalation в Kubernetes. Автор статьи простым языком объясняет, зачем нужен этот флаг, как он работает и почему его наличие или отсутствие не критично для большинства сценариев. Если хотите понять, как устроена безопасность контейнеров, — эта статья для вас.

Привет, Хабр! Меня зовут Валентин Вертелецкий, я DevOps в СберТехе, занимаюсь развитием Platform V Kintsugi — это графическая консоль для сопровождения Postgres-like СУБД. Наш продукт построен на микросервисной архитектуре и сначала разрабатывался с использованием базовой функциональности Kubernetes — там нет встроенных механизмов аутентификации, авторизации, управления доступом и шифрования трафика. Когда же у нас стало больше сервисов, нам понадобилось повысить защиту и отказоустойчивость, добавить возможности управления доступом.

Мы опираемся на подход Zero Trust: ни одному элементу системы не доверяем по умолчанию. Каждый запрос проверяется, привилегии для администраторов минимальны, трафик валидируется и шифруется. Нам предстояло обеспечить надёжную аутентификацию и авторизацию, а также централизованный контроль и мониторинг запросов. В этом нам помогла технология Service Mesh. 

Для управления микросервисами в Kubernetes мы используем Platform V Synapse Service Mesh от СберТеха — это решение на основе платформы Istio. Покажу, как всё работает у нас. Плюс, я подготовил демо-проект для тестирования кейсов (ссылка в конце статьи). Надеюсь, он будет полезен командам, работающим с микросервисами. 

В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

В этой статье мы рассмотрим, те преимущества, которые дает использование GitOps, а также развеем некоторые мифы вокруг GitOps..

Делимся практическим опытом миграции PostgreSQL Patroni из Kubernetes на «железные» серверы. Автор рассказывает про выбор метода переноса, настройку standby-кластера, обновление конфигураций и управление трафиком приложений через pgbouncer. Полезно для DevOps и инженеров, которые хотят избежать сбоев и обеспечить плавный переход на bare-metal-инфраструктуру.