Kubernetes *

Наверняка вы все работаете с 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.

Всем привет!

На связи Георг Гаал. Сегодня хочу поделиться своими мыслями о том, стоит ли — и почему стоит — внедрять Service mesh в современной инфраструктуре.

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

В этом практическом руководстве, мы познакомимся с Kubernetes (K8s) с точки зрения пентестера, а именно с основами, терминологией и методами исследования экземпляров Kubernetes.

В Kubernetes 1.28 появилось новое поведение: init-контейнеры теперь могут иметь поле restartPolicy (KEP 753). Это позволяет явно указать kubelet’у, что такой контейнер следует считать сайдкаром, а не классическим init-контейнером. В Kubernetes 1.33 эта долгожданная фича наконец получила стабильный статус. Разбираемся, что такое сайдкар-контейнеры и когда их лучше использовать.

Чем быстрее прогресс RISC-V, тем острее встает вопрос адаптации ПО под эту архитектуру. Например, инструментов для работы с микросервисами, без которых уже сложно представить современную разработку. Есть ли место контейнеризации в открытой архитектуре?

Под катом вас ждет тестирование современных инструментов оркестрации — Kubernetes, K3s и Docker Swarm. Мы — команда совместной лаборатории «Технологии программирования» Санкт-Петербургского политехнического университета Петра Великого и YADRO — попробовали запустить их на микрокомпьютере Lichee Pi 4A и оценили их производительность.

Мы все знаем, что Hashicorp Vault — это фактический стандарт для хранения секретов, а Kubernetes — для размещения приложений. Но как подружить их вместе? Существует множество инструментов для интеграции Vault с Kubernetes, и каждый из них имеет свои плюсы и минусы. Как выбрать подходящий?

В этой статье, созданной по мотивам выступления на DevOpsConf’25, вы узнаете о самых популярных инструментах доставки секретов из Hashicorp Vault в Kubernetes, таких как External Secrets Operator, Hashicorp Vault Secrets Operator, Hashicorp Vault Agent Injector, Hashicorp Vault CSI Provider, Bank Vaults-Vault Secrets Webhook. Для каждого инструмента будет приведён пример настройки, объяснено, как именно секрет попадает в приложение, а также мы с вами сравним их с точки зрения ротации секретов и удобства использования.

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

Привет! Я Андрей Квапил (или kvaps) и в этой статье я опишу наш путь организации доставки приложений в Kubernetes, объясню недостатки классического GitOps в локальной разработке и покажу, как новая утилита cozypkg решает эти проблемы. Материал рассчитан на разработчиков, знакомых с Helm и Flux.

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

Контейнерные технологии, такие как Docker и Kubernetes, стали стандартом для развертывания приложений в облаке. Они обеспечивают изоляцию, переносимость и масштабируемость, но также вносят новые сложности в кибербезопасность. Одна из таких проблем — «дрейф контейнеров» (container drift) — ситуация, когда работающий контейнер постепенно отклоняется от своего исходного состояния.

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

KubeVirt — это расширение для Kubernetes, которое позволяет запускать виртуальные машины внутри K8s-кластера. Именно эта технология, пусть и существенно доработанная, лежит в основе Deckhouse Virtualization Platform. Недавно наша команда встретила статью Дина Льюиса, которая отлично объясняет внутреннее устройство KubeVirt, принципы его работы и то, как они соотносятся с более привычными многим концепциями vSphere. Мы решили перевести её для сообщества. 

Под катом — перевод этого масштабного труда, который поможет получить чёткое представление о KubeVirt и принять взвешенное решение о его внедрении.