Mops DevOps

Обзор новых проектов которые появились в CNCF Sandbox в 2024 году Как ни крути, а CNCF Sandbox наш маяк 🚨 в бушующем море новых проектов позволяющий понять, какие из них уже пора пробовать на зуб, а что оставить дозревать. 🔹 Provisioning, Observability, Analysis: автоматизация работы с Terraform и платформа как код - Atlantis - bpfman - Kubean - KusionStack - OSCAL Compass - Perses - Ratify 🔹 Orchestration & Management: гибкие политики планирования и безопасное управление сервисами - HAMi - Kmesh - Koordinator - Kuadrant - KubeSlice - LoxiLB - Sermant 🔹 Runtime и App Definition & Development: отказоустойчивое хранилище и анализ временных рядов - OpenEBS - openGemini - OVN-Kubernetes - Radius - Score - Shipwright - Stacker - youki А также мегаобзор проектов, попавших в CNCF Sandbox в 2023 году. Возможно вы что-то пропустили. #cncf

Kubernetes в изоляции: когда ваш кластер не должен знать о существовании интернета Вы думаете, что развернуть Kubernetes без интернета — это просто kubeadm init плюс пара манифестов? Посмотрим, как скрипты решают проблемы, о которых вы даже не задумывались. Спойлер: здесь есть чему удивиться. И философский вопрос: зачем это всё? Потому что настоящий DevOps — не тот, кто умеет копировать команды из интернета, а тот, кто может развернуть production‑кластер: - на заброшенной арктической станции, - на сервере с доступом только через 3G‑модем, - в подвале банка с железобетонными стенами. 👉 https://habr.com/ru/companies/slsoft/articles/897102/ #kubernetes

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

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

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

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

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

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

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

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

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

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

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

Прощай, 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

Контейнеры в одном инструменте, виртуалки — в другом, частное облако — вообще отдельная история со своей командой и своим бюджетом. На практике границы между ними давно стёрлись. Монолиты работают в виртуальных машинах, микросервисы — в контейнерах, часть инфраструктуры — на собственном железе, часть — в облаке. Каждый кусок требует своего набора инструментов и своих правил доступа. Deckhouse Platform собирает всё это под одним управлением. Контейнеры, виртуальные машины, ML-нагрузки и управляемые сервисы работают на любой инфраструктуре, без привязки к одному провайдеру. Сейчас так работают 1300+ кластеров в 260+ компаниях. На консультации с инженерами Deckhouse разберите, какие из ваших сценариев платформа закрывает уже сейчас 👈