Kubernetes *

Многие команды уже построили вокруг Kubernetes свои внутренние платформы, но со временем они превращаются в свалку YAML’ов и разрозненных Helm-чартов. В статье показывается, как собрать из этого аккуратный «конструктор» из трёх уровней компоновки (инфраструктура, сервисы платформы, приложения), завязать всё на GitOps через Argo CD и vCluster, а затем скрыть сложность за шаблонами и CRD, чтобы разработчику было достаточно описать один WebApp-ресурс вместо возни с десятком сущностей Kubernetes.

Построение отказоустойчивой гибридной сети между локальной инфраструктурой и облаком — одна из ключевых задач при миграции. Стандартных решений здесь не существует: выбор архитектуры и технологий зависит от требований безопасности, производительности и желания избежать vendor lock-in.

Я хочу показать один из способов решения такой задачи на примере облака VK Cloud с учетом специфики его SDN-сети. Отдельно хочется добавить, что рассматриваемый в статье подход к построению сетевой связности может быть успешно применен не только в VK Cloud.

В основу статьи легли вопросы и задачи, с которыми клиенты часто обращаются к командам Presale архитекторов и Professional services VK Cloud, когда они хотят построить надежное гибридное решение для своего бизнеса.

Мне хотелось написать статью, которая будет не научно-популярным повествованием, а практическим руководством, систематизирующим имеющиеся знания по разным продуктам и сетевым технологиям.

Всем привет! На связи Александр Синичкин, ведущий архитектор CTCS – CrossTech Container Security – решения для обеспечения комплексной безопасности контейнерных сред: от сканирования образов до контроля запуска рабочих нагрузок и реагирования на инциденты в средах выполнения. Сегодня я расскажу, как и почему мы решили разрабатывать продукт CTCS, с какими сложностями столкнулись и каких ошибок могли бы избежать, куда планируем развиваться.

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

Статья поможет ответить на вопросы:

- Как понять, какую функцию ядра выбрать для использования с механизмом kprobe?

- С чего начать ее поиск?

- Какими инструментами пользоваться?

kprobe — это, по сути, ловушка, или брейкпоинт, который можно установить почти в любом месте кода ядра Linux. 

Всем привет! В этой статье поговорим про бэкапы PostgreSQL в Kubernetes через призму самого популярного опенсорс-оператора для этой СУБД — CloudNativePG. Мы расскажем о том, как внедрение нового решения на основе WAL-G позволило ускорить резервное копирование и восстановление больших баз данных и поделимся своим опытом доработки CloudNativePG.

На связи Иван Архипов, ведущий разработчик в команде платформы данных в Yandex Cloud, и я приглашаю под кат всех, кому интересна эксплуатация PostgreSQL в Kubernetes!

Kubernetes — это фундамент современных микросервисных архитектур, оркеструющий миллионы контейнеров по всему миру. Но что происходит, когда одному сервису нужно «поговорить» с другим? Как они находят друг друга в динамической среде, где поды постоянно создаются и уничтожаются? 

Управление сервисами в Kubernetes — это мост между изолированными контейнерами, обеспечивающий надежную коммуникацию в условиях постоянных изменений. В этой статье мы разберем ключевые абстракции для управления сетевым взаимодействием в Kubernetes на примере миникуба (minikube).

Эта инструкция представляет собой полное руководство по развертыванию отказоустойчивого кластера HashiCorp Vault в Kubernetes и настройке двухуровневой Public Key Infrastructure (PKI). Корневой сертификат и промежуточный CA создаются через OpenSSL, но промежуточный импортируется и настраивается в Vault для повседневного выпуска сертификатов. Инфраструктура интегрируется с cert-manager для автоматического управления жизненным циклом TLS-сертификатов.

Почему kubectl delete pvc не всегда приводит к удалению тома? В статье — детальный разбор механизма финализаторов, роль PVC Protection Controller, типичные причины зависаний и безопасные способы диагностики и восстановления.

Helm 4 принёс пользователям единственное значимое изменение — внедрение Server-Side Apply вместо 3-Way Merge. Это решает проблемы с некорректными обновлениями ресурсов, но многих возможностей Helm по-прежнему не достаёт.

Nelm — наша современная альтернатива Helm 4 — ушёл вперёд по фичам, исправлениям и улучшениям. В статье смотрим на новые возможности обоих проектов, детально разбираем их отличия и объясняем, что ждёт Nelm дальше.

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

Вместо 3 часов дебага падающего Prometheus вы смотрите дашборд, который показывает 99.9% uptime вашего мониторинга.

Это реальность с правильно настроенным стеком на основе VictoriaMetrics.

Привет! Меня зовут Виталий Шишкин, я эксперт продукта PT Container Security. За годы работы над продуктом MaxPatrol 10 мы строили аудит Linux на базе подсистемы auditd, которая решала свою задачу и достаточно просто настраивалась, но ситуация поменялась с появлением контейнеров, которые auditd корректно поддерживать не умеет. Поэтому эта задача потребовала не просто смену решения для аудита системы, но и создание целого продукта, который сможет учитывать особенности Kubernetes и используемые им технологии ядра Linux.

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.

В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

Всем привет, меня зовут Александр Зимин, я руковожу разработкой подсистемы хранения данных в Deckhouse. Сегодня хочу поговорить о хранении данных на локальных дисках в Kubernetes и поделиться тем, как мы автоматизируем их поиск и разметку для администраторов и пользователей.

На календаре 2025 год, и термин platform engineering прочно вошел в лексикон всех инженеров и менеджеров, занимающихся вопросами ИТ-инфраструктуры предприятий — примерно так же, как когда-то «DevOps», а еще раньше «Agile». К слову, предыдущие тренды порой превращались в модный хайп, под которым каждая компания понимала свое видение процессов разработки и развертывания. Но платформенная инженерия сегодня — это не просто набор практик, а системный ответ на тот уровень сложности, к которому индустрию привели облака, микросервисы, CI/CD, SRE и бесконечный поток обновлений в экосистемах OSS (Open Source Software, мир open-source инструментов).

Привет! Меня зовут Роман Христевич, я DevOps-инженер в Cloud.ru, занимаюсь плагинами и безопасностью для кластеров Kubernetes. Сегодня расскажу, как я сражался с ветряными мельницами — мусором в кластерах Kubernetes после тестирования релизов, рандомных Helm Chart и просто в автотестах. И как я эти мельницы все-таки одолел.

Если вы DevOps, SRE или системный администратор, то вам не раз и не два приходилось вычищать кластеры от отработанных Jobs в статусе Complete или Configmaps с Secrets, которые создали руками для уже раскатанного Helm Chart. Разовая акция не вызывает особых забот, а вот если это надо делать несколько раз в неделю, это уже проблема или даже боль.

Под катом я расскажу, как прошел путь, усеянный граблями, от самописных решений до K8s-cleaner, и почему я теперь доволен. Если ты еще не прошел мой путь, приглашаю под кат!

Когда-то я просто хотел писать мобильные приложения. Никаких планов «стать техлидом», «управлять командами» или «строить архитектуру» у меня не было. Я просто любил разбираться в технологиях и доводить фичи до ума.

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

Расскажу коротко, как это произошло у меня.

В этой статье я руками сравнил производительность PostgreSQL на «голой» VM в Yandex Cloud и в кластере CloudNativePG в Kubernetes. Один и тот же конфиг, одинаковые ресурсы, fio и pgbench, несколько типов хранилищ — и просадка до ~40% при работе через cnpg.

Разбираемся, где теряются TPS: на диске, в сети или в оболочке k8s, показываем все цифры в таблицах и схемах прохождения запроса «до VM» и «до Pod’а» — и в конце честно отвечаем, стоит ли игра свеч.

На днях вышел первый за шесть лет мажорный релиз Helm — v4. В статье разберём ключевые изменения по сравнению с v3: Server-Side Apply вместо 3-Way Merge, реализацию поддержки WASM-плагинов, замену движка ожидания готовности ресурсов и content-based-кеширование чартов. А ещё посмотрим, какие проблемы по-прежнему остаются с Helm и предложим для них решение.

Установка и эксплуатация приложений Spark в облаке зачастую становятся препятствием для дата-инженеров (Data Engineer, DE): сложная работа с Helm-конфигурациями отвлекает внимание от анализа данных и замедляет подготовку среды. Но полностью отказываться от Spark зачастую нерационально, поэтому многие команды стремятся найти свое решение для обхода существующих сложностей.

Привет, Хабр. Меня зовут Юрий Орлов. Я руководитель команды разработки ML Platform в VK Tech. В этой статье я расскажу о том, как мы автоматизировали развертывание Spark в облаке и создали клиент на Python, который снижает требования к знаниям в области DevOps и Kubernetes, необходимым для начала работы со Spark.

В статье показываем, как за 10 минут развернуть Kubernetes-платформу с помощью графического установщика Deckhouse Kubernetes Platform. Пройдём все этапы: настроим статический или облачный кластер, подключим модуль виртуализации и сразу начнём работать через встроенный веб-интерфейс — без DNS, Ingress и ручного YAML.