🏓 Как добиться 100% SLA более чем на 90 дней

❕ Мы начали с метрик.
Зафиксировали SLI и SLO: аптайм, потери пакетов, конвергенция BGP, MTTR. На каждую метрику — пороги и автоматические действия. Если что-то уходит за границы — система реагирует раньше людей.

🔎 Сеть
Несколько независимых аплинков, приходящих на независимые взаиморезервируемые маршрутизаторы. BGP с community для инженерии трафика и blackhole. Мониторим префиксы, xFlow, задержки на магистралях. Роутинговые «что если» прогоняем заранее.

💻 Кластера
Только HA. Хранилища настроены под сценарий: синхронно для критичных RPO, асинхронно между площадками для DR. Регулярно проверяем репликацию и отработку аварий.

🛡 Прод
Любое изменение — через тестовые среды и поэтапный выпуск. Rate limiting и load shedding включаются до того, как пользователи заметят деградацию. Окна обслуживания — только в периоды минимальной активности и так, чтобы клиенты это "не почуствовали".

⚙️ Операции
Runbook’и подробные и точные: кто, что, за сколько минут. Проводим тестовые испытания: искусственные отказы, секундомер, разбор полётов. Ошибочный бюджет не «тратим» — предотвращаем инциденты раньше.

🗂 Прозрачность
Важные метрики — публичны.
За последние 90 дней:
0 инцидентов с влиянием на сервисы
0 минут простоя
100.000% аптайма.

Это видно здесь

Как говорит наш ДИТ:

«В нашем деле хорошо — это когда никто ничего не заметил. И вот уже 90 дней подряд мы ничем не удивляем.
100%. Ровно. Скучно. Красиво»

⚙️ Must-Have Cloud-Native утилиты

⚙️ K9s
— терминальный UI для управления Kubernetes кластерами с возможностью мониторинга ресурсов, диагностики и оперативного управления подами.

⚙️ Lens
— полнофункциональная IDE для Kubernetes с визуализацией кластера, встроенным терминалом и поддержкой расширений.

⚙️ Alertmanager
— компонент экосистемы Prometheus для обработки, группировки и маршрутизации оповещений с поддержкой различных каналов уведомлений.

⚙️ VictoriaMetrics
— высокопроизводительная и экономичная система мониторинга и хранения временных рядов, совместимая с Prometheus.

⚙️ Cert-manager
— автоматическое управление TLS-сертификатами в Kubernetes, включая выпуск, обновление и продление от Let's Encrypt и других CA.

#полезное

💻 Cloud Controller Manager в Kubernetes: интеграция с облаками

Компонент Kubernetes, который абстрагирует работу с API облачных провайдеров.

💬 Как работает

Изначально облачная логика была внутри kube-controller-manager. Начиная с Kubernetes 1.6, CCM выделен в отдельный процесс/Deployment и берёт на себя задачи, связанные с облаком: создание LoadBalancer, управление нодами, маршрутизация и пр.

💬 Из чего состоит

CCM включает контроллеры (node, route, service), которые отслеживают состояние кластера и вызывают облачные API для синхронизации. Например, при создании Service типа LoadBalancer CCM запрашивает у провайдера балансировщик. Это позволяет использовать Kubernetes в мультивендорных средах без «вшивания» логики конкретного облака в ядро.

💬 Что это даёт

✅ Абстракция от вендора. Кластер не привязан к одному облаку: меняете провайдера — меняете реализацию CCM.

✅ Динамическое управление ресурсами. Автоматическое создание и удаление объектов (LB, маршрутов, узлов) по мере необходимости.

✅ Гибкость и масштабирование. Поддержка частных облаков и on-prem через кастомные реализации CCM.

Примечание: для хранилищ сейчас обычно используются CSI-драйверы; исторически облачные диски интегрировались через провайдер в Kubernetes.

💬 Что может CCM

✅ LoadBalancer
Автоматически создаёт облачный балансировщик для Service.

✅ Node Management
Добавляет/удаляет ноды, выставляет providerID и метки (например, зона доступности).

✅ Маршруты/сети
Настраивает маршрутизацию между нодами, если это требуется конкретным провайдером.

✅ Автоскейлинг
CCM предоставляет интерфейс для Cluster Autoscaler, чтобы динамически добавлять/удалять ноды в облаке при изменении нагрузки. Без CCM автоскейлинг ограничен локальными кластерами; с ним — полноценно работает в облаке.

#полезное

☯️CCM: проблема «курица и яйцо» в Kubernetes

В официальном блоге Kubernetes есть статья о классической проблеме инициализации Cloud Controller Manager после выноса cloud-provider из ядра.

💬 Что не так с CCM?

— Зависимость от нод.
При старте kubelet с --cloud-provider=external получают запрещающую метку (taint)
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule.

CCM должен снять эту запрещающую метку и добавить облачные сведения (адреса, метки). Если CCM развёрнут как Deployment/DaemonSet без необходимых допусков (tolerations), он может не запуститься на таких нодах.

— Каскадный эффект. Неинициализированные узлы блокируют запуск CCM, тот — снятие запрещающей метки. Параллельно CNI может ждать IP от CCM, узлы получают node.kubernetes.io/not-ready, и система зацикливается.

— Задержки.
Новый процесс инициализации добавляет задержки по сравнению с прежним поведением, когда kubelet сразу заполнял данные узла.

💬 Как исправить?

— hostNetwork: true.

Чтобы CCM использовал сетевой стек хоста и имел доступ к конечным точкам (endpoints) и API провайдера.

— Deployment/DaemonSet + механизм leader-election.

Разворачивайте как управляемый ресурс и включайте --leader-elect=true при нескольких репликах, чтобы избежать гонок.

— Размещение на control plane.

Задайте nodeSelector: { node-role.kubernetes.io/control-plane: "" } и добавьте podAntiAffinity, чтобы реплики не оказывались на одном хосте.

— Явные допуски (tolerations).

🟢Для старта на неинициализированных узлах:
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule

🟢Для размещения на control plane:
node-role.kubernetes.io/control-plane:NoSchedule и/или node-role.kubernetes.io/master:NoSchedule

🟢Для устойчивости при инициализации:
node.kubernetes.io/not-ready:NoExecute и node.kubernetes.io/unreachable:NoExecute (иногда может потребоваться и NoSchedule).

Дополнение: автоскейлинг по размеру кластера для CCM не рекомендуется; несколько реплик нужны для отказоустойчивости, а не для ускорения работы.

💬 Если CCM работает вне управляемого им кластера (например, в hosted control plane), применимость советов зависит от конкретной топологии и ограничений среды. Это не «упрощённый» случай — проверяйте требования вашей архитектуры.

#заметкиИнженера

🖥 NFS (Network File System) — протокол для совместного доступа к файлам по сети, разработанный Sun Microsystems в 1984 году.

Позволяет монтировать удалённые директории как локальные, делая их доступными для нескольких хостов. Используется в кластерах, NAS и облаках для общего хранилища.

🟡 Как работает

— Архитектура «клиент-сервер»: сервер экспортирует каталоги, клиенты их монтируют
— RPC-протокол: для управления подключениями (порт 111)
— NFS-демоны: nfsd обрабатывает запросы, mountd управляет монтированием
— Версии протокола: NFSv3 (UDP/TCP), NFSv4 (TCP, встроенная аутентификация)

🟡 Базовая настройка на сервере

# Установка пакета
sudo apt install nfs-kernel-server

# Создаём экспортируемый каталог
sudo mkdir /srv/share
sudo chown nobody:nogroup /srv/share

Конфигурация /etc/exports:

/srv/share 192.168.1.0/24(rw,sync,no_subtree_check)

🟡 Ключевые атрибуты /etc/exports

— rw/ro — чтение-запись или только чтение
— sync/async — синхронная/асинхронная запись
— no_subtree_check — отключение проверки поддеревьев
— no_root_squash — доступ root без преобразования
— all_squash — всех пользователей отображать в nobody
— anonuid/anongid — явное указание UID/GID для анонимных пользователей

🟡 Настройка клиента

# Установка пакета
sudo apt install nfs-common

# Монтирование каталога
sudo mount -t nfs server-ip:/srv/share /local/mount

NFS — классика для общих файловых систем в Linux, идеально для кластеров или бэкапов

#линуксятина

☁️ Путь к Cloud-native: как изменилась разработка

От монолита на «железе» и каскада — к микросервисам в контейнерах, облаку и DevOps.

Четыре составляющие подхода:

— Процесс:
Waterfall сменили Agile и DevOps — короткие итерации, автоматизация, CI/CD.

— Архитектура:
от монолита к микросервисам с независимыми релизами.

— Развёртывание:
от серверов в стойках и ВМ к образам Docker и контейнерам.

— Инфраструктура: вместо своих стоек — облако как базовая среда.

#полезное

Кейс: Гибридное облако и DBaaS для поставщика электроэнергии

📞 Задача

⚪️Обеспечить гарантированную доступность ИТ-сервисов.

⚪️Сформировать целевую гибридную архитектуру с учётом территориальных ограничений и пошагового плана миграции.

⚪️Закрыть дефицит компетенций по администрированию СУБД через модель сервиса (DBaaS).

🖲️ Этапы реализации

⚪️Совместная рабочая группа: аудит текущей инфраструктуры, расчёт TCO и выбор сервисной модели.

⚪️Проектирование целевой гибридной архитектуры с размещением в ЦОД Новосибирска; подготовка ТЗ и требований к SLA.

⚪️План миграции с обходными сценариями под технические ограничения и распределённые площадки.

⚪️Перенос критичных сервисов поэтапно с контролем доступности; ввод в промышленную эксплуатацию.

⚪️Подключение DBaaS: обслуживание >200 БД (в т.ч. InterSystems IRIS и MS SQL) силами команды CORTEL.

⚪️Настройка 24×7 поддержки и регламентов взаимодействия по SLA.


🚩 Результат

⚪️Доступность 99,982% в год на новой гибридной архитектуре (ранее — 96,15%).

⚪️100% клиентов перешли на онлайн-сервисы благодаря модернизации и новому качеству обслуживания БД.

⚪️Выгода сервисной модели: −59% к TCO относительно модернизации собственных ЦОД (по расчёту до старта проекта).

⚪️Гарантированный SLA до 99,99% по критичным сервисам и работа 24×7 без зависимости от отпусков и замен в ИТ-штате.

⚪️Быстрое закрытие дефицита компетенций: DBaaS вместо долгого найма редких DBA под кастомные решения.

«Мы скрупулёзно проработали ТЗ и требования к качеству. На выбранной гибридной архитектуре обеспечили непрерывность работы приложений и предсказуемый SLA; команда CORTEL быстро погрузилась и качественно оказывает сервис».
— директор по ИТ «НовосибирскЭнергоСбыт»

✉️ Подробнее о проекте читайте здесь.

#изПрактики

😎 Дом, офис или гибрид

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

Чтобы не словить минусы удалёнки одиночество и изоляция, размытые границы дня и переработок, расфокус и «залипание» в ленте, а еще проблемы со спиной и лишним весом — нужен режим.

🤷‍♂️ Дисциплина — наше всё.

🥰 Начинать день с одного приоритетного дела.

😠 Развести типы задач по местам: офис — встречи, обсуждения, согласования; дом — письменная, проектная, инженерная работа.

😠 Организовать рабочую точку дома: стол, свет, удобный стул, наушники; фиксированное время начала и завершения; ритуал выхода (закрыт ноутбук — работа окончена).

🤙 Зарезервировать время для созвонов; в остальное время — асинхронные сообщения.

🎧 Поддерживать свой жизненный ресурс: вода под рукой; полноценный обед без встреч и скроллинга ленты.

А еще разминки для тела и глаз 🙃

😄 — дом
👍 — офис
🔥 — гибрид

P.S. Не забудьте закрыть ноутбук на эти два дня, хороших выходных✔️

#MentalDebug

⚠️ Как КИИ соответствовать новым требованиям

С 1 сентября 2025 года внесены изменения: новые сроки, официальный стандарт ПНСТ 1007-2025 и типовые отраслевые объекты.

➡️ Что сделать уже сейчас

🟡 Определить контур: реестр объектов КИИ и уровни значимости.

🟡 Сверить требования: ПНСТ 1007-2025 и типовые объекты/ перечень обязательных мер.

🟡 Составить перечень доработок: что добавить, что заменить, что убрать — с оценкой риска и трудозатрат.

🟡 Составить план до 01.01.2028 и 01.12.2030: приоритеты, сроки, владельцы, бюджет.

🟡 Оформить процессы: регламенты реагирования, журналы, роли, обучение.

🟡 Запустить контроль: метрики, квартальные ревизии, доказательная база для проверок.

👉 Подробнее читайте в новом материале

#статья

💻 Disruption Budget в Kubernetes: как не сломать сервис плановыми работами

PodDisruptionBudget (PDB) - это объект Kubernetes, который ограничивает количество одновременно недоступных подов во время добровольных вытеснений (voluntary disruptions).

🔵 Ключевое отличие:
PDB не защищает от аппаратных сбоев или проблем с нодами. Его задача — сделать плановые работы предсказуемыми и безопасными.

🔵 Зачем это нужно?

Без PDB:
— При drain ноды Kubernetes может одновременно выключить все поды
— Rolling update может убить старые поды до запуска новых
— Обновление кластера = лотерея доступности сервиса

С PDB:
— Гарантируется минимальное количество работающих реплик
— Контролируется максимальное количество одновременно недоступных подов
— Плановые работы перестают влиять на SLO

🔵 Примеры использования

💬 Защищаем критичное приложение

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 2  # Всегда должно быть доступно не менее 2 подов
  selector:
    matchLabels:
      app: payment-service

Можно использовать для сервисов, где каждая недоступная реплика влияет на бизнес-метрики.

💬 Постепенное обновление stateful-сервиса

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: kafka-pdb
spec:
  maxUnavailable: 1  # Одновременно может быть недоступен только 1 под
  selector:
    matchLabels:
      app: kafka-broker

Можно использовать для stateful-приложений (БД, очереди), где одновременный уход нескольких реплик может нарушить консистентность.

🔵 Как это работает на практике

— При drain ноды kubectl drain node-1 — kubelet проверяет PDB перед каждым вытеснением
— При rolling update — Deployment согласует обновление с ограничениями PDB
— При ручном удалении kubectl delete pod — PDB может заблокировать операцию

PodDisruptionBudget — это не опция, а обязательный инструмент для любого продакшн-сервиса в Kubernetes.

Он превращает потенциально опасные операции в контролируемые процессы и позволяет соблюдать SLO даже во время плановых работ.

#заметкиИнженера

💎 Chaos Mesh — платформа хаос-инжиниринга для Kubernetes.

Позволяет моделировать отказы и оркестровать сценарии через CRD и удобную веб-панель (Chaos Dashboard).

⚙️ Основной функционал:

— Типы экспериментов: PodChaos, NetworkChaos, IOChaos, TimeChaos, DNSChaos, StressChaos, KernelChaos, а также облачные сбои.

— Оркестрация сценариев через Chaos Workflows, в том числе проверки статуса и последовательности шагов.

— Управление через Kubernetes API/kubectl и Web-UI; все сущности оформлены как CRD.

— Безопасность: ограничение пространств имён, аутентификация, admission-webhook и RBAC-контроль.

— Интеграции: GitHub Actions (chaos-mesh-action) для запуска экспериментов в CI.

— Установка через Helm-чарт

Полезно для проверки устойчивости сервисов к сбоям до продакшена и выявления «узких мест» инфраструктуры.

👉 Git
#полезное

📊 Мониторинг системных метрик в Linux

В Linux есть встроенные утилиты для анализа в реальном времени

↗️ Что и чем смотреть

— top / htop: Мониторинг процессов, CPU, памяти в реальном времени.
— iostat: Статистика ввода-вывода (диски, I/O bottlenecks).
— vmstat: Виртуальная память, CPU, процессы (общая нагрузка).
— netstat / ss: Сетевые соединения, порты, статистика трафика.

↗️ Основное использование:

🟡 top: Интерактивный мониторинг процессов.

top # запуск, Shift+P для сортировки по CPU, Shift+M по памяти q для выхода.

🟡 htop: Улучшенный top с цветами, мышью и деревом процессов.

htop # аналогично top, но удобнее;

🟡 iostat: I/O статистика по дискам.

iostat -x 1 5 # расширенный вывод, интервал 1с, 5 итераций

(показывает %util — загрузку дисков, await — время отклика).

🟡 vmstat: Краткий обзор системы.

vmstat 1 5 # интервал 1с, 5 итераций

(показывает r/b — процессы в очереди/блоке, swpd — swap, si/so — swap in/out).

🟡 netstat / ss: Сетевые соединения.

netstat -tuln # TCP/UDP listening порты
ss -tuln # аналог netstat
ss -tp 'state established' # активные TCP-соединения с процессами.

Эти утилиты — первый инструмент при любой диагностике проблем с производительностью. Не заменяют полноценные системы мониторинга, но дают мгновенную картину происходящего в системе.

#линуксятина

⏰ Site Reliability Engineering — набор инженерных практик для стабильного сервиса, предсказуемых рисков и затрат.

➡️ Функции SRE влияют на ключевые показатели:
SLA/SLO — обещанная и целевая доступность;
MTTR/MTBF — скорость восстановления и частота отказов;
RTO/RPO— время восстановления и допустимые потери данных при аварии;
TCO— совокупная стоимость владения.

Разберём их в виде глоссария:

🟢SLI/SLO/SLA

Фиксирует качество сервиса в числах: доступность, ошибки, время ответа.

*обеспечивает выполнение обязательств, снижает штрафы и споры, задаёт понятные приоритеты.

🟢Incident Response

Стандартизирует действия во время сбоя.

*сокращает MTTR, уменьшает потери выручки и репутации, помогает удерживать SLA/SLO.

🟢 Postmortem

Фиксирует, что произошло, почему это случилось и что нужно изменить, чтобы больше не повторилось.

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

🟢Observability

Диагностирует неизвестные проблемы через исследование метрик, логов и трейсов.

* уменьшает время диагностики, поддерживает достижение SLO, убирает «слепые зоны».

🟢 Progressive Delivery

Проводит поэтапный вывод обновлений с контролем трафика и быстрым откатом при проблемах.

* снижает релиз-инциденты, сокращает MTTR, уменьшает стоимость сбоев.

🟢 HA и DR

Размещает сервис в нескольких зонах/регионах, хранит копии данных, автоматически переключает трафик, регулярно проверяет восстановление из резервных копий.

* предсказуемые RTO/RPO, соблюдение требований, меньше простоев и ниже TCO.

🟢Автоматизация и runbook-и

Стандартизирует и автоматизирует типовые операции: перезапуск, откат, переключение трафика и т.д.

*сокращает MTTR и операционную рутину (toil), обеспечивает предсказуемые результаты.

🟢Chaos Engineering

Проводит запланированные эксперименты: отключение зависимостей, задержки, падение узлов и т.д., проверяет реакцию и восстановление сервиса.

*снижает частоту и длительность сбоёв, помогает удерживать SLA/SLO, уменьшает незапланированные расходы.

🟢 Управление toil

Измеряет повторяющиеся ручные задачи и устраняет их.

*высвобождает время инженеров на улучшения и фичи, уменьшает TCO.

#полезное

😎 Настоящий SRE: инжиниринг надежности для специалистов и организаций

Практическое руководство по тому, как мыслить, работать и строить команды в парадигме SRE, отвечающие за надежность современных сервисов.

🔎 Рассматривается:

— что такое SRE, чем оно отличается от DevOps и классической эксплуатации;
— менталитет SR-инженера: системное мышление, фокус на клиенте, работа с инцидентами и обратной связью;
— культура SRE и «продвижение» надежности внутри компании;
— как стать SR-инженером: переход из разработки, админства, нетехнических ролей, поиск работы и собеседования;
— один день из жизни SR-инженера, рутина, борьба с выгоранием и устойчивые рабочие практики;
— факторы успеха и типичные провалы при внедрении SRE в организации;
— иерархия надежности Дикерсона, модели команд SRE и этапы развития практики SRE в компании;
— дополнительные ресурсы, письма «молодому SRE» и советы от опытных практиков.

Полезно начинающим и действующим SR-инженерам, DevOps- и платформенным командам, инженерам эксплуатации, техлидам и руководителям ИТ, которые хотят системно подойти к надежности и выстроить зрелую практику SRE в своей организации.

Автор:
Дэвид Н. Бланк-Эдельман.
Издательство:
O’Reilly / «Спринт Бук», рус. изд., 2025.

#книги

🚂 sl: поезд вместо ls

sl — консольная утилита, которая запускает анимацию паровоза в ASCII-графике, когда вы вместо ls набираете sl .

👍 Это исторический Unix-розыгрыш: его придумали, чтобы «наказывать» вечных опечатывающихся.

Работает как обычная команда:
ввёл sl — поехал поезд, терминал на пару секунд превращается в анимированный скринсейвер.

😈 Можно развлечь своих коллег.

⌨️ Установка

# Debian / Ubuntu
sudo apt install sl

# Fedora
sudo dnf install sl

# Arch / Manjaro
sudo pacman -S sl

P.S. хороших выходных ☺️

#rootoffun

⚖️ Изменения в законодательстве для ИТ

📝 Увеличен срок хранения данных пользователей: мессенджеры, соцсети и другие сервисы (организаторы распространения информации) должны будут хранить их не 1 год, а 3. Это правило начнёт действовать с 1 января 2026 года.

📝 Госаккредитация ИТ-компаний с 2026 года будет зависеть от того, открыт ли их официальный сайт для любого посетителя: без регистрации, паролей и ввода личных данных.

📝 Налоговые льготы для ИТ-компаний пересматриваются: планируется повысить льготный тариф страховых взносов и частично изменить льготы по НДС для операций с российским ПО. Окончательный текст закона пока не утверждён.

📝 Штрафы от 10 до 500 тыс.₽ предлагают ввести за размещение видео, созданных с помощью ИИ, если они не помечены соответствующей маркировкой. Соответствующий законопроект уже внесён в Госдуму.

#ИТиЗАКОН

📦 Три типа хранилища

Наглядная схема от ByteByteGo.

➡️ Блочное хранилище (Block Storage)

Сервер получает необработанные блоки (том) и сам решает, как их использовать: под файловую систему, базу данных, виртуальные машины.

Подходит для задач, когда:

— требуются высокие IOPS и низкая задержка;
— нужно хранить данные СУБД;
— разворачиваются диски виртуальных машин и другие критичные транзакционные сервисы.

➡️ Файловое хранилище (File Storage)

Поверх блоков поднимается файловая система с привычной моделью «папки/файлы», доступной по сети (NFS, SMB).

Подходит для задач, когда:

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

➡️ Объектное хранилище (Object Storage)

Данные хранятся в виде отдельных объектов в общем пространстве, без привычных папок. Доступ к ним идёт через API (часто S3-совместимый). Такой подход делает упор на большой масштаб, надёжность и низкую стоимость, а не на максимальную скорость.

Подходит для задач, когда:

— нужны недорогие и надёжные объёмы хранения на терабайты и выше;
— требуется хранить бэкапы, архивы, статику и медиа;
— накапливаются данные для аналитики и построения data lake.

#полезное

👋 Инструменты для Argo CD

Экосистема инструментов вокруг Argo CD

🟠 Argo CD Autopilot
— инструмент для быстрого развертывания и управления ArgoCD по принципу "GitOps для самого ArgoCD".

🟠 Argo CD Image Updater
— инструмент для автоматического обновления образов в приложениях ArgoCD до последних версий.

🟠 Argo Rollouts
— расширение для управления постепенным развертыванием (canary, blue-green) в Kubernetes.

🟠 Make-argocd-fly
— Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений

#полезное

⭐️ Инструменты для FluxCD

Экосистема инструментов вокруг FluxCD

🔵 Flagger
— оператор для автоматизации canary-релизов в Kubernetes, часто используемый с FluxCD.

🔵 Weave GitOps
— корпоративная платформа GitOps на основе Flux с веб-интерфейсом, RBAC и расширенной аналитикой.

🔵 FluxCD Multi Tenancy
— инструмент для организации мультитенантной работы в FluxCD, позволяющий изолировать команды и среды в рамках одного кластера.

🔵 Terraform Provider for Flux
— официальный Terraform провайдер для развертывания и управления FluxCD через Infrastructure as Code.

#полезное

💎 Конец эры Ingress NGINX

В блоге Kubernetes объявили о поэтапном завершении поддержки Ingress NGINX.

📍 Что такое Ingress в K8s

Ingress — это Kubernetes-ресурс, который описывает, как внешний HTTP/HTTPS-трафик попадает к сервисам внутри кластера: хосты, пути, TLS, балансировка нагрузки.
Без него каждый сервис приходится выводить наружу через NodePort или отдельный LoadBalancer, что быстро становится неудобно в production.

Сам по себе Ingress — это только декларация. Работу за него делает Ingress-контроллер: отдельный компонент, который отслеживает создание и изменение Ingress-ресурсов через Kubernetes API и на их основе настраивает прокси или балансировщик (NGINX, Envoy, HAProxy и т.п.).

📍 Что такое Ingress NGINX

Ingress NGINX — это один из таких контроллеров. Он использует NGINX, парсит Ingress-ресурсы и генерирует для него конфигурацию.

Его массово выбрали как «дефолтное» решение за счёт:

— простого старта;
— хорошей производительности;
— богатого набора функций (rate limiting, авторизация, тонкая настройка через аннотации).

📍 История проблемы

Ingress NGINX давно жил в режиме «минимально достаточной поддержки». На фоне высокой популярности проект сталкивался с одними и теми же ограничениями:

— мало мейнтейнеров,
— сложная кодовая база,
— растущий backlog issues и PR.

Решение о завершении поддержки — логический итог этого накопившегося технического и организационного долга.

📍 Что происходит сейчас

— Поддержка Ingress NGINX заявлена до марта 2026 года.
— До этого момента будут выходить критические обновления безопасности.
— Текущие развёртывания продолжают работать в прежнем режиме.
— Образы контейнеров, Helm-чарты и другие артефакты остаются доступными.

#заметкиИнженера

➡️ Чем заменить Ingress NGINX?

Обзор альтернативных контроллеров на замену Ingress NGINX

📍 Gateway API — развивается как преемник классического Ingress и более гибкий способ описания сетевого трафика в кластере.

По сравнению с Ingress он:

— поддерживает более сложные сценарии маршрутизации (canary, A/B-тесты и др.);

— вводит чёткое разделение ролей между инфраструктурой и приложениями;

— становится отраслевым стандартом, который поддерживают разные вендоры и open source-проекты.

📍 Traefik Proxy

— динамическая конфигурация без перезапуска;
— встроенный dashboard для мониторинга и отладки;
— поддержка нескольких протоколов (HTTP, TCP, gRPC, WebSocket).

📍 HAProxy Ingress Controller

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

📍 Контроллеры на базе Envoy: Contour, Emissary-ingress

— расширенные возможности для интеграции с service mesh;
— гибкая конфигурация через xDS-API;
— активное развитие и поддержка со стороны сообщества и вендоров.

📍 Что учитывать при выборе?

— Сложность миграции с существующих конфигураций Ingress NGINX
— Поддержка Gateway API — становится ключевым критерием
— Производительность под вашу нагрузку
— Экосистема и сообщество вокруг проекта

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

#полезное