Kubernetes *

Статья о том, как werf помог упростить переход на Kubernetes, ускорить CI/CD и решить проблемы с кэшированием. Автор поделился опытом внедрения, первыми шагами и преимуществами, которые получила его команда.

Привет! С вами Олег, Рамиль и Андрей из Flocktory. Мы руководим машинным обучением и разработкой в компании, сейчас активно внедряем AI для лучшей персонализации. В прошлом году наши команды реализовали ML-сервисы, внедрили ML Feature Store и переработали жизненный цикл моделей (о чём мы подробно рассказывали на HighLoad++: https://highload.ru/moscow/2024/abstracts/12929). В этой статье поразмышляем над следующим шагом для среднего размера компании, которая внедряет AI – как масштабировать проекты машинного обучения. Обработка, анализ и обучение на данных влекут за собой применение ML систем, в том числе нейросетей. Это требует больших вычислительных ресурсов: сотни гигабайт ОЗУ, десятки ядер CPU, а также видеокарты и (или) специальные чипы для ускорения вычислений.

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

Привет, Хабр! Меня зовут Глеб Когтев, я руководитель команды VPC Host Components, которая занимается разработкой виртуальной облачной сети для MWS Cloud Platform. C этой статьёй мне помогал Юрий Кондратов — SRE в команде Kubernetes Operations, Research & Engineering (KORE). 

Сегодня поговорим об устройстве сети в Kubernetes-кластере, немного о нашем подходе к обеспечению связности сервисов и чем нам был полезен Multus CNI. Статья будет полезна тем, кто использует Kubernetes в своих задачах и хочет разобраться в устройстве сети, а ещё во взаимодействии компонентов K8s с контейнерами.

В 2023 году мы впервые попытались запустить платформу dBrain.cloud на Astra Linux версии 1.7 Special Edition. Первая попытка оказалась неудачной.

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

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

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

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

Когда мы только начинали работу над платформой, тестирование напоминало ручное управление парусником в шторм — много усилий, но результат непредсказуем. Разработчики вручную создавали тестовые среды, QA проверяли функционал через Postman, а о стабильности релизов можно было только мечтать. Каждый новый релиз был как лотерея: либо всё работает, либо начинается долгий процесс поиска причины багов в production.

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

Эта статья в трёх частях — результат моего опыта в решении этой задачи. Внутри вас ждёт пошаговое руководство по реализации бюджетного распределённого инференса с использованием Ray Serve, vLLM, Kubernetes, Proxmox и других технологий. В первой части мы разберём настройку GPU и его проброс в Proxmox, развернём Kubernetes-кластер, установим GPU Operator и KubeRay Operator.

При использовании GitLab CI/CD с Kubernetes возникает необходимость видеть связку между логами и конкретными CI job'ами или pipeline'ами. Это особенно полезно для отладки и мониторинга. Однако по умолчанию логи из подов не содержат этих связующих метаданных.

В данной статье мы покажем, как можно передавать метки job_id, pipeline_id, project_name и другие из GitLab Runner в систему логирования VictoriaLogs с помощью Promtail и систему мониторинга VictoriaMetrics.

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

Google, без преувеличения, изменил мир IT, подарив нам Kubernetes – систему, ставшую де-факто стандартом оркестрации контейнеров. И когда выбираешь управляемый Kubernetes от его же создателей, такой как Google Kubernetes Engine (GKE), ожидания, естественно, высоки. Уж кто-кто, а "первоисточник" должен уметь "готовить" свое детище идеально, предоставляя не только удобство, но и прозрачные, глубоко интегрированные и безопасные решения "из коробки". Особенно когда речь заходит о такой фундаментальной вещи, как сетевое взаимодействие и его безопасность.

GKE предлагает два режима работы кластеров: routes-based и VPC-native. Именно VPC-native кластеры позиционируются Google как обеспечивающие более тесную интеграцию с сетью VPC. Как утверждает Google, одно из преимуществ таких кластеров заключается в том, что IP-адреса подов (pods) нативно маршрутизируемы внутри сети VPC кластера и других сетей VPC, подключенных к ней через VPC Network Peering (подробнее см. документацию GKE по IP-алиасам и VPC-native кластерам). Это вселяет уверенность, что возможности VPC, включая мощный механизм GCP Firewall, будут доступны и для наших подов так же легко и нативно, как для обычных виртуальных машин.

Однако, погружаясь в детали настройки контроля сетевого доступа для подов к ресурсам внутри VPC, но внешним по отношению к самому Kubernetes (например, к базам данных Cloud SQL или другим бэкендам), начинаешь сталкиваться с нюансами. Нюансами, которые заставляют усомниться в "бесшовности" этой интеграции. Эта статья – не попытка принизить достижения Google или GKE. Скорее, это повод для всех нас, инженеров, задуматься о тех важных деталях реализации, которые часто остаются "под капотом". Повод погрузиться глубже, понять, как все устроено на самом деле, и какие компромиссы или сложности скрываются за маркетинговыми лозунгами. Ведь чем сложнее архитектура безопасности, тем выше вероятность ошибки конфигурации, особенно если ее компоненты и их взаимодействие не до конца понятны. Если даже у такого гиганта, как Google, в его флагманском продукте для Kubernetes есть подобные неочевидные моменты, то нам, инженерам, работающим с этими системами ежедневно, тем более важно понимать все тонкости для обеспечения надежности и безопасности наших собственных окружений.

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

Низкий порог входа в разработку контроллеров Kubernetes часто приводит к проблемам в production. Мы перевели статью, в которой автор делится опытом создания надёжных контроллеров, рассказывает о принципах проектирования API и объясняет важность автономной реконсиляции. Узнайте, как сделать контроллеры действительно масштабируемыми.

Обычно, когда мы говорим о безопасности Kubernetes, мы прежде всего говорим о защите подов от внешних угроз, но в некоторых случаях они сами могут представлять определенную опасность. Для того, чтобы эти угрозы мог реализовать атакующий, у него должны быть доступ к кластеру, разрешение RBAC на создание одного некоторых типов ресурсов (CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet) хотя бы в одном пространстве имен, и также должны отсутствовать политики безопасности.

Если у вас все это есть — тогда мы идем к вам в этой статье мы рассмотрим, какие атаки из подов вам могут грозить. А даже если есть не все, то особенно расслабляться все равно не стоит.

Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.

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

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

Статья написана по мотивам выступления Максима Чудновского, лидера по продукту Platform V Synapse Service Mesh СберТех на Highload++, где он рассматривал кейс миграции с OpenShift на Platform V DropApp, но предложенные подходы могут быть использованы и для миграции на другие российские Kubernetes-платформы: Deckhouse, Штурвал, Боцман и так далее.

Помимо вариантов использования механизмов ETL, трансляции шаблонов в релизных конвейерах, рассматривается подход применения менеджера политик Kubelatte для того, чтобы мигрировать с OpenShift без единой правки кода.

Привет, Хабр! Меня зовут Павел Минкин, тружусь в качестве DevOps-инженера в FinTech-компании. Интересуюсь технологиями, автоматизирую все, что попадает под руку, верю в DevSecOps, провожу вебинары.

Давайте ответим на вопросы, которые витают в воздухе, но остаются незаданными: а что произойдет, если засунуть AI приложение в кластер? А надо ли это делать? И как это сделать минимальным количеством инструментов? А можно без GPU?

Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и всем советуем. Обо что споткнулись и всем советуем там не спотыкаться.

В статье разберем процесс внедрения виртуализации в платформу контейнеризации, обсудим ее преимущества для пользователей и покажем, каким образом это решение упрощает администрирование ИТ-инфраструктуры.

В 2017 году мы рассказывали о том, как спроектировали нашу систему поиска сообщений так, чтобы она могла индексировать миллиарды сообщений. Благодаря этому наша поисковая инфраструктура стала высокопроизводительной, экономной, масштабируемой и простой в использовании. Мы решили выбрать Elasticsearch, в котором сообщения Discord шардились по индексам и использовалось логическое пространство имён для сообщений Elasticsearch в двух кластерах Elasticsearch. Сообщения шардились или по серверу Discord (который ниже будем называть гильдией) или по личным сообщениям (DM). Это позволило нам хранить все сообщения гильдии рядом для обеспечения высокой скорости запросов и работать с маленькими, более удобными кластерами. Так как поиском пользуются не все, сообщения индексировались лениво, и мы создали очередь сообщений, позволявшую воркерам получать блоки сообщений для индексирования, чтобы воспользоваться возможностями массового индексирования (bulk-indexing) Elasticsearch.

Но с ростом объёмов Discord наша поисковая инфраструктура начала трещать по швам…‍