Kubernetes *

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

Там внизу, под катом, повествование о том, как сетевик кубернетес с 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-инфраструктуру.

Добрый день, всех приветствую на этом портале. В этой статье рассмотрим практические вопросы установки гиперконвергентной среды Harvester на bare metal серверы облачного провайдера или в виртуальные серверы для тестирования.

В инструкции по установке рассмотрен линейный процесс с носителем и iso образом. Мы рассмотрим установку внутри виртуальной машины для последующей эксплуатации на bare metal. Установочный образ не всегда распознается провайдером, а запись на флешку или диск занимает значительное время.

Итак, сервер загружен из rescue и доступна консоль.

31 июля прошла большая конференция Kubernetes Community Day, которую проводил программный комитет из команды «Штурвала», Yandex Cloud, VK и Ænix. Собрали для вас ключевые доклады и презы под катом.

Кто был там — поделитесь впечатлениями в комментариях!

С апреля 2025 года вышли три обновления Deckhouse Kubernetes Platform. В них — управление лейблами узлов через файлы, TLS для логов через Secrets, переход на OpenTofu, перезагрузка узлов аннотациями и поддержка Kubernetes 1.32. Разбираем ключевые изменения и их пользу для пользователей.

Привет, Хабр! Наверняка каждый разработчик или администратор сталкивался с ситуацией, когда для проверки гипотезы или нового функционала срочно нужна «чистая» база данных. Приходится либо искать свободный сервер, либо разворачивать всё локально, тратя время на установку и настройку. А если таких тестовых баз нужны десятки для команды или разных команд? У наших клиентов мы видели целый зоопарк из PostgreSQL разных версий и конфигураций, поддержка которых превращалась в головную боль. Именно эту проблему — создание «одноразовых» и легковесных баз по одному клику — мы и решили. Меня зовут Сергей Гонцов, я занимаюсь развитием СУБД, основанной на PostgreSQL, которая совсем недавно перешла «под крыло» Arenadata и называется теперь Arenadata Prosperity (ADP). В этой статье расскажу нашу историю, как мы готовили свой DBaaS-сервис.

В этой статье автор рассказывает о том, как самостоятельно построить сервис-меш с помощью современных инструментов и Open Source-решений. Материал будет полезен разработчикам и инженерам, интересующимся внутренним устройством сервис-мешей, их преимуществами, а также возможностями настройки и кастомизации под собственные нужды.

Поговорим о политиках безопасности в кубере. Обсудим на примерах зачем они нужны, в каких случаях они действительно помогут обезопасить, когда политики могут положить всю систему и как ими пользоваться в кубере. Плюсом захватим немного кода на go для работы с ними. И увидим, как одной политикой поломать кубер!

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

Эта статья будет полезна DevOps-инженерам, SRE-специалистам и всем, кто работает с Kubernetes и хочет глубже понять его внутренние механизмы. Если вы настраиваете, масштабируете или устраняете неполадки в кластере K8s, важно разобраться в etcd — распределенном key-value-хранилище, которое лежит в основе отказоустойчивости Kubernetes.

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

В этой статье мы разберем распространенные мифы о etcd, а также дадим практические рекомендации по его настройке и эксплуатации.

В основе материала — перевод опубликованных исследований инженеров Red Hat. Примечание редактора: Нам показалось, что авторы хорошо знакомы с механизмами etcd, но мало разбираются в работе СХД, поэтому мы дополнили перевод своими комментариями.

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

Привет, Хабр! Меня зовут Катя Низовцева, я системный администратор в Selectel. В этой статье мы подробно рассмотрим, как с помощью Kubespray быстро и эффективно развернуть работоспособный Kubernetes-кластер, а также интегрировать с ним систему мониторинга VictoriaMetrics. Этот подход особенно полезен, когда необходимо оперативно создать тестовое окружение или подготовить базовую инфраструктуру для дальнейшего развития.

Мы видели много инфраструктур и встречали самые разные способы доставки секретов в приложения, развёрнутые в кластерах Kubernetes. Но ни один из этих способов не был одновременно удобным и по-настоящему безопасным. В статье расскажем про существующие варианты, посмотрим на их плюсы и минусы и поделимся тем, как мы решали задачу доставки секретов в Deckhouse Kubernetes Platform. 

Контейнерные приложения все чаще требуют постоянного хранилища, будь то базы данных, кэш или файловые серверы. Но Kubernetes по умолчанию не «умеет» работать напрямую с системами хранения данных, в этом ему помогает CSI (Container Storage Interface). А если хочется управлять хранилищем через единый стандарт и без привязки к конкретному вендору, на помощь приходит спецификация Swordfish.

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

Control plane Kubernetes — как сейф с главными ключами. Он управляет кластером, хранит sensitive-информацию и зачастую представляет собой лакомую цель для злоумышленников. 

В этой статье — разбор того, как спрятать control plane в сервисе Managed Kubernetes, предоставляемом в облаке: зачем это нужно, какие варианты существуют и с какими проблемами мы столкнулись на практике. Рассмотрим несколько open source решений, которые протестировали у себя в поисках надёжного способа изолировать control plane-ноды от пользователя и сделать их недоступными для какого-либо внешнего взаимодействия.

Меня зовут Каиржан, я DevOps/Software-инженер в команде разработки
MWS Cloud Platform, пишу на Go под Kubernetes и ClusterAPI. Наша команда разрабатывает сервис Managed Kubernetes для публичного облака — от инфраструктуры до собственных провайдеров для ClusterAPI. Поэтому вопрос безопасности control plane (CP) для нас стоит особенно остро.  

В какой-то момент в нашей команде стало очевидно: пора тащить всю инфраструктуру в Git — по-взрослому, через GitOps. Kubernetes у нас уже был, ArgoCD тоже. Осталось «дотащить» туда AWS-ресурсы, которые мы описываем с помощью AWS CDK.

Идея казалась простой: есть CDK-код в Git, запускается ArgoCD, всё красиво деплоится в облако. Но реальность оказалась совсем не такой. CDK — это не YAML и даже не Terraform. Это исполняемый код. GitOps — это про декларативность и kubectl apply. CDK с этим не дружит.

Ожидалось, что наверняка есть готовый Kubernetes-оператор, который запускает cdk deploy при изменении кода. Как это уже сделано для Terraform (через ArgoCD Terraform Controller), Pulumi, или хотя бы через ACK. Но после долгого ресерча выяснилось: нет ничего рабочего и production-ready.

Так появилась идея — написать собственный Kubernetes-оператор, который сможет:

- раз в какое-то время (или по коммиту в Git) запускать cdk deploy;
- проверять cdk diff и cdk drift для отслеживания изменений и дрифта;
- удалять CloudFormation-стэк, если ресурс удалили из Git;
- интегрироваться с ArgoCD и Prometheus.

Получился полноценный GitOps-воркфлоу для AWS CDK — без пайплайнов, без ручных cdk deploy, без дрейфующих стэков.

Под катом — расскажу, как мы подошли к проблеме, как устроен Custom Resource CdkTsStack, какие фишки мы добавили (метрики, хуки, IAM-пользователи), и почему наш подход оказался практичнее, чем существующие альтернативы вроде Terraform Operator или Pulumi.

Привет, Хабр! Я Максим, инженер по тестированию Selectel. Недавно мы провели технический воркшоп по работе с Kubernetes на выделенных серверах. Под катом — подробный текстовый разбор. Рассмотрим создание кластера через панель управления, деплой приложения, настройку внешнего доступа и подключение облачной базы данных с тестовым запросом прямо из пода.