Kubernetes *

Привет, Хабр! Мы — команда Cozystack, open-source платформы для построения облаков на своём железе. Хотим рассказать, почему мы решили целиться в направление игровых серверов и что из этого вышло.

Kubernetes-кластер без сети — не кластер, а просто набор несвязанных компонентов. Чтобы «оживить» его, важно понимать, что такое Container Network Interface (CNI) и как он работает.

В статье — детальный разбор механизма CNI: что такое CNI-плагин, как он запускается и какие операции выполняет в кластере. В конце работа CNI демонстрируется на примере кастомного плагина.

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

Привет! Это снова Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наши операторы продолжают бороздить просторы K8s, а инсталляторы — разворачивать новые кластеры, и мы готовы поделиться с вами новыми полезностями.

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

Иметь свой мессенджер — больше не роскошь, а страховка от блокировок. В условиях, когда привычные инструменты могут исчезнуть в любой момент, полный контроль над перепиской становится вопросом выживания бизнеса. Рассказываем, как поднять Rocket.Chat “в облаке”: от простого Docker Compose до отказоустойчивого Kubernetes-кластера

Статья будет о том, как быстро начать работать с vLLM и vLLM Production Stack: от первого запуска модели до базовых режимов инференса через OpenAI-совместимый API. Разберем практические настройки и сценарии запуска — tool calling, thinking/non-thinking, мультимодальные и CPU-модели, а так же какие стартовые параметры сильнее всего влияют на память, производительность и стабильность. Отдельном рассмотрим полезные оптимизации для production-сценариев: FP8, Tensor Parallelism, KV-cache offloading, Speculative Decoding и ускорение холодного старта больших моделей.

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

Неделю назад мы запустили DevOps-челлендж в честь 5-летия нашего блога на Хабре. Участникам нужно было разобраться, почему приложение не может синхронизироваться в ArgoCD, найти ошибку в конфигурации и довести деплой до зеленого статуса.

Челлендж завершен, а значит, пришло время подвести итоги и пошагово разобрать решение.

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

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

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

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

На связи команда разработки контейнерной платформы «Штурвал». Недавно мы выпустили новую версию 2.13.

Теперь пользователям доступны установка через YAML и флаги командной строки, профили кластеров по шаблонам, containerd 2.x с шифрованием образов, сводные отчеты по безопасности. Под катом делимся самым интересным.

Я ставил Kubernetes на Orange Pi (orangepi4pro) и наивно ожидал, что Calico «просто заведётся». В реальности DaemonSet calico-node ушёл в перезапуски, readiness/liveness-пробы падали, а в событиях Kubernetes мелькали BIRD и Felix.

Сначала это выглядит как «какая-то проблема Calico/BGP», но причина оказалась куда прозаичнее: в установленном ядре банально нет нужных netfilter/ipset/ipip модулей.

У вас в GitLab несколько проектов с одинаковым CI? Или просто надоела копипаста в пайплайнах? Каждое изменение нужно отразить в 10 местах? Рассказываем, как сократить код на 56 %, убрать дублирование и сделать один CI для всей группы проектов. Шаблоны, матрицы и практика.

Многие уверены, что если сервис поднят в кластере — значит, он защищён от любых потрясений инфраструктуры, и, если что-то случится, Kubernetes "сам всё поднимет". Но на деле есть нюанс. Реальная устойчивость и грамотный disaster recovery появляются только на стыке платформы, клиентской логики и конфигурации сервисов. А обнаружить узкие места возможно только во время инцидентов или плановых аварийных учений. Так мы и поступили: выключили 30% нод в production кластере и посмотрели, что будет.

В статье разберём — почему именно 30%, какие сбои и узкие места всплыли в ходе учений, а также какие сделали выводы и мы, как команда Kubernetes, и прикладные команды.

Все кто касался темы обеспечения бесперебойной работы сервисов знает на сколько изнуряющим и трудно оценимым по времени бывает диагностика и устранение инцидентов. Настало время это исправить!

Ваша ML-модель работает в ноутбуке, а в продакшене — нет. Бывало такое? Именно здесь начинается настоящая инженерная задача: взять эксперимент из Jupyter-ноутбука и превратить его в воспроизводимый, наблюдаемый и масштабируемый пайплайн — от сырых данных до стабильного инференса под реальной нагрузкой. Kubernetes давно стал де-факто стандартом для этой работы: более 70% компаний используют его в продакшене — это не дань хайпу, это прагматичный выбор тех, кто уже наступал на грабли.

В этой статье разберем, почему K8s выигрывает у альтернатив именно для ML-нагрузок, а также обсудим какие мифы и анти-паттерны тормозят команды на пути к продакшену. Пройдемся по полному стеку: от подготовки кластера и фиксации данных через DVC до canary-деплоя модели и автоскейлинга GPU-подов. В конце вас ждет взгляд на то, куда движется индустрия: serverless-ML, multi-LLM-ops и edge-развертывания.

Если вы DevOps- или MLOps-инженер, которому приходится запускать обучение и инференс в одном кластере, или R&D-инженер, чьи модели «магически ломаются» при переходе в прод — читать обязательно.

Привет, я Александр Хренников, руководитель DevOps-юнита в KTS.

Нам тут, оказывается, 5 лет стукнуло. Точнее, нашему блогу на Хабре. Подарков мы не дождались, так что решили сами вручить их вам. Дарить будем футболки с нашим фирменным принтом — Котзиллой. Это как Годзилла, только кот.

Но подарок получат не все, а десять DevOps-инженеров, которые справятся с нашим испытанием быстрее остальных. Суть проста: мы даем вам тестовый стенд с кластером Kubernetes с ArgoCD и отдельный GitLab-сервер. В ArgoCD добавлено приложение — простой Nginx, обернутый в Helm-чарт. И оно не запускается. Надо запустить.

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

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

Меня зовут Сергей Емельянов. Я руководитель Core-команды VK Tech. В этой статье я пошагово покажу процесс построения синтетической платформы для обработки потоковых данных на Kubernetes.

В больших инфраструктурах Kubernetes не живёт сам по себе: вокруг него выстраивается экосистема со своими дефолтами, ограничениями и точками отказа. В нее входят CNI, ingress-контроллеры, системы мониторинга, бэкапов, политики безопасности, GitOps и десятки других компонентов.

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

Инженеры практики контейнеризации, виртуализации и частного облака К2Тех изучили особенности эксплуатации четырех российских платформ: «Штурвал», Nova Container Platform, «Боцман», Deckhouse Kubernetes Platform. Результаты сравнения разложили по полочкам в таблицах – их вы найдете в статье.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

Сейчас очень часто в вакансиях на ДевОпс ищут людей которые, понимают и могут в Helm чарт.

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

Я решил поделиться с вами своим опытом и понял что тут как никогда пригодится метод понимания процессов через визуализацию. О принципах работы метода «Дворца памяти» можно прочитать тут же на Хабр.

Привет, на связи Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Мы все так же пилим наш космолет и готовы поделиться с вами новыми полезными рекомендациями и предостеречь от ошибок при разработке операторов.

В первой части мы уже начали обсуждать разработку K8s-операторов. Сегодня поговорим о поведении  Reconcile и конфликтах обновлений. Рассмотрим возможные ошибки и обсудим тонкости, которые помогут их избежать.

Поехали!

Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме».

Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.