Kubernetes *

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

Представьте: у вас десятки микросервисов, миллионы логов и трассировок, а ваша задача — поддерживать SLA и не дать системе сломаться. Ручная настройка SLO (Service Level Objectives) и мониторинг SLI (Service Level Indicators) превращается в кошмар.

SLO-Scout решает эту проблему с помощью AI, анализа телеметрии и автоматизации, позволяя SRE сосредоточиться на надежности, а не на ручной рутине.

Еще до открытия для себя практик Dev-ops я использовал Docker для упаковки и быстрой доставки кода на сервера (всё делалось ручками, я еще не знал про CI/CD xD). Со временем мои приложения становились больше, появлялись микросервисы, убирался монолит. И управлять ручками или через Portainer всей архитектурой было слегка сложновато. Простой, куча вопросов, падение контейнеров, рост нагрузки и все в этом духе. Тогда-то я и открыл для себя кубер.

Привет, Хабр. Это октябрьский дайджест по инфраструктуре и данным: безопасность Kubernetes, IaC и GitOps, Kafka и балансировка в Angie, Postgres 17/FDW, OpenSearch, файловые системы Linux и многое другое. В нем мы рассказываем об актуальных программах, а также приглашаем на бесплатные уроки от экспертов индустрии. Каждый сможет найти что-то полезное для себя.

Вы сделали заказ в интернет-магазине, а он внезапно завис в самый разгар скидок. За кулисами этого сервиса работают сотни строк кода и ещё больше человеческой поддержки. DevOps — это  способ организовать эту работу так, чтобы новые функции доходили до вас быстрее и без сбоев. Он объединяет разработчиков, тестировщиков и операторов, автоматизируя рутинные шаги и следя за сервисом в режиме реального времени. Звучит хорошо, но на практике автоматизация закрывает далеко не всё.

В статье рассмотрим, что за зверь такой DevOps. Когда работает, а когда спотыкается и где автоматизация работает, а где нужна платформа и процессы. Даже если вы не айтишник — переходите под кат.

Недавно мы реализовали интеграцию NeuVector с Deckhouse Kubernetes Platform по запросу сообщества. Тем не менее наш практический опыт показывает, что NeuVector нельзя считать надёжным инструментом обеспечения безопасности кластеров и контейнеров в production-средах.

В статье набрасываем на вентилятор приводим аргументы, подтверждающие эту позицию, несмотря на отдельные сценарии, когда использование NeuVector может быть оправдано. А ещё предлагаем современные и надёжные Open Source-альтернативы.

Привет, Хабр! Это Станислав Егоркин, инженер юнита k8s департамента разработки Infrastructure в Авито. В одной из своих прошлых статей я описал, как мы детектируем проблемы на нодах Kubernetes-кластеров. Логичным продолжением этой работы стала автоматизация их лечения. В этой статье я расскажу, как у нас устроены механики Auto Healing.

Привет, Хабр!

Помните тот момент, когда вы в очередной раз выставляли requests и limits для вашего пода, основываясь на... чем, собственно? На глазок? На данных «ну там вроде 128 мегабайт хватает»? На результатах пятиминутного стресс‑теста, который показал, что под нагрузкой нужно 2 ядра? Мы все через это проходили. Получается классическая ситуация: либо мы недодаем ресурсов, и наш падает от OOMKilled в самый неподходящий момент, либо мы перестраховываемся и заливаем в него гигабайты памяти и ядра, которые он использует раз в год под Новый Год, а кластер тем временем плачет от нехватки нод.

Горизонтальное масштабирование (HPA) — наш спаситель, он известен всем и каждому. Увеличилась нагрузка — запустил еще пару копий приложения. Красиво. Но что, если само приложение не очень‑то умеет работать в несколько копий? Или если нагрузка не «всплесковая», а просто приложение со временем начало есть больше памяти из‑за роста данных? Тут подходит менее раскрученный, но полезный коллега — Vertical Pod Autoscaler (VPA).

Идея VPA до проста: он смотрит на фактическое потребление ресурсов вашими подами и говорит: «твоему приложению на самом деле нужно не 100 милликор, а стабильно 150, давай исправим эту несправедливость». А в продвинутом режиме он не просто говорит, а берет и делает. Главная загвоздка, из‑за которой многие плюются — для применения новых лимитов под нужно перезапустить, это downtime, но эту проблему можно и нужно грамотно обойти.

Привет, Хабр! Я — Калашников Сергей, DevOps‑инженер в Центре Перспективных Разработок (ex. R&D) компании Bercut. Cегодня поделюсь опытом внедрения систем на базе Tarantool и Tarantool Vshard в оркестратор Kubernetes.

Tarantool — платформа, которая включает в себя in‑memory базу данных, а также встроенный сервер приложений. На базе этой платформы наша команда разрабатывает различные информационные системы, расширяя функциональность с применением языков Lua, Rust, C\C++.

Несмотря на все очевидные плюсы Tarantool, он не является тривиальным в части конфигурирования и bootstrap. Это привело нас к разработке Operator для Kubernetes, который обеспечивает развертывание и конфигурирование кластеров на базе Tarantool и Tarantool Vshard.

Привет, Хабр! На связи Тимур Парфёнов, директор департамента эксплуатации Рунити. Сегодня поговорим о Kubernetes. Точнее — о том, почему он стал стандартом де-факто для оркестрации контейнеров и зачем большинству проектов нужен Kubernetes как сервис (KaaS). Статья будет особенно интересна тем, кто еще не знаком с K8s или только планирует его использовать в разработке. Ну, а старичков приглашаю тоже — присоединиться к обсуждению болей и радостей этой технологии.

Мониторинг служебных компонентов Kubernetes в пространстве kube-system часто остается за пределами первоначальной настройки кластера. Однако стабильность таких компонентов как kube-apiserver, kube-scheduler и kube-controller-manager напрямую определяет работоспособность всей системы. Сбор метрик с этих подов требует точной настройки механизма обнаружения и безопасного доступа к их эндпоинтам.

Привет, Хабр! Меня зовут Катя Низовцева, я системный администратор в Selectel. В этой статье я покажу практическую методику развертывания vmagent с помощью Helm и настройки конфигураций для сбора метрик с ключевых системных компонентов. Это обеспечит видимость их состояния без избыточной сложности. Мы увидим в Victoria Metrics Cluster метрики, снимаемые с подов в служебном неймспейсе kube-system. Но обо всем по порядку.

Недавно мы представили MWS Container Platform — платформу для управления приложениями и инфраструктурой на базе Kubernetes. А сегодня в статье предлагаем взглянуть на гайды по теме ИБ при работе с оркестратором: базовые материалы для начинающих, референсы для опытных инженеров и разборы распространенных ошибок. В целом материалам будет полезен системным администраторам, DevOps-инженерам и тем, кто начинает работать с Kubernetes.

Я работаю в одном крупном российском банке, где занимаюсь разработкой распределённых систем. За последние несколько лет наша архитектура заметно усложнилась — часть сервисов работает в OpenShift, часть на виртуалках, а кое-что до сих пор крутится на «железе».

Основная боль заключалась в том, что у нас не было единой системы мониторинга. Метрики мы собирали из разных источников: где-то стоял Prometheus, где-то — Zabbix, в Kafka писали свои дашборды, а для C++ приложений вообще не было нормального мониторинга. Каждый инцидент превращался в расследование: мы переключались между тремя-четырьмя консолями, сверяли логи, писали временные скрипты для выгрузки метрик. В среднем на поиск корневой причины (root cause analysis) у нас уходило от нескольких часов до пары дней.

Autoscaler призван оптимизировать ресурсы CPU и памяти кластеров. Но что, если он сам становится источником проблем? Обычный алерт о пропавших метриках обернулся расследованием на всю ночь. Шаг за шагом команда выясняла, почему VPA начал агрессивно пересоздавать поды, пока не дошла до скрытой настройки, едва не похоронившей кластер. Подробности в статье.

Всем привет! Это вновь Илья Смирнов, архитектор решений из Cloud.ru. В прошлой статье мы рассмотрели традиционные подходы к масштабированию подов и узлов кластера Kubernetes. Но остался нерешенным вопрос — как масштабировать приложение по событиям из внешней системы? Ведь мы хотим, чтобы каждое новое сообщение в очереди RabbitMQ масштабировало нагрузку вверх, реализовать event-driven подход и масштабировать приложение не по метрикам утилизации ресурсов, а по факту появления новых событий от внешних систем. Так как же быть?

Я предлагаю использовать решение KEDA 😉

Привет, Хабр! С вами команда Russtech. Сегодня мы хотим рассказать о работе Russ Programmatic, нашего подразделения, разработавшего систему продажи рекламного инвентаря с помощью аукционов в реальном времени. Программатик в DOOH имеет ряд отличий от традиционного digital-программатика. В этой статье мы обсудим эти ключевые особенности и поделимся нашим опытом внедрения программатических продаж.

Привет, меня зовут Анатолий, я руковожу группой нагрузочного тестирования в ЮMoney. Началась осень, и не за горами сезон распродаж: магазины уже готовятся к пиковым нагрузкам, продумывают акции и спецпредложения, обновляют ассортимент, договариваются с поставщиками. ЮKassa, наш сервис электронных платежей, тоже в ожидании сезона скидок. В этой статье я расскажу, как мы к нему готовимся, что помогает нашей системе выдержать пиковые нагрузки и как сделать так, чтобы все клиенты остались довольны.

В августе мы добавили аддоны в 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. Или если вы хотите видеть, что происходит с пользовательским трафиком на каждом из этапов обновления.