Kubernetes *

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

Kubernetes — мощный и одновременно сложный инструмент, работа с которым неизбежно порождает… инциденты. И на практике DNS виновата далеко не всегда. Иногда всё ломает слишком длинное имя деплоймента, протухший CA-сертификат или сбой сетевой карты, из-за которого TCP-пакеты просто отбрасываются. В статье вас ждут самые интересные и поучительные инженерные истории с Reddit.

Сталкивались ли вы с ситуацией, когда нужно получить доступ к сети подов или сервисов в кластере Kubernetes? Кто-то может возразить, что маппинга портов через port-forward или использования NodePort вполне достаточно, однако часто это не так. Список реальных кейсов велик, рассмотрим несколько для примера:

— разработчикам нужен прямой доступ к сервисам по ClusterIP для дебага;

— используются внешние балансировщики (например, SIP/RTP-прокси для телефонии или антиспам-решения), когда они не могут быть размещены внутри Kubernetes;

— присутствуют аппаратные решения вроде NGFW от именитых производителей.

В тексте мы в первую очередь будем опираться на практику Managed Kubernetes-сервиса Selectel, но он также будет полезен, если у вас свой K8s с CNI Calico.

За последние два месяца в Deckhouse Virtualization Platform (DVP) вышло пять новых релизов (0.19–0.23). За это время в платформе появилось много важных улучшений, о которых мы расскажем в этом обзоре. Среди них — готовность к продакшену, улучшенная безопасность, автоматическая перебалансировка ВМ по узлам, оптимизация миграции и вложенная виртуализация. Подробности в обзоре.

Артём Еремин, системный инженер Nova Container Platform в Orion soft.

Всем привет! Недавно я выступал на мероприятии СНОВА О КУБЕРЕ и рассказывал о Service Mesh. Тема достойна и поста на Хабре, потому что Service Mesh стал распространенной фишкой, но при этом не самой простой. 

Мы в Orion soft решили внедрить ее в нашу платформу оркестрации Nova Container Platform, и по пути столкнулись с целым рядом «подводных камней»: от выбора самого решения до нюансов настройки MTLS и организации точек входа трафика в наш кластер. В этой статье я расскажу, как мы выбирали реализацию для Service Mesh, почему остановились на Istio, какие вопросы решали и что из этого получилось.

Привет, Хабр! С вами Антон Паус. Я четыре года проработал системным инженером в российском офисе Cisco, а сейчас работаю DevOps-инженером в Cloud.ru — занимаюсь облаком собственной разработки. 

С 2024 года я веду проект по разработке новой архитектуры кластера виртуализации Evolution IaaS на базе Kubernetes. Раньше мы использовали связку Ansible и Docker, и это отлично работало на существующем масштабе, но с ростом клиентской нагрузки столкнулись с рядом сложностей, что в конечно итоге и сподвигло нас на обновление архитектуры. 

Проект получился довольно объемным и со множеством нюансов и сложностей, о которых я, возможно, напишу в следующих статьях. В этой же хотел остановиться на нюансах сетевого взаимодействия в кластере bare metal Kubernetes — в ходе работы возник ряд сложностей (например, с первоначальной установкой K8s на сервер с несколькими интерфейсами), о решении которых я и расскажу. 

Если развернуть кластер Kubernetes на железе — в ваших обозримых планах, надеюсь, мои изыскания будут полезны. А еще в статье довольно много сетевки, так что приготовьтесь!

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