Kubernetes *

Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки.

В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете.

В 2023 году к нам регулярно приходили разработчики с вопросом: «Кажется, тупит сеть. Посмотрите?» Вопросы были по делу, и каждый раз отвечать было сложно. Когда тойл от подобных обращений превысил разумные пределы, мы решили разработать SLO на летенси в Ingress. Но оказалось, что это не так уж просто.

Представьте, что однажды утром вы просыпаетесь, а мир вокруг стал другим. Нет, ничего страшного не случилось: ни ледникового периода, ни падения метеорита. Но все сервисы вдруг начали работать так, как работали в те времена, когда про Kubernetes еще никто не слышал.

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

Это было хорошо. Но довольно быстро стало понятно главное:

Привет, Хабр! Меня зовут Вадим Королёв. Я руководитель команды разработки в X5 Tech. Очень люблю Next.js и решать проблемы, которые он приносит. С ним всегда происходит что-то интересное. Расскажу о причине утечки памяти в Node.js, которая оказалась глубже, чем можно было подумать.

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

В этот момент я занимался архитектурой и оптимизацией Node.js в музыкальном стриминге. Открыл графики и увидел явный рост памяти, который уходил в пик и приводил к перезапуску подов. Так началась «классическая предновогодняя история». Next.js в Kubernetes внезапно начал есть память так, будто у него внутри чёрная дыра.

В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.

Весной этого года NVIDIA открыла исходный код KAI Scheduler — Kubernetes-нативного планировщика GPU-нагрузок, который раньше входил в состав платформы Run:ai и теперь распространяется под лицензией Apache 2.0. Интерес к этому проекту закономерен: планировщик давно работает в продакшене и решает ряд проблем, с которыми сталкивается любая команда, пытающаяся эффективно распределять GPU-ресурсы в кластере.

Мы в Orion soft изучили технические детали KAI Scheduler, чтобы понять, как он устроен изнутри, какие задачи закрывает и какие идеи могут быть полезны инженерам, работающим с Kubernetes, ML-нагрузками и распределёнными GPU-оркестраторами. Ниже — разбор архитектуры, базовых сущностей и цикла планирования.Преимущества KAI Scheduler

Управление AI-нагрузками на GPU и CPU сталкивается с рядом задач, которые традиционные планировщики ресурсов не всегда способны решать. KAI Scheduler был разработан специально для того, чтобы закрыть эти проблемы:

Мы доверили ИИ первым реагировать на критические инциденты в продакшене. Это сократило время реакции, но одна его галлюцинация едва не отправила весь кластер в ребут...

История о том, как мы получили мощного, но странного стажёра, с которым нельзя оставаться наедине.

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

Представьте, что вы наконец-то выстроили надежный периметр вокруг своих контейнеров, сканируете образы и настраиваете политики в соответствии с общепринятыми стандартами безопасности. И кажется, всё под контролем. Но что, если атака началась в уже запущенном контейнере? Как обнаружить, что прямо сейчас легитимный микросервис крадет ваши данные или майнит криптовалюту?

В данном случае на классические средства защиты рассчитывать не приходится: они охраняют контейнеры снаружи и не видят, что происходит внутри. А большинство инструментов для выявления угроз в среде выполнения — сложные и дорогие. Тем не менее выход есть: недавно специалисты из команды PT Container Security представили рынку первое в России открытое решение для защиты рантайма контейнерных сред — Runtime Radar. Подробнее о нем в нашей статье рассказывают руководитель разработки Никита Ладошкин и эксперт Виталий Шишкин (@JCD3nt0n).

Сегодня официально выпустили новую версию Kubernetes — 1.35. Собрали обзор со всеми изменениями. Среди главных нововведений — возможность запускать поды с hostNetwork: true и hostUsers: false, групповое планирование подов и перевод контроллера маршрутов на watch-модель.

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

Продолжаю делиться дискуссиями из нашего телеграм-канала Dev Q&A. На этот раз собрались поговорить о том, почему при всём богатстве инструментов — Kubernetes, CI/CD, low-code, AI-ассистенты — разработка не становится ни быстрее, ни дешевле.  Собрал ключевые мысли в статью. Получилось про три столпа эффективности, про хаос который понятнее порядка, и про то, почему скрам по книжке остановил компанию на две недели, а Waterfall принёс миллиард. 

Команда Deckhouse Storage рассказала о поддерживаемых в наших платформах CSI с использованием реализаций от вендора (для платформ Huawei, HPE, NetApp и Yadro), а также о собственном универсальном CSI-драйвере csi-scsi-generic, который поддерживает интеграцию с любыми системами хранения данных.

Привет, Хаброжители! «Паттерны Kubernetes» — это не очередной справочник по настройке кластеров или описанию API. Это фундаментальный труд, который отвечает на самый главный вопрос: как эффективно проектировать и строить приложения, предназначенные для работы в Kubernetes? Авторы систематизировали лучшие практики, преобразовав их в паттерны. Книга учит не просто использовать Kubernetes, а мыслить категориями платформы, комбинируя примитивы для создания отказоустойчивых, масштабируемых и удобных в эксплуатации систем. Это must-read для любого разработчика, который хочет выйти за рамки простого деплоя контейнеров и овладеть всеми возможностями Kubernetes.

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

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

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

Всем привет! Меня зовут Артемий, я работаю SRE-инженером в команде RTP (real time processing) Clickstream в Авито. Сегодня мы хотим поделиться нашей историей о том, как мы переехали в Kubernetes, развернув Apache Flink с помощью Flink k8s operator.

В Istio всё начинается с маленькой «удобной» идеи — прокси рядом с каждым подом. А заканчивается тем, что XDS разносит по кластеру тонны Listener’ов, Route’ов и Cluster’ов, дублируя конфиги для сервисов, которые вы даже не трогаете. Память тает, GC злится, а апдейты сервисов превращаются в шторм.

В статье пойдет речь о том, как мы в проде с 20K+ подов «урезали аппетит» сайдкаров на гигабайты. Обсудим, где работает жёсткое ограничение видимости, когда спасает Ambient Mesh, зачем нужен ленивый XDS и почему «волшебной кнопки» нет — но есть комбинации, дающие двузначную экономию. Эта статья написана по мотивам моего доклада для конференции Saint HighLoad++.

В статье — проверенные практики от сообщества Kubernetes: от выбора версии API и работы с YAML до управления подами и лейблами. Плюс несколько советов от команды Deckhouse по работе с ресурсами и автомасштабированием.

Год назад я не знал о Kubernetes практически ничего. Сегодня у меня свой pet-проект развернут в облачном кубере, и я чувствую себя достаточно уверенно, чтобы делиться опытом. Что изменилось? Я начал преподавать в МАИ и проходить сертификацию по работе.

Звучит парадоксально, правда? Обычно всё наоборот - сначала учишься, потом учишь других. Но в моем случае именно преподавание стало катализатором интенсивного обучения. И в этой статье я расскажу, как это работает и какой путь я прошел.

Мы тут в Cozystack в очередной раз решаем проблему курицы и яйца: как задеплоить CNI и kube-proxy через Flux, но при этом обеспечить работу самого flux без CNI и kube-proxy.

Сам Flux запустить без CNI и kube-proxy можно используя проект flux-aio (от создателя Flux), который запускает единый deployment со всеми контроллерами настроенными на коммуникацию друг с другом через localhost.

Специфика Cozystack заключается в том, что на каждый кластер мы деплоим внутри небольшой HTTP-сервер с Helm-чартами и другими ассетами используемыми в платформе. Flux эти чарты читает и устанавливает в систему.

Но вот как организовать доступ флюксу к внутреннему HTTP-серверу, запущенному как под внутри того же кластера?