Kubernetes *

В прошлом году я писал на Хабре про Telescope - инструмент для просмотра логов через веб-интерфейс. Тогда основной сценарий был связан с ClickHouse, и в комментариях логично возник вопрос: не "прибит" ли инструмент к одной базе данных.

Технически - нет. Модель источников изначально задумывалась расширяемой. Позже появилась поддержка Docker, чтобы Telescope можно было использовать и в локальной разработке, без централизованного хранилища логов.

В версии 0.0.24 добавлен ещё один тип источника логов - Kubernetes. Теперь Telescope может напрямую читать логи pod-ов через Kubernetes API, сохраняя ту же модель прав доступа и язык фильтрации.

В этом посте хочу показать, что было добавлено в проект и чем это может быть полезно на практике.

Казалось бы, права на чтение — что с них взять? Оказывается, в Kubernetes разрешение nodes/proxy GET позволяет выполнять любой код в любых подах кластера. Уязвимость уже нашли в популярных Helm-чартах, включая Prometheus, Datadog и Grafana. И да, команда Kubernetes решила это не исправлять.

Цель проекта — проверить отказоустойчивость Strimzi Kafka в Kubernetes с помощью chaos-экспериментов (Chaos Mesh). Для этого разворачивается полный стенд: кластер Kafka (KRaft, 3 контроллера + 3 брокера), мониторинг (VictoriaMetrics K8s Stack, Grafana), сбор логов (VictoriaLogs), верификация сквозной доставки сообщений через Redis и Go-приложения producer/consumer. Затем последовательно применяются chaos-сценарии (pod-kill, network partition, CPU/memory stress, IO/DNS/JVM/HTTP chaos и др.) и проверяется, что кластер корректно восстанавливается без потери данных.

В какой-то момент почти в каждом Kubernetes-кластере наступает день, когда kubeconfig с правами cluster-admin перестаёт быть временным решением и внезапно становится: так исторически сложилось. Пользователей становится больше, доступы плодятся, а вопрос: кто и зачем может удалить namespace в проде? повисает в воздухе без логичного ответа.

До определённого масштаба это ещё можно терпеть: сертификаты, статические токены, ручная раздача доступов. Но как только в кластере появляются: несколько команд, требования по аудитам, SSO или просто здравый смысл, становится ясно — Kubernetes нужно подключать к нормальной системе аутентификации.

Kubernetes из коробки умеет работать с OIDC (OpenID Connect), и это, пожалуй, самый адекватный способ интегрировать его с внешним Identity Provider. В роли такого провайдера часто выступает Keycloak: open-source, self-hosted, с поддержкой групп, ролей и интеграцией с LDAP/AD. В общем, всё, что обычно уже есть в инфраструктуре, либо планируется к появлению.

Хабр, привет! На связи команда облачного провайдера Nubes.

Когда мы решили запустить собственный Kubernetes as a Service, на поверхности все выглядело просто: развернуть кластеры, завернуть в удобный интерфейс и добавить автоматику. На практике же оказалось, что «ванильный» Kubernetes, Kubespray и вендорские платформы порой приносят хаос вместо готового сервиса.

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

Со стороны сертификация ФСТЭК России часто воспринимается как преимущественно бюрократический процесс. Но при более близком знакомстве быстро становится понятно: ключевая сложность не в документах как таковых.

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

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

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Привет, Хабр! В первый месяц 2026 года команда Selectel выпустила из беты сетевые диски для выделенных серверов, обновила работу с Karpenter и реализовала еще несколько полезных опций. Обо всех обновлениях читайте под катом.

Полное руководство по развертыванию высокодоступного кластера Kubernetes 1.35 на Ubuntu 24.04

Эта подробная техническая статья представляет собой пошаговое руководство по созданию отказоустойчивого кластера Kubernetes версии 1.35 с использованием утилиты kubeadm. В руководстве рассматривается развертывание производственного кластера с тремя master-нодами и тремя worker-нодами, что обеспечивает высокую доступность и отказоустойчивость.

Kubernetes взламывают не «эксплойтом века», а банальностями: открытый доступ, cluster-admin «на время», default serviceAccount, секреты в манифестах (да, base64 не защита). Дальше сценарий предсказуемый — от тихого майнинга до утечки ключей, как в истории с Tesla.

В статье разберу три базовых опоры k8s-безопасности: минимизация прав через RBAC, нормальная работа с секретами и изоляция workload’ов через securityContext и политики — с типовыми ошибками и практиками, которые реально внедрить.

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

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

Я разберу платформенный подход: что такое платформы, как они работают, кому нужны и как построить свою. А также сравню разные архитектуры для платформ, расскажу, почему мы остановились именно на K8s как на ключевой технологии, и покажу, как мы собрали на его основе production-решение.

Привет! Я Сергей Истомин, DevOps-инженер в KTS.

Хотите удобно деплоить дашборды и датасорсы в концепции IAC? Я тоже. 

Услышав про Grafana Operator, я, окрыленный надеждами, пошел к нему за решением. Но у Grafana Operator оказалось свое представление о деплое, о провижининге и о том, как он вообще должен работать.

Всем привет! В этой статье я расскажу, как мы запускаем большие языковые модели на Kubernetes-платформе Nova AI. Разобьем материал на две части: сначала посмотрим, с помощью чего это реализовано (архитектура и компоненты), а затем — что это позволяет делать (сценарии использования и практические кейсы).

Цель этой статьи — восполнить пробел в документации связки Strimzi Kafka и мониторинга. У Strimzi есть раздел про метрики и Prometheus и примеры в репозитории (examples/metrics/prometheus-install), но они рассчитаны на общий Prometheus Operator; пошагового руководства именно под Helm-чарт kube-prometheus-stack (с порядком установки и нужными label’ами) в открытом доступе не нашлось. Ниже — собранный и проверенный вариант такой установки.

При проектировании инфраструктуры часто возникает задача поднять кластер «с чистого листа». Безусловно, Terraform и Ansible — это стандарт индустрии. Однако мне нужен был процесс быстрого получения готового кластера K8s, полностью независимый от локального окружения, чтобы запуск не требовал предварительной подготовки версий библиотек, интерпретаторов или наличия локальных файлов конфигурации.

В этой реализации я намеренно упростил работу с конфигурацией: параметры виртуальных машин (CPU, RAM, диски) описаны прямо в коде (см. config.go). Я решил, что проектирование гибкой системы внешних конфигов можно оставить на потом, чтобы на данном этапе не отвлекаться и сфокусироваться на главной задаче — отладке самого механизма восстановления и связности компонентов.

Я реализовал подход полной автоматизации с использованием технологий, которыми увлекаюсь. Суть проста: на машине CI-раннера нет ничего, кроме одного бинарного файла. Всё состояние кластера (IP-адреса, ID дисков), дампы баз данных и зашифрованные секреты хранятся в S3. Это позволяет восстановить кластер в исходное состояние даже после полного удаления, просто вытянув актуальное состояние из облачного хранилища.

В этой статье я поделюсь опытом создания кастомного CLI для подготовки инфраструктуры и использования FluxCD для развертывания приложений. А для проверки результата я использую Yandex Cloud Managed Kubernetes, чтобы запустить K6 Operator и дать внешнюю нагрузку в 1000 пользователей на восстановленные сервисы.

Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов.

Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес.

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

Когда на сервере появляется «прожорливый» процесс, который забирает все ядра и постепенно выдавливает память, хочется ограничить его быстро — но так, чтобы это было воспроизводимо и не держалось на магии.

В статье — практический разбор cgroups v2: как руками через cgroupfs создать группу, задать лимиты CPU/RAM и правильно запускать процессы без «окна без ограничений», а затем сделать то же самое через cg*-утилиты и systemd-run/slice. По дороге станет ясно, почему эти приёмы напрямую перекладываются на мир Docker и Kubernetes.

Мониторинг — это сердце любой современной IT-инфраструктуры. Сегодня я хочу рассказать о нашем опыте построения и развития инфраструктуры мониторинга в одном из крупнейших банков России – Россельхозбанке.

Привет, Хабр! Меня зовут Сергей Смирнов, я DevOps экосистемы «Своё» в РСХБ.Цифра.

Речь пойдет не о всей гигантской IT-инфраструктуре банка, а о ее специфической части. Мы работаем с тем, что можно назвать «внешним облаком» РСХБ. В этой статье я расскажу об общей архитектуре, ключевых технологиях для сбора метрик, логов, трассировок, алертинга и визуализации, принципах настройки и развертывания, примерах и готовых решениях, в частности о том, как Victoria Metrics может стать центральным элементом системы мониторинга, охватывающей как Kubernetes, так и другие компоненты инфраструктуры.

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

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

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