Mops DevOps

VictoriaLogs в Kubernetes: от установки до практического применения Руководство по развёртыванию и использованию VictoriaLogs в Kubernetes. Документ фокусируется на практических шагах: установка через Helm, интеграция с cert-manager и Ingress, генерация логов, примеры запросов в LogsQL и интеграция с экосистемой наблюдаемости. 👉 https://habr.com/ru/articles/985350/ #VictoriaLogs

Grafana Operator — дорога к IAC или путь в никуда? Услышав про Grafana Operator, я, окрыленный надеждами, пошел к нему за решением. Но у Grafana Operator оказалось свое представление о деплое, о провижининге и о том, как он вообще должен работать. 👉 https://habr.com/ru/companies/kts/articles/993002/ #grafana

Прощай, Ingress. Здравствуй, Gateway API Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes. Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress. Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой. 👉 https://habr.com/ru/companies/gnivc/articles/992366/ #kubernetes

Братцы! С Новым годом! Пусть праздники пройдут без инцидентов! Набирайтесь сил!!! 🎄🎄🎄

Перенос кластера kubernetes на другие ip адреса Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки. В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете. 👉 https://habr.com/ru/articles/980976/ #kubernetes

Архитектурный квиз: костыль или элегантное решение? Отказоустойчивый и масштабируемый энтерпрайз невозможно спроектировать по книжкам. Одно и то же решение может фигурировать и в best, и в bad practice — и, что забавно, иногда переходит из одного списка в другой. Ещё недавно монолиты считались злом, а теперь снова в моде. Хотите посмотреть, как знакомые паттерны ведут себя в реальном контексте? Чтобы показать это на практике, я собрала три инженерных кейса. Каждый оформлен в формате детективного квиза: роль, фабула, вопросы на размышление, разбор и выводы. Попробуйте разобраться в проблеме, пройти тест и определить: где костыль, где инженерный компромисс, а где — настоящая best practice. 👉 https://habr.com/ru/companies/cdek_blog/articles/969692/

Сравнение числа ошибок в коде, написанном людьми и AI Исследователи из компании CodeRabbit проанализировали 470 pull-запросов (350 - созданные AI, 150 - написанные вручную) в открытых проектах на GitHub и пришли к выводу, что в изменениях, сгенерированных AI-ассистентами, присутствует в 1.7 раза больше значительных дефектов и в 1.4 раза больше критических проблем, чем во вручную написанном коде. В среднем в сгенерированных через AI pull-запросах присутствовало 10.83 проблем, в то время как в созданных вручную изменениях данный показатель составил 6.45. 👉 https://www.opennet.ru/opennews/art.shtml?num=64485 #ai

Не runc’ом единым: интересные среды запуска контейнеров Существует множество сред для запуска контейнеров; среди распространенных можно выделить runc и kata. Мы в Beeline Cloud решили поговорить не только о широко известных, но и о набирающих свою аудиторию рантаймах. В подборке: проект, который окрестили «Docker’ом на диете»; система, заточенная под unikernel; среда для работы на устройствах с ограничениями по памяти и не только. Все они имеют лицензию Apache-2.0. 👉 https://habr.com/ru/companies/beeline_cloud/articles/979010/ #containers

Балансировка DNS-трафика и активные health-check'и апстримов — как и почему мы начали использовать DNSdist Долгое время в нашей внутренней сети для обработки DNS-трафика мы использовали только BIND, и нам с ним было хорошо. Но в какой-то момент его возможностей перестало хватать. В статье расскажу, что именно с BIND не так и почему теперь весь DNS-трафик у нас проходит через DNSdist. И что это вообще такое... #dns

Kubernetes кластер на миллион узлов. Обзор проекта k8s-1m Кейса о том, как не догадки, а измерения двигают пределы Kubernetes. Ключевые идеи: изоляция QPS по типам ресурсов, смягчение гарантий хранения для эфемерных данных, и шардирование планировщика. Полезно всем, кто проектирует крупные кластеры или хочет работать с ними. 👉 https://habr.com/ru/articles/958074/ #kubernetes

Kubernetes v1.35: Timbernetes (The World Tree Release) Вышла новая версия Kubernetes. Основные изменения: 🔹Stable: In-place update of Pod resources Возможность менять requests/limits (CPU/RAM) без рестарта пода. Давно ждали 🎉 🔹Stable: PreferSameNode traffic distribution Локализация трафика внутри узла, если эндпоинт есть локально 🔹Stable: Configurable NUMA node limit for topology manager Возможнось использовать больше 8 NUMA nodes 🔹Beta: maxUnavailable for StatefulSets Возможность определить максимальное количество подов, которые могут быть недоступны во время обновления. Этот параметр наиболее эффективен в сочетании с параметром .spec.podManagementPolicy, для которого установлено значение Parallel. В этом случае для приложений с отслеживанием состояния (которые могут допускать отключение более одного модуля) обновление завершится быстрее. 🔹Больше не поддерживаются cgroup v1 Релиз, включает 60 улучшений, из которых 17 стали стабильными, 19 — бета-версиями и 22 — альфа-версиями. 👉 https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/ #kubernetes

НАЙС.ОС - минималистичный дистрибутив, собранный с нуля и оптимизированный для контейнеров Проект НАЙС.ОС развивает самостоятельный Linux-дистрибутив, собираемый "с нуля" из исходного кода и поддерживающий собственную пакетную базу, не заимствующую сценарии сборки пакетов из других дистрибутивов. Проект развивает свой инструментарий, свой набор патчей и свою политику сборки. 👉 https://www.opennet.ru/opennews/art.shtml?num=64417 #containers #os

Docs-as-Code (DaC) — это подход к созданию и сопровождению технической документации с использованием тех же инструментов и рабочих процессов, что и при разработке программного кода. Этот метод легко интегрирует документацию в жизненный цикл разработки программного обеспечения, способствуя сотрудничеству, контролю версий и автоматизации. 🔹 Docs as Code: введение в предмет 🔹 Docs as Code: настраиваем инструменты под себя 🔹 Как мы пытались в Docs as Code и проиграли 🔹 Победить хаос в документации: почему мы создали свой продукт для Docs-as-a-Code #docs

Почему в Rust всё правильно Не существует той самой «серебряной пули», то есть инструмента, решающего абсолютно все задачи. Также не бывает и идеального языка программирования. Но что если вам скажут, что существует почти идеальный язык? И это Rust! 👉 https://habr.com/ru/companies/domclick/articles/970010/ #rust

Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше Helm 4 принёс пользователям единственное значимое изменение - внедрение Server-Side Apply вместо 3-Way Merge. Это решает проблемы с некорректными обновлениями ресурсов, но многих возможностей Helm по-прежнему не достаёт. Nelm - современная альтернатива Helm 4 - ушёл вперёд по фичам, исправлениям и улучшениям. 👉 https://habr.com/ru/companies/flant/articles/970498/ #helm

Helm v4: разбираем ключевые отличия от Helm v3 🔹 Server-Side Apply вместо 3-Way Merge 🔹 WASM-плагины 🔹 kstatus для ожидания готовности ресурсов 🔹 Content-based-кеширование чартов 🔹 OCI-чарты можно устанавливать по их digest 👉 https://habr.com/ru/companies/flant/articles/967150/ #helm

Как работает ingress-nginx: нырнем поглубже В этой серии статей, созданной по мотивам выступления на DevOpsConf’25, подробно разберемся как работает сам ingress-nginx контроллер и почему это не совсем классический nginx. Погрузимся в дебри LUA-кода чтобы понять, как реализована балансировка. А также затронем тему сниппетов, как их включить если они вам очень нужны, и почему этого делать не стоит 😀 🔹 Часть 1 — basics 🔹 Часть 2 — балансировка #kubernetes #nginx

Как мог бы выглядеть Kubernetes 2.0 В преддверии 10-летней годовщины со дня выхода Kubernetes 1.0 поразмышляем о том, что могло бы войти в релиз 2.0. Например, заменить YAML и etcd, а также существенно переработать пакетный менеджер. 👉 https://habr.com/ru/companies/flant/articles/922242/ #kubernetes

OS Talos Linux. Хайп или реальный продукт OS Talos Linux спроектирован специально под Kubernetes. На трансляции разберем почему поднялся хайп вокруг этой OS и на сколько она функциональна, а так же: • архитектуру и философию проекта • эксплуатацию • кейсы • примеры решений 👉 https://www.youtube.com/watch?v=liso5CNn4G4&t=1458s #kubernetes #talos

Kubernetes как PaaS: максимум возможностей без разработки Kubernetes — это не просто оркестратор контейнеров, а целая экосистема инструментов, которые позволяют построить PaaS без написания кода. Helm, ArgoCD, Crossplane, Knative и другие решения делают управление приложениями и инфраструктурой настолько простым, что разработка собственной платформы превращается в задачу конфигурации, а не программирования. Разберем, как создать PaaS, используя мощь Kubernetes и его экосистему. #kubernetes