Kubernetes *

Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.

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

На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.

Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.

Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

В статье — реальный опыт перехода от классических облачных инстансов к Kubernetes и созданию абстракции Serverless, которая полностью избавила разработчиков от забот об инфраструктуре. Узнайте, как это повлияло на скорость релизов и стабильность сервисов Mercado Libre.

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

Меня зовут Алиса, и я руковожу командой разработки контейнерной платформы «Штурвал». В последнее время мы с командой много работали над реализацией мультитенантности и перепробовали множество разных вариантов. Ниже я расскажу, как тенанты помогают закрыть «боли» при работе с K8s на примере трех проблем и поделюсь полезными инструментами.

Эта статья будет интересна тем, кто:

👉 «с ноги» врывается в свой первый кубер;
👉 самостоятельно строит Kubernetes-платформу;
👉 управляет одним или множеством кластеров K8s.

P. S. 31 июля в Москве состоится первая независимая конфа Kubernetes Community Day. Два пространства с хардкорными докладами и воркшопами от крутых экспертов из VK, МКБ, Yandex Cloud, «Лаборатории Числитель», ecom.tеch, Cloud ru, Luntry, FUN&SUN, Lamoda Tech и др. Участие бесплатное. Регистрация тут.

Перевели для вас цикл статей об эволюции технологической платформы Mercado Libre — от монолитной архитектуры начала 2000-х к современной мультиоблачной платформе Fury, которая обеспечивает разработчикам удобную, масштабируемую и безопасную среду для создания, развёртывания и управления приложениями. В этой первой части описывается переход компании от единой базы и медленных релизов к микросервисам и облачным технологиям, что позволило значительно ускорить разработку и повысить надежность систем.

В статье рассматривается подход к снижению энергозатрат Kubernetes-кластера путём динамической подстройки ресурсов под реальный профиль нагрузки. Описан опыт внедрения системы сбора показателей энергопотребления, построения модели потребления сервисов и разработки «умного» контроллера на Go. Приведены примеры кода для Python и Go, а также разбор неожиданных подводных камней, с которыми столкнулся инженер.

В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.

В первой части мы разобрались с принципами работы Ingress-nginx контроллера. Теперь пришло время углубиться в то, как в Ingress-nginx устроен механизм обновления бэкендов и как реализована балансировка нагрузки на примере sticky sessions. Готовы узнать больше? Поехали!

Напомню, если вдруг забыли, эта статья написана по мотивам выступления на DevOpsConf’25, а меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team.

Итак, рассмотрим, как реализовано обновление бэкендов в самом контроллере.

Наверняка вы все работаете с Kubernetes, публикуете сервисы наружу через Ingress-контроллер. Уверен, что большинство из вас использует ingress-nginx. Создаете манифест, деплоите его в k8s, но не всегда получаете именно тот результат, который хотели бы. Или же все работает, но спустя какое-то время что-то идет не так. 

В этой серии статей, созданной по мотивам выступления на DevOpsConf’25, мы подробно разберемся как работает сам ingress-nginx контроллер и почему это не совсем классический nginx. Погрузимся в дебри LUA-кода чтобы понять, как реализована балансировка. А также затронем тему сниппетов, как их включить если они вам очень нужны, и почему этого делать не стоит.

Меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team. Больше 15 лет я в IT: за это время админил, разрабатывал, развивал on-premise инфраструктуру, инфраструктуру в облаках и даже курсы по DevOps, Security и DataTech в Yandex Cloud. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.

Привет, Хабр! С вами команда разработки платформы Russ Online Группы компаний Russ (входит в объединенную компанию Wildberries & Russ). Мы хотим поделиться историей о том, как от монолитной системы мы перешли к микросервисной архитектуре и облачным решениям на базе Kubernetes и S3. Эта трансформация создала фундамент для дальнейшего развития платформы и внедрения новых сервисов.

Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.

SRE Spotify написал интересный deep dive о том, как Kubernetes управляет контейнерами, запуская их как обычные процессы Linux. Вместо теоретических рассказов о пространствах имён, cgroups и внутренностях ОС автор развернул под в Kubernetes-кластере и исследовал, что происходит вокруг него на уровне Linux.

В оригинале для экспериментов использовался дистрибутив Kubernetes K3s, но наш инженер вдохновился историей и повторил все шаги на бесплатной версии нашей платформы — Deckhouse Kubernetes Platform Community Edition. Поэтому в статье теория из оригинала будет совмещена с нашей практикой. Будет полезно, если вы хотите лучше разобраться в фактических принципах работы K8s.

Примерно в 2012-2013 году в сообществе сисадминов стали много говорить о технологии под названием «Borg». Складывалось впечатление, что это какая-то система управления контейнерами, основанная на Linux и применяемая в Google — с её помощью они эксплуатируют свои внутренние ресурсы. Терминология по этой системе немного озадачивала; внутри кластеров, состоящих из «ячеек» (cells), в ней находились какие-то «борглеты», но суть уже на данном этапе начинала ускользать. В системе существовали концепции «сервисов» (services) и «заданий» (jobs), так, что приложения могли при помощи сервисов откликаться на пользовательские запросы, после чего система собирала задания в пакеты, и эти пакетные задания уже выполнялись достаточно долго.

Затем 7-го июня 2014 года состоялся первый коммит в Kubernetes. Это греческое слово означает «кормчий», и в течение первых трёх лет существования этой технологии решительно никто не понимал, как его правильно произносить. Поэтому пришлось сдаться и позволить простым смертным обозначать его как k8s.

В сообществе наделала шума свежая статья о том, каким мог бы быть Kubernetes, если бы его создавали с учётом всего, что мы знаем сейчас — почти десятилетие спустя после выхода версии 1.0. В ней DevOps-инженер Мэт Дугган предлагает заменить etcd и YAML (на HCL!), а также размышляет про новый пакетный менеджер вместо Helm и IPv6 по умолчанию. 

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

Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.

Так ли нужно хранить 3 ТБ метрик за 180 дней? Устали от компромисса между детализацией мониторинга и размером storage?
В статье разберём, как разделить метрики на два независимых потока без Multi Retention из Enterprise-версии. Solution inside: простое, но эффективное решение с сохранением детализации для оперативного мониторинга и разумным использованием дискового пространства. Идём организовывать хранение сырых метрик на 30 дней и агрегированных — на 180!

Мало скопировать чужой код, чтобы оператор работал как надо. Перед этим стоит узнать, как устроен Kubernetes: что делать, если оператор ведёт себя странно, как изменить его поведение и где искать проблему. Без теории не получится написать оператора, который работает так, как задумывали разработчики Kubernetes.
Меня зовут Иван, я техлид в Outlines Tech. Это первая часть цикла про создание собственного K8S-оператора. Чтобы сразу не перегружать вас информацией, ниже будет только база про Kubernetes: как он устроен, из чего состоит, как управляет состоянием и зачем это всё знать перед тем, как писать оператора.

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

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