Отдельно проверим доступность приложений и управляющего API. Если обновление включает перезапуск etcd, выполняющиеся запросы к API server могут зависнуть на это время, даже после drain узла.

Команды проверки и изменения конфигурации разнесены по этапам: сначала собираем сведения, затем готовим приложения и только после этого обновляем компоненты.

Сначала расставим границы обновления

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

Начните с команды, которая покажет версии клиента kubectl и сервера:

В выводе ищите Client Version и Server Version. Это ещё не инвентаризация всех узлов: версия сервера описывает ту часть системы, к которой обратился клиент. Версии kubelet на всех узлах покажет следующая команда:

В столбце VERSION указаны версии kubelet, в STATUS ожидается Ready. Сохраните этот вывод для сравнения после обновления.

Официальный гайд kubeadm рассчитан на переход 1.36.x → 1.37.x. Если кластер старше, подготовьте последовательность промежуточных обновлений. Для EKS, GKE, AKS и других управляемых сервисов понадобится процедура провайдера: команды обслуживания самостоятельно установленного control plane нельзя автоматически переносить в managed-окружение.

Во время перехода разные версии компонентов допустимы в определённых пределах. Например, kubelet не должен быть новее API server. Когда в отказоустойчивом кластере одновременно работают API server 1.36 и 1.37, обновлять kubelet до 1.37 ещё рано. Совместимость должна сохраняться с обоими серверами. Поэтому следуйте порядку действий: сначала управляющие компоненты, потом рабочие узлы.

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

Какие static Pods перестанут запускаться

Обычный Pod создаётся через Kubernetes API. Static Pod запускается kubelet по локальному описанию на узле. Это позволяет поднимать компоненты, которые нужны для работы самого API server. В кластерах kubeadm таким способом запускаются компоненты control plane.

Static Pods изначально не предназначались для чтения объектов API, однако ошибка позволяла некоторым ссылкам на Secrets и ConfigMaps работать. В 1.37 это поведение окончательно запрещено: feature gate PreventStaticPodAPIReferences, позволявший отключить ограничение, удалён. Проблема возникает у Pod с такими ссылками, а не у любого Pod, использующего секрет.

Проверьте каталог, из которого kubelet читает static-манифесты. В конфигурации kubelet его задаёт staticPodPath; для типового kubeadm-окружения в рассмотренных материалах используется /etc/kubernetes/manifests/. Если у вас другой путь, проверять нужно именно его.

Особое внимание уделите полям configMapRef, secretRef, configMapKeyRef и secretKeyRef. Найденные ссылки требуют разбора: какой компонент читает значение, почему он запускается как static Pod и как предоставить ему конфигурацию до появления API server. Проверка должна охватывать и шаблоны, из которых вы создаёте новые узлы. В разборе devs group найдёте варианты исправления: предоставить компоненту локальный файл через hostPath или перенести подходящую нагрузку в DaemonSet. Выбор зависит от того, нужен ли компонент для запуска самого control plane.

В официальном руководстве есть ещё одна полезная деталь: kubelet читает файлы static-манифестов независимо от расширения. Если оставить рядом с рабочим файлом копию с окончанием .backup, она тоже может попасть в обработку. Поэтому резервные копии храните вне каталога static Pods. .

Какие параметры помешают запуску kubelet

В 1.37 обновлён встроенный cAdvisor, который собирает статистику контейнеров. Часть его старых флагов больше не принимается. Если они передаются kubelet при запуске, процесс завершается с ошибкой. Среди удалённых параметров есть --containerd, --boot-id-file, --machine-id-file, --global-housekeeping-interval и семейство --storage-driver-*. Из прежних флагов cAdvisor сохранён --housekeeping-interval.

Проверьте, как запускается служба: изучите systemd unit, файл /var/lib/kubelet/kubeadm-flags.env и /etc/default/kubelet. Набор мест зависит от установки: unit может подхватывать параметры из другого файла. Поэтому просмотр одного unit ещё не означает, что все аргументы найдены.

В выводе смотрите, откуда служба получает аргументы и переменные окружения. Сопоставьте найденные параметры с полным списком удалённых флагов в changelog. Название --containerd здесь относится к старому параметру cAdvisor; по нему нельзя делать вывод, что сам runtime containerd требуется удалить.

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

Отдельно проверьте панели и правила оповещений, завязанные на cAdvisor. В 1.37 исчезают серии container_cpu_load_average_10s, container_cpu_load_d_average_10s и container_tasks_state. Составьте список зависимых проверок.

Что проверить в SELinux и томах

SELinux использует метки объектов и процессов для контроля доступа. Раньше при подготовке тома runtime мог рекурсивно менять метки файлов и каталогов. Если файлов много, этот обход занимает время. Оптимизированный механизм задаёт контекст при монтировании тома через -o context=<label>.

В Kubernetes 1.37 SELinuxMount включён по умолчанию. При этом механизм применяется при выполнении набора условий: нужен подходящий PVC, известная Kubernetes SELinux-метка и поддержка со стороны драйвера. CSI-драйвер объявляет такую поддержку полем spec.seLinuxMount: true. На узлах без SELinux эти изменения не действуют.

Риск появляется при совместном использовании тома на одном узле. Официальный разбор приводит два сценария: Pods с разными метками используют разные subPath одного тома; либо том разделяют на привилегированный и непривилегированный Pods. При новом способе монтирования один из конфликтующих Pods может остаться в ContainerCreating.

В Kubernetes 1.36 можно заранее проверить такие конфликты с помощью selinux-warning-controller, который работает внутри kube-controller-manager. По умолчанию он отключён. Для проверки включите его через параметр --controllers у kube-controller-manager; в документации приведён пример --controllers=*,selinux-warning-controller.

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

Для приложения, которому нужно прежнее поведение, есть настройка Recursive. Ниже кусок спецификации Pod, который сохраняет рекурсивное применение меток:

У Deployment или StatefulSet этот параметр должен находиться внутри спецификации Pod в шаблоне: spec.template.spec.securityContext. Проверьте итоговый манифест, который действительно получает кластер. Применять исключение ко всем приложениям заранее не нужно: сначала определите затронутые нагрузки и протестируйте выбранное поведение.

Что ещё изменилось в конфигурации

Раздел Urgent Upgrade Notes содержит несколько менее заметных изменений. Их удобно пройти отдельным списком до тестового обновления.

• Удалена версия scheduling.k8s.io/v1alpha2. Changelog требует убрать соответствующие объекты до обновления. Если команда использовала экспериментальные API планировщика, ей нужно разобрать эти объекты и способ их замены.
• Значение eventRecordQPS: 0 теперь означает отсутствие ограничения частоты событий. Чтобы сохранить ограничение, задайте ненулевое значение; в release notes приведён пример 50.
• Kubelet выводит эффективную конфигурацию при запуске. Администраторам предлагают проверить доступ к nodes/logs и ограничить его доверенными пользователями.

В первом случае недостаточно найти старую строку версии в репозитории и заменить её во всех файлах. В плане работ должны быть учтены существующие объекты. Во втором случае привычный ноль меняет поведение после обновления. В третьем нужно проверить права на диагностическую информацию.

Для каждого пункта запишите результат применительно к своему кластеру: используется ли настройка, кто за неё отвечает и что требуется изменить. Если экспериментальные API не включались, это тоже полезный результат проверки. Он объясняет, почему соответствующий шаг исключён из вашей процедуры, и позволяет повторить аудит позднее.

Нужно ли одновременно менять containerd и IPVS

Некоторые обзоры требуют перейти на containerd 2.x перед Kubernetes 1.37. В чейнджлоге удаление части настроек kubelet и связанного с ними резервного поведения перенесено с 1.37 на 1.38 для согласования с поддержкой containerd 1.7. Этот перенос не распространяется на перечисленные выше флаги cAdvisor: они уже удалены в 1.37 и мешают запуску kubelet, если остались в аргументах службы. Совместимость установленного runtime и срок его поддержки нужно проверять отдельно.

С IPVS ситуация тоже требует точной формулировки. В 1.37 этот режим kube-proxy продолжает работать. Официальный анонс указывает ожидаемое отключение по умолчанию в 1.40 и удаление в 1.43. Текущий режим можно посмотреть так:

Если видите mode: ipvs, добавьте миграцию в план инфраструктурных работ. Сам этот результат ещё не означает, что обновление на 1.37 нужно остановить.

Проверка cgroup v1 относится к совместимости узлов. Отказ kubelet запускаться с cgroup v1 по умолчанию действует с версии 1.35. В 1.37 сохраняется временное переопределение failCgroupV1: false, однако проект рекомендует переходить на cgroup v2.

Для вашей процедуры из этого следует простой подход: зафиксировать обязательные исправления отдельно от запланированных миграций. Если runtime или сеть тоже требуют изменений, выделите им собственные проверки. Тогда при неудачном тесте будет понятнее, какое именно изменение вызвало новое поведение.

Как подготовить тестовое обновление

Тест должен проверять те зависимости, которые есть в продакшене. В перечень для своего окружения включите сеть, подключение хранилищ, правила допуска запросов и мониторинг. Если приложение использует особые настройки безопасности или обновляется как StatefulSet, эти особенности тоже должны попасть в проверку.

Составьте короткий сценарий для каждого важного приложения: что должно запуститься после переноса, к каким данным оно обращается и как вы подтвердите работоспособность. Результат «Pod появился в списке» слишком узок для решения о доступности сервиса. Проверка должна доходить до операции, ради которой приложение запущено.

Отдельно продумайте поведение при выводе узла из работы. PodDisruptionBudget, или PDB, ограничивает допустимое число недоступных реплик при добровольных прерываниях, которые используют Eviction API. Обычный drain учитывает этот бюджет. При нехватке доступных реплик он может ждать, пока приложение восстановится.

Например, в документации разобран случай с тремя репликами и требованием сохранять две доступными. Одну реплику можно остановить для обслуживания узла: Kubernetes создаст ей замену, а две другие продолжат работать. Остановить следующую получится, когда новая реплика будет готова. Если для её запуска не хватает ресурсов, потребуется вернуть в работу обслуженный узел или добавить новый. Поэтому заранее проверьте, хватит ли на остальных узлах ресурсов для запуска Pods на время обновления.

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

Если для подготовки нужна внешняя команда, на нашем сайте, Centicore Group есть услуги по развёртыванию ИТ-ландшафта, миграции ИТ-инфраструктуры и поддержке облачных сервисов. Перед обращением соберите сведения о текущем окружении и требованиях приложений: с ними будет проще обсудить объём работ.

В каком порядке обновлять кластер

Начните с первого узла control plane. По официальному гайду на нём обновляют kubeadm до выбранной версии 1.37.x, проверяют план и запускают обновление управляющих компонентов. Пакеты берут из репозитория соответствующей минорной версии.

Изучите предложенный план. Затем выполните команду обновления, заменив x конкретным номером патча:

На остальных узлах control plane сначала обновите пакет kubeadm, затем выполните sudo kubeadm upgrade node. Повторять kubeadm upgrade plan на каждом узле не требуется. Обновляйте управляющие узлы последовательно. Отдельно проверьте инструкцию установленного сетевого плагина CNI и выполните необходимые шаги его обновления.

Обновление kubelet и kubectl нужно выполнить и на узлах control plane. Для каждого узла предусмотрены drain, установка пакетов, перезапуск kubelet и uncordon. Учитывайте совместимость версий: если kubelet может обращаться к нескольким API server, все они должны быть обновлены до 1.37 перед переходом этого kubelet на 1.37. После обслуживания управляющих узлов переходите к рабочим узлам.

Перед минорным обновлением kubelet узел нужно освободить от обычных рабочих Pods. Команда drain помечает его недоступным для стандартного планирования и запрашивает выселение нагрузок:

Дождитесь успешного завершения. Если операция ждёт, сначала выясните причину. PDB может ограничивать выселение, а приложению может требоваться время на восстановление. --ignore-daemonsets позволяет продолжить при наличии Pods DaemonSet, но не удаляет их. Drain также не останавливает static Pods, поэтому управляющие компоненты требуют своей процедуры обслуживания.

После обновления управляющих узлов переходите к рабочим узлам под Linux. На каждом рабочем узле обновите пакет kubeadm, выполните kubeadm upgrade node, проведите drain, затем обновите пакеты kubelet и kubectl до выбранной версии. Команда upgrade node подготавливает локальную конфигурацию kubelet; установку нового пакета нужно выполнить отдельно.

После установки пакетов перезапустите службу:

Когда закончите проверки узла, разрешите планирование:

Обновляйте остальные рабочие узлы по очереди. Следите, чтобы на оставшихся узлах хватало ресурсов для работы приложений. В вашей инструкции должны быть записаны конкретные имена узлов и версии пакетов. Все значения в угловых скобках и x в примерах заменяются до запуска.

Что проверить перед следующим узлом

Сначала убедитесь, что kubelet работает и узел вернулся в Ready. Затем проверьте перенесённые приложения по сценарию, подготовленному до обновления. Сравните результат с исходным состоянием: появились ли новые ошибки, подключились ли тома, продолжают ли поступать данные мониторинга.

В отдельную проверку вынесите StatefulSet. В 1.37 функция MaxUnavailableStatefulSet включена по умолчанию. Поле spec.updateStrategy.rollingUpdate.maxUnavailable задаёт, сколько Pods может быть недоступно во время обновления StatefulSet. Значение maxUnavailable по умолчанию равно 1. Проверяйте его вместе с spec.podManagementPolicy: документация описывает одновременное обновление нескольких Pods для политики Parallel и maxUnavailable больше 1. При таком сочетании Pods могут становиться готовыми в разном порядке, что подходит не каждому приложению.

Просмотрите существующие стратегии обновления. Если поле уже было задано в манифесте, проверьте, какое поведение оно даёт при включённой функции. Для приложения, где нужен порядок восстановления экземпляров — отдельно тестируйте ускоренный rollout.

При этом PDB и стратегия StatefulSet регулируют разные операции. PDB учитывается при выселении через Eviction API; собственное rolling-обновление контроллера StatefulSet не ограничивается этим бюджетом. Поэтому нормальный drain и rollout приложения должны быть отдельными пунктами проверки.

Лучше заранее сформулировать условие продолжения обычным предложением: «следующий узел обновляем, когда перенесённые нагрузки восстановились и прошли свои проверки». За ним должны стоять конкретные результаты тестов. Если один Pod всё ещё ждёт том или приложение отвечает с ошибкой, переход к следующему узлу только усложнит поиск причины.

Что делать, если обновление остановилось

Разберите, на каком этапе произошёл сбой: при выполнении kubeadm, запуске kubelet или восстановлении приложения. Сохраните вывод команды и журналы проблемной службы. До выяснения причины оставьте остальные узлы на текущем этапе.

Для kubelet начните с проверки состояния и журнала:

Если проблема в старом аргументе запуска, вернитесь к проверке конфигурации службы. Если kubelet работает, а приложение застряло на подключении тома, продолжайте разбор на уровне Pod и хранения. Так результаты диагностики будут связаны с конкретным этапом обновления.

Официальный гайд допускает повторный запуск kubeadm upgrade, если операция оборвалась и автоматическое восстановление не завершилось. Процедура идемпотентна: повторное выполнение приводит компоненты к заявленному состоянию. Это механизм восстановления незавершённого обновления.

Kubeadm также создаёт каталоги резервных копий в /etc/kubernetes/tmp: kubeadm-backup-etcd-<date>-<time> и kubeadm-backup-manifests-<date>-<time>. Первая копия относится к локальному участнику etcd; при внешнем etcd соответствующий каталог будет пустым. Вторая содержит сохранённые static-манифесты. Используйте их по документированному сценарию для вашей конфигурации.

При обновлении StatefulSet со стратегией RollingUpdate и политикой OrderedReady возможна остановка: Pod с новой конфигурацией не переходит в Ready, и контроллер ждёт его восстановления. Известная проблема проявляется при восстановлении: даже после возврата рабочего шаблона контроллер может продолжать ждать готовности неисправного Pod. После возврата шаблона нужно удалить затронутые Pods с ошибочной конфигурацией, чтобы контроллер пересоздал их. Этот сценарий нужно заранее включить в тест восстановления приложения.

Когда можно переходить в прод

На начало сентября 2026 года последним патчем ветки остаётся 1.37.0. Релиз 1.37.1 запланирован на 15 сентября; дата окончания поддержки ветки указана как 28 октября 2027 года. Перед началом обновления ещё раз проверьте страницу релиза⁠: запланированный патч может ещё не выйти.

Советуем дождаться 1.37.1 или 1.37.2, если нет конкретной причины переходить сразу. Официальная рекомендация Kubernetes — использовать актуальные патчи исходной и целевой минорных версий. Ожидание можно включить в график, продолжая проверку совместимости и подготовку окружения.

Решение о продакшене должно опираться на результаты теста. Команда знает, какие манифесты пришлось исправить, как приложения пережили выселение с узла и где лежат данные для восстановления. После первого обновлённого узла она может объяснить, почему продолжать допустимо.

Если проверка нашла конфликт меток или неподходящую конфигурацию службы, подготовка уже принесла результат: проблема найдена до окна обслуживания. Пофиксите её, повторите затронутый сценарий и внесите исправление в процедуру. Тогда следующее обновление начнётся с накопленных знаний о вашем кластере.

До 1.37 для этого нужен был сторонний компонент либо alpha-гейт. Теперь это часть ядра, и владельцы очередей и batch-обработчиков могут перестать платить за поды, которые часами ждут задач. Экономия заметнее всего там, где под резервирует дорогие ресурсы: выделенные ядра или GPU. Обычным HTTP-сервисам функция не подходит в чистом виде, и авторы предупреждают об этом прямо.

• Beta по умолчанию: feature gate HPAScaleToZero включён и в kube-apiserver, и в kube-controller-manager Kubernetes 1.37.
• minReplicas: 0 работает только с объектной или внешней метрикой (например, длина очереди); HPA только на CPU и памяти API-сервер отклонит.
• Kubernetes Service не буферизует запросы, пока нет готовых подов, поэтому для HTTP нужен отдельный слой буферизации.
• Условие ScaledToZero=True отличает автоматическое уменьшение до нуля от ручной паузы: HPA не разбудит workload, который остановил не он.
• Перед откатом версии или выключением гейта нужно вернуть minReplicas не меньше 1 и поднять всё, что стоит на нуле.

Почему CPU и память для этого не годятся

Обычно HPA масштабирует по загрузке CPU или памяти, а эти метрики приходят из работающих подов. Когда реплик ноль, измерять нечего, и сигнала «пора подниматься» не будет. Объектные и внешние метрики от подов не зависят: длина очереди существует независимо от того, есть ли у неё потребители. Поэтому minReplicas: 0 требует хотя бы одной такой метрики в спецификации, а HPA, где есть только ресурсные метрики, API-сервер отклоняет.

В блоге приводится пример с метрикой Prometheus queue_consumer_lag. Чтобы HPA её увидел, нужен адаптер, который отдаёт значение через External Metrics API, например Prometheus Adapter с правилом в externalRules. Перед созданием HPA авторы советуют проверить, что метрика читается:

Если запрос не возвращает значение, сначала чинится конвейер метрик: HPA не сможет поднять workload с нуля, пока метрика недоступна. В этом случае он выставляет условие ScalingActive=False с причиной вроде FailedGetExternalMetric, и восстановить мощность придётся либо починкой метрики, либо ручным масштабированием.

Как выглядит HPA с нулём реплик

Пример из блога нацелен на Deployment queue-worker, допускает от нуля до десяти реплик и просит по одной реплике на каждые 30 задач в очереди:

Когда очередь пуста, HPA уменьшает Deployment до нуля. Когда приходят задачи, внешняя метрика по-прежнему доступна, контроллер пересчитывает число реплик и поднимает поды в пределах maxReplicas. Остальные правила HPA продолжают действовать: в частности, окно стабилизации при уменьшении по умолчанию пять минут, так что короткий провал длины очереди не снесёт всех воркеров разом. Окно настраивается через spec.behavior.scaleDown.

Есть важная деталь: Deployment нужно запускать хотя бы с одной репликой. Ручная установка нуля реплик всегда означала паузу автоскейлинга, и это поведение сохранено: HPA не разбудит workload, который остановил не он сам.

Как контроллер отличает «ноль» от «паузы»

Ноль реплик двусмыслен: либо HPA сам всё погасил, либо оператор руками остановил сервис. Разрешает это условие статуса ScaledToZero. Когда HPA уменьшает workload с одной и более реплик до нуля, он записывает ScaledToZero=True, и последующие циклы согласования знают, что нулевое состояние принадлежит контроллеру и метрики нужно продолжать читать. После подъёма условие меняется на ScaledToZero=False с причиной NotScaledToZero. Workload на нуле без условия ScaledToZero=True считается поставленным на паузу. Посмотреть условия можно командой kubectl describe hpa queue-worker.

Кому это не подходит и чем грозит откат

Плата за нулевые реплики называется cold start: HPA должен заметить изменение метрики, планировщик разместить под, приложение подняться. Для очереди, которая надёжно хранит задачи, это нормально. Для HTTP это проблема: Service в Kubernetes не буферизует запросы, пока нет готовых подов, поэтому запросы, пришедшие в «ноль», просто не будут обслужены. Запросным нагрузкам нужен отдельный буферизующий слой, и блог его не предлагает, это остаётся на стороне пользователя.

С обновлением тоже есть оговорки. В 1.37 гейт HPAScaleToZero включён по умолчанию в обоих компонентах: API-сервер принимает minReplicas: 0, а controller-manager выполняет масштабирование по условию. При поэтапном обновлении control plane создавать HPA с нулём стоит только после того, как оба компонента обновлены и гейт активен на обоих: controller-manager без гейта воспринимает нулевые реплики как ручную паузу и может оставить workload лежать. Перед выключением гейта или откатом на версию без реализации на условиях нужно перевести затронутые HPA на minReplicas: 1 и выше и поднять до одной реплики всё, что сейчас стоит на нуле.

Что делать и что дальше

1. Проверьте версию кластера: по умолчанию функция включена начиная с 1.37. Что ещё вошло в этот релиз, мы разбирали в новости про потоковое чтение коллекций из etcd: https://tproger.ru/news/kubernetes-1-37-chitaet-bolwie-kollekcii-iz-etcd-potokom-i-ekono
2. Выберите кандидатов: потребители очередей, batch-обработчики, задачи на GPU. HTTP-сервисы без буфера оставьте на minReplicas: 1.
3. Убедитесь, что метрика читается через External Metrics API, до создания HPA с нулём.
4. Стартуйте Deployment с одной репликой и следите за условиями ScaledToZero и ScalingActive в describe hpa.
5. Оцените cold start для своего образа: время подъёма пода плюс инициализация приложения задают задержку первой задачи после простоя.

Путь у функции длинный: первая alpha-реализация появилась ещё в Kubernetes 1.16, версия 1.36 добавила условие ScaledToZero и поведение контроллера, которое отличает автоматику от ручной паузы, а 1.37 включила всё по умолчанию после интеграционных и end-to-end тестов на уменьшение до нуля и подъём по внешней метрике. Дизайн описан в KEP-2021, функцией владеет SIG Autoscaling. Про GA авторы пока не говорят: следующий шаг, по их словам, собрать эксплуатационный опыт с беты; обратную связь ждут в канале #sig-autoscaling в Slack Kubernetes.

Источники: Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (блог Kubernetes, Johannes Würbach), KEP-2021: HPA supports scaling to and from zero pods, Prometheus Adapter: external metrics

Изображение на обложке: Логотип: The Kubernetes Authors

Если вы держите кластер с десятками тысяч подов или крупными объектами и видели пики памяти на kube-apiserver или etcd именно во время чтения коллекций после рестарта, это обновление адресовано вам. Тем, у кого кластер маленький, а etcd остался на 3.6, ничего не изменится: API server сам поймёт, что стриминг недоступен, и продолжит работать по-старому.

• EtcdRangeStream в v1.37 имеет статус beta и включён по умолчанию; для работы нужен etcd 3.7 или новее.
• Раньше страница ограничивалась числом ключей, поэтому страница крупных объектов могла весить сколько угодно; теперь чанки ограничены по байтам.
• Стриминг используется при инициализации watch cache и при list-запросах, которые уходят в etcd напрямую.
• Проверка: метрика etcd_request_duration_seconds_count с operation="listStream" больше нуля.
• Отключение: флаг --feature-gates=EtcdRangeStream=false на kube-apiserver.

Откуда брались пики памяти

Большую часть list- и watch-запросов API server обслуживает из своего кеша в памяти, watch cache. Чтобы этот кеш наполнить, при старте и при каждой реинициализации нужно вычитать полное состояние ресурса из etcd. Для ресурсов с большим числом объектов или с крупными объектами, вроде подов, такое чтение дорогое.

Пагинация там уже была: API server запрашивал у etcd фиксированное число ключей за раз. Проблема в том, что страница, ограниченная числом ключей, ничего не знает о размере объектов. Страница из крупных объектов остаётся очень большой, расход памяти трудно предсказать, а неудачное сочетание размера объектов и параллельных чтений заканчивается OOM. Хуже того, обычный вызов Range в etcd собирает страницу целиком до отправки, а API server держит её в памяти, пока декодирует, так что один и тот же payload одновременно лежит с обеих сторон. Основная нагрузка ложится на etcd, и именно там стриминг помогает сильнее всего.

Что делает RangeStream

В etcd 3.7 появился потоковый вариант того же чтения, RPC RangeStream. Он принимает тот же RangeRequest, что и Range, и возвращает тот же набор результатов, но не собирает ответ целиком, а режет его на чанки и стримит. Размер чанка подстраивается под возвращаемые значения, поэтому коллекция крупных объектов ограничена байтами, а не числом ключей, и память освобождается по ходу потока.

Когда функция включена, API server использует RangeStream везде, где читает из etcd целую коллекцию: при инициализации watch cache и в fallback-путях, когда list-запрос нельзя обслужить из кеша и приходится идти в etcd напрямую. Каждый чанк декодируется по прибытии и освобождается до запроса следующего, так что ни одна из сторон не держит коллекцию целиком.

Требования и совместимость

• Kubernetes v1.37 или новее.
• etcd v3.7 или новее.

RangeStream используется, когда на kube-apiserver включён feature gate EtcdRangeStream (в v1.37 он beta и включён по умолчанию) и etcd не старше 3.7. Поддержку на стороне etcd API server определяет при старте и дополнительно откатывается в рантайме, если вызов вернул Unimplemented. Поэтому API server 1.37 в паре со старым etcd сам продолжит ходить по пагинированному Range, ничего настраивать не нужно. Kubernetes 1.37 вышел 26 августа; etcd 3.7 анонсирован в июле, и RangeStream добавлен туда заранее под эту интеграцию.

Выключить функцию можно флагом:

Как убедиться, что стриминг работает

API server записывает потоковые чтения под отдельной меткой операции в своих etcd-метриках. Ненулевое значение означает, что RangeStream используется:

Если счётчик остаётся нулевым, API server по-прежнему ходит по пагинированному Range, и самая вероятная причина в том, что etcd старше 3.7. На практике это значит, что обновление control plane до 1.37 без обновления etcd эффекта не даст; проверять стоит обе версии.

Кому это нужно, а кому нет

По нашей оценке, выигрыш заметят кластеры, где list-запросы большие: много подов, крупные CRD, частые реинициализации watch cache после рестартов API server или сбоев. В небольших кластерах путь чтения при etcd 3.7 тоже сменится, но эффект, по нашей оценке, будет мал: там пиковый расход и так укладывался в лимиты. Цифр экономии памяти в анонсе нет, так что оценивать эффект придётся по собственным графикам потребления etcd и kube-apiserver до и после включения. Управляемые сервисы Kubernetes у российских облачных провайдеров обновляют версии control plane и etcd по своему графику, поэтому сначала стоит свериться с их release notes.

Подробности дизайна вынесены в KEP-5966, вопросы принимают в канале #sig-etcd в Slack Kubernetes.

Источники: Блог Kubernetes: etcd RangeStream Cuts Memory Use on Large List Reads, KEP-5966: etcd RangeStream, Анонс etcd v3.7

Изображение на обложке: Kubernetes

Как работают Kubernetes Deployments

Начать можно с руководства по Kubernetes Deployments DevOps-инженера Пуру Туладхара. Автор объясняет, как Deployment управляет ReplicaSet и подами, поддерживает нужное количество реплик и выполняет обновления приложения.

В Kubernetes Deployment встроены две стратегии обновления: RollingUpdate (постепенное обновление подов) и Recreate (полная остановка старой версии перед запуском новой). Canary- (канареечная — постепенное открытие новой версии части пользователей) и Blue-Green-выкладку (сине-зелёная — переключение трафика между двумя параллельными версиями) собирают с помощью нескольких Deployment и дополнительного управления трафиком. Для сложной маршрутизации могут потребоваться Ingress-контроллер, API-шлюз или service mesh. Среди практических советов: держать K8s-конфигурации в системе контроля версий и подключать их к CI/CD-конвейеру, для сбора метрик можно использовать Prometheus, а для их визуализации — Grafana. Набор доступных показателей зависит от источников данных и настроенных экспортёров.

Более компактный формат у подборки Kubernetes 101 под лицензией Apache 2.0. У репозитория около полутора тысяч звёзд на GitHub, а материал разбит на четыре блока: базовые советы по Dockerfile, инфраструктура (безопасность, сети, нагрузки), ключевые концепции Kubernetes с той же канареечной и сине-зелёной выкладкой и короткий финальный раздел про деплой и ревью.

Развернуть кластер без лишних компонентов

Пошаговая инструкция по запуску K8s-кластера ориентирована на минимальный набор компонентов на виртуальных машинах с Debian 11. Прежде чем переходить к развёртыванию самого кластера, автор отключает swap, загружает модули ядра overlay и br_netfilter, а затем устанавливает kubelet, kubeadm, kubectl и CRI-O. В современных версиях Kubernetes swap можно оставить включённым при соответствующей настройке kubelet, хотя по умолчанию он по-прежнему не запускается на Linux-узле с активным swap.

После этого автор выбирает CIDR для сети подов, подключает первый рабочий узел и настраивает доступ к API кластера через kubectl. В отдельном репозитории лежат конфигурации Terraform для развёртки виртуальных машин под лицензией GPL 3.0, которые можно взять как основу и адаптировать под свою инфраструктуру.

Уточнение: материал опубликован в мае 2023 года, поэтому его стоит использовать для знакомства с устройством кластера, а команды перед запуском проверять с актуальной документацией Kubernetes и CRI-O.

Официальные рекомендации

Компактный гайд от GitLab показывает связку GitLab Agent, CI/CD и FluxCD. В примере конвейер упаковывает Kubernetes-манифесты в OCI-артефакт и помещает его в GitLab Container Registry, после чего FluxCD получает и применяет артефакт в кластере. Одной из практик оттуда является использование OCI-репозитория как кеширующего слоя между Git и FluxCD: конвейер GitLab упаковывает манифесты в OCI-артефакт и отправляет его в реестр. FluxCD следит за указанным OCIRepository, получает новую версию артефакта и применяет содержащиеся в нём манифесты.

Некоторые разделы доступны только в платных редакциях GitLab. Остальная часть руководства показывает общую схему GitOps: конвейер упаковывает манифесты в OCI-артефакт, а Flux получает его из OCI-репозитория и применяет в кластере. Источником истины при этом остаётся Git, а OCI-репозиторий работает лишь промежуточным слоем доставки.

Свой блок практик есть и у самой команды Kubernetes. В нём собраны и базовые пункты вроде «указывайте стабильные версии API», и более прикладные советы по сервисам, меткам и работе с kubectl. Разработчики рекомендуют избегать подов без привязки к ReplicaSet или Deployment и не задавать hostPort напрямую.

Как устроен Kubernetes у нас в Linx Cloud

Кластеры работают в режиме Multi Master: etcd работает в кластерном режиме на выделенных SSD-дисках, поэтому отказ одного мастера не останавливает работу остальных. Хранение данных построено на нескольких storage-классах: SSD Ceph, HDD Ceph, геораспределённый Ceph между дата-центрами, а также блочные диски по iSCSI и файловое хранилище с NFS-протоколом для legacy-приложений. Кластер масштабируется автоматически через Cluster Autoscaler: узлы добавляются и удаляются по нагрузке. Создать и удалить кластер можно через панель управления, API или собственный Terraform-провайдер.

Более свежая часть платформы — Kubernetes as a Service на базе Deckhouse Kubernetes Platform: встроенный мониторинг, управление сертификатами и безопасность из коробки, без ручной настройки инфраструктуры. Конкретный состав компонентов и версии для обеих линеек стоит уточнять у технической команды Linx Cloud перед внедрением. Документация по Kubernetes у крупного облачного провайдера обновляется часто, и часть деталей может не совпадать с формальной датой последней правки страницы.

Open Source-инструменты для Kubernetes

Glasskube был менеджером K8s-пакетов, вдохновлённым Homebrew, npm и apt: каждое обновление проходило проверку на наборе тестов, а в каталоге были доступны Ingress-NGINX, Kube Prometheus Stack, cert-manager и другие распространённые компоненты Kubernetes. В 2024 году проект вошёл в CNCF Landscape. Но 17 июня 2026 года репозиторий заархивирован владельцем и переведён в режим read-only — для нового проекта Glasskube уже не стоит рассматривать как активное решение, хотя документация (архитектура, установка на разные ОС, шаблон для ArgoCD) остаётся доступной, если инструмент уже внедрён.

K0rdent запустила Mirantis в начале 2025 года как инструментарий для проектирования распределённых сред управления контейнерами (DCME). 0rdent разворачивают как управляющую платформу. Через Cluster API он создаёт и обновляет дочерние кластеры в облачной, локальной или гибридной инфраструктуре. Набор доступных провайдеров и дополнительных сервисов зависит от версии и конфигурации. В мае 2026 года кластеры, развёрнутые и управляемые через k0rdent, прошли проверку CNCF Kubernetes v1.35 на соответствие требованиям conformance и получили статус Certified Kubernetes; сам k0rdent при этом включён в CNCF Landscape как management-платформа для сертифицированных дистрибутивов. В документации есть быстрый старт, настройка управляющего кластера и примеры конфигураций.

DeployKF разработчики описывают как платформу, которая берёт лучшее из Kubeflow, Airflow и MLflow, чтобы дать любому пользователю Kubernetes возможность строить ML-платформу без экспертизы в MLOps. На практике готова пока только экосистема Kubeflow: интеграцию с Airflow и MLflow сами разработчики помечают как «coming soon» в своей документации. Сейчас работают централизованная система конфигураций и интеграция с Istio, cert-manager, Kyverno, S3 и MySQL, хотя раздел про Kyverno в документации тоже пока не завершён.

Managed Kubernetes как сервис от Linx Cloud

Управлять кластером самостоятельно необязательно: у нас есть платформа для развёртки, масштабирования и мониторинга контейнерных приложений на основе Deckhouse Kubernetes Platform. По сравнению с «ванильной» конфигурацией она добавляет метрики и дашборды для мониторинга, готовые компоненты аутентификации и авторизации, преднастроенные Flannel или Cilium для сети.

Подробный разбор возможностей и интерфейса сервиса есть в статье на Хабре, со скриншотами или на сайте Linx Cloud. Сервис можно протестировать напрямую и задать нам вопросы по использованию.

Если у вас нет времени смотреть все записи докладов целиком, держите главное.

Пределы стандартной сети Kubernetes

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

Андрей Половов в своём докладе разобрал технические пределы классических CNI-плагинов. В Deckhouse отказались создавать Франкенштейна из готовых CNI- и SDN-решений, чтобы получить нативную для Kubernetes сетевую подсистему, в результате команда выкатила собственную программно-определяемую сеть.

В инструменте уже есть поддержка дополнительных сетей на классических VLAN, решён вопрос с адрес-менеджментом и dedicated NIC c поддержкой SR-IOV. В работе — дополнительные сети на XVLAN, DHCP для виртуалок, NetworkPolicy для дополнительных сетей, BGP и ALB-AAA.

Виртуалки как first-class citizens в Kubernetes

Тема с виртуалками в Kubernetes давно висит в воздухе. Компании идут в микросервисы и контейнеризацию, но в проде у многих до сих пор крутятся монолитные системы и легаси-приложения. Их реально проще держать в ВМ, чем быстро переписывать к следующему кварталу. На конференции этот вопрос разобрали в докладе Павла Тишкова через практику использования виртуализации внутри Kubernetes. Разговор шел именно про надежность и привычную управляемость виртуальных машин под управлением оркестратора.

Проблема соседства ВМ и контейнеров

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

Инженерам нужен способ держать все нагрузки в общем контуре и перестать плодить «зоопарк» из платформ, консолей и ручных регламентов. В докладе Павел разобрал практику запуска и управления виртуальными машинами наравне с контейнерамии внутри K8s.

Что меняется для инфраструктурной команды

Когда виртуалка становится штатным объектом внутри оркестратора, команда получает привычный operational flow. Ресурсы, политики, сеть и автоматизация начинают жить в одном контексте. Они больше не разъезжаются по разным панелям управления, где каждая вкладка требует отдельного ритуала. Вывод капитанский, но полезный: чем меньше ручной магии вокруг инфраструктуры, тем реже ночной дежурный вспоминает создателей этого стека.

Разработчики и DevOps получают возможность держать рядом сервис в контейнере и зависимый компонент в ВМ (которая тоже в контейнере). Изменения можно катать через знакомые процессы и постепенно разгребать наследство без миграции ради миграции. Deckhouse развивает виртуализацию без отрыва от Kubernetes и рассматривает виртуальные машины как часть общего рантайма для гибридных нагрузок.

Что стоит вынести из доклада

Виртуалки никуда не делись. Теперь их просто встраивают в современный платформенный слой, где уже прижились контейнеры, GitOps и декларативное управление. Такой подход спасает команды, желающие унифицировать эксплуатацию и убрать лишние переходы между разными контурами администрирования. Если у вас в инфраструктуре до сих пор живут монолиты, которые нельзя быстро распилить на микросервисы, эту тему точно можно посмотреть.

Самописный сontrol plane для SDS

Работа с Software-Defined Storage в Kubernetes часто оборачивается попытками подружить облачно-ориентированные технологии с инструментами старой школы. Александр Зимин разобрал типичный сценарий такого столкновения на примере LINSTOR. Разработчики Deckhouse изначально взяли этот инструмент на роль control plane, понимая его архитектурные ограничения. Они согласились на внешнюю базу данных и push-модель управления конфигурациями.

Со временем эти компромиссы дали о себе знать. Экспериментальный режим работы с etcd регулярно приводил к зависанию реплик при штатных обновлениях. Добавим к этому, что инженеры постоянно ловили баги во время изменения размеров томов и при эвакуации узлов.

Большой болью оказался и технологический стек. Подсистему хранения данных в Deckhouse пишет Go-команда, которой приходилось тратить спринты на дебаг и патчинг чужого Java-кода. Поддерживать и дальше такой воркфлоу было абсолютно невыгодно. Поэтому, набравшись опыта с LINSTOR, инженеры просто отказались от готового решения и написали собственный control plane под программно-определяемого хранилища.

Спикер показал понятный рубикон для платформенной разработки. Полезно видеть чужой опыт и понимать, когда пора перестать адаптировать готовый open-source продукт под свои задачи и сесть за написание кастомного решения.

Реальная цена защиты кластера

При переходе в Kubernetes инженеры закладывают мощности под бизнес-логику, но не всегда учитывают ресурсы для средств защиты кластеров. Никита Ладошкин из Positive Technologies показал «налоги» на информационную безопасность, которые стоит держать в уме, если вы хотите получить больше защищенности, чем в «ванильном» Kubernetes.

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

Защита самой платформы

Разумеется, информационная безопасность в контексте Kubernetes не ограничивается одним контролем уже запущенных нагрузок. Сама платформа для их развёртывания тоже должна быть защищена от разных векторов атак. В Deckhouse используют подходSecure by Design. Разработчики внедрили контроль целостности — обязательную цифровую подпись всех контейнерных образов платформы и её системных компонентов. Такой механизм исключает подмену на этапе доставки, иезаметная подмена кода полностью исключается.

Контроль всех ИБ-компонентов кластера в Dechouse Kubernetes Platform вынесли в специализированный интерфейс для централизованного контроля. А компаниям, которые подпадают под требования регуляторов пригодится сертифицированная ФСТЭК России редакция платформы.

Архитектура в пайплайнах вместо ревью

Когда код пушат десятки команд, техлиды физически не могут отсматривать каждый коммит. Архитектурное ревью быстро превращается в бутылочное горлышко, где релизы висят в ожидании согласования. Антон Исанин из «АльфаСтрахования» показал, как выпилить этот ручной труд с помощью Deckhouse Development Platform.

Ребята зашили стандарты разработки прямо в CI/CD. Теперь пайплайн сам разворачивает валидную среду и бьет по рукам, если сервис не проходит по инфраструктурным требованиям. Разработчики просто получают готовую песочницу и сразу пишут бизнес-логику. Сеньорам при этом больше не нужно тратить время на проверку базового бойлерплейта и объяснение правил при онбординге новых людей.

Что выкатил сам Deckhouse: веб-интерфейс, мониторинг, управление GPU и

В главном докладе Александр Титов и Давид Мэгтон показали ключевые апдейты Deckhouse Kubernetes Platform, а детали реализации и новости других продуктов команда раскрыла на профильных питчах.

Платформа для запуска софта должна быть простой в эксплуатации, несмотря её на сложность «под капотом». Для этого инженеры Deckhouse существенно прокачали графический интерфейс: теперь в нём доступны 100% возможностей CLI и API платформы, а ещё появилась удобная мультитенантность. Графический инсталлятор же теперь умеет ставить DKP в 9 видов инфраструктур.

С наблюдаемостью знакомая история: при росте количества метрик сборщики телеметрии начинают неадекватно потреблять оперативную память. Команда Deckhouse выкатила для решения этой задачи свою систему мониторинга Prom++. Она оптимизирует хранение данных и экономит RAM на серверах. API полностью совместим с Prometheus, поэтому переписывать привычные дашборды и алерты не придется.

Как уже было понятно из доклада про виртуализацию, DKP умеет запускать виртуальные машины наравне с контейнерами. За год с прошлой конференции здесь добавилось много новых фич, например, живая миграция и клонирование ВМ, гибкое управление USB и продвинутый мониторинг.

Под ML-задачи завезли нативное управление видеокартами. Платформа теперь умеет динамически нарезать одну физическую GPU на изолированные ресурсы для разных задач.

Представили и линейку управляемых сервисов. Сейчас в платформе уже доступны семь сервисов, которые закрывают основные сценарии работы с данными: PostgreSQL, Kafka, Cassandra, Valkey, Memcached, Hive Metastore и Trino.

Что еще стоит посмотреть в записи

Из остального расписания советуем глянуть кейс Владимира Анисимова и Антона Белоусова про партизанский кластер DKP CE. Материал пригодится инженерам, которым нужно собрать proof of concept для закрытого контура. Спикеры показали процесс развертывания платформы на обычном пользовательском железе практически без доступа в интернет. Этот опыт пригодится, если нужно обкатать гипотезу до выделения бюджетов на энтерпрайз-лицензии и серверные стойки.

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

Записей докладов хватит для понимания, куда сейчас движется инфраструктурная разработка. Собирать окружение на кастомных баш-скриптах становится слишком дорого. Готовая платформа избавляет команду от необходимости связывать разные инструменты руками, и к этому формату работы пора привыкать.

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

Я перешёл в Android-инфраструктуру — начал делать инструменты для других мобильных разработчиков. Это помогло увидеть: главные проблемы не в фичах, а в слое между приложением и бэкендом.

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

Когда я проектировал gateway, я точно знал, что почувствуют мобильные разработчики, если ошибусь. Добавить ещё один сетевой вызов — это будет не бесплатно. Оставить логику в приложении — значит отдать её на устройство, которое я не контролирую.

Чего именно не хватало? Я неплохо понимал мобильную сторону, но совершенно не ориентировался в распределенных системах. Знал, например, что такое таймаут, но не представлял, как выставить его в цепочке из пяти сервисов так, чтобы одно медленное звено не обрушило весь экран пользователя. Понимал, что сети падают, но не умел проектировать систему, способную оставаться на плаву в таких условиях.

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

Пришлось учиться думать в терминах деградации, частичных отказов, плавного падения.

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

Формального плана у меня не было — учился на практике. Это лучший, хотя и самый стрессовый способ. Пробелы выявляла практика. Столкнулся с нерешаемой задачей — понял, чего не знаю. Пошёл разбираться.

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

По срокам: техническая база уложилась в несколько месяцев. Паттерны осваиваются быстрее, чем кажется, особенно если сразу применять их к живой задаче. Гораздо дольше происходила смена образа мышления. Перейти от вопроса «работает ли фича?» к вопросу «что случится, когда это упадёт в три часа ночи?» — вот что заняло основное время.

Что означает «выдающийся уровень» в инфраструктуре

Когда говорят «спроектировать gateway с нуля и перевести на него живую платформу», за этими словами стоит не один навык, а целых три, и каждый требует совершенно разной подготовки.

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

Наконец, владение надёжностью. Gateway — единая точка отказа: упал он, упало всё. Годы уходят на то, чтобы сделать его скучным и предсказуемым: резервирование, автомасштабирование, circuit breakers, режимы деградации, еженедельный пересмотр мощностей. Высший пилотаж — когда о системе просто не думаешь, потому что она работает.

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

Когда перед тобой лежит жёсткий список формальных требований, люди часто отсеивают себя сами, даже не попробовав. А в инфраструктуре по-настоящему важно только одно: можешь ли ты решать задачи. Я пришёл сюда без профильного диплома и учился ровно тому, что требовалось в моменте, потому что задачи сами подталкивали к этому.

Индустрия, к слову, до сих пор не слишком хорошо умеет проверять те навыки, которые на этом уровне оказываются решающими: умение видеть ограничения на стыке систем, предвидеть сценарии отказов, двигать людей к соглашению. Всему этому учатся не до начала работы, а непосредственно в процессе.

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

Лучшая инфраструктура для мобильных продуктов строится теми, кто сам их создавал и знает все узкие места не понаслышке. Этот опыт даёт верное направление: ты чувствуешь, где настоящие проблемы, потому что сталкивался с ними лично. Такому не учат по книгам.

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

Но при этом к такому коду часто боятся прикасаться. И не без причины. В старых системах редко бывает понятная карта зависимостей. Документация устарела, часть знаний живет только в головах нескольких разработчиков, а бизнес при этом продолжает ждать новых релизов, интеграций и продуктовых экспериментов.

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

Хорошая новость в том, что модернизация legacy-кода не обязана быть большим взрывом. Старую систему можно менять постепенно, сохраняя рабочий продукт, не замораживая фичи и не устраивая один критический релиз, от которого зависит всё.

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

На старте такой план часто звучит логично. Особенно если текущая система действительно мешает развитию. Например, мобильное приложение растет, у него уже миллионы пользователей, бэкенд написан несколько лет назад как монолит, а каждая новая фича требует изменений в десятке мест. Команда устала чинить регрессии, бизнес устал ждать, и всем хочется «один раз нормально переписать».

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

Во-первых, переписывание шло параллельно с продуктовой разработкой. За время миграции бизнес добавил два новых типа документов и изменил правила подписи актов. Новая система проектировалась под старые требования и к моменту готовности уже не соответствовала продукту.

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

Название пришло из биологии. Фикус-душитель растет вокруг дерева-хозяина и постепенно вытесняет его. В архитектуре принцип похожий: старая система продолжает работать, новая функциональность появляется рядом, а затем отдельные потоки постепенно переводятся на новую реализацию.

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

Сначала команда описывает текущий контракт: какие события приходят в модуль уведомлений, какие каналы используются, какие шаблоны отправляются, какие ошибки считаются допустимыми. Затем рядом создается новый сервис уведомлений, который реализует тот же контракт. На первом этапе он может даже не отправлять реальные сообщения, а только принимать события и логировать результат. После проверки часть трафика переводится на новую реализацию. Когда сервис стабилизируется, старый код уведомлений удаляется из монолита.

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

Это опасный путь. В legacy-системах странное поведение часто существует не случайно. За ним может стоять неочевидное бизнес-правило, старый клиент, интеграция с внешней системой или исторический баг, на который уже кто-то завязался.

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

Допустим, в банковском приложении есть старый модуль истории операций. Он медленный, сложно расширяется, но при этом не выполняет сами транзакции. Это хороший кандидат для первой миграции. Ошибка в истории операций неприятна, но обычно менее критична, чем ошибка в списании денег.

Команда может вынести чтение истории в отдельный сервис, сначала запустить его в shadow-режиме, потом включить для части пользователей, затем полностью перевести чтение на новую реализацию. При этом критичная транзакционная логика останется в старой системе до тех пор, пока команда не наберет опыт безопасной миграции.

Миграция данных: самая сложная часть

Большая часть статьи говорит о маршрутизации запросов и переключении трафика. Но в реальных проектах основная сложность лежит ниже — в данных. Старая и новая реализации почти всегда работают с общим состоянием: одной БД, одним хранилищем документов, одним набором очередей. Переехать туда «одним коммитом» нельзя.

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

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

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

После этого рядом пишется новая реализация. Она должна повторять текущее поведение, а не сразу становиться «идеальной версией будущего». На этом этапе полезно фиксировать все расхождения: где старая система работает странно, где требования не описаны, где бизнес-правила требуют уточнения.

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

Обратимые с компенсацией. Новая реализация пишет дополнительные данные (например, дублирует операции в новую таблицу), но старый источник тоже обновляется. Откат возможен, но требует решить, что делать с уже записанными данными: оставить, очистить, синхронизировать. План этих действий должен быть написан до выкатки, не во время инцидента.

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

Третья ошибка — отсутствие наблюдаемости. Без логов, метрик и трассировки команда не управляет миграцией, а угадывает. Особенно опасно смотреть только на технические ошибки и игнорировать бизнес-показатели.

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

Если продуктом ежедневно пользуются сотни тысяч или миллионы людей, нельзя позволить себе «переписать и посмотреть, что будет». Нужно менять архитектуру так, чтобы пользователь не замечал процесса миграции.

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

Когда модернизацию лучше не делать

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

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Написать оператор можно на Go с помощью operator-sdk: сгенерировать скелет проекта, определить CRD, реализовать Reconcile и задеплоить в кластер. В этой статье разберём паттерн Operator и соберём рабочий оператор, который создаёт Deployment и Service по декларативной спецификации, отслеживает дрейф конфигурации и мгновенно откатывает несанкционированные изменения.

Оператор Kubernetes — это пользовательский контроллер, который расширяет API кластера собственными ресурсами (CRD) и непрерывно приводит фактическое состояние к желаемому.

Шаблон Reconcile — Observe → Create → Correct → Report — лежит в основе любого оператора: контроллер наблюдает, создаёт недостающее, исправляет отклонения и сообщает статус.

С помощью operator-sdk и kubebuilder-меток можно сгенерировать скелет проекта, CRD и RBAC-манифесты, не писать boilerplate вручную.

Owner Reference связывает дочерние ресурсы с родительским кастомным ресурсом (CR): при удалении WebApp Kubernetes автоматически уберёт связанные Deployment и Service.

Обновление статуса через Status().Update() изолировано от основного ресурса и предотвращает бесконечные циклы реконсиляции.

Почему стандартных примитивов Kubernetes не хватает

Kubernetes предоставляет мощный набор базовых абстракций: Pod, Deployment, StatefulSet, Service, Ingress. Они отлично справляются с запуском контейнеров, балансировкой трафика и базовым масштабированием. Однако эти примитивы агностичны к бизнес-логике приложения.

Представьте, что вам нужно развернуть production-grade кластер PostgreSQL. Помимо самих подов с базой, потребуются: инициализация репликации, управление резервными копиями, обновление версий без простоя, автоматическое переключение при отказе мастера. Всё это — операционная экспертиза, которую DevOps-инженеры накапливают годами. Оператор превращает эту экспертизу в автоматизированный контроллер, который круглосуточно следит за ресурсом и принимает решения.

Сегодня операторы де-факто стали стандартом для управления сложными stateful-приложениями в Kubernetes: от баз данных и брокеров сообщений до сервисных mesh и CI/CD-систем. Концепция была сформулирована инженерами CoreOS ещё в 2016 году, а сейчас поддерживается Cloud Native Computing Foundation (CNCF) как ключевой паттерн платформенной инженерии.

Архитектура оператора: CRD, Reconciler и control loop

Любой оператор состоит из двух ключевых компонентов:

• Custom Resource Definition (CRD) — расширение API Kubernetes, которое определяет новый тип ресурса со своей схемой Spec (желаемое состояние) и Status (фактическое состояние).
• Контроллер (Reconciler) — программный цикл, который постоянно сравнивает Spec и Status, а затем выполняет действия для их сближения.

Контроллер не работает по принципу «выполнил шаги и вышел». Вместо этого он реализует control loop: каждую итерацию можно запускать снова и снова — результат не сломается, потому что код сравнивает «что есть» с «что нужно» и корректирует только расхождения. Это критически важно, потому что события в распределённой системе приходят асинхронно, а состояние объекта могло измениться за время обработки предыдущего события.

Создаём проект с operator-sdk

Вручную писать весь boilerplate контроллера — неэффективно. Инструмент operator-sdk (основанный на Kubebuilder) генерирует стандартную структуру проекта Go, включая точку входа main.go, Makefile с целями для сборки и тестирования, а также инфраструктуру для управления CRD.

Инициализируем проект и создаём API с контроллером:

Флаг --resource сгенерирует Go-структуры, описывающие схему пользовательского ресурса. Флаг --controller создаст шаблон reconciler'а — файла, в котором мы будем писать логику управления.

Определяем схему CRD

Откроем api/v1/webapp_types.go. Здесь мы описываем два структурных блока: WebAppSpec — то, что задаёт пользователь в YAML-манифесте, и WebAppStatus — то, что оператор сообщает о текущем состоянии.

Важнейшая часть — kubebuilder-маркеры над основной структурой:

Маркер +kubebuilder:subresource:status сообщает Kubernetes, что для этого ресурса нужен отдельный endpoint /status. Без него любое обновление статуса будет восприниматься API-сервером как изменение всего объекта, что вызовет каскадную реконсиляцию и может привести к бесконечному циклу.

Маркеры +kubebuilder:printcolumn настраивают вывод команды kubectl get webapps: вместо голого имени ресурса пользователь увидит фазу, желаемое и доступное количество реплик.

Reconciler: сердце оператора

Файл internal/controller/webapp_controller.go содержит функцию Reconcile — точку входа в control loop. Перед ней размещаются RBAC-маркеры, которые генерируют манифесты прав доступа при выполнении make manifests:

Без этих маркеров оператор не получит прав на чтение и запись стандартных ресурсов Deployment и Service, и при запуске в кластере упадёт с ошибкой доступа. Разберём функцию Reconcile по шагам.

Шаг 1. Получение актуального состояния

Reconciler получает не сам объект, а лишь его имя и пространство имён. Это архитектурное решение Kubernetes: между постановкой события в очередь и его обработкой объект мог измениться. Поэтому первое действие — всегда запросить свежую версию ресурса из API.

Здесь apierrors импортируется из пакета k8s.io/apimachinery/pkg/api/errors, а ctrl — из sigs.k8s.io/controller-runtime.

Шаг 2. Реконсиляция Deployment

Сначала проверяем, существует ли связанный Deployment. Если нет — создаём его через вспомогательную функцию deploymentForWebApp.

Вызов return ctrl.Result{Requeue: true}, nil ставит событие обратно в очередь: контроллер немедленно перезапустит Reconcile для того же объекта, чтобы продолжить с следующего шага. Это удобнее, чем ждать следующего внешнего события.

Вот как выглядит функция deploymentForWebApp:

Owner Reference — это механизм garbage collection в Kubernetes. Когда пользователь удаляет ресурс WebApp, кластер автоматически удалит все дочерние объекты, на которые ссылается поле ownerReferences. Без этой связи после удаления кастомного ресурса в кластере останутся «зомби»-поды и сервисы.

Шаг 3. Обнаружение дрейфа конфигурации

Если Deployment уже существует, мы не просто идём дальше — сравниваем желаемое и фактическое состояние. Это и есть то, что отличает оператор от одноразового скрипта.

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

Шаг 4. Реконсиляция Service

С вычислительным слоем разобрались — теперь нужен сетевой доступ. Логика полностью идентична: проверяем наличие Service, создаём при отсутствии, устанавливаем Owner Reference. Для локального тестирования в Minikube используем тип NodePort.

Вспомогательная функция serviceForWebApp строит объект Service с нужными селекторами и портами:

Шаг 5. Обновление статуса

Последний шаг — сообщить пользователю текущее состояние приложения через status subresource. Здесь критически важно использовать именно r.Status().Update(), а не r.Update().

Разделение основного endpoint ресурса и subresource /status — фундаментальное свойство Kubernetes. Оно гарантирует, что обновление статуса не триггерит новое событие изменения ресурса и, соответственно, не запускает бесконечную реконсиляцию.

Тестирование: как проверить, что оператор работает

Для локального тестирования подойдёт Minikube. Запускаем оператор в одном терминале, а в другом — создаём кастомный ресурс.

Проверяем, что оператор создал инфраструктуру и отчитался о статусе:

Демонстрация: откат несанкционированных изменений

Главная ценность оператора — самовосстановление. Сымитируем вмешательство: масштабируем Deployment в обход кастомного ресурса.

Мгновенно в логах контроллера появляется сообщение:

Лог оператора:
INFO Drift detected! Updating Deployment {"DesiredReplicas": 3, "ActualReplicas": 10}

А через несколько секунд избыточные поды начинают завершаться:

В это время статус WebApp отражает промежуточное состояние Scaling, а после полного схождения — автоматически переключается обратно на Running.

Когда операторы необходимы, а когда избыточны

Не каждому приложению нужен собственный оператор. Для stateless-сервисов, которые достаточно описать парой манифестов Deployment + Service, оператор будет накладным расходом. Однако есть категории систем, где без оператора не обойтись:

• Базы данных — PostgreSQL, MySQL, MongoDB, etcd: репликация, бэкапы, обновления, failover.
• Брокеры сообщений — Kafka, RabbitMQ, NATS: управление партициями, топиками, кластерной топологией.
• Сетевые компоненты — Ingress-контроллеры, service mesh: динамическая маршрутизация и политики безопасности.
• CI/CD и GitOps — Tekton, Argo CD: оркестрация пайплайнов и синхронизация состояния кластера с репозиторием.

В российской инфраструктурной практике операторы активно используются в Managed Kubernetes от крупных облачных провайдеров. Например, в Яндекс Облаке операторы лежат в основе managed-сервисов баз данных, обеспечивая автоматизацию резервного копирования, мониторинга и масштабирования.

Выводы

Паттерн Operator — это не просто модное слово в экосистеме Kubernetes, а проверенный подход к автоматизации эксплуатации сложных приложений. Вместо того чтобы полагаться на runbook'и и ручные действия инженеров, оператор кодирует операционную экспертизу в программу, которая работает круглосуточно, не устаёт и не забывает проверить важный шаг.

В этой статье мы прошли полный путь: от генерации скелета проекта через operator-sdk до работающего контроллера, который создаёт инфраструктуру, отслеживает дрейф конфигурации и автоматически восстанавливает желаемое состояние. Ключевые навыки — понимание асинхронной природы control loop, правильное использование Owner Reference и изолированное обновление статуса — применимы далеко за рамками Kubernetes.

Оператор — это не магия, а дисциплина. Каждая итерация Reconcile — это честный вопрос: «Что должно быть?» против «Что есть сейчас?». Ответить на него правильно — значит построить надёжную систему.

Полный код проекта доступен в репозитории автора оригинального туториала: SandeshOjha06/k8-operator. Если вы планируете развиваться в направлении platform engineering или SRE, умение писать и отлаживать собственные контроллеры станет серьёзным конкурентным преимуществом.

Источники:

• Building a Kubernetes Operator from Scratch with Operator SDK — оригинальный туториал Сандеша Оджха.
• Kubernetes Operators — официальная документация Kubernetes.
• Operator SDK — фреймворк для разработки операторов.
• The Kubebuilder Book — руководство по построению Kubernetes API и контроллеров.

Технически связать их реально за один спринт. Платформа 1С умеет отдавать данные через REST API по протоколу OData ещё с восьмёрки — достаточно опубликовать базу на веб-сервере. Kubernetes отдаёт метрики через Prometheus. Grafana умеет читать оба источника одновременно.

В статье, как это сделать на практике: какие данные вообще стоит тащить из 1С в общий дашборд, где обычно ломается интеграция и как не превратить это всё в очередную ФИЧУ, которая падает каждый раз после обновления конфигурации.

Что умеет 1С в плане интеграции

Забудьте о том, что 1С — это закрытая коробка, к которой можно обращаться только через COM-соединение или выгрузки текстовых файлов на FTP. Современная 1С — это нормальный HTTP-бэкенд, если правильно включить тумблеры.

REST API и OData из коробки

Вам не нужно писать ни строчки кода на 1С, чтобы вытащить из неё метрики. Платформа умеет автоматически генерировать REST-интерфейс для всех объектов конфигурации сразу после публикации базы на веб-сервере (обычно это Apache или IIS).

Под капотом работает открытый протокол OData 3.0. 1С честно принимает HTTP-запросы и отдаёт чистый JSON. Хотите посмотреть количество открытых заказов? Стучитесь GET-запросом к документу. Нужны остатки на складе? Спрашиваете виртуальную таблицу регистра накопления.

Пример запроса на получение последних 10 документов продаж из опубликованной базы:

КОД

OData поддерживает фильтрацию прямо в URL. Если вам нужны только заказы за конкретный период или больше определённой суммы, вы передаёте это в параметре $filter, и 1С сама собирает нужную выборку на стороне базы данных.

HTTP-сервисы внутри конфигурации

OData отдаёт данные «как есть», повторяя структуру таблиц 1С. Иногда это слишком тяжеловесно. Например, если для дашборда вам нужна одна цифра «Сумма продаж за час», через OData придётся вытягивать массив заказов и суммировать их на стороне Kubernetes.

Для таких случаев в 1С есть HTTP-сервисы. Это кастомные эндпоинты, которые 1С-разработчик пишет прямо в конфигураторе. Вы договариваетесь с ним о контракте, он пишет код, который внутри 1С сам считает нужные метрики и отдаёт наружу лёгкий JSON в нужном вам формате.

Плюс: идеальная подгонка под архитектуру, меньше трафика, работает быстро. Минус: каждый такой эндпоинт придётся поддерживать и тестировать при обновлениях основной конфигурации.

Файловый обмен как запасной вариант

Случаются ситуации, когда безопасники отказываются открывать HTTP-порты сервера 1С наружу, или база крутится в закрытом контуре.

Здесь работает старый добрый асинхронный обмен. В 1С настраивается регламентное задание, которое собирает нужные метрики и складывает их в JSON-файл в общую сетевую папку или S3-хранилище. Exporter на стороне K8s просто читает этот файл по расписанию.

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

Как устроен стек на стороне Kubernetes

Здесь есть чёткое разделение ролей: одни сервисы отдают метрики, другие их собирают, третьи рисуют графики.

Prometheus собирает, Grafana показывает

Стандартный стек наблюдаемости (observability) в Kubernetes состоит из двух главных компонентов.

• Prometheus — это база данных временны́х рядов. Он работает по pull-модели: у него есть список эндпоинтов, он ходит по ним с заданной частотой (например, каждые 15 секунд), забирает текущие значения метрик и складывает к себе в хранилище.

• Grafana — она ничего не хранит и ничего не собирает. Она отправляет PromQL-запросы в Prometheus, получает массивы чисел и отрисовывает их в панели.

Чтобы 1С появилась в Grafana, нам нужно научить Prometheus её опрашивать. Но Prometheus ждёт метрики в своём специфическом текстовом формате (вида orders_count{status="new"} 42), а 1С отдаёт JSON через OData. Нужен переходник.

Prometheus Exporter как мост к 1С

Этот переходник называется exporter. Технически это микросервис, который принимает запрос от Prometheus, идёт в 1С, парсит JSON-ответ и выдаёт его в нужном формате.

Пишется он элементарно. Вот рабочий пример на Python с использованием официальной библиотеки prometheus_client:

КОД

Вы упаковываете этот скрипт в Docker-образ, деплоите в Kubernetes как обычный под (Deployment) и вешаете на него Service. После этого добавляете в конфиг Prometheus новую job'у для скрейпинга вашего экспортера. Готово — метрики 1С лежат в Prometheus рядом с метриками CPU ваших подов.

Loki для логов рядом с метриками

Цифры (метрики) — это половина картины. Иногда для разбора инцидента нужны тексты ошибок: почему конкретно не провелась накладная или отвалился обмен с банком.

В экосистеме K8s за логи отвечает Loki — он умеет принимать структурированные логи и отдавать их обратно.

Если настроить выгрузку журнала регистрации 1С в сторону Loki (например, через тот же exporter или агент сборки логов), вы получаете ультимативный дашборд. На одном экране в Grafana у вас будет график падения сетевого трафика в кластере, график падения чеков из 1С, а прямо под ними — таблица с текстами ошибок из базы за ту же самую минуту.

Где обычно ломается

Интеграция 1С и K8s кажется простой только в теории, по факту — это две разные системы. Если запустить мониторинг по принципу «написали скрипт и забыли», он упадёт в первый же месяц. И вот почему.

Обновления конфигурации 1С

Главный враг любой OData-интеграции — релизный цикл самой 1С. OData жёстко завязана на имена объектов в базе данных.

Программист 1С переименовал реквизит СтатусОплаты в СтатусДокумента? Ваш Python-экспортер упадёт с ошибкой KeyError, метрики перестанут собираться, а дашборд в Grafana замрёт на старых значениях. HTTP-сервисы ведут себя аналогично — если в очередном релизе поменяли логику сбора данных, старый эндпоинт сломается.

Как чинить: Во-первых, договориться об API-контракте. Во-вторых, добавить в CI/CD пайплайн на стороне 1С банальный автотест: после сборки релиза дёргаем тестовые OData-запросы. Если тест упал — значит, обновление ломает мониторинг, и релиз останавливается.

Авторизация и сетевая доступность

Исторически 1С — это глубокий бэкофис, закрытый файрволами. Kubernetes живёт либо в облаке, либо в выделенном контуре. Подружить их по сети — это всегда квест через службу безопасности.

OData умеет в Basic-авторизацию, но слать логины-пароли в открытом виде между кластером и 1С — плохая идея.

Минимально рабочий вариант: поставить перед 1С API Gateway (тот же Nginx или Kong), закрыть его на mTLS (взаимную аутентификацию по сертификатам) и пускать внутрь только IP-адреса подов вашего экспортера. Пароль от учётки 1С должен лежать в Kubernetes Secrets, а не хардкодиться в Python-скрипте.

Разные ритмы данных

У DevOps-инженеров и аналитиков 1С разное восприятие времени. Prometheus собирает метрики CPU каждые 15 секунд. 1С может рассчитывать себестоимость раз в час или перепроводить документы задним числом.

Если натравить ваш Python-экспортер на тяжёлый OData-запрос (например, «собери-ка мне все чеки за сегодня и посчитай среднее») каждые 15 секунд, 1С просто ляжет от количества соединений. А если опрашивать 1С раз в 10 минут, то график на фоне метрик Kubernetes будет выглядеть рваным.

Как чинить: В Grafana есть настройка Min step для каждой панели. Разделите экраны: метрики K8s пусть обновляются раз в 15 секунд, а бизнес-данные из 1С — раз в минуту или пять минут. А чтобы не класть базу тяжёлыми запросами, делайте агрегацию на стороне 1С (через HTTP-сервис), а не вытягивайте тысячи строк OData в память экспортера ради одного числа.

Пошаговый план интеграции

Разработчики Centicore Group, которые занимаются заказной разработкой и интеграцией сложных контуров, часто повторяют одно правило: не пытайтесь на первом этапе затащить в мониторинг вообще всё. Вот минимальный путь, который можно пройти за неделю без отрыва от основной работы:

1. Определите одну бизнес-метрику, которая важна SRE. Это может быть «количество чеков в минуту» или «число ошибок проведения». Не тащите всю финансовую отчётность в Grafana.
2. Опубликуйте 1С на веб-сервере. Включите поддержку стандартного интерфейса OData и проверьте, что нужный документ или регистр отдаёт JSON по HTTP.
3. Напишите Python-экспортер. Он должен делать ровно две вещи: ходить в 1С по расписанию через OData и отдавать данные в формате, понятном Prometheus. Оберните скрипт в Docker.
4. Настройте сетевой доступ. Спрячьте 1С за API Gateway. Задеплойте под с экспортером в Kubernetes и дайте ему доступ к шлюзу.
5. Настройте Prometheus. Добавьте scrape-конфиг, чтобы Prometheus начал опрашивать ваш экспортер. Убедитесь, что метрика появилась в хранилище.
6. Соберите дашборд. Выведите на один экран в Grafana технические метрики кластера (CPU, память, рестарты) и бизнес-метрику из 1С. Обязательно разведите интервалы обновления: для K8s — 15 секунд, для 1С — 1–5 минут.
7. Настройте первый алерт. Например: «Если количество ошибок из 1С > 10 за 5 минут, а в кластере есть рестарты подов — отправь уведомление в Трекер».

1С и Kubernetes — это просто два HTTP-клиента, как только вы соберёте их на одном дашборде, половина конфликтов между бизнесом и разработкой отпадёт сама собой.

Релиз Kubernetes 1.36, запланированный на 22 апреля 2026 года, содержит разнообразный набор новых alpha-фич, сфокусированных на трёх ключевых направлениях: производительность рабочих нагрузок, масштабируемость API и эффективное использование ресурсов. В этом обновлении много давно ожидаемых возможностей: workload-aware preemption для AI/ML-задач, шардирование API-стримов для больших кластеров, глубокая интеграция Dynamic Resource Allocation (DRA) в scheduler.

В обзоре — 20 новых фич, добавленных в Kubernetes как alpha (то есть выключены по умолчанию): от node-уровневых gRPC API до graceful leader transitions. Это даёт представление, куда движется контейнерная оркестрация.

Прим. Авторы стараются указывать актуальные изменения, но из-за быстро меняющегося ландшафта фич Kubernetes часть KEP (Kubernetes Enhancement Proposals) может быть исключена из milestone ближе к дате релиза.

— Релиз. Kubernetes 1.36 выходит 22 апреля 2026. Статья рассматривает 20 alpha-фич.

— Фокус. AI/ML (workload-aware preemption, gang scheduling, DRA), масштабируемость (sharded watches, kubelet gRPC API), ресурсы (pod-level resource managers, HPA scale-to-zero).

— По категориям. Nodes (5), Scheduling (6), API (4), Apps (1), Storage (1), Various (3) — итого 20 KEP-ов.

— Non-alpha. OCI VolumeSource → Stable; Device taints в DRA → Beta (включены по умолчанию). User namespaces в Pod → Stable после 3,5 года в альфе. gitRepo volume plugin удалён.

Nodes

DRA: Device Attributes в Downward API

KEP #5304 · Feature gate: отсутствует. Фреймворк предоставляет boolean-флаг (например, --enable-device-metadata), который драйверы встраивают в свой CLI.

KEP-5304 вводит стандартный способ для DRA-драйвера наполнять метаданные устройства. Фреймворк затем автоматически передаёт эти метаданные в контейнер, монтируя их как JSON-файл по заданному пути. Больше не нужно изобретать кастомные контроллеры или запрашивать Kubernetes API из самой рабочей нагрузки только ради этих деталей.

В текущей версии DRA, чтобы получить информацию о выделенных устройствах (например, PCIe-адреса для GPU или UUID для mediated-устройств), нужно читать статус ResourceClaim, находить подходящий ResourceSlice и парсить атрибуты. Неудобно. KEP-5304 позволяет DRA-драйверу возвращать метаданные устройства прямо в ответе на gRPC-вызов PrepareResourceClaims (kubelet → driver), а kubelet пишет их в JSON-файл и монтирует его в контейнер. В итоге приложение внутри контейнера просто читает файл /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json.

Новый kubelet gRPC API для локальных подов

KEP #4188 · Feature gate: PodInfoAPI.

Сейчас, чтобы получить свежий статус пода (ready ли он, его IP, его labels), компоненты на той же ноде — CNI-плагины, мониторинг-агенты — должны ходить в API-сервер. Это создаёт проблемы с надёжностью (если нода потеряла связь с control-plane, локальные компоненты не получат свежие данные, хотя они есть у локального kubelet), масштабируемостью (нагрузка на API-сервер от агентов на каждой ноде) и задержкой (сетевой вызов всегда медленнее локального).

Предлагается новый gRPC API для подов прямо на ноде: UNIX-сокет /var/lib/kubelet/pods/kubelet.sock, доступ только для привилегированных процессов. API возвращает самую свежую информацию, доступную kubelet, даже если она ещё не синхронизирована с API-сервером. Клиент может запросить полный PodSpec и PodStatus либо конкретные поля через google.protobuf.FieldMask. Три основных метода: ListPods, GetPod, WatchPods.

CRI List Streaming

KEP #5825 · Feature gate: CRIListStreaming.

Иногда kubelet нужен список всех контейнеров на ноде (например, для garbage collection). Для этого он отправляет CRI-запрос ListContainers. Проблема: существующие CRI RPC — unary, то есть клиент (kubelet) шлёт один запрос, сервер (container runtime) возвращает один ответ со всем списком. На нагруженных нодах с тысячами контейнеров (например, от множества короткоживущих CronJob) список может превысить 16 МБ — дефолтный максимум в gRPC. Этот лимит достигается уже на ~11 000 контейнерах (~14 000 подов).

Чтобы не ломать совместимость, KEP добавляет новые server-side streaming RPC. При streaming-вызове container runtime не строит весь ответ в памяти — открывает gRPC-поток и отправляет StreamContainersResponse для каждого контейнера по очереди. kubelet читает из потока, пока тот не закроется, затем обёртка собирает куски в единый список.

DRA: видимость доступности ресурсов

KEP #5677 · Feature gate: DRAResourcePoolStatus.

Разработчику хочется видеть, какие DRA-ресурсы свободны в кластере, чтобы траблшутить Pod, который не шедулится из-за «insufficient DRA resources». Админу — знать, сколько GPU доступно, для планирования мощностей. Сейчас это сложно: ResourceSlices — cluster-scoped и показывают только общую capacity, ResourceClaims — namespaced и отслеживают конкретные выделения, пользователь с ограниченными правами не видит ResourceClaims вне своего namespace, нет API-механизма видеть соотношение available/allocated.

KEP добавляет ResourcePoolStatusRequest — паттерн CertificateSigningRequest: пользователь создаёт объект с указанием driver (обязательный) и pool filter (опциональный), контроллер в kube-controller-manager подхватывает его, считает availability и пишет результат в status. Для обновления — удалить старый запрос и создать новый.

Пример — посмотреть статус всех GPU-пулов:

Pod-Level Resource Managers

KEP #5526 · Feature gates: PodLevelResources, PodLevelResourceManagers.

KEP-2837 позволил задавать единый бюджет ресурсов (CPU, память и т.д.) для всего пода целиком, а не для каждого контейнера отдельно. Это полезно для Guaranteed-QoS-подов в HPC, AI/ML, NFV. Проблема: текущие resource managers работают на уровне контейнера и не умеют использовать pod.spec.resources для NUMA-решений.

KEP-5526 даёт выбор из двух моделей управления ресурсами (обе поддерживают Guaranteed-поды с mix из Guaranteed- и non-Guaranteed-контейнеров):

• Pod Scope — Topology Manager назначает один ресурсный пул с одной NUMA-ноды на весь под, используя pod.spec.resources. CPU и Memory managers выделяют эксклюзивные сегменты для Guaranteed-контейнеров, остаток идёт в shared-пул для остальных
• Container Scope — ресурсы управляются для каждого контейнера отдельно, pod.spec.resources игнорируется при размещении

Первая модель — для ML-тренировочного контейнера с сайдкарами (логирование, ingestion, мониторинг) на одной NUMA-ноде. Вторая — для независимого управления контейнерами с разными требованиями внутри одного Guaranteed-пода: Guaranteed-контейнер получает эксклюзивные NUMA-выровненные ресурсы, non-Guaranteed в том же поде работают в shared-пуле ноды. Раньше это было невозможно: все контейнеры в поде должны были быть Guaranteed.

Scheduling

Workload-aware preemption

KEP #5710 · Feature gate: WorkloadAwarePreemption.

Scheduler может инициировать preemption — принудительное удаление подов с более низким приоритетом, чтобы освободить ресурсы под высокоприоритетный под. Проблема: он делает это пер-под. А AI/ML- и HPC-нагрузки обычно — группа тесно связанных подов (например, для распределённого обучения). Если даже один под из группы вытеснен, весь job стопорится и просто ждёт возврата этого пода, удерживая ресурсы впустую.

KEP-5710 вводит workload-aware preemption: группы связанных подов (PodGroups) теперь — единая сущность для scheduling и preemption. Scheduler прикидывает, можно ли освободить место под высокоприоритетную группу, вытеснив менее важные группы целиком.

Новое поле DisruptionMode в GangSchedulingPolicy контролирует, может ли Kubernetes вытеснять отдельные поды или группу только целиком (PodGroup). Поле PriorityClassName в PodGroupSpec задаёт приоритет всей группы — используется для всех решений о scheduling/preemption, перекрывая приоритеты отдельных подов. Строится на KEP-4671 (Gang Scheduling в Kubernetes).

Topology-aware workload scheduling

KEP #5732 · Feature gate: TopologyAwareWorkloadScheduling.

Строится на идеях KEP-4671 и KEP-5710. Классический scheduler принимает решения пер-под, что неоптимально для групп связанных подов: их имеет смысл размещать на одной ноде или хотя бы близких нодах — для снижения latency. KEP-5732 делает scheduler topology-aware: можно указать, чтобы группа подов размещалась в пределах одного topological domain, определённого общим label — например, topology.kubernetes.io/rack.

DRA: List-типы для атрибутов

KEP #5491 · Feature gate: DRAListTypeAttributes.

KEP обновляет DRA API под более сложные hardware-конфигурации. Раньше атрибуты устройств в ResourceSlice могли быть только скалярными (string, number, boolean). Нельзя было описать устройство с несколькими соединениями — например, CPU, подключённый к нескольким PCIe-шинам.

Теперь драйверы могут отдавать атрибуты как списки строк, чисел или версий. Обновлена логика в ResourceClaim: matchAttribute теперь требует непустого пересечения списков (не точного совпадения), distinctAttribute — попарной непересекаемости.

Пример ResourceSlice с атрибутом resource.kubernetes.io/pcieRoot в разных форматах:

DRA: поддержка ResourceClaim для Workloads

KEP #5729 · Feature gate: WorkloadPodGroupResourceClaimTemplate.

DRA даёт использовать специализированные ресурсы — GPU, FPGA, кастомные сетевые карты. Чтобы под получил такой ресурс, нужно создать соответствующий ResourceClaim. Проблема: если несколько подов делят ресурс, максимум было 256 подов на один ResourceClaim из-за лимита status.reservedFor.

KEP-5729 чинит: ResourceClaims теперь могут быть на уровне PodGroup. Один claim на всю группу, все поды в ней могут использовать ресурс. Поды ссылаются на ресурс по локальному group-name через PodGroupResourceClaim, а не прямому имени. Динамически создаваемые поды получают доступ к общему ресурсу, автоматически созданному для группы, без необходимости знать его имя заранее.

DRA: Native Resource Requests

KEP #5517 · Feature gate: DRANativeResources.

Появление DRA в Kubernetes породило два независимых механизма учёта ресурсов, которые управляют одним и тем же. Это даёт двойной учёт:

• Supply — capacity CPU/памяти ноды хранится в двух местах: Node.Status.Allocatable у kubelet и ResourceSlice у DRA-драйвера
• Consumption — поды могут запрашивать ресурсы двумя путями: через spec.containers[].resources.requests или spec.initContainers[].resources.requests (проверяет NodeResourcesFit) или через ResourceClaim (обрабатывает DynamicResources)

KEP-5517 интегрирует DRA-ресурсы со standard resource tracking scheduler-а, обеспечивая единый учёт и предотвращая overcommit. Пример: ML-job запрашивает GPU через ResourceClaim, но конкретная модель GPU требует определённого количества CPU и HugePages. Раньше пользователь должен был знать об этом и прописывать в PodSpec. Теперь GPU-устройство декларирует зависимости само — scheduler учитывает потребности GPU в CPU и HugePages дополнительно к обычным requests.

WAS (Workload-Aware Scheduling): декомпозиция PodGroup API

KEP #5832 · Feature gate: GenericWorkload.

Kubernetes имеет gang scheduling — запуск всех подов в группе вместе. Проблема: логика gang scheduling изначально тесно связана с конкретной реализацией API под названием PodGroup, которая была частью объекта Workload. Это создавало два неудобства:

• Другие проекты экосистемы (Kueue, JobSet), тоже требующие gang scheduling, были вынуждены использовать этот конкретный PodGroup API — не могли применить свои CRD для описания групп
• Обновление статуса одной маленькой Pod-группы требовало чтения/записи всего Workload-объекта, что давало просадку производительности и конфликты при большом числе групп

KEP-5832 разделяет PodGroup и Workload: PodGroup становится самостоятельным объектом, Workload — статичным шаблоном, определяющим общую политику и структуру групп. Высокоуровневые контроллеры (Job, JobSet, LeaderWorkerSet) автоматически создают инстансы PodGroup из шаблона Workload, затем поды этой PodGroup. В Pod spec появилось поле spec.schedulingGroup.podGroupName, указывающее прямо на PodGroup. Scheduler больше не следит за Workload-объектами — работает напрямую с потоком PodGroup.

API

Stale Controller Mitigation

KEP #5647 · Feature gate: StaleControllerConsistency.

Контроллеры в Kubernetes (например, kube-controller-manager) работают в reconciliation loop: следят за состоянием кластера, сравнивают желаемое с фактическим, синхронизируют. Они используют локальный кэш состояния, чтобы не перегружать API-сервер. Кэш обновляется через watch — это eventually consistent, то есть «когда-нибудь» изменения доедут. Задержка бывает от миллисекунд до минут.

В больших high-load кластерах проблема обостряется. Контроллер создаёт Pod, через секунду получает запрос reconcile того же объекта, но кэш ещё не обновился — контроллер «не видит» созданный под и пытается создать его снова или делает что-то ещё не то.

KEP-5647 вводит два изменения:

• В informer добавляется BookmarkFunc, единственная задача которого — уведомить слушателей, что произошло обновление. Вместе с обычными Add/Update/Delete это позволяет контроллеру знать, насколько свеж его кэш
• Улучшена логика контроллера. После успешной операции CREATE или UPDATE сохраняется новый resourceVersion объекта. Перед следующим reconcile контроллер проверяет, обработал ли informer resourceVersion как минимум такой же свежий. Если да — кэш актуален, можно продолжать. Если нет — reconcile пропускается, объект ставится обратно в очередь с exponential backoff

Graceful Leader Transition

KEP #5366 · Feature gate: GracefulLeaderTransition.

В high-availability кластерах несколько реплик ключевых control-plane-компонентов (kube-controller-manager, kube-scheduler) работают одновременно. Чтобы избежать конфликтов, используется leader election. Старый механизм при потере лидерства просто завершал процесс через os.Exit(), kubelet его рестартовал. Это съедало ресурсы, и компонент не мог gracefully завершить работу.

KEP-5366 вводит smarter способ передачи лидерства без полного рестарта:

• Рефакторинг кода контроллеров — чтобы все внутренние goroutines завершались чисто. Критично, чтобы не утекали ресурсы при частой смене ролей
• Улучшен release leader lease: вместо ожидания TTL, уходящий лидер активно освобождает lock при shutdown, ускоряя новые выборы. Управляется флагом ControllerManagerReleaseLeaderElectionLockOnExit
• Финальная стадия (флаг GracefulLeaderTransition) меняет core-логику компонента: при потере лидерства он не завершается через os.Exit(), а переходит в follower-состояние и пытается стать лидером снова

Server-side Sharded List and Watch

KEP #5866 · Feature gate: ShardedListAndWatch.

В Kubernetes контроллеры непрерывно мониторят состояние ресурсов (Pods, Services) через LIST и WATCH. С ростом кластеров эти операции тяжело масштабировать. Большинство контроллеров, как kube-controller-manager, масштабируются только вертикально — не умеют разделять watch-поток. Некоторые (kube-state-metrics) научились делать client-side sharding, но каждая реплика всё равно получает все события ресурса, десериализует всё, потом выбрасывает то, что не для её шарда. Лишняя сетевая нагрузка и CPU.

KEP-5866 переносит фильтрацию на API-сервер. Новый параметр shardSelector позволяет клиенту подписаться на конкретный шард данных — задаётся хэш-диапазон. Пример запроса:

API-сервер использует быстрый FNV-1a для хэша metadata.uid. Если хэш попадает в диапазон — событие уходит клиенту. Каждая реплика подписывается на свой диапазон и получает clean, non-overlapping поток.

Manifest Based Admission Control Config

KEP #5793 · Feature gate: ManifestBasedAdmissionControlConfig.

Чинит серьёзную startup-уязвимость в Kubernetes. Обычно все правила валидации запросов (admission webhooks — MutatingAdmissionWebhook, ValidatingAdmissionWebhook, access policies) — это API-объекты внутри кластера. Это даёт опасное окно: при старте API-сервера (или недоступности etcd) запросы могут обрабатываться до того, как правила загружены. Плюс любой пользователь с повышенными правами может — намеренно или случайно — удалить admission policies по сети.

KEP-5793 добавляет способ задавать security-политики через локальные манифест-файлы на диске control-plane-сервера. Эти файлы загружаются и применяются до того, как сервер начнёт слушать сеть. API-сервер непрерывно мониторит локальный каталог — при изменении файла правило немедленно подхватывается, валидируется и применяется без рестарта. Если валидация упала, сервер отклоняет новый манифест, логирует warning и возвращается к last-known-good конфигурации.

Apps

WAS: интеграция Workload API с Job controller

KEP #5547 · Feature gate: EnableWorkloadWithJob.

Job controller в Kubernetes отвечает за запуск джобов. Он создаёт поды, но нет гарантии, что они стартанут одновременно. Реальная проблема для распределённых нагрузок (AI/ML, MPI-задачи), где всё должно стартовать синхронно.

KEP-5547 расширяет Job controller нативной поддержкой gang scheduling (KEP-4671) через Workload и PodGroup API. Когда создаётся Job с нужными параметрами (для альфы это parallelism > 1, completionMode: Indexed, parallelism = completions), контроллер автоматически:

• Создаёт объект Workload с политикой scheduling для группы подов, указывая gang.minCount равным parallelism
• Создаёт объект PodGroup по шаблону из Workload
• При создании подов Job добавляет schedulingGroup.podGroupName в их спецификацию, связывая поды с соответствующей PodGroup

Scheduler видит, что поды — часть PodGroup, и ждёт возможности запустить все поды из minCount (минимум для старта workload) одним махом.

Storage

PVC — время последнего использования

KEP #5541 · Feature gate: PersistentVolumeClaimUnusedSinceTime.

Со временем в кластерах накапливаются PVC, которые больше не используются. Приложение удалили, мигрировали или просто остановили, а PVC остаётся — жрёт хранилище и деньги. Сейчас в Kubernetes нет простого способа посмотреть, когда PVC использовался в последний раз.

KEP-5541 добавляет поле UnusedSince в статус PVC (PersistentVolumeClaimStatus). PVC protection controller ставит туда metav1.Now при удалении или переходе в terminal state последнего пода, ссылающегося на PVC, и nil при появлении нового пода, начинающего ссылаться на этот PVC.

Various

HPA: масштабирование до/от нуля по object/external metrics

KEP #2021 · Feature gate: HPAScaleToZero.

Раньше Horizontal Pod Autoscaler не мог скейлить до нуля реплик. Он опирался на метрики активных подов — CPU, память — поэтому всегда требовался минимум один работающий под для сбора данных.

KEP вводит поддержку external и object metrics: HPA может принимать решения по внешним индикаторам (например, длина очереди сообщений). Если задач нет — число подов приложения скейлится до нуля, фактически глушит его. HPA записывает это в специальный status-поле ScaledToZero. Это предотвращает случайный scale-up приложения, которое админ вручную опустил до нуля через replicas: 0. Как только появляется задача (сообщение в очереди) — HPA поднимает первую реплику.

Native Histogram Support для метрик Kubernetes

KEP #5808 · Feature gate: NativeHistograms.

Гистограммы в Prometheus сейчас работают через предопределённые buckets. Разработчик заранее задаёт диапазоны значений. Например, для latency: до 10 мс, до 50 мс, до 100 мс, до 500 мс. Если запрос занял 49 мс — инкрементится «до 50 мс». У этого два недостатка:

• Неоднозначность — невозможно узнать точное распределение внутри bucket (все запросы на 11 мс или все на 49 мс? Эта информация теряется)
• Избыточность — передаются данные для всех bucket'ов, даже если туда ничего не попало. Жрёт ресурсы и диск

Prometheus v2.40 ввёл Native Histograms (стали stable в v3.8.0) с умными auto-adjusting экспоненциальными buckets. KEP-5808 интегрирует Prometheus Native Histograms в метрики компонентов Kubernetes.

Обработка незашифровываемых ресурсов

KEP #3926 · Feature gate: AllowUnsafeMalformedObjectDeletion.

Шифрование API-ресурсов at-rest давно используется в Kubernetes. Иногда оно ломается из-за внешних сбоев или неверной настройки. Если один объект определённого типа не расшифровывается, то list этого типа в префиксе, содержащем объект, всегда падает — даже если остальные объекты читаются. Поломанный объект нельзя удалить через Kubernetes API, админ должен лезть в etcd вручную.

KEP-3926 предлагает метод идентификации ресурсов, которые не расшифровываются или не декодируются в объект, и вводит новый DeleteOption — IgnoreStoreReadErrorWithClusterBreakingPotential, разрешающий удалить ресурс, даже если его данные не читаются.

Non-alpha highlights релиза 1.36 — выбор Дмитрия Шурупова

Статья намеренно фокусируется на alpha-фичах, чтобы показать, куда движется разработка. Но каждый релиз содержит много других обновлений — это alpha, введённые раньше, или фичи, сейчас находящиеся в beta/stable. Самые заметные, по мнению Дмитрия Шурупова (сооснователя Palark, CNCF Ambassador):

• Device taints и tolerations в DRA (KEP 5055) и DRA support for partitionable devices (KEP 4815) — Beta. Включены по умолчанию
• OCI VolumeSource (KEP 4639) — Stable. Новый VolumeSource (появился в 1.31), поддерживает OCI-образы: хранение файлов и расшаривание между контейнерами в поде без включения в основной образ
• User namespaces в Pods (KEP 127) — Stable. Стартовал в alpha в 1.25 (август 2022), через 3,5 года наконец GA
• Mutating Admission Policies (KEP 3962) — Stable. Расширяет mutating admission webhooks через CEL-выражения
• Accelerated recursive SELinux label change (KEP 1710) — Stable. В beta с 1.27 (апрель 2023)
• gitRepo volume plugin (KEP 5040) — удалён. Критическая security-проблема: выполнение кода как root на ноде

Часть alpha-фич из 1.35 и более ранних релизов (gang scheduling, user namespaces в HostNetwork-подах) значительно доработана, но осталась в альфе.

Это не полный список изменений — полную информацию можно посмотреть в official enhancements tracker и changelog.

Заключение

Релиз Kubernetes 1.36 существенно расширяет инструментарий оркестратора, фокусируясь на производительности, безопасности и удобстве использования. Интегрируя gang scheduling и продвинутое управление ресурсами, Kubernetes всё лучше подходит для современных распределённых нагрузок и больших кластеров, одновременно оптимизируя ядро своих API.

Спасибо всем разработчикам и авторам KEP, сделавшим Kubernetes 1.36 возможным. Вы потрясающе сработали.

Интересуют другие alpha-фичи, недавно добавленные в Kubernetes? Читайте deep-dives по Kubernetes 1.35 (декабрь 2025) и Kubernetes 1.34 (август 2025).

Оригинал статьи: palark.com/blog/kubernetes-1-36-release-features/. Перевод публикуется с сохранением оригинальной структуры и всех технических деталей.

Рассказываем, что показала компания, о чём говорили спикеры и куда движется индустрия.

Сначала цифры: как вырос Cloud.ru

На конфренции Cloud.ru впервые публично раскрыла детальную финансовую отчётность. Выручка за 2025 год — 76,5 млрд рублей (+50% год к году). Чистая прибыль — 14,7 млрд(+86%).

Основной драйвер роста — инфраструктура для ИИ: обучение и инференс моделей дали 54% выручки. При этом классические облачные сервисы тоже выросли на 31%, что быстрее темпов роста рынка России.

По инфраструктуре Cloud.ru — один из крупнейших облачных провайдеров в стране. В парке находится 43 000+ единиц оборудования, 29 000+ серверов, 9 ЦОДов суммарной мощностью 56 МВт.

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

Важный нюанс: убыточных направлений нет. Разные платформы находятся на разных стадиях развития, но инвестиции отбиваются в плановые сроки.

АФЛТ-Системс, например, уже в активной фазе перехода к регулярной эксплуатации AI. Павел Павленко, руководитель направления развития GenAI, говорит: «GoCloud для меня в этом году — про то, как индустрия перешла от разговоров про потенциал GenAI к разговору про реальные внедрения, метрики и архитектурные решения. Мы строим внутреннюю AI-платформу, выстраиваем процессы и запускаем первые продукты, в том числе AI-фикацию пайплайна разработки. На таком этапе ценность партнёра измеряется не презентациями, а скоростью реакции и готовностью идти в эксперимент».

Что происходит на рынке: от пилотов к промышленной эксплуатации

Последние 2–3 года компании делали пилоты по внедрению генеративного ИИ в основном благодаря визионерской силе лидеров, CEO, директоров. Пилоты часто были точечными и экспериментальными: автоматизировали поддержку и отвечали на частые простые вопросы, генерировали контент.

Сейчас модели стали лучше, а бизнес опытным путем выяснил, какие функции эффективнее передавать ИИ. Результаты пилотов всё чаще признаются успешными.

Например, Артём Бондарь, руководитель направления NLP в Центре искусственного интеллекта Т-Банка, выделяет три ключевых направления GenAI-инструментов. Первое — агенты и копайлоты в полном цикле разработки. Второе — инструменты для HQ-профессий: от генеративных моделей для общих задач до вертикальных решений вроде автоматической генерации креативов «почти без касания людей».

Но прямой финансовый эффект особенно заметен в автоматизации поддержки и операционки. Здесь задействован весь спектр GenAI-подходов:

• пошаговая автоматизация с помощью LLM там, где есть регламентированный процесс,
• агенты, которые ищут решение в сконструированной для них среде,
• и AI-сотрудник Афанасий Иванов (АИ), который работает в компании уже больше года и использует те же интерфейсы, что и люди.

Становится ясно, что перелом скоро наступит. И это точно не год.

Последует волнообразный рост спроса на инференс, а не только на обучение. Раньше инфраструктура была перекошена только в ту сторону, хоть и занимаются обучением единицы компаний в стране. Уже за последние полтора года спрос на инференс резко вырос. Скоро пропорция выровняется 50 на 50, а дальнейший переход будет зависеть от того, насколько быстро заработает агентная экономика.

DevOps-практики тоже перешли в практическую плоскость. В МТТЕХ выстроили модель GitOps, где Git — единый источник истины, а все изменения проходят через ревью и автоматизированный деплой. IaC-подход (Terraform, Ansible) и self-hosted GitLab в облаке позволяют управлять инфраструктурой как кодом.

Если раньше поднятие инфраструктуры занимало недели и требовало вовлечения нескольких команд, то сегодня мы говорим про минуты и полностью автоматизированные процессы,

При этом классические облачные нагрузки тоже растут. Цифровизация никуда не делась, а GenAI-трансформация косвенно драйвит и классику: нужны хранилища, CPU для сопутствующих задач, сети.

Neocloud: GPU как отдельное направление

На этом фоне Cloud.ru выделил AI-инфраструктуру в отдельное бизнес-направление — Neocloud. Это единая управляемая среда для полного цикла работы с моделями: от разработки и обучения до инференса и эксплуатации.

Нагрузки под ИИ сильно отличаются от классических. Для них нужны высокоскоростные соединения между GPU, умный шедулинг (днём — инференс, ночью — дообучение), возможность получить кластер из сотен HGX, а потом отпустить. Но на рынке такого предложения нет. Neocloud как раз решает управление вычислительными ресурсами на масштабе.

В Neocloud есть:

• Доступ к тысячам современных GPU в публичном облаке.
• Поддержка гибридных сценариев (своя инфраструктура + облако).
• Собственная платформа Distributed Train для распределённого обучения с проактивным мониторингом, автоматической заменой отказавших узлов и гибким управлением очередями.

Чем Neocloud выгодно разработчикам

Решения такого уровня остаются доступными и для пользователей. Арендовать HGX теперь не проблема, они доступны буквально по цене обеда.

Выгодная стоимость для Cloud.ru остается приоритетом. Компания заявляет, что не планирует повышать цены в этом году.

Это не единственный аргумент в пользу облака. Как отмечает Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность, для госсектора и крупных компаний есть ещё одно важное преимущество: «С облаком удобнее проходить закупочные процедуры. Ты сделал рамочный договор, и в любой момент, когда у тебя появился новый госзаказчик, быстро развернул инфраструктуру».

Агенты: EvoClaw, Agent Space и новый способ общения с облаком

Другой инструмент, о котором рассказали на конференции, — EvoClaw. Это управляемый облачный сервис для работы с OpenClaw и другими open source агентными фреймворками. ИИ-агент обеспечивает observability, мониторинг, логирование и поддерживает политики безопасности. Cloud.ru одним из первых в России приступил к открытому тестированию OpenClaw ещё в феврале 2026 года.

Ключевые особенности EvoClaw:

• Агент запускается в пару кликов.
• Политики безопасности приведены к Zero Trust, привилегии — по минимальному принципу.
• Агенты изолированы своим рабочим пространством.
• Интеграция с AI Factory (Foundation Models, AI Agents, Managed RAG).

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

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

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

Ещё одно решение Cloud.ru для работы с агентами — Agent Space — мобильное и десктоп-приложение, которое позволяет чатиться с агентом. Оно работает на протоколе A2A (Agent-to-Agent). А в каталоге представлены уже более 20 бизнес-сценариев, среди которых и «Агент Python-разработчик».

AI Workflows: low-code оркестратор

Бизнес-процесс редко состоит из одного действия. Обычно это цепочка: проверить данные в 1С, прогнать их через LLM, создать задачу в Jira, отправить уведомление в Telegram.

Для таких сценариев Cloud.ru запустил AI Workflows — low-code конструктор, который сейчас находится в публичном тестировании.

Пользователь собирает цепочку шагов в визуальном интерфейсе (как в n8n, но с ИИ-блоками). На каждом шаге можно подключить готовый коннектор к 1С, Jira, Confluence, PostgreSQL, почтовым клиентам, мессенджерам или внутренним сервисам через API. А между ними — вызовы LLM из Evolution Foundation Models, инференс-моделей или даже готовых агентов.

На старте AI Workflows ориентирован на готовые коннекторы и предсобранные кубики. Вставлять кастомные скрипты прямо в цепочку пока нельзя. Но в компании понимают, что разработчикам это нужно и планируют дать такую возможность, подчеркивает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

На пресс-конференции прозвучала интересная мысль: AI Workflows — это тоже промежуточный этап. Через пару лет, когда компании привыкнут делегировать задачи ИИ, и этот уровень оркестрации станет не нужен, всё будет ИИ-фицировано насквозь.

Безопасность: Guardrails и Container Security

Агенты получают доступ к вашей инфраструктуре. Да, это удобно, но возникает закономерный вопрос: как не допустить, чтобы агент случайно (или специально) не отправил чувствительные данные во внешнюю LLM? Или не поднял контейнер с критической уязвимостью?

На GoCloud 2026 анонсировали два инструмента, которые закрывают эти риски — на уровне данных и на уровне инфраструктуры.

Guardrails Filter: чтобы секреты не утекли

Guardrails Filter — это фильтр между агентами и большой языковой моделью. Он сканирует исходящий запрос, находит потенциально чувствительные данные (ПДн, реквизиты, API-ключи, секреты), маскирует их и только потом отправляет в LLM. Когда модель возвращает ответ, фильтр восстанавливает реальные значения на месте.

Guardrails как раз обеспечивает фильтрацию при обращении к внешним моделям. Наши же модели не дообучаются, данные не используются, не имеют доступа в интернет. Это проверено пен-тестами,

Evolution Container Security: чтобы контейнеры не стали дырой

На уровне государства вводятся понятия «суверенного искусственного интеллекта», проходят публичные слушания по закону. Граница безопасности активно формируется. Cloud.ru отвечает на этот запрос и даёт широкую линейку сервисов безопасности, чтобы клиент мог выбрать нужный уровень под свой класс информационной системы.

По оценкам экспертов, порядка 80% запущенных кластеров Kubernetes содержат роли с избыточными привилегиями. И Evolution Container Security обеспечивает безопасность контейнерных сред Kubernetes. Сервис уже доступен в публичном тестировании.

Возможности Evolution Container Security:

• Сканирование контейнеров на уязвимости (включая БДУ ФСТЭК).
• Встроенный ИИ-агент для генерации политик безопасности.
• Создание и управление политиками через конфигуратор.
• Проверка конфигураций во время развёртывания.

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

Что еще волнует безопасников

На круглом столе «Облако уже сегодня. Как получить конкурентное преимущество без компромиссов по безопасности» участники честно рассказали о своих страхах. Главный — потеря контроля. «Облако — это чёрный ящик, который необходимо контролировать, обвязывать своими сервисами, чтобы перепроверять подрядчика», — поделился Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность.

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

Облачные провайдеры, включая Cloud.ru, уже отвечают на эти запросы — едиными политиками безопасности, мониторингом и логированием как в публичном облаке, так и в гибридных средах.

Но есть и другой уровень безопасности — физический. Антон Фомин, CDO Navio, рассказывает, как GenAI помогает спасать жизни: «Как собрать данные о лобовом столкновении, не отправляя водителя на встречную машину? Мы это делаем с помощью нашего фотореалистичного стимулятора. Вот настоящая польза генеративного ИИ: заглянуть за горизонт и научить машины ездить без риска».

Гибридные облака: почему это сложно и как Cloud.ru стали одними из первых в этом поле

Гибридное облако — одна из тех тем, о которой много говорят, но мало кто делает хорошо. На конференции Cloud.ru представил исследование, которое показывает: интерес к гибридной модели растёт, но её часто воспринимают как нечто сложное и размытое.

Что такое гибрид на самом деле? Если отбросить маркетинговые формулировки, гибрид — это частное облако (on-prem) + публичное облако + связь между ними под единой платформой. Из единого личного кабинета можно управлять ресурсами и там, и там, переезжать виртуальными машинами из публичного облака в свой ЦОД и обратно.

Гибрид для меня — это возможность использования on-prem инфраструктуры, но с биллингом, управлением ресурсами, логированием, личным кабинетом

Гибрид это всё ещё больно и дорого. Публичное облако можно обновлять постоянно — раз-два в день, а то и чаще. Если в сервисе появилась ошибка, её сразу исправляют. С гибридом так не получится. Релиз, который поедет к клиенту на on-prem инфраструктуру, нужно собирать, тестировать, сертифицировать. И каждый сервис внутри этого релиза должен работать без оглядки на внешние зависимости.

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

Почему индустрия всё равно придёт к гибриду

• Безопасникам проще контролировать конфигурации и видеть всю инфраструктуру.
• Финансистам — смотреть утилизацию оборудования.
• CTO — видеть все виртуальные машины.
• В on-prem сложно инвентаризировать legacy-системы. Гибрид даёт прозрачность.

Cloud.ru начал строить гибридную платформу ещё на ранней стадии публичного облака. В прошлом году анонсировали Evolution Stack — платформу для создания частных и гибридных облаков. Клиенты уже могут получить единые политики безопасности, мониторинг и логирование для on-prem и публичного облака. Единой консоли управления «из облака» (модель Outpost, как у западных гиперскейлеров) пока нет. Но пилоты с единым центром управления готовы запускать уже сейчас.

В России почти нет провайдеров, которые могут предложить гибридное облако как отчуждаемый продукт, который можно установить у себя в ЦОДе. Cloud.ru сделал это за счёт того, что публичное облако и гибридная платформа построены на единой кодовой базе. Сервисы идентичны, пользовательский опыт одинаковый. Разработка начинается в публичном облаке, а прод уезжает на on-prem — и это работает, потому что сервисы внутри одни и те же.

Что будет с разработкой: не паникуем, но не забываем готовиться

Агенты уже пишут код, тестируют, разворачивают инфраструктуру. DevOps-инженер отдаёт помощнику создание виртуальных машин и настройку баз данных. SRE-агент сам поднимает метрики и ищет первопричины инцидентов. Вопрос, который возникает у каждого разработчика: «Меня заменят?»

В ближайшем будущем роли не отомрут, но изменятся. «Разработчику нужно поднимать уровень, становиться тимлидом — а его тиммейтами будут агенты», считает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

Чем больше у разработчика экспертизы, чем лучше он понимает, как на самом деле устроен продукт, что такое репозитории, из каких блоков он состоит, — тем эффективнее он будет с агентами работать,

Новый челлендж — экономика решений. Можно написать агенту одну строчку, а потом 10 тысяч раз переделывать, уточнять, перезапускать. Каждый шаг — это токены. А токены — это деньги. Борьба будет не за то, кто быстрее написал код, а за то, сколько стоило решить задачу.

Новая роль — оркестратор агентов. На круглом столе «DevOps инструменты в облаке» представители МТТЕХ, Familia, Ventra и «Технологии – и точка» сформулировали главный тренд: «Мы движемся к модели, где человек становится оркестратором агентов. Он их направляет, пишет принципы, управляет — как оргструктурой».

Количество агентов будет расти драматически — от десятков до тысяч. И тот, кто научится управлять этой «армией», останется востребованным.

Агенты не приходят на пустое место. Основной барьер для внедрения ИИ-агентов не технологический, а организационный. Если в компании данные разрознены, процессы не формализованы, а культура не готова делегировать решения машине — никакой агент не поможет. И наоборот: в компаниях, где данные структурированы и процессы прозрачны, агенты достигают 60–90% автоматизации.

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

Сначала вы управляете всем с помощью kubectl: запускаете kubectl get pods, describe, logs, exec, delete и apply по 50 раз в день в пяти неймспейсах. Это работает, но процесс медленный и неудобный — особенно потому, что каждый раз приходится указывать ключ -n namespace.

— На помощь приходит K9s (или Lens). Это терминальный UI, который собирает всю информацию о кластере в одном месте. С ним можно переключаться между неймспейсами и кластерами, смотреть логи, заходить в под (exec) и делать всё необходимое.

Вы деплоите манифесты с ноутбука через kubectl apply. Кто-то меняет Deployment прямо в кластере, и запущенные сервисы больше не согласуются с тем, что прописано в Git. Типичный дрейф конфигурации — про него никак не узнаешь, пока не упадёт прод.

— Внедряете Argo CD. Git становится единым источником истины: любые изменения автоматически синхронизируются с кластером; если кто-то поменяет Deployment вручную, Argo CD сразу перезапишет его обратно. (А ещё есть werf, который отлично интегрируется с Argo CD. Познакомиться с ним поближе можно на сайте проекта или в нашем курсе — заглядывайте!).

В Kafka скопилось 200К сообщений, но процессор загружен всего на 5 %, поэтому HPA не видит причин для масштабирования. Очередь растёт, пользователи ждут.

— Перехóдите на KEDA. Инструмент умеет масштабировать поды по размеру очереди, числу сообщений Simple Queue Service или метрикам Prometheus, а не только по процессору. В итоге бэклог благополучно разгребается.

Нагрузка скакнула, Horizontal Pod Autoscaler добавил поды, но узлы забиты под завязку, и те зависают в состоянии Pending. HPA свою работу сделал, но проблема в том, что новые поды просто негде разместить.

— На выручку приходит Karpenter. Поды зависли в Pending? Не беда! Karpenter поднимет новый узел за пару секунд (и удалит, когда нагрузка спадёт). Платишь только за то, что используешь.

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

— Поэтому вы используете Network Policies. База данных принимает трафик только от приложения, всё остальное закрыто. В итоге, если какой-то под взломают, радиус поражения будет минимальным.

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

— Внедряете сервис меш. Istio или Linkerd подселяют сайдкар-прокси к каждому поду, и вы получаете mTLS между всеми сервисами, повторные запросы, circuit breaker'ы и метрики трафика. А самое главное — не надо править код приложения!

Секреты в Kubernetes закодированы в Base64, лежат в etcd, и их может прочесть любой, у кого есть доступ к kubectl. Хорошо бы перенести их в специализированное хранилище вроде HashiCorp Vault или AWS Secrets Manager, но переписывать код приложения — не вариант.

— Поэтому вы используете Secrets Store CSI Driver. Секреты хранятся в Vault или AWS Secrets Manager и монтируются прямо в поды как файлы. В самом Kubernetes они нигде не «светятся».

Один разработчик выкатывает контейнер с root-правами, другой забывает проставить лимиты на ресурсы. Но вы узнаёте об этом только после инцидента, и так постоянно.

— Ставите Kyverno. Ресурсы проверяются на соответствие политикам ещё до того, как попадут в кластер: теперь нельзя развернуть root-контейнеры, образы без digest-хеша и деплойменты без лимитов.

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

— Значит, пора установить Prometheus и Grafana. Prometheus собирает метрики со всех подов, узлов и системных компонентов, а Grafana превращает их в наглядные дашборды. Сразу видны всплеск нагрузки, точное время его появления и сервис-виновник. (К слову, наш высокопроизводительный форк Prometheus — Deckhouse Prom++ — потребляет до 10 раз меньше памяти.)

Grafana показывает сам всплеск, но не говорит, какой запрос его вызвал, на какой сервис он пришёл первым и где именно начал тормозить. Логи дают лишь обрывки данных, а метрики — общие цифры. Ни то, ни другое не показывает картину целиком.

— Поэтому вы добавляете Jaeger. Он отслеживает путь запроса через все сервисы, показывая задержку на каждом переходе (hop) и точное место сбоя. Иголка в стоге сена находится за считаные секунды.

Рекламная пауза

Если вы не хотите разбираться в инструментах экосистемы с нуля, попробуйте Deckhouse Kubernetes Platform Community Edition — нашу готовую Open Source-платформу на базе Kubernetes. Она собрана инженерами «Фланта» из проверенных компонентов, которые не придётся обновлять вручную, и существенно сэкономит ваши ментальные ресурсы.

Реклама. Рекламодатель: АО «Флант» ИНН 7723661439, erid: 2W5zFHw9J5P

Эту статью будет проще читать, если вы знакомы с основами Yoke и Air Traffic Controller.

Если вкратце, Yoke позволяет определять пакеты как распространяемые программы, скомпилированные в WASM, которые называются Flights («рейсы»). Air Traffic Controller («диспетчер воздушного движения») расширяет API Kubernetes через Airways («воздушные трассы») — специальный ресурс, который создаёт CRD и связывает его с конкретным Flight.

Этот материал как раз о том, как Air Traffic Controller открывает простор для мощной и гибкой оркестрации ресурсов.

За пределами плоского YAML: как выглядит реальная оркестрация в Kubernetes

Если вам доводилось управлять современными сложными приложениями в Kubernetes, то наверняка знакомо чувство тревоги, когда ждёшь, пока все ресурсы перейдут в healthy-статус. Например, база данных должна быть готова до запуска приложения, серия пакетных задач (batch jobs) должна выполниться в строгой последовательности, а сервис может зависеть от секрета, которым управляет совершенно другая система. Как описать эти взаимоотношения? Сегодня, по большому счёту, никак.

Годами Helm и Kustomize были основными инструментами для управления Kubernetes-приложениями. Но они работают как генераторы манифестов: вы описываете список YAML-файлов, отправляете их в API и надеетесь, что всё сработает. Для простых stateless-приложений это нормально, но когда нужны порядок выполнения, координация между компонентами или управление состоянием — такой подход не годится.

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

Пробел в оркестрации

Причина этого пробела кроется в истории. Инструменты вроде Helm и Kustomize — это, по сути, шаблонизаторы на стороне клиента. Они генерируют манифесты, и на этом их работа заканчивается. Даже серверные GitOps-решения вроде Argo CD или FluxCD придерживаются той же концепции, ведь они преимущественно используют те же инструменты для генерации манифестов, которые потом синхронизируют за вас.

Конечно, есть обходные пути. Вы наверняка сталкивались с хуками pre/post-install в Helm или волнами синхронизации (sync waves) в Argo CD. И хотя это полезные фичи, проблема решается лишь частично. Они срабатывают только при установке или обновлении, но не работают на протяжении всей жизни приложения.

Пара слов о YAML и итоговой согласованности

Мы осознаем, что предложение отойти от использования YAML воспринимается неоднозначно. Для многих в сообществе «голые» манифесты — единственный «правильный» способ взаимодействия с API Kubernetes. Такая привязанность привела к тому, что для решения сложных проблем с зависимостями все стали активно полагаться на один базовый паттерн — итоговую согласованность (eventual consistency).

Идея в том, чтобы выкатить всё разом и просто надеяться, что рано или поздно контроллеры всё приведут к желаемому состоянию, зависимости подтянутся и кластер сам… заведётся. Все мы видели это на практике: под уходит в CrashLoopBackOff и висит в нём, пока какая-нибудь другая система наконец не создаст нужный ему ConfigMap или Secret.

Сразу поясним: итоговая согласованность — это фундаментальная часть Kubernetes и очень мощная идея. Проблема в том, что мы слишком долго использовали её как единственный инструмент для управления комплексными воркфлоу. Нам приходилось на неё полагаться, потому что имеющиеся инструменты не давали иного выбора: что имеем, тем и пользуемся. Наши YAML-ориентированные утилиты могли описать лишь то, что мы хотим получить в итоге, но не то, как к этому прийти.

Дилемма оператора

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

И хотя создание оператора — мощный и правильный подход, это ещё и масштабная задача. Здесь и высокий порог входа, и постоянные расходы на разработку и поддержку, которые далеко не всегда оправданы. Неужели нет золотой середины?

Новая модель: логика приложения как код

Вот тут-то на сцену и выходят Yoke и Air Traffic Controller (ATC) с новым образом мышления. Вместо того чтобы генерировать статичный набор YAML-файлов, Yoke описывает пакеты в виде исполняемого кода.

Это позволяет сфокусироваться на логике оркестрации приложения, написав простую [WASM] программу, работающую по знакомой схеме:

1. Прочитать входные параметры из кастомного ресурса.
2. Принять решения, основываясь на текущем состоянии кластера.
3. Обновить статус кастомного ресурса, указав прогресс или другую информацию.
4. Создать те ресурсы, которые должны быть в кластере прямо сейчас.

И да, это очень похоже на классический цикл согласования (reconciliation loop) в контроллере Kubernetes — так и задумано.

ATC — это контроллер, чья единственная работа — приводить ресурсы в кластере к желаемому состоянию. WASM-модуль представляет собой ядро логики и выступает посредником для цикла согласования, управляя желаемым состоянием (ресурсами) пакетов и избавляя вас от необходимости создавать и поддерживать собственный оператор с нуля.

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

По своей сути, «Flight» в Yoke — это просто программа (скомпилированная в WASM; аналог Helm-чартов), которая считывает кастомный ресурс (Custom Resource) из stdin и записывает желаемое состояние системы в stdout.

Но поскольку ATC перезапускает её в рамках цикла управления (control loop), она становится динамической и реагирующей. Код выполняется каждый раз, когда:

• ресурс, которым он управляет (например, Job или Deployment), обновляется или удаляется;
• внешний ресурс, который он отслеживает (например, Secret от другого инструмента), создаётся, обновляется или удаляется.

Так код реагирует на изменения в кластере в реальном времени.

Примеры

Пример 1: пайплайн для последовательного запуска задач

Предположим, вам нужно создать ресурс Pipeline для запуска трёх задач друг за другом: job-one, job-two, job-three. При этом каждая следующая задача должна стартовать только после успешного завершения предыдущей.

С Yoke эту логику можно описать прямо в коде.

Сначала определим Go-тип для кастомного ресурса Pipeline:

Затем добавим соответствующее определение Airway, которое указывает ATC, как им управлять:

Основная магия содержится в WASM-модуле. Рассмотрим её пошагово:

Эта простая Go-программа как раз и реализует логику оркестрации. Она создаёт задачу, проверяет её статус и движется дальше, только когда та завершится. А цикл управления от ATC берёт на себя всю рутину по «ожиданию» и «перезапускам».

Пример 2: координация с внешними ресурсами

Рассмотрим другой распространённый сценарий: приложению требуется база данных. Вы используете Crossplane для инициализации CloudSQLInstance, который в итоге создаёт Secret, содержащий данные для подключения. Deployment не запустится до тех пор, пока этот Secret не будет существовать.

Сегодня вы, скорее всего, просто выкатываете всё сразу и ждёте, когда появится секрет (под приложения находится в состоянии CrashLoopBackOff). Но можно поступить умнее.

Давайте опишем ресурс App, который будет управлять этим процессом:

Airway нужно будет настроить так, чтобы он имел доступ к кластеру, а если точнее — чтобы мог искать ресурсы типа Secret.

Логика в нашем WASM-модуле будет такой:

Эта логика описывает зависимость: создать базу данных, дождаться секрета и только после этого развернуть приложение. Больше никаких подов в состоянии CrashLoopBackOff, только чистая оркестрация с отслеживанием состояния!

Заключительные мысли

Применяя подход «логика приложения как код», Yoke предлагает компромисс между статическими YAML-шаблонами и полнофункциональными операторами. Он позволяет кодифицировать сложные, активно реагирующие стратегии развёртывания с отслеживанием состояния, используя привычные языки программирования и инструменты, делая настоящую оркестрацию доступной для каждого.

MLOps — это правила, версии и автоматизация для жизненного цикла ML-модели: от данных и обучения до деплоя, мониторинга качества и переобучения. Проще говоря, MLOps нужен, чтобы модель не жила в режиме train.ipynb и чатов с сообщениями “какую версию мы вообще выкатили?”.

— MLOps не заменяет DevOps: он добавляет к нему данные, эксперименты, модели и контроль качества после релиза.

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

— В MLOps важно версионировать не только код, но и срез данных, конфигурацию обучения, артефакты модели и правила деплоя.

— Начать можно без огромного стека: часто достаточно CI/CD, понятного трекинга экспериментов, одного способа деплоя и мониторинга качества.

— Если модель влияет на продукт или деньги, ручной процесс почти всегда становится слишком дорогим и хрупким.

Где заканчивается DevOps и начинается MLOps

В обычном DevOps мы доставляем код: собираем приложение, тестируем, выкатываем, следим за доступностью и ошибками. В ML-системе этого мало, потому что итог зависит не только от кода, но и от того, на каких данных модель обучалась, как считались признаки и не изменился ли сам входной поток.

• В DevOps главный артефакт обычно релиз приложения или контейнер. В MLOps артефактов больше: код, данные, конфигурация обучения, модель, метрики и правила выкладки.
• В DevOps после релиза вы в основном смотрите на uptime и ошибки. В MLOps этого недостаточно: сервис может быть здоровым, а качество предсказаний уже проседать.
• В DevOps откат часто означает вернуть прошлую версию приложения. В MLOps иногда нужно откатывать ещё и модель, и связанный с ней pipeline.
• В MLOps часто автоматизируют не только доставку, но и сам ML-pipeline. В обзоре Google Cloud это описано как отдельные уровни зрелости: continuous training и automation вокруг ML-процесса, а не просто “ещё один деплой”.

Если упростить до одной фразы, DevOps отвечает на вопрос “как надёжно возить приложение”, а MLOps — “как надёжно возить модель, которая со временем стареет и зависит от данных”.

Простой пример: как MLOps выглядит вживую

Допустим, у вас есть модель, которая советует товары в интернет-магазине. Раз в неделю команда обновляет данные о просмотрах, покупках и корзинах, обучает новую версию модели и решает, стоит ли пускать её в production.

В этом и есть суть MLOps: команда может повторить обучение, понять происхождение модели, безопасно выкатить новую версию и вовремя заметить, что она перестала приносить пользу.

Что именно MLOps держит под контролем

• Данные. Важно знать, на каком срезе данных обучали модель, какая у него схема и какие шаги подготовки применялись.
• Код и конфигурацию обучения. Без них нельзя честно воспроизвести эксперимент.
• Эксперименты. Нужно видеть, какой запуск дал лучшие метрики и почему.
• Реестр моделей. Он нужен не только для хранения, но и для управления жизненным циклом: кандидат, staging, production, rollback.
• Сервинг и качество после релиза. Модель должна быть не просто “задеплоена”, а полезна на живых данных и понятна по состоянию.

Здесь есть важная тонкость: “версия данных” — это не просто ссылка на папку. Обычно нужен хотя бы воспроизводимый снапшот, схема, split на train и validation и понимание, как были собраны признаки. Иначе воспроизводимость остаётся на словах.

Какой стек нужен на старте

MLOps не начинается с покупки большого комбайна. Для большинства команд старт выглядит довольно приземлённо.

• CI/CD для кода и пайплайнов, чтобы обучение и деплой не жили только на ручных командах.
• Трекинг экспериментов и реестр моделей. Чаще всего тут закрывают базовые боли MLflow или похожим инструментом.
• Один понятный способ выкладки: отдельный сервис, batch-job или managed endpoint в облаке.
• Мониторинг инфраструктуры и качества модели. Если у вас уже есть единая наблюдаемость, сюда хорошо стыкуются подходы из OpenTelemetry.
• Kubeflow Pipelines имеет смысл рассматривать тогда, когда у вас уже много ML-пайплайнов и вы реально живёте в Kubernetes, а не просто хотите “поставить серьёзный инструмент”.

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

Когда MLOps уже нужен

• Модель уже влияет на деньги, выдачу, рекомендации, скоринг или другой продовый результат.
• Команда регулярно обучает новые версии и больше не может держать всё в ноутбуках и чатах.
• Стало трудно ответить на простые вопросы: какая версия сейчас в production, на каких данных она училась и как её откатить.
• После релиза важны не только uptime и latency, но и бизнес-метрики модели.
• В ML-процессе участвуют уже не один исследователь, а несколько ролей: ML, backend, infra, аналитика, продукт.

Если же модель пока живёт в чистом исследовании и до production ещё далеко, полноценный MLOps-слой может быть преждевременным. Сначала полезнее навести порядок в базовой инженерии, а потом уже усложнять процесс.

Типичные ошибки

• Думать, что MLOps = один инструмент вроде Kubeflow. Это подход, а не название продукта.
• Версионировать только код и забывать про данные, признаки и конфигурации.
• Считать успешный деплой доказательством качества модели.
• Не иметь model registry и нормального процесса продвижения модели между окружениями.
• Строить тяжёлую платформу раньше, чем команда научилась воспроизводимо обучать и выкатывать хотя бы одну модель.

Главное

MLOps нужен в тот момент, когда модель перестаёт быть разовым экспериментом и становится частью production-системы. Если команда умеет повторить обучение, понимает происхождение модели, безопасно выкатывает её и следит за качеством после релиза, значит MLOps у неё уже начинает работать. Если нет, почти любой рост ML-продукта быстро превратится в ручной хаос.

Если хочешь глубже понять соседние слои инфраструктуры, смотри также материалы про CI/CD, Kubernetes, GitOps и roadmap DevOps-инженера. Они помогают увидеть, на какой инфраструктурной базе MLOps обычно строится.

GitOps появился как ответ именно на эту проблему. Идея простая: желаемое состояние приложения и инфраструктуры хранится в Git, а специальный контроллер сам приводит кластер к этому состоянию. Разработчик не «деплоит руками» в Kubernetes, а меняет конфигурацию в репозитории, после чего система синхронизирует окружение с Git.

GitOps — это способ управлять конфигурацией и деплоем через Git, а не через ручные действия в кластере.

Он не заменяет CI/CD: CI собирает артефакт, а GitOps следит, чтобы среда реально пришла к состоянию из репозитория.

На практике GitOps чаще всего встречается в Kubernetes-связке с Argo CD или Flux CD, Helm и Kustomize.

Главная ценность GitOps — прозрачная история изменений, воспроизводимость и меньше ручных правок в production.

Если у команды ещё нет Docker, CI/CD, review-процесса и понятной структуры конфигурации, GitOps внедрять рано.

Если у вас ещё плавают базовые термины, лучше идти по цепочке: Git и GitHub, CI/CD, Kubernetes и Helm. Но если кластер у вас уже есть, а релизы всё ещё зависят от ручного kubectl, значит вы уже упёрлись в ту самую проблему, которую GitOps решает.

Что такое GitOps и зачем он нужен

GitOps — это способ управлять выкладкой и конфигурацией через Git. Манифесты, Helm values, Kustomize-оверлеи и другие декларативные описания лежат в репозитории, а изменения проходят через обычный процесс: commit, pull request, review и merge. После этого контроллер в кластере приводит среду к состоянию из Git.

Если говорить языком OpenGitOps и Argo CD, у вас есть desired state в Git и live state в кластере. Когда они расходятся, система показывает drift и может синхронизировать окружение обратно к версии, зафиксированной в репозитории.

• Git хранит не только код, но и манифесты, Helm chart-ы, Kustomize-конфигурации и параметры окружений.
• Изменения проходят через review и историю коммитов, а не через ручной доступ к production.
• Откат для декларативной конфигурации часто сводится к возврату предыдущего commit или merge request.
• Состояние среды становится проверяемым: то, что описано в репозитории, должно совпадать с тем, что реально запущено.

Если совсем коротко: CI/CD отвечает на вопрос «как собрать и доставить новую версию», а GitOps — на вопрос «как гарантировать, что среда реально живёт по описанию из Git».

Как работает GitOps на практике

Основная механика GitOps крутится вокруг трёх сущностей: репозиторий с желаемым состоянием, контроллер в кластере и цикл синхронизации. Разработчик меняет не сам кластер, а конфигурацию в Git. Контроллер читает репозиторий, сравнивает его с реальным состоянием и приводит окружение к нужной версии.

Git как источник истины

Проще всего думать так: Git хранит не “примерную конфигурацию”, а целевое описание среды. Если сервис должен работать с двумя репликами, конкретным образом и определёнными ingress-правилами, именно репозиторий считается источником этой правды.

Это не единственно правильная структура, но принцип один и тот же: production описан в Git, а не существует только в голове дежурного инженера или в shell history.

Контроллер и reconciliation loop

В кластере обычно работает GitOps-контроллер или стек контроллеров, например Argo CD или Flux CD. Он регулярно сравнивает репозиторий с текущим состоянием среды. Если что-то не совпадает, приложение помечается как рассинхронизированное, а дальше система либо показывает diff, либо сама подтягивает кластер к desired state из Git.

Почему это лучше ручного kubectl

Ручной деплой ломается не только из-за ошибок в YAML. Он ломается из-за неявности: непонятно, кто и когда поменял кластер, почему staging отличается от production и какой набор команд вообще был выполнен. GitOps убирает эту “устную традицию”: история изменений живёт в commit и pull request, а не в чьей-то памяти или shell history.

Самый понятный сценарий выглядит так: CI собрал образ api:1.4.2, команда поменяла тег в values-prod.yaml через pull request, после merge Argo CD подтянул новую конфигурацию в кластер. Если кто-то потом руками вернёт старый тег или изменит число реплик прямо в live-среде, контроллер увидит drift и покажет, что кластер разошёлся с Git.

Чем GitOps отличается от CI/CD

GitOps часто путают с CI/CD, потому что обе темы связаны с доставкой изменений. Но зона ответственности у них разная: CI/CD собирает и публикует артефакт, а GitOps отвечает за то, чтобы среда действительно пришла к конфигурации из Git.

• CI проверяет код: тесты, линтеры, сборка, статический анализ.
• CD публикует артефакт: image, package, release или deployment-пакет.
• GitOps управляет desired state среды: манифестами, Helm values, Kustomize-оверлеями и другими конфигурациями.
• В реальной цепочке они работают вместе: CI собрал образ, CD довёл его до registry, а GitOps синхронизировал кластер с новой конфигурацией из Git.

Поэтому фраза «GitOps заменяет CI/CD» некорректна. Типовой сценарий такой: CI собрал образ api:1.4.2, команда обновила тег в values-prod.yaml через pull request, после merge Argo CD увидел diff и применил новый релиз в кластер. Пока этот последний шаг живёт вне Git, у вас есть CI/CD, но нет управляемого desired state.

Какие инструменты чаще всего используют для GitOps

GitOps — это не конкретный продукт, а подход. Но в Kubernetes-мире есть несколько типовых инструментов, которые чаще всего закрывают эту задачу.

• Argo CD — удобный первый выбор, если нужен понятный UI, diff, sync-статусы и наглядная работа с приложениями в Kubernetes.
• Flux CD — GitOps-стек из нескольких контроллеров, который часто выбирают команды, предпочитающие максимально Git-centric и CRD-based подход.
• Helm — не GitOps-инструмент сам по себе, а упаковочный слой для релизов, с которым удобно работать GitOps-контроллеру.
• Kustomize — способ описывать вариации конфигурации без шаблонов; часто используется там, где команда хочет хранить разные окружения рядом, но без Helm chart-ов.

Для первого внедрения обычно не нужен сложный зоопарк инструментов. Достаточно одной понятной связки: например, Argo CD плюс Helm или Flux CD плюс Kustomize. Важнее не количество компонентов, а дисциплина: изменения в production идут только через Git.

Где GitOps особенно полезен, а где его рано внедрять

GitOps особенно хорошо раскрывается там, где уже есть несколько окружений, несколько сервисов и больше одного человека, который влияет на деплой. Как только конфигурация начинает жить отдельно от кода, а изменения попадают в кластер в обход review, GitOps перестаёт быть модным словом и становится способом вернуть контроль над средой.

• Уже пора: у вас есть Kubernetes, staging и production, несколько сервисов или несколько команд, а история изменений в кластере должна быть прозрачной.
• Уже пора: релизы регулярно упираются в ручной kubectl, чат-инструкции или правки values-файлов мимо pull request.
• Пока рано: если у вас ещё нет нормального контейнерного и CI/CD-фундамента.
• Пока рано: если команда пока не умеет поддерживать манифесты, Helm values и окружения в Git без хаоса и копипаста.

GitOps не чинит плохую инженерную дисциплину автоматически. Если в репозитории бардак, нет review, chart-ы размножены копированием, а secrets живут где попало, контроллер начнёт очень последовательно раскатывать этот бардак по окружениям.

Типичные ошибки при внедрении GitOps

1. Считать, что GitOps = Argo CD. Argo CD — только один из инструментов, а не весь подход целиком.
2. Пытаться внедрить GitOps до Docker, CI/CD и базовой дисциплины вокруг Git и review.
3. Хранить в Git хаотичную конфигурацию без структуры по окружениям, сервисам и зонам ответственности.
4. Смешивать сборку артефакта и управление состоянием среды в один непрозрачный pipeline.
5. Оставлять ручные hotfix-изменения в кластере без возврата их в репозиторий.
6. Думать, что GitOps отменяет мониторинг, rollback-план и нормальную эксплуатацию stateful-компонентов.

Хороший тест на зрелость простой: после инцидента вы открываете Git и видите, какая конфигурация должна быть в production. Потом возвращаете кластер к этому состоянию без ручной магии. Но важно помнить границу: GitOps хорошо откатывает декларативные ресурсы и desired state, а миграции базы, данные и внешние зависимости всё равно требуют отдельного плана.

С чего начать GitOps без лишней боли

Не надо сразу переводить на GitOps весь кластер и каждую сервисную мелочь. Нормальный старт — один сервис, одно непроизводственное окружение и очень понятный путь изменений.

1. Выберите один сервис или namespace и храните его манифесты, Helm values или Kustomize-конфигурацию в Git.
2. Подключите Argo CD или Flux CD и сначала добейтесь прозрачного diff и понятного sync-статуса, а не полной магии.
3. Зафиксируйте правило: изменения в production идут только через pull request, без ручных правок через kubectl.
4. Отдельно опишите rollback для миграций, данных и stateful-изменений: Git-rollback сам по себе не откатывает всё подряд.

Когда команда привыкнет к этой дисциплине на одном сервисе, можно переносить на GitOps другие окружения и приложения. Самый плохой сценарий — внедрять красивый термин, не меняя review-процесс, ownership и работу с конфигурацией.

Выводы

GitOps — это не магическая кнопка и не синоним CI/CD. Это способ сделать деплой и конфигурацию прозрачнее: изменения проходят через Git, состояние среды сравнивается с репозиторием, а drift, откаты и расследования становятся понятнее. Особенно хорошо это работает там, где Kubernetes уже есть, а цена ручных действий в production быстро растёт.

Если вам ещё рано, сначала доберите базу: Git и GitHub, Docker, CI/CD, Kubernetes и Helm. Если база уже есть и релизы всё ещё упираются в ручной доступ к кластеру, GitOps — логичный следующий шаг. А дальше уже можно разбираться с Argo CD и более сложными сценариями.

Для практики лучше держать рядом и официальные материалы: OpenGitOps, Argo CD и Flux CD. Они помогут не перепутать общий принцип с конкретной реализацией.

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

— Начинать стоит не с Kubernetes, а с Linux, терминала, сетей, Git и простых скриптов.

— Docker и CI/CD нужны раньше оркестрации: сначала вы делаете поставку повторяемой, потом масштабируете её.

— Для старта достаточно одного облака, одного CI-инструмента и одного стека наблюдаемости.

— Secrets, security, cost control и GitOps появляются не в конце карьеры, а после того, как у вас уже есть рабочая автоматизация.

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

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

Что входит в работу DevOps-инженера

DevOps-инженер не просто «настраивает Kubernetes». Его задача — делать путь от коммита до работающего сервиса быстрым, предсказуемым и безопасным. Это значит, что нужно уметь читать код, понимать инфраструктуру, автоматизировать рутину, наблюдать систему после релиза и быстро чинить её, когда что-то пошло не так.

На практике в работу входят пять больших зон: среда исполнения, доставка изменений, инфраструктура, эксплуатация и безопасность. Поэтому хороший план обучения всегда шире, чем набор из Docker, Kubernetes и Terraform.

• Среда исполнения: Linux, процессы, файлы, сеть, сервисы, контейнеры.
• Доставка: Git, pull request, CI/CD, артефакты, окружения, rollback.
• Инфраструктура: облако, сети, IAM, Terraform, Ansible, managed-сервисы.
• Эксплуатация: метрики, логи, трассировка, алерты, инциденты, SLA и SLO.
• Безопасность: секреты, права доступа, сканирование образов, supply chain, политики.

Шаг 1. База: Linux, терминал, сети и скрипты

Первый слой DevOps — это не облака и не кластеры. Это уверенная работа в Linux, понимание того, как живут процессы и сервисы, умение читать логи и свободно пользоваться терминалом. Если вы не понимаете, что делает systemd, чем отличается порт от сокета и почему DNS резолвится не туда, дальше будет очень много механики без понимания.

Сюда же относится базовое скриптование. Не нужно сразу становиться backend-разработчиком, но умение писать небольшие утилиты на Bash или Python на практике очень помогает: разбирать логи, чистить артефакты, собирать конфиги, запускать health-check, дёргать API. Без этого DevOps быстро превращается в бесконечное копирование команд из чужих README.

• Linux: файловая система, права, процессы, systemd, пакеты, сервисы, cron.
• Terminal: ssh, curl, grep, sed, awk, перенаправления, пайпы.
• Сети: DNS, HTTP/HTTPS, TLS, reverse proxy, firewall, балансировщик, NAT.
• Скрипты: Bash для короткой автоматизации, Python или Go для более сложных утилит.
• Результат этапа: вы можете зайти на сервер, понять, что на нём происходит, и автоматизировать простую рутину без GUI.

Для входа в этот слой пригодятся материалы 100 команд Linux для ежедневной работы и что такое Git и GitHub. Даже если ваша цель — Kubernetes, этот фундамент пропускать нельзя.

Шаг 1.2. Язык для автоматизации: Bash, Python или Go

В полной карте DevOps почти всегда есть отдельная ветка про язык программирования. Смысл не в том, чтобы срочно стать backend-разработчиком на новом стеке, а в том, чтобы уметь писать автоматизацию, разбирать данные, работать с API и не бояться внутренностей CI/CD-скриптов. Для старта почти всегда достаточно Bash и Python; позже во многих инфраструктурных командах всплывает Go, потому что на нём написано много облачных и Kubernetes-инструментов.

Лучший практический подход такой: короткие shell-скрипты и glue-логика делайте на Bash, утилиты посложнее и интеграции с API пишите на Python, а Go держите как полезный следующий слой для более серьёзной автоматизации и понимания экосистемы Kubernetes. Ruby, JavaScript или Rust тоже встречаются, но они уже зависят от конкретной команды и окружения.

• Bash нужен почти каждому DevOps-инженеру: shell-обвязка, команды, пайплайны, entrypoint-скрипты, быстрая диагностика.
• Python удобен для API-интеграций, генерации конфигов, внутренней автоматизации и небольших CLI-утилит.
• Go полезен как следующий шаг: Terraform-, Kubernetes- и cloud-экосистема часто живёт рядом с ним.
• Результат этапа: вы умеете не только запускать команды, но и собирать из них рабочую автоматизацию.

Шаг 1.5. Терминальные инструменты, редакторы и базовая диагностика

В полной карте DevOps отдельной веткой идут знание терминала, работа с текстом, мониторинг процессов и наблюдение за производительностью. Это не декоративные подпункты, а повседневный набор инженера. Нужно уметь не только открыть shell, но и быстро понять, что грузит CPU, кто держит порт, какой процесс падает, где застрял запрос и что изменилось в системе после релиза.

Сюда же относятся редакторы и инструменты для правки текста прямо на машине. Не обязательно фанатично жить в vim, но знать хотя бы один консольный редактор полезно. Если вы иногда работаете с Windows-средой, пригодится и базовый PowerShell. В некоторых командах встречаются Windows-узлы или BSD-системы, но для старта основным остаётся Linux-маршрут: сама идея одна и та же, вы умеете диагностировать систему без GUI.

• Диагностика процессов и ресурсов: ps, top, htop, lsof, ss, journalctl, free, df.
• Текст и данные: grep, sed, awk, cut, sort, uniq, jq.
• Редакторы: vim, nano, VS Code Remote или любой другой инструмент, которым вы реально можете править конфиг на сервере без паники.
• Результат этапа: вы можете диагностировать систему, править конфиг, фильтровать данные и не тонуть в логах и процессах.

Шаг 1.6. Прокси, веб-серверы, балансировка и сетевые протоколы

В полной карте навыков отдельно вынесены forward proxy, reverse proxy, firewall, load balancer, caching server и web server. Для DevOps это фундамент прикладной инфраструктуры. Даже если вы не будете администрировать почтовые системы или edge-инфраструктуру каждый день, вы должны понимать, где заканчивается приложение и начинается сетевой слой перед ним.

Минимум на старте — уверенно разбираться в DNS, HTTP/HTTPS, TLS и SSH. Полезно знать, зачем нужны Nginx, Caddy, Apache или IIS, чем reverse proxy отличается от forward proxy, как работает кеширование на уровне приложения и фронт-прокси, и что делает балансировщик перед несколькими инстансами сервиса. Если проект касается почты, пригодятся и базовые представления о SMTP, IMAP/POP3, SPF, DKIM и DMARC.

Отдельный практический навык на этом слое — troubleshooting сетевых сбоёв. Нужно хотя бы на базовом уровне понимать TCP/IP, TLS-handshake, как читать ответ curl -v, чем помогают dig, nslookup, traceroute, mtr и tcpdump. Без этого любой сбой быстро превращается в гадание между приложением, прокси, DNS и сертификатом.

• Протоколы: DNS, HTTP/HTTPS, TLS, SSH, FTP/SFTP; для почтовой инфраструктуры — SMTP, IMAP, POP3, SPF, DKIM, DMARC.
• Сетевые примитивы: OSI-модель на практическом уровне, порты, NAT, firewall rules, white- и graylisting там, где это действительно нужно.
• Серверы и прокси: Nginx, Caddy, Apache HTTP Server, Tomcat, IIS, reverse proxy, forward proxy, caching layer, load balancer.
• Результат этапа: вы понимаете, как трафик доходит до сервиса, где его можно завернуть, защитить, закешировать или распределить.

Шаг 1.7. Когда нужен Windows- и PowerShell-путь

Большая часть DevOps-маршрута действительно крутится вокруг Linux, но в реальной инфраструктуре периодически встречаются Windows-серверы, AD-среды, IIS, .NET-сервисы и корпоративная автоматизация через PowerShell. Поэтому полезно понимать, где заканчивается универсальный Linux-фундамент и начинается специфический Windows-путь.

Для первого входа в профессию не нужно строить отдельную карьеру вокруг Windows, если ваша цель — современный облачный стек. Но знать базовый PowerShell, устройство Windows-сервисов, права, scheduled tasks и особенности IIS полезно. Это даёт гибкость: вы понимаете, как жить не только в Linux-кластере, но и в смешанной корпоративной инфраструктуре.

• PowerShell пригодится там, где есть Windows-серверы, AD, IIS или корпоративная автоматизация.
• Linux остаётся основным путём для старта, но знание Windows-инструментов расширяет рынок и спектр задач.
• Если ваша цель — современный облачный стек, держите Windows как дополнительную ветку, а не как главный трек.
• Результат этапа: вы понимаете, когда PowerShell действительно нужен, а когда достаточно Linux-инструментов.

Шаг 2. Git, GitHub и командная разработка

Следующий обязательный слой — контроль версий и нормальная командная работа. DevOps живёт вокруг изменений: кто что поменял, где сломалось, как откатить, что именно уехало в релиз. Если Git для вас всё ещё сводится к git add . и git push, вы будете постоянно терять контекст.

Нужно уметь не только коммитить, но и читать diff, разбирать конфликты, работать с ветками, pull request и review. Отдельно полезно понимать, как устроены GitHub, GitLab и Bitbucket как платформы: secrets, actions или pipelines, registry, environments, protected branches, runners. Подробный разбор — в нашем полном путеводителе по Git.

• Минимум: commit, branch, merge, rebase, tags, releases, pull request.
• Командная часть: code review, правила ветвления, шаблоны PR, protected branches.
• Платформа: GitHub Actions, GitLab CI или Bitbucket Pipelines как часть экосистемы вокруг репозитория.
• Результат этапа: вы воспринимаете репозиторий как источник истины не только для кода, но и для процессов доставки.

Шаг 2.5. GitHub, GitLab и Bitbucket как платформы

Отдельная ветка в карте DevOps — это платформы вокруг репозитория. Репозиторий сегодня почти всегда живёт не в вакууме, а внутри сервиса, где рядом находятся pull request, трекинг задач, CI/CD, secrets, environments, registry, релизы и права доступа. Поэтому GitHub, GitLab и Bitbucket полезно воспринимать не просто как место для git push, а как управляющий слой вокруг разработки и доставки.

На старте не так важно, какой именно сервис вы выберете. Гораздо важнее понять общую модель: репозиторий связан с пайплайнами, секретами, защитой веток, код-ревью и артефактами. Если это уложилось в голове, переход между GitHub, GitLab и Bitbucket становится намного проще, потому что вы уже понимаете не кнопки, а саму логику платформы.

• GitHub часто удобен для старта и открытых проектов, GitLab силён как единая платформа, Bitbucket регулярно встречается в корпоративной среде.
• Общие сущности у них одни и те же: PR или MR, protected branches, runners, registry, secrets, environments, release-процесс.
• Полезный навык здесь — не “знать все вкладки”, а понимать, как VCS-платформа связывает код, review, CI/CD и доступы.
• Результат этапа: вы работаете не просто с Git, а с полноценной инженерной платформой вокруг репозитория.

Шаг 3. Контейнеры, Docker и повторяемое окружение

После Git начинается первый по-настоящему практический слой DevOps: повторяемое окружение. Здесь на сцену выходит Docker. Пока приложение нельзя одинаково запустить у разработчика, в CI и на сервере, разговоры про зрелую автоматизацию бессмысленны.

На этом этапе важно не просто уметь стартовать контейнер, а понимать, как он устроен: образ, слой, registry, volume, сеть, переменные окружения, multi-stage build. Полезно хотя бы на уровне ориентира знать, что рядом существуют и более низкоуровневые контейнерные технологии вроде LXC. Отдельный обязательный навык — собрать локальный стенд из нескольких сервисов: приложение, база данных, очередь, reverse proxy.

• Освойте Dockerfile, docker build, docker run и docker compose; как ориентир держите в голове и LXC как соседний класс технологий.
• Поймите разницу между образом, контейнером, volume, сетью и registry.
• Научитесь публиковать образы в registry и тянуть их в CI.
• Результат этапа: один и тот же сервис поднимается локально, в тестовой среде и в pipeline без разъезда зависимостей.

Шаг 4. CI/CD, артефакты и среды поставки

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

На этом этапе кроме самого pipeline нужно разобраться ещё с тремя вещами: где лежат артефакты, как устроены окружения и как делается откат. Реальный CI/CD — это не только тесты и сборка, но и публикация образа, миграции, промоушен между dev, staging и production, ручные approvals и rollback.

• Базовый набор: job, stage, runner, cache, artifacts, variables, secrets.
• Инструменты для старта: CI/CD, GitHub Actions, GitLab CI, Jenkins, а как ориентир по рынку — CircleCI, TeamCity и Octopus Deploy.
• Артефакты: registry для образов, package registry для зависимостей, release-версии.
• Результат этапа: после коммита система сама собирает, тестирует и готовит сервис к выкладке.

Если на этом этапе пропустить тему артефактов и сред, дальше начнутся типичные проблемы: в production уехал не тот образ, staging живёт отдельно от CI, а rollback зависит от памяти одного человека. Поэтому этот слой нужно довести до реальной практики, а не до уровня демо-пайплайна из трёх шагов.

Шаг 4.5. Артефакты, registry и package-хранилища

Полный DevOps-путь почти всегда упирается не только в pipeline, но и в место, где живут артефакты. Docker image, release-архив, Helm chart, внутренний пакет библиотеки — всё это должно быть версионируемым, неизменяемым и доступным для доставки в нужную среду. Поэтому управление артефактами в DevOps выделяют в отдельный слой.

На старте достаточно понимать принцип и знать несколько типовых инструментов: реестр контейнеров, пакетное хранилище, а в более зрелой среде — Artifactory, Nexus или Cloudsmith. Важна не марка продукта, а дисциплина: артефакт собирается один раз, получает версию или digest, проходит проверки и дальше только продвигается между окружениями.

• Registry и репозитории нужны для образов, пакетов, chart-ов и бинарных артефактов.
• Immutable artefact важнее названия инструмента: пересобирать один и тот же релиз под каждой средой — плохая идея.
• Проверки на этом слое: digest, SBOM, provenance, политика хранения, очистка старых версий.
• Результат этапа: вы всегда знаете, какой именно артефакт уехал в staging и production.

Шаг 5. Облака, сети, IAM и инфраструктура как код

После доставки встаёт вопрос: где всё это живёт и как этим управлять без ручного кликанья в панели облака. Здесь начинается инфраструктура как код. Нужно понимать не только Terraform и Ansible, но и сами строительные блоки: виртуальные машины, сети, балансировщики, объектные хранилища, управляемые базы данных, IAM, DNS, сертификаты и секреты.

Новички часто пытаются сразу выучить три облака, десять сервисов и все инструменты IaC. Это плохая стратегия. На старте достаточно одного облака и одной понятной связки: например, Terraform для описания ресурсов и Ansible для конфигурации машин или прикладной автоматизации поверх них.

Самый полезный первый сценарий здесь очень приземлённый: поднимите в одном облаке сеть, одну виртуальную машину, DNS-запись, сертификат, балансировщик или reverse proxy и выкатите туда свой контейнерный сервис. Если вы можете описать этот путь в Terraform, а потом воспроизвести окружение заново, слой уже перестаёт быть абстракцией.

• Terraform отвечает за ресурсы: VPC, подсети, серверы, балансировщики, DNS, managed-сервисы.
• Ansible помогает настраивать машины, пакеты, конфиги и прикладные роли после их создания.
• Обязательно понять IAM: роли, пользователи, политики, принцип наименьших привилегий.
• Освойте одно облако: AWS, GCP, Azure, DigitalOcean, Hetzner, Alibaba Cloud, Heroku, Contabo или другой провайдер, но не все сразу.
• Смотрите на стоимость с самого начала: тэги, бюджеты, права на выключение idle-ресурсов, размеры инстансов и storage lifecycle.
• Результат этапа: вы можете заново поднять окружение из кода и объяснить, кто к чему имеет доступ.

Terraform — не единственный путь. В больших облаках часто встречаются CloudFormation, AWS CDK и Pulumi: они помогают описывать инфраструктуру либо декларативно, либо через знакомый язык программирования. Полезно знать, что такие ветки существуют, но для старта одной модели достаточно: сначала понять сам принцип provisioning, а уже потом выбирать синтаксис и экосистему.

То же самое касается configuration management. В roadmap рядом с Ansible стоят Chef и Puppet — чаще они живут в старых enterprise-средах. Для новичка важно знать, что это класс инструментов для конфигурации машин и сервисов, но начинать проще с Ansible и одного облака, а не пытаться учить все подходы сразу.

Для этого слоя уже есть хороший мостик в статью как автоматизировать инфраструктуру с помощью Terraform и Ansible. Но поверх него полезно добавить ещё два практических вопроса: как хранить состояние, и как не превратить облако в свалку ресурсов без владельца и тэгов.

Шаг 6. Kubernetes, Helm и оркестрация

Как правило, после контейнеров, pipeline и базовой инфраструктуры имеет смысл переходить к Kubernetes. Иначе оркестрация будет выглядеть как стена терминов: pod, deployment, service, ingress, configmap, secret, autoscaling, statefulset. Kubernetes не заменяет Docker и CI/CD, а строится поверх них.

На этом этапе важно научиться думать не «как запустить контейнер», а «как описать приложение как систему»: сервис, конфигурация, ingress, secrets, health probes, ресурсы, rollout и rollback. Сразу после этого почти неизбежно появляется Helm, потому что вручную копировать YAML по окружениям долго и опасно.

• Kubernetes: pod, deployment, service, ingress, configmap, secret, namespace, HPA.
• Helm: chart, values, templates, releases, upgrade, rollback.
• Не пропускайте управляемые кластеры: EKS, GKE, AKS помогают понять практику без раннего героизма с self-hosted-установками.
• Результат этапа: приложение описано как релиз в кластере, а выкладка перестаёт зависеть от ручного редактирования YAML.

Здесь же стоит впервые по-настоящему заняться секретами. Если секреты лежат рядом с конфигами, например прямо в values.yaml или в переменных на одном сервере без отдельного механизма управления, система остаётся хрупкой. DevOps-маршрут без secret management и нормального доступа к конфигам всегда упирается в безопасность и аудит.

Шаг 6.5. Когда вместо Kubernetes подходят serverless и managed-платформы

В полном DevOps-roadmap рядом с Kubernetes стоят не только managed-кластеры, но и альтернативы: ECS/Fargate, Docker Swarm, AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify и другие платформы, где часть операционной сложности уже скрыта. Это важная ветка, потому что не каждому проекту нужен полноценный Kubernetes-кластер.

Практическое правило простое. Если у вас небольшой сервис, предсказуемая нагрузка и нет сложной платформенной инфраструктуры, managed-платформа или serverless могут дать более короткий путь в production. Kubernetes нужен там, где важны стандартизация, плотная оркестрация, множественные сервисы, сложные rollout-ы и контроль над платформой. Поэтому DevOps-инженеру полезно понимать и этот выбор, а не сводить всё к одной технологии.

• Managed orchestration: EKS, GKE, AKS, ECS/Fargate, Docker Swarm как разные точки на шкале контроля и сложности.
• Serverless и edge-платформы: AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify.
• Вопрос выбора: сколько платформы вы хотите администрировать сами, а сколько готовы отдать провайдеру.
• Результат этапа: вы умеете выбирать модель запуска под задачу, а не тянуть Kubernetes туда, где он не нужен.

Шаг 7. Наблюдаемость, алерты и работа с инцидентами

Многие доходят до первого деплоя и считают, что основная работа закончена. На самом деле она только начинается. Если вы умеете выкатывать сервис, но не можете понять, жив ли он, где деградирует и когда нужно будить команду, система остаётся непрозрачной. Поэтому следующий обязательный слой — наблюдаемость: метрики, логи, трассировка, алерты и операционные runbook.

Полезно научиться отвечать на четыре вопроса: что сломалось, насколько это критично, где искать причину и как быстро откатиться или стабилизировать систему. Для этого нужен не только дашборд, но и набор сигналов: технические метрики, бизнес-метрики, логи приложений, трассировка запросов, health-check и понятные пороги тревоги.

На практике здесь важно развести сигналы по ролям: метрики отвечают на вопрос «насколько плохо», логи помогают искать конкретную ошибку, трассировка показывает путь запроса через сервисы, а runbook и postmortem превращают инцидент в воспроизводимый процесс, а не в хаотичное тушение пожара.

• Метрики и дашборды: Grafana, Prometheus, SLI и SLO.
• Логи: централизованный сбор, поиск по сервисам, correlation id, retention.
• Трассировка: OpenTelemetry и распределённые traces для сложных цепочек запросов.
• Инциденты: алерты, on-call, runbook, postmortem, rollback как нормальная часть процесса.
• Результат этапа: вы не просто релизите сервис, а умеете доказуемо поддерживать его в рабочем состоянии.

Шаг 7.5. Логи, трассировка и стек наблюдаемости целиком

Чтобы покрыть карту DevOps почти полностью, важно смотреть на observability как на стек, а не на один дашборд. В инфраструктурном мониторинге часто встречаются Prometheus, Grafana, Zabbix, Datadog и New Relic. Для логов — Elastic Stack, Graylog, Splunk, Papertrail, Loki. Для трассировки и мониторинга приложений — Jaeger и OpenTelemetry. В живой работе эти слои комбинируются, а не конкурируют лоб в лоб.

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

• Практика надёжности: SLI, SLO, error budget, profiling и явные критерии деградации.
• Инфраструктурный мониторинг: Prometheus, Zabbix, Datadog, New Relic, Grafana.
• Логирование: Elastic Stack, Graylog, Splunk, Papertrail, Loki.
• Трассировка и application monitoring: Jaeger, OpenTelemetry и смежные инструменты APM.
• Результат этапа: вы понимаете, какой класс сигналов отвечает за какой тип проблем.

Шаг 7.6. Инциденты, on-call и postmortem

Полный DevOps-маршрут не заканчивается на мониторинге. Когда система падает ночью или деградирует под нагрузкой, включается incident response: кто дежурит, где лежит runbook, кто принимает решение об откате, как фиксируется таймлайн и как команда разбирает причину после восстановления. Без этого даже хороший мониторинг остаётся просто шумом в Slack.

На старте не нужно строить идеальную SRE-организацию, но полезно привыкнуть к базовой дисциплине: алерт должен вести к понятному действию, у сервиса должен быть владелец, а после серьёзного сбоя команда делает короткий postmortem с выводами и задачами. Это и есть момент, где DevOps начинает становиться зрелой эксплуатацией, а не только автоматизацией деплоя.

• On-call и escalation: кто реагирует первым, кого будить дальше и где лежат контакты.
• Runbook: короткий рабочий документ с проверками, откатом, командами и здравыми fallback-действиями.
• Postmortem: что произошло, как обнаружили, как стабилизировали, что меняем в системе, чтобы не повторилось.
• Результат этапа: аварии превращаются из хаоса в управляемый процесс восстановления.

Эту идею жёстко сформулировала Charity Majors в статье для Honeycomb, опубликованной 15 января 2026 года. Её мысль хорошо ложится на практическую часть DevOps: если у команды нет короткой обратной связи между кодом и production, то инструменты сами по себе мало что дают.

a single feedback loop connecting devs with prod.

Шаг 8. Секреты, безопасность и supply chain

Безопасность не стоит оставлять «на потом», но и пытаться учить весь DevSecOps на старте тоже не нужно. Гораздо полезнее встроить базовые практики в уже знакомую цепочку: секреты не хранятся в репозитории, доступы выдаются по ролям, образы и зависимости сканируются, а pipeline умеет остановить поставку, если в артефакте есть критическая проблема.

Сюда же относится supply chain security: кто собрал образ, откуда приехала зависимость, чем подписан артефакт, где лежит SBOM, можно ли воспроизвести релиз. Для начинающего инженера это не означает десяток экзотических продуктов. Это означает нормальную дисциплину в CI/CD, registry и правах доступа.

Кроме секретов и supply chain, здесь обязательно появляются RBAC, least privilege, ротация доступов, image signing и правила policy enforcement. На практике это означает, что не каждый сервис и не каждый человек получает админские права, а pipeline и платформа умеют останавливать небезопасные деплои ещё до production.

Полезно смотреть на безопасность не как на набор галочек, а как на threat model: где у системы слабые места, какие зависимости вы подтягиваете в образ, кто может изменить конфигурацию, откуда приходит секрет, кто имеет доступ к кластеру и как это всё проверяется. Тогда безопасность становится частью инженерного решения, а не внешним аудитом в конце.

Если нужен простой первый выбор, начинайте с нативного secret manager вашего облака или другого управляемого хранилища секретов. Поднимать Vault в учебном проекте полезно позже, когда вы уже понимаете ротацию, доступы и интеграцию с CI/CD. Для старта важнее усвоить сам принцип: секреты живут отдельно от кода и попадают в систему по контролируемому каналу.

• Секреты: KMS, Vault, cloud secret manager, Sealed Secrets — выбрать один понятный путь.
• Доступы и политика: RBAC, least privilege, ротация ключей, policy enforcement и admission checks.
• Доступы: роли вместо общих аккаунтов, least privilege, аудит действий.
• Артефакты: image scanning, dependency scanning, SBOM, подпись релизов там, где это нужно.
• Результат этапа: доставка становится не только автоматической, но и контролируемой с точки зрения риска.
• Supply chain на практике: image signing, provenance, сканирование зависимостей и контроль того, что именно уходит в production.

Шаг 9. GitOps, платформенный подход и зрелые практики

Когда контейнеры, инфраструктура, кластеры и наблюдаемость уже работают устойчиво, можно переходить к следующему уровню зрелости. Здесь появляются GitOps, декларативный деплой через ArgoCD, политики в коде, типовые шаблоны для сервисов и внутренняя платформа, которая упрощает жизнь всей команде, а не только одному DevOps-инженеру. В этой же ветке полезно знать, что кроме ArgoCD существует FluxCD, а рядом с платформенным слоем часто появляются service mesh-инструменты вроде Istio, Linkerd, Consul и Envoy.

Важно понимать, что эти практики не лечат хаос сами по себе. Если у вас ещё не собраны базовые процессы, GitOps превращается в ещё один слой сложности. Но когда фундамент готов, именно здесь начинается настоящее ускорение: Git становится источником истины для доставки, а платформа — продуктом для внутренних команд.

До первой junior-позиции обычно достаточно уверенно закрыть слои от Linux и Git до Docker, CI/CD, базовой инфраструктуры, деплоя и наблюдаемости. GitOps, платформенный подход, service mesh и глубокая стандартизация платформы чаще становятся следующей ступенью уже после реальной работы с несколькими сервисами и командами.

• GitOps нужен после устойчивого Kubernetes-процесса, а не вместо него.
• Политики в коде и типовые шаблоны полезны, когда в организации уже несколько сервисов и повторяющиеся правила.
• Платформенный подход — это следующий шаг после ручной поддержки одинаковых запросов от команд.
• Результат этапа: вы оптимизируете не только один деплой, а всю систему разработки и эксплуатации.

Шаг 9.5. Доступность, данные и FinOps-практики

В официальной карте рядом с GitOps и платформенными практиками идут cloud design patterns: availability, data management, design and implementation, management and monitoring. Это означает, что зрелый DevOps не заканчивается деплоем. Нужно думать о резервировании, отказоустойчивости, резервном копировании, восстановлении, хранении состояния, управлении квотами и стоимости платформы.

На практике сюда входят реплики и зоны доступности, стратегия backup и disaster recovery, различие между stateless и stateful-нагрузкой, контроль за ростом storage, бюджетами и неиспользуемыми ресурсами. Именно здесь DevOps начинает пересекаться с SRE, архитектурой и FinOps. Для первой работы не нужно становиться экспертом во всём сразу, но игнорировать эти темы уже нельзя. В зрелой команде FinOps — это не отдельная бухгалтерия, а часть инженерной обратной связи: сколько стоит сервис, где ресурсы простаивают и какой архитектурный выбор реально окупается.

• Availability: health-check, реплики, зоны, failover, rollback, disaster recovery.
• Data management: stateful workload, backup, restore, retention, object storage и managed database.
• Cost management: бюджеты, квоты, тэги, cleanup idle-ресурсов, размер инстансов и storage lifecycle.
• Результат этапа: вы думаете не только о запуске сервиса, но и о его цене, устойчивости и данных.

Шаг 9.6. Карьерные треки: DevOps, SRE, platform engineer, cloud engineer

Когда база уже собрана, полезно понимать, куда дальше растёт роль. DevOps-инженер чаще сильнее сидит на доставке, инфраструктуре и автоматизации; SRE делает больший акцент на надёжности, SLI/SLO и инцидентах; cloud engineer глубже уходит в облачную платформу и сервисы провайдера; platform engineer строит внутренние инструменты, шаблоны и единый путь для команд разработки.

На старте эти роли пересекаются почти полностью, поэтому учить их отдельно рано. Но как карьерная рамка это важно: вы начинаете понимать, почему один инженер копает в Kubernetes и Terraform, другой — в error budget и postmortem, а третий — во внутренний self-service для разработчиков.

• DevOps engineer: автоматизация доставки, инфраструктуры, CI/CD и операционных процессов.
• SRE: надёжность, доступность, SLI/SLO, on-call, incident response и postmortem.
• Cloud engineer: сервисы провайдера, IAM, сеть, storage, управляемые платформы и архитектурные паттерны.
• Platform engineer: внутренняя платформа, шаблоны, self-service и developer experience.

Шаг 9.7. Где в этой карте MLOps

MLOps логично стоит рядом с платформенным и облачным треком, а не вместо базового DevOps-маршрута. Сначала вам всё равно нужны Linux, Git, контейнеры, CI/CD, инфраструктура как код, наблюдаемость и безопасность. Только поверх этого появляется специфический слой машинного обучения: данные, обучение моделей, реестр моделей, feature store, воспроизводимые пайплайны и выкладка инференса.

Если говорить совсем просто, MLOps — это DevOps для систем, где кроме кода живут ещё модели и данные. Поэтому в этом треке к обычному деплою добавляются новые вопросы: как версионировать датасеты, как переобучать модель без хаоса, как проверять качество до и после релиза, как ловить drift и как откатывать не только код, но и модель.

• База та же самая: Docker, CI/CD, облака, Kubernetes, observability, secrets и права доступа.
• Специфика MLOps: versioning данных и моделей, training pipeline, model registry, feature store, offline и online evaluation.
• Инференс в production добавляет свои задачи: latency, стоимость GPU или CPU, batch и realtime-режимы, drift monitoring, rollback модели.
• Для старта это не обязательный слой каждому DevOps-инженеру, но если вы идёте в ML-команды, его стоит рассматривать как отдельную специализацию поверх крепкого DevOps-фундамента.

Что можно оставить на потом

Одна из главных ловушек DevOps — ощущение, что нужно знать вообще всё. Это не так. Есть темы, которые стоит трогать позже, когда уже есть реальная потребность: service mesh, то есть дополнительный сетевой слой между сервисами, multi-cloud, сложные self-hosted-кластеры, bare metal, внутренние PaaS, serverless на нескольких провайдерах и тонкая оптимизация FinOps.

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

• Service mesh нужен не каждому проекту и редко бывает стартовой темой.
• Multi-cloud — история про зрелую организацию, а не про первый учебный проект.
• Serverless полезно знать, но не как замену фундаменту из сетей, CI/CD и наблюдаемости.
• FinOps и оптимизация затрат раскрываются сильнее, когда у вас уже есть реальные счета и метрики нагрузки.

Практический план обучения на 6–9 месяцев

Самая рабочая стратегия — не читать про DevOps абстрактно, а вести один сервис через весь путь. Возьмите небольшое приложение, например API или веб-сервис, и усложняйте его инфраструктуру по мере роста навыков. Тогда каждый новый слой будет опираться на уже работающую систему, а не на набор разрозненных упражнений.

Какие учебные проекты реально помогают войти в DevOps

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

Лучший индикатор прогресса — не список прочитанных статей, а набор законченных проектов. Если у вас есть только конспекты, но нет сервиса, который проходит путь от коммита до мониторинга, знания быстро рассыпаются. Поэтому полезно строить обучение вокруг нескольких практических сценариев.

1. Поднять веб-приложение с базой данных через Docker Compose и опубликовать образ в registry.
2. Сделать CI-пайплайн, который тестирует проект, собирает образ и выкладывает его в staging.
3. Описать тестовую инфраструктуру через Terraform и накатить конфиг через Ansible.
4. Развернуть сервис в Kubernetes, вынести параметры в Helm и выполнить обновление с откатом.
5. Подключить Grafana и Prometheus, собрать дашборд по ошибкам и задержкам, добавить алерт на деградацию.
6. Убрать секреты из репозитория и перевести их в managed secret store или Kubernetes secrets с контролируемым доступом.

Как стать DevOps-инженером и что нужно уметь junior

Чтобы претендовать на первую DevOps-роль, не нужно знать весь рынок инструментов. Но нужно показать связный практический путь: вы умеете работать с Linux и Git, упаковывать сервис в Docker, собирать pipeline, поднимать тестовую инфраструктуру, читать метрики и не теряться при сбое. Работодатель обычно ищет не энциклопедические знания, а способность провести сервис от коммита до рабочего окружения.

Хороший junior-ready уровень выглядит так: у вас есть один или два проекта, которые можно открыть и показать. В них видно инфраструктуру, Dockerfile, pipeline, деплой, базовый мониторинг и понятные README с тем, как это запускается и как откатывается. Это намного сильнее, чем длинный список прочитанных курсов.

• Вы умеете поднять сервис локально, упаковать его в контейнер и опубликовать образ в registry.
• Вы можете настроить CI, который тестирует, собирает и публикует артефакт без ручной сборки.
• Вы понимаете базовые облачные сущности: сеть, VM, DNS, IAM, secret store, балансировщик.
• Вы можете развернуть сервис на сервере или в Kubernetes и объяснить, как его мониторить и откатывать.
• У вас есть портфолио из реального pet-проекта, а не только конспектов и скриншотов из лабораторных.

Дальше траектория обычно расходится на несколько направлений: DevOps-инженер с уклоном в доставку и инфраструктуру, SRE с акцентом на надёжность и инциденты, cloud engineer с фокусом на облачную платформу и platform engineer, который строит внутренние инструменты и шаблоны для разработчиков. На старте эти роли сильно пересекаются, поэтому базовый маршрут у них общий.

Как понять, что этап закрыт и можно идти дальше

Переход между этапами лучше проверять не ощущением «кажется, я уже почитал достаточно», а конкретными результатами. Если у вас нет практического артефакта на выходе, тема обычно ещё не закрыта. Для DevOps это особенно важно: знания быстро расслаиваются, если за ними не стоит работающий сервис, pipeline или окружение.

1. Linux и сети закрыты, когда вы можете зайти на машину по SSH, найти проблему в логах, проверить порты, DNS и сервисы без GUI-подсказок.
2. Git закрыт, когда вы спокойно работаете с ветками, pull request, конфликтами и понимаете, что именно уезжает в релиз.
3. Docker закрыт, когда ваш сервис стабильно собирается в образ, стартует вместе с зависимостями и одинаково работает локально и в CI.
4. CI/CD закрыт, когда после коммита автоматически проходят тесты, собирается артефакт, появляется версия и у вас есть понятный rollback.
5. Terraform и облако закрыты, когда вы поднимаете тестовое окружение из кода и можете заново воспроизвести его без ручного кликанья.
6. Kubernetes и Helm закрыты, когда вы выкатываете приложение в кластер, меняете конфигурацию по окружениям и обновляете релиз без редактирования YAML вручную на проде.

Как не запутаться в инструментах и не выгореть

DevOps широкий, а не линейный. Поэтому полезно думать не категориями «мне срочно нужен ещё один инструмент», а категориями «какую конкретную проблему я сейчас решаю». Если вы не умеете повторяемо запускать приложение, вам рано в service mesh и другие продвинутые сетевые надстройки. Если вы не понимаете IAM, не стоит спорить о multi-cloud-архитектуре. Если после релиза вы не видите метрик, не нужно начинать с GitOps.

Нормальный темп обучения — один слой за раз, с обязательной практикой и возвращением к предыдущим этапам. В реальной работе вы всё равно будете постоянно ходить назад: править Dockerfile после проблем в CI, улучшать Terraform после ошибок в доступах, менять алерты после неудачного инцидента. Это не откат, а нормальная сборка компетенции.

• Выберите один главный учебный сервис и не распыляйтесь на пять разных pet-проектов.
• Один инструмент на категорию лучше, чем поверхностное знакомство с тремя конкурирующими решениями.
• После каждого этапа задавайте себе вопрос: что я теперь умею делать руками, чего не умел неделю назад?
• Если новая тема не решает текущую боль, отложите её до момента, когда под неё появится практический контекст.

Выводы

План обучения DevOps работает только тогда, когда вы строите его слоями. Сначала система и сеть, потом контроль версий и контейнеры, затем CI/CD, инфраструктура и облака, после этого оркестрация, наблюдаемость, безопасность и только потом зрелые платформенные практики. Такой порядок помогает не просто выучить названия инструментов, а понять, какую проблему решает каждый из них.

Если хотите идти по этому маршруту через уже готовые материалы Tproger, используйте связку так: Git и GitHub → Docker → CI/CD → Kubernetes → Helm → GitOps → ArgoCD. Для инфраструктуры и наблюдаемости возвращайтесь к материалам про Terraform и Ansible и Grafana.

Когда дойдёте до конкретного инструмента, сверяйтесь уже с его официальной документацией: Docker, Kubernetes, Terraform, Argo CD. Так вы получите и общую картину, и правильные практические детали.

Helm нужен именно для этого. Он собирает Kubernetes-манифесты в chart, подставляет разные значения для разных окружений и даёт нормальный цикл жизни релиза: установить, обновить, откатить.

• Helm — это пакетный менеджер для Kubernetes, примерно как npm для JavaScript-проектов или apt для Linux-пакетов.
• Главная единица в Helm — chart: шаблон приложения, в котором лежат Kubernetes-манифесты, values и зависимости.
• Helm особенно полезен, когда нужно ставить одно и то же приложение в dev, staging и production с разными параметрами.
• Базовый цикл работы выглядит так: добавить репозиторий, выбрать chart, установить release, затем при необходимости обновить или откатить его.

После Docker и Kubernetes вопрос обычно уже не в том, как запустить контейнер, а как не запутаться в конфигурации приложения целиком. Вот здесь и появляется Helm.

Что такое Helm и зачем он нужен

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

Обычно Helm появляется в тот момент, когда в кластере у вас уже не один учебный Pod, а нормальное приложение: backend, PostgreSQL, ingress-nginx, Redis и ещё несколько настроек поверх. Держать такой набор манифестов вручную быстро становится тяжело, особенно если окружений несколько.

• убирает дублирование YAML между окружениями;
• позволяет параметризовать конфигурацию через values.yaml;
• устанавливает сложные приложения одной командой;
• хранит историю релизов и умеет откатывать неудачные обновления.

Если совсем коротко: Kubernetes запускает контейнеры, а Helm помогает ставить приложение в кластер как один цельный пакет.

Из чего состоит Helm: chart, release, repo и values.yaml

Чтобы дальше не путаться, достаточно держать в голове четыре термина.

Что такое Helm Chart

Chart — это пакет приложения. В нём обычно лежат шаблоны Kubernetes-манифестов, файл Chart.yaml с метаданными, файл values.yaml со значениями по умолчанию и при необходимости зависимости от других chart-ов.

Что такое Helm Release

Release — это конкретная установленная копия chart-а в кластере. Один и тот же chart можно установить несколько раз с разными именами и настройками: например, myapp-dev и myapp-prod.

Что такое Chart Repository

Chart repository — это место, откуда вы забираете готовые chart-ы. Это может быть обычный HTTP-репозиторий с индексом пакетов или OCI-реестр. Для примеров в статье достаточно Bitnami.

Что такое values.yaml в Helm

values.yaml — файл со значениями для шаблонов. За счёт него один и тот же chart можно использовать в разных окружениях: рядом с базовым values.yaml появляются values-dev.yaml и values-prod.yaml, где меняются реплики, теги образов и домены.

Но сами values ещё не показывают, куда именно они подставятся. Ниже — минимальный фрагмент шаблона Deployment, который берёт значения из .Values.

А для разных окружений значения обычно раскладывают по отдельным файлам:

Проще всего думать так: chart — это шаблон приложения, values — параметры для него, release — установленный экземпляр, repo — место, откуда этот шаблон взяли.

Как Helm работает на практике

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

После установки Helm создаёт release и раскладывает в кластер всё, что описано в chart-е. Если позже вы меняете, например, тег образа или число реплик в values-prod.yaml, релиз обновляется без ручной правки манифестов.

На практике вокруг helm upgrade и крутится большая часть работы: поменяли образ, значения или сам chart — обновили релиз. Если после этого что-то сломалось, helm rollback позволяет быстро вернуться к предыдущей версии.

Где здесь шаблоны

Внутри chart-а YAML почти всегда параметризован: количество реплик, тег образа, имена сервисов, домены. Поэтому один и тот же chart спокойно живёт и в dev, и в production.

Почему Helm — это не просто набор YAML-файлов

Голые манифесты в Git тоже работают. Проблемы начинаются позже: куски YAML дублируются, настройки между окружениями расползаются, а история конкретного релиза живёт у вас в голове. Helm хотя бы наводит в этом порядок.

Когда Helm удобнее kubectl apply, а когда нет

Helm не заменяет kubectl. kubectl работает с отдельными ресурсами, а Helm — с приложением как с пакетом.

• kubectl apply хорош, когда ресурсов мало и они почти не меняются.
• Helm удобнее, когда приложение состоит из многих манифестов и должно ставиться повторяемо.
• Kustomize часто выбирают, когда важнее патчи поверх базовых YAML, чем пакетная модель chart-ов.
• ArgoCD и другие GitOps-инструменты нередко используют Helm как источник шаблонов, а сами отвечают уже за непрерывную доставку.

Helm и ArgoCD обычно работают в связке. Helm отвечает за шаблоны и values, а ArgoCD следит, чтобы кластер действительно пришёл к состоянию из Git.

Если проводить грубую аналогию, то Docker пакует приложение, Kubernetes его запускает, а Helm приводит в порядок конфигурацию всего этого хозяйства.

Как начать работать с Helm: минимальный сценарий

Когда готовых chart-ов уже мало, следующий шаг — собрать свой. Команда helm create создаёт стартовый каркас: шаблоны, файл values.yaml и служебные метаданные.

Дальше всё довольно прозрачно: шаблоны лежат в templates/, значения — в values.yaml, а перед установкой вы можете заранее посмотреть, какой YAML Helm реально сгенерирует.

Это особенно удобно, когда нужно сравнить dev и production до деплоя: сначала смотрите итоговый YAML локально, потом уже делаете install или upgrade.

Частые ошибки новичков в Helm

• Считать Helm заменой Kubernetes. На самом деле Helm только управляет шаблонами и релизами поверх Kubernetes API.
• Смешивать секреты, production values и тестовые настройки в одном файле. Лучше разделять values по окружениям.
• Запускать upgrade без понимания, что изменилось. Перед релизом полезно рендерить шаблоны через helm template.
• Игнорировать rollback-стратегию. История релизов — одна из самых практичных возможностей Helm, ей стоит пользоваться.
• Ставить Helm туда, где достаточно пары статичных манифестов. Если приложение маленькое, лишняя абстракция может только мешать.

На pet-проекте с двумя манифестами Helm и правда может быть лишним. Но как только появляются несколько сервисов, отдельные values для окружений и регулярные релизы, без него быстро становится тесно.

Выводы

Helm полезен не как модный инструмент из DevOps-стека, а как способ перестать руками таскать за собой растущий набор Kubernetes-манифестов.

Самый полезный следующий шаг после этой статьи — не читать ещё один ликбез, а собрать маленький учебный chart руками. Сгенерируйте его через helm create, вынесите настройки в values-dev.yaml и values-prod.yaml, прогоните helm template и сделайте первый install в Minikube или kind. После этого связка с CI/CD, Kubernetes и ArgoCD уже будет восприниматься намного проще.

Для старта хватит официальной инструкции по установке Helm, базового руководства и тестового кластера в Minikube или kind. Один вечер с install, template, upgrade и rollback обычно объясняет Helm лучше любого ликбеза.

Если хотите понять, где Helm находится в общей DevOps-цепочке, посмотрите план обучения DevOps-инженера. Там Helm связан с Docker, CI/CD, Kubernetes, наблюдаемостью и следующими шагами вроде GitOps и ArgoCD.

Цель статьи — описать один из векторов атаки, который злоумышленники могут использовать для сохранения и расширения своего доступа после первичной компрометации кластера Kubernetes, получив учётные данные администратора. Она не охватывает все возможные способы, но описывает один конкретный сценарий. Надеюсь, она также поможет понять некоторые внутренние механизмы и стандартные настройки, которые злоумышленники могут использовать в своих интересах.

Общий сценарий таков: злоумышленники получают временный доступ к ноутбуку администратора кластера, который отошёл, чтобы ответить на звонок, и не заблокировал устройство. Их задача — выяснить, как получить и сохранить доступ к кластеру до возвращения администратора.

Первоначальный доступ

Первое, что, скорее всего, захочет сделать хакер, — получить root-шелл на одном из узлов кластера. Это отличная отправная точка, чтобы поискать другие учётки или подложить свои бинарники. В Kubernetes это делается элементарно, потому что есть встроенная функция kubectl debug.

Типичная команда выглядит следующим образом (только подставьте имя из вашего кластера):

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

Запуск исполняемых файлов

Получив доступ к оболочке узла, злоумышленник, скорее всего, попытается загрузить и запустить свои инструменты. Это может оказаться не так просто, поскольку многие дистрибутивы Kubernetes защищают ОС узла, монтируя файловые системы в режиме «только для чтения» или с флагом noexec. Но есть одна вещь, которую умеют выполнять узлы любого Kubernets-кластера, — запуск контейнеров! Так что если атакующий сможет загрузить на узел контейнер и запустить его на нём, то у него будет возможность выполнить любую программу.

Чтобы понять, как это сделать, давайте рассмотрим некоторые малоизвестные фичи Kubernetes. В кластере все контейнеры запускаются средой исполнения контейнеров (container runtime), обычно это containerd или CRI-O. Находясь на узле, можно взаимодействовать с этими программами напрямую, в обход API Kubernetes.

В примере ниже я создаю новый неймспейс containerd с помощью утилиты ctr. Это полезно, потому что (по моему опыту):

• ctr всегда идёт в комплекте с containerd, не нужно качать никаких сторонних клиентов;
• контейнер в отдельном неймспейсе сложнее заметить тому, кто мониторит хост.

Важно: неймспейсы containerd — это не то же самое, что неймспейсы Kubernetes или Linux.

Назовём его sys_net_mon — это не так бросается в глаза, как что-нибудь вроде «здесь-были-хакеры». Когда неймспейс готов, нужно скачать образ контейнера:

Самое интересное, что внутри этого образа нет ничего, связанного с systemd или мониторингом сети. С точки зрения безопасности важно помнить: Docker Hub не следит за содержимым неофициальных и непроверенных (unverified) образов. Кроме того, назвать свой образ можно как угодно.

Теперь воспользуемся ctr, чтобы запустить контейнер:

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

Статические манифесты

Ещё один способ, которым можно запустить контейнер на узле, — это статические манифесты. На большинстве хостов у kubelet'а есть специальная директория, из которой он автоматически подгружает статические манифесты. Поды, которые описываются такими манифестами, запускаются вообще без участия API-сервера. И тут у атакующих есть классный трюк: прописать свой статический под в несуществующем неймспейсе. Тогда он не зарегистрируется на API-сервере и не будет показываться в kubectl get pods -A или других подобных командах. Подробнее о статических подах и их особенностях в плане безопасности можно почитать в блоге Иэна Смарта.

Удалённый доступ

Следующая проблема для наших атакующих — сохранить удалённый доступ к системе после возвращения администратора. Существует множество программ для удалённого доступа, но большинство хакерских утилит легко обнаруживаются EDR/XDR-агентами, поэтому в качестве альтернативы можно использовать что-то вроде Tailscale.

У Tailscale есть несколько фич, очень полезных для атакующих (вдобавок к их обычному применению!). Первая — его можно запустить с помощью всего двух статически скомпилированных Go-бинарников, которые легко переименовать. Другими словами, можно выбрать, что будет отображаться в списке процессов на узле. В том же духе, что и с образом контейнера, воспользуемся бинарниками с именами systemd_net_mon_server и systemd_net_mon_client.

Запуск сервера:

Запуск клиента:

Что касается сети, если используется DERP-сеть Tailscale, трафик пойдёт через порт 443/TCP, а такой доступ обычно разрешен в большинстве окружений. К тому же можно использовать Tailscale'овский ACL (Access Control List, список контроля доступа), чтобы запретить «подсадному» контейнеру связываться с другими машинами в сети Tailnet злоумышленника.

Как только эти сервисы поднимутся, можно будет спокойно заходить обратно в контейнер по SSH. У Tailscale свой SSH-сервер в комплекте, так что никакой «левый» sshd не будет светиться в процессах :).

Учётные данные — API kubelet'а

После получения удалённого доступа злоумышленникам всё ещё необходимы «долгоиграющие» учётные данные. Кроме того, было бы неплохо иметь возможность «прощупывать» кластер в обход API Kubernetes, поскольку такие действия могут засветиться в журналах аудита. Для этого им нужен доступ к учётным данным пользователя, который может напрямую обращаться к API kubelet'а. Этот API работает на каждом узле на порту 10250/TCP и лишён встроенных опций аудита.

В своём докладе для этой цели я использую инструмент teisteanas, который через API запросов на подпись сертификатов (Certificiate Signing Request, CSR API) создает учётные данные в kubeconfig-формате. Так можно завести учётку для любого пользователя. Для скрытности злоумышленник, скорее всего, выберет существующего пользователя, которому уже назначены права в системе RBAC, чтобы избежать необходимости создавать новые роли кластера или привязывать роли. Конкретный выбор пользователя зависит от окружения. В своих демках я использую kube-apiserver — пользователя, существующего в кластерах GKE.

С kubeconfig-файлом и доступом к порту kubelet'а на хосте можно получать списки подов на узле или выполнять команды внутри этих подов. Проще всего это сделать с помощью утилиты kubeletctl. Таким образом, из нашего контейнера, работающего в сетевом неймспейсе узла, можно выполнить следующую команду:

CSR API

Стоит также пару слов сказать о CSR API — для атакующих это очень удобная лазейка. Этот API встроен практически во все дистрибутивы Kubernetes. Через него можно создавать учётные данные для доступа к кластеру (кроме EKS, там это не работает). Самое важное: этими учётными данными может воспользоваться любой, у кого есть доступ к API-серверу. А поскольку большинство облачных Kubernetes-решений по умолчанию «выставляет» API-сервер в интернет, атакующий с такими учётными данными сможет подключиться к кластеру откуда угодно.

CSR API также привлекателен для злоумышленников по ряду других причин:

• Если ведение журналов аудита не включено и не настроено должным образом, не остаётся никаких записей ни об использовании этого API, ни о создании учётных данных.
• Учётные данные, созданные через этот API, не могут быть отозваны без ротации корневого сертификата всего кластера, что чревато. Соответствующее Issue на GitHub, касающееся отзыва сертификатов, открыто всего лишь с 2015 года, так что в ближайшей перспективе вряд ли что изменится.
• Можно создавать учётные данные для системных аккаунтов. Поэтому даже при включённом аудите бывает сложно отличить вредоносную активность от легитимной.
• Учётные данные, как правило, долгоживущие. Конечно, срок их действия зависит от конкретного дистрибутива, но обычно он варьируется в диапазоне 1–5 лет.

В примерах для доклада я использую кластер GKE и с помощью CSR API создаю учётку для пользователя system:gke-common-webhooks, у которого довольно много прав.

Token Request API

Даже если CSR API недоступен, в Kubernetes есть и другой встроенный способ заводить новые учётки — Token Request API. Обычно он используется для создания токенов для сервисных аккаунтов, но администратор с нужными правами может адаптировать его для своих задач. Как и в случае с CSR API, никаких следов не остаётся (кроме логов аудита), и новые учётки сложно отозвать, особенно если использовался сервисный аккаунт системного уровня, ведь единственный способ — удалить сам аккаунт, к которому привязан токен.

Со сроком жизни токена тоже не всё так плохо для хакера. В зависимости от дистрибутива он может варьироваться от 24 часов до целого года (по крайней мере в тех managed-дистрибутивах, что я видел).

В докладе я использую утилиту tocan, чтобы упростить создание kubeconfig-файла из токена сервисного аккаунта.

Выбранный сервисный аккаунт очень интересен тем, что у него есть право escalate. Это означает, что он всегда может стать cluster-admin'ом, даже если у него изначально нет таких прав. (Я уже писал об escalate ранее.)

Обнаружение подобных атак

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

• Журналы аудита Kubernetes — крайне важный аспект. Необходимо, чтобы журналирование было включено, логи были централизованы и хранились достаточно долго. Это позволит выявить некоторые из описанных техник, особенно злоупотребление CSR API и Token Request API.
• Агенты на узлах — агенты безопасности на узлах кластера помогут обнаружить активность вроде трафика Tailscale (в зависимости от их настроек).
• Журналы узлов — важно обеспечить надлежащую централизацию и хранение журналов с узлов, поскольку злоумышленники могут оставлять в них следы.
• Знай свою систему — звучит просто, но это не так. Если вы знаете, какие процессы в норме работают на ваших узлах, то сможете заметить аномалии вроде systemd_net_mon. Проблема в том, что у каждого дистрибутива свой набор системных сервисов, которые запускает облачный провайдер, так что разобраться в том, что есть норма, — задача непростая.

Как защититься

Пара советов администраторам, как снизить риски такого сценария:

• Изолируйте свои кластеры от интернета! Публичный доступ к API-серверу означает, что вы находитесь в шаге от серьёзных проблем в случае утери учётных данных. Как правило, managed-дистрибутивы Kubernetes позволяют ограничить доступ, но по умолчанию такое ограничение не настроено.
• Принцип наименьших привилегий — в рассмотренном сценарии скомпрометированный ноутбук имел права уровня cluster-admin, что позволило злоумышленникам легко перемещаться по кластеру. Если бы администратор использовал учётную запись с меньшими привилегиями, атака, скорее всего, провалилась бы. Хотя некоторые из использованных прав, такие как отладка узлов, довольно распространены, другие (вроде доступа к CSR API и Token Request API) вряд ли необходимы для повседневного администрирования и могут быть отключены.

Заключение

В этой статье рассмотрен лишь один из возможных векторов, который злоумышленники могут использовать для сохранения и расширения доступа к кластеру. Очевидно, существуют и другие возможности. Надеюсь, этот материал прольёт свет на некоторые аспекты работы Kubernetes и поможет понять, как повысить безопасность кластера.

Что такое Kubernetes

Kubernetes (произносится «кубернетес», сокращённо K8s) — это система оркестрации контейнеров с открытым исходным кодом, которая автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. Kubernetes был создан компанией Google на основе внутренней системы Borg и передан в открытый доступ в 2014 году. Сегодня он управляется фондом Cloud Native Computing Foundation (CNCF).

Если Docker — это технология упаковки приложений в контейнеры, то Kubernetes — это система, которая управляет этими контейнерами в промышленном масштабе: решает, на каком сервере их запустить, следит за их здоровьем, перезапускает упавшие, масштабирует под нагрузку и обновляет без простоев.

- Kubernetes автоматизирует развёртывание, масштабирование и управление контейнерами - Основные сущности: Pod, Node, Cluster, Deployment, Service, Namespace - Архитектура делится на Control Plane (управление) и Worker Nodes (исполнение) - K8s поддерживает самовосстановление: упавший Pod перезапускается автоматически - Kubernetes подходит для больших распределённых систем; для небольших проектов достаточно Docker Compose - Минимальный старт — Minikube или kind на локальной машине за 10 минут - Облачные решения GKE, EKS, AKS берут на себя управление Control Plane - По данным CNCF на 2024 год, Kubernetes используют или оценивают более 84% организаций (CNCF 2023)

Зачем нужен Kubernetes — проблема управления контейнерами в масштабе

Контейнеры решили проблему «у меня работает, у тебя не работает» — приложение вместе со всеми зависимостями упаковывается в изолированный образ. Но с ростом количества контейнеров появляются новые проблемы.

• Высокая доступность. Если контейнер упал — его нужно перезапустить. Вручную это нереально при сотнях сервисов.
• Балансировка нагрузки. Трафик нужно распределять между несколькими экземплярами одного сервиса.
• Масштабирование. В час пик нужно быстро добавить экземпляры, ночью — убрать, чтобы сэкономить ресурсы.
• Обновления без даунтайма. Rolling update или blue-green деплой требуют координации.
• Управление конфигурацией и секретами. Переменные среды, токены, сертификаты — всё это нужно доставлять в контейнеры безопасно.
• Размещение на серверах. Решить, на каком из 50 серверов запустить очередной контейнер, учитывая доступные ресурсы CPU и памяти.

По данным CNCF, организации, использующие микросервисную архитектуру, в среднем управляют более чем 10 сервисами в продакшене, а крупные компании — тысячами. Вручную это не масштабируется. Kubernetes решает все перечисленные задачи декларативно: вы описываете желаемое состояние системы, а K8s сам приводит её к этому состоянию и поддерживает его.

Основные концепции Kubernetes

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

Pod — минимальная единица развёртывания

Pod — это один или несколько контейнеров, которые всегда запускаются вместе на одном узле и разделяют сетевое пространство (один IP-адрес) и тома хранилища. Обычно один Pod = один контейнер с основным приложением. Второй контейнер в Pod используется как sidecar: например, для сбора логов или проксирования трафика.

Node — рабочий узел кластера

Node (узел) — это физическая или виртуальная машина, на которой запускаются Pod-ы. Каждый узел содержит kubelet (агент, который следит за Pod-ами), kube-proxy (сетевые правила) и container runtime (Docker, containerd или CRI-O). В кластере обычно несколько узлов — от 3 до тысяч в крупных системах.

Cluster — совокупность всех узлов

Cluster (кластер) — это набор узлов, управляемых единым Control Plane. Весь Kubernetes работает внутри кластера. Один кластер может объединять сотни серверов в разных датацентрах.

Deployment — управление жизненным циклом приложения

Deployment — это объект, который описывает желаемое состояние для набора Pod-ов: сколько реплик должно работать, какой образ использовать, как выполнять обновления. Deployment следит за тем, чтобы нужное количество Pod-ов всегда было запущено, и управляет rolling-обновлениями.

Service — стабильная точка доступа к Pod-ам

Service — это абстракция, которая предоставляет стабильный IP-адрес и DNS-имя для набора Pod-ов. Pod-ы могут создаваться и удаляться, их IP меняется — Service обеспечивает постоянную точку входа и балансирует нагрузку между ними. Основные типы: ClusterIP (внутри кластера), NodePort (снаружи по порту узла), LoadBalancer (облачный балансировщик).

Namespace — изоляция ресурсов внутри кластера

Namespace — это виртуальный раздел внутри кластера. Позволяет изолировать ресурсы разных команд, проектов или окружений (dev, staging, production) в рамках одного кластера. По умолчанию существуют namespace-ы: default, kube-system, kube-public.

Как работает Kubernetes — архитектура изнутри

Kubernetes состоит из двух уровней: Control Plane (управляющий слой) и Worker Nodes (рабочие узлы). Разберём каждый компонент.

Control Plane — мозг кластера

• API Server (kube-apiserver) — единственная точка входа для всех операций с кластером. Все компоненты общаются только через API Server. kubectl, CI/CD системы, внутренние контроллеры — всё идёт через него. Принимает REST-запросы, валидирует их и сохраняет состояние в etcd.
• etcd — распределённое хранилище типа «ключ-значение», где хранится всё состояние кластера: конфигурации, метаданные Pod-ов, секреты. Это единственное место с состоянием в Kubernetes — если etcd жив, кластер восстановим.
• Scheduler (kube-scheduler) — отвечает за размещение новых Pod-ов на узлах. Учитывает доступные ресурсы узлов, affinity-правила, ограничения и политики. Не запускает Pod-ы сам — только решает, на каком узле их запустить.
• Controller Manager (kube-controller-manager) — набор контроллеров, каждый из которых следит за определённым типом ресурсов. Deployment Controller следит, чтобы работало нужное число реплик. Node Controller реагирует на отказ узлов. ReplicaSet Controller поддерживает заданное количество Pod-ов.

Worker Nodes — исполнители

• kubelet — агент на каждом узле. Получает от API Server описание Pod-ов, которые должны работать на этом узле, запускает их через container runtime и сообщает статус.
• kube-proxy — управляет сетевыми правилами на узле (iptables или IPVS). Обеспечивает работу Service: трафик к виртуальному IP Service перенаправляется на реальные Pod-ы.
• Container Runtime — движок для запуска контейнеров. Kubernetes поддерживает containerd (рекомендован), CRI-O и Docker Engine через специальный shim.

Типичный жизненный цикл запроса: вы применяете YAML через kubectl apply → API Server сохраняет объект в etcd → Scheduler находит подходящий узел → kubelet на том узле получает задание и запускает контейнер → Controller Manager следит, что всё работает как описано.

Kubernetes vs Docker Compose vs Docker Swarm — когда что использовать

Выбор инструмента зависит от масштаба задачи. Не стоит использовать Kubernetes там, где достаточно Docker Compose — это избыточная сложность.

• Docker Compose — идеально для локальной разработки и небольших проектов на одном сервере. Простой синтаксис, быстрый старт, нет оверхеда. Не умеет автоматически восстанавливаться при отказе хоста, не масштабируется горизонтально.
• Docker Swarm — встроенная кластеризация Docker. Проще Kubernetes, подходит для небольших кластеров (2–10 серверов), когда не нужны продвинутые возможности. Экосистема значительно меньше, развитие заморожено.
• Kubernetes — для продакшен-систем с требованиями к высокой доступности, горизонтальному масштабированию, сложным сетевым политикам и богатой экосистеме. Оправдан при наличии хотя бы 3–5 сервисов и команды DevOps.

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

Ключевые отличия в цифрах: Docker Compose запускается за секунды, Kubernetes требует минимум 3 узла для продакшена и несколько часов на начальную настройку. Зато Kubernetes поддерживает до 5000 узлов и 150 000 Pod-ов в одном кластере.

Как начать работу с Kubernetes

Для изучения и разработки не нужен облачный кластер. Есть несколько способов запустить Kubernetes локально.

Minikube — классический локальный кластер

Minikube запускает однонодовый кластер Kubernetes в виртуальной машине или контейнере. Поддерживает macOS, Linux и Windows. Встроен dashboard, поддержка нескольких профилей и дополнений.

kind — Kubernetes в Docker

kind (Kubernetes IN Docker) запускает узлы кластера как Docker-контейнеры. Быстрее Minikube, идеален для CI/CD и тестирования, поддерживает многонодовые кластеры.

Облачные управляемые сервисы

Для продакшена большинство команд выбирает управляемый Kubernetes — облачный провайдер берёт на себя Control Plane, обновления и резервирование etcd.

• GKE (Google Kubernetes Engine) — оригинальный управляемый K8s от Google. Лучшая интеграция с экосистемой Google Cloud, автопилот-режим для полностью управляемой инфраструктуры.
• EKS (Amazon Elastic Kubernetes Service) — Kubernetes на AWS. Глубокая интеграция с сервисами AWS: IAM, ALB, EBS. Самый популярный выбор среди enterprise-компаний.
• AKS (Azure Kubernetes Service) — K8s на Microsoft Azure. Хорошая интеграция с Azure Active Directory, бесплатный Control Plane.
• Yandex Managed Service for Kubernetes — российский вариант с серверами в РФ, интеграция с Yandex Cloud.

Помимо самого кластера, при работе с REST API сервисов внутри Kubernetes понадобится настроить Ingress-контроллер (nginx, Traefik) для маршрутизации внешних HTTP-запросов к нужным Service-ам.

Выводы

Kubernetes — это де-факто стандарт оркестрации контейнеров в 2024–2025 годах. По данным CNCF Annual Survey, более 84% компаний используют или оценивают K8s, а рынок контейнерной оркестрации продолжает расти двузначными темпами.

Kubernetes решает реальные проблемы масштаба: автоматическое самовосстановление, горизонтальное масштабирование, нулевой даунтайм при обновлениях, декларативное управление инфраструктурой. За это приходится платить сложностью — не стоит применять K8s там, где хватает Docker Compose.

Путь в Kubernetes начинается с понимания контейнеров, затем — знакомство с kubectl и Minikube, первые Deployment-ы и Service-ы, потом — изучение Ingress, ConfigMap, Secret, HorizontalPodAutoscaler. Это путь в несколько месяцев, но он открывает доступ к одной из самых востребованных технологий в DevOps.

Изучаете облачные технологии? Прочитайте наши статьи о микросервисной архитектуре и Docker — они помогут выстроить полную картину современной облачной разработки. Автоматизировать деплой в Kubernetes поможет CI/CD: пайплайн собирает образ, прогоняет тесты и автоматически деплоит в кластер.

Если хотите собрать Kubernetes не как отдельный страшный инструмент, а как часть цельного пути, посмотрите план обучения DevOps-инженера. Там видно, почему Kubernetes появляется после Docker, CI/CD и инфраструктуры, а не вместо них.

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

Ключевые выводы:
— fsGroup в Kubernetes рекурсивно меняет владельца всех файлов на PersistentVolume при каждом монтировании — это безопасный дефолт, который становится проблемой на больших томах.
— Параметр fsGroupChangePolicy: OnRootMismatch (доступен с K8s 1.20) проверяет только корневую директорию вместо обхода всех файлов.
— Одна строчка в манифесте сократила время рестарта Atlantis с 30 минут до 30 секунд — экономия ~600 инженерных часов в год.
— Безопасные дефолты Kubernetes рассчитаны на небольшие рабочие нагрузки. При масштабировании их стоит пересматривать.

Проблема — 30 минут на рестарт

Atlantis — это инструмент для автоматизации Terraform через pull/merge request'ы. В Cloudflare он управляет десятками проектов и работает как singleton StatefulSet в Kubernetes. Для хранения состояния репозиториев Atlantis использует PersistentVolume (PV).

Перезапуски нужны регулярно: ротация секретов, onboarding новых проектов, обновления конфигурации. С учётом примерно 100 рестартов в месяц каждый 30-минутный простой складывался в 50+ часов заблокированного инженерного времени ежемесячно. Плюс каждый рестарт триггерил алерт и будил дежурного.

Ситуация обострилась, когда на PV закончились inode'ы. Inode — это запись о файле или директории в файловой системе, и их количество фиксируется при создании ФС. Единственный способ получить больше inode'ов в их конфигурации — увеличить размер тома, а для этого нужен рестарт пода.

Расследование

Первые зацепки

После kubectl rollout restart statefulset atlantis новый под появлялся практически мгновенно, но зависал на стадии инициализации:

События пода выглядели нормально — Kubernetes успешно распределил под на ноду, скачал образ init-контейнера за доли секунды. Но между назначением на ноду и началом скачивания образа был необъяснимый промежуток в 30 минут.

Копаем глубже — логи kubelet

Событий Kubernetes было недостаточно. Инженеры обратились к логам kubelet — компонента, который на каждой ноде координирует создание подов, монтирование томов и другие операции. Поскольку kubelet работает как systemd-сервис, его логи доступны через централизованную систему (в данном случае Kibana).

В логах kubelet было видно, что PersistentVolume монтируется сразу после назначения пода. Секреты тоже монтируются без проблем. Но затем — снова провал, и в логах появляется ошибка:

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

Разгадка — fsGroup

Последней зацепкой стало имя PV. Инженеры использовали его как поисковый запрос в Kibana — и сразу нашли ключевое сообщение:

Вот в чём было дело. В spec.securityContext пода было указано fsGroup: 1. Это нужно, чтобы процессы Atlantis (запущенные не от root) имели доступ к файлам на томе. Но способ, которым Kubernetes это обеспечивает, оказался проблемой: при каждом монтировании kubelet выполняет рекурсивный chgrp по всем файлам и директориям на PersistentVolume.

А файлов к тому моменту были миллионы — команда недавно столкнулась с нехваткой inode'ов, что прямо указывало на огромное количество файлов. Рекурсивный обход миллионов записей на каждом рестарте — вот что съедало 30 минут.

Решение — одна строчка

Начиная с версии 1.20, Kubernetes поддерживает поле fsGroupChangePolicy в pod.spec.securityContext. По умолчанию оно установлено в Always — рекурсивный обход при каждом монтировании. Альтернативное значение OnRootMismatch проверяет только корневую директорию тома: если у неё уже правильная группа, рекурсивный обход не запускается.

Фикс целиком:

Важно: устанавливать OnRootMismatch стоит только если вы уверены, что ничто не меняет группу файлов на PersistentVolume извне. В случае Cloudflare инженеры проверили, что никакие процессы не модифицируют права на файлы в томе, и только после этого применили настройку.

Почему это работает

Параметр fsGroup в Kubernetes решает конкретную задачу: контейнеры, запущенные от непривилегированного пользователя, должны иметь доступ к файлам на примонтированном томе. Kubernetes обеспечивает это, выполняя chgrp -R по всему содержимому PV при каждом монтировании.

Для небольших томов с сотнями или тысячами файлов это работает незаметно. Но по мере роста данных время обхода растёт линейно. На миллионах файлов — даже на быстрых NVMe-дисках — операция занимает десятки минут.

Политика OnRootMismatch меняет логику: kubelet проверяет только корневую директорию тома. Если её группа совпадает с fsGroup, рекурсивный обход пропускается. Поскольку Atlantis сам создаёт файлы с правильной группой (она наследуется от корневой директории), проверять миллионы файлов при каждом рестарте нет необходимости.

Результат

• Время рестарта: 30 минут → 30 секунд (ускорение в 60 раз)
• Экономия: ~50 часов заблокированного инженерного времени в месяц
• В годовом исчислении: ~600 часов продуктивной работы, возвращённых команде
• Ложные алерты: дежурный инженер больше не получает пейджер на каждый рестарт
• Время на фикс: одна строчка в YAML-манифесте

Как отметили в Cloudflare: диагностика заняла больше времени, чем само исправление.

Уроки для разработчиков

1. Проверяйте дефолты при масштабировании. Безопасные настройки по умолчанию в Kubernetes рассчитаны на простые рабочие нагрузки. Когда данные растут, дефолты могут незаметно стать бутылочным горлышком.
2. Ищите не только в событиях Kubernetes. Pod events показывают не всё. Логи kubelet, метрики нод, журналы CSI-драйверов — полезные источники информации при отладке проблем с монтированием.
3. Считайте стоимость «мелких» проблем. 30 минут простоя кажутся терпимыми. 30 минут x 100 раз в месяц = 50 часов. Масштаб меняет приоритеты.
4. Аудит securityContext. Поля fsGroup, runAsUser, runAsGroup и fsGroupChangePolicy напрямую влияют на время старта подов с PersistentVolume. Если у вас большие тома — проверьте эти настройки.
5. Не всякий фикс должен быть сложным. Самые ценные исправления часто оказываются самыми простыми — но требуют глубокого понимания того, как система работает под капотом.

Частые вопросы

Что делает fsGroupChangePolicy в Kubernetes?

Параметр fsGroupChangePolicy определяет, когда Kubernetes рекурсивно обновляет группу-владельца файлов на PersistentVolume. Значение Always (по умолчанию) запускает рекурсивный chgrp при каждом монтировании. Значение OnRootMismatch выполняет обновление только если группа корневой директории не совпадает с fsGroup. Поддерживается с Kubernetes 1.20.

Безопасно ли использовать OnRootMismatch?

Если файлы на PersistentVolume создаются только процессами внутри пода (и наследуют правильную группу от корневой директории), OnRootMismatch безопасен. Но если внешние процессы или другие поды могут менять группу файлов на томе, лучше оставить значение Always и искать другие способы оптимизации.

Как узнать, влияет ли fsGroup на время старта моих подов?

Проверьте логи kubelet на ноде, где запускается под. Если в них есть сообщение "Setting volume ownership... If the volume has a lot of files then setting volume ownership could be slow", значит рекурсивный обход выполняется. Также можно сравнить время между событиями Scheduled и Started для пода — большой разрыв при наличии PV с fsGroup указывает на эту проблему.

Выводы

История Cloudflare — отличный пример того, как безопасный дефолт может превратиться в серьёзную проблему на масштабе. fsGroupChangePolicy: Always — разумная настройка для небольших томов, но на миллионах файлов она съедает минуты при каждом рестарте.

Главный урок: если что-то в вашем кластере работает медленнее, чем должно — не расширяйте окно алертов, а копайте глубже. Иногда ответ — это одна строчка YAML.

По материалам блога Cloudflare.

LiteLLM — это open-source прокси для работы с API различных LLM-провайдеров: OpenAI, Anthropic, Azure, Bedrock и ещё сотней других. Библиотека позволяет переключаться между моделями через единый интерфейс с автоматическими фоллбэками, ретраями и трекингом расходов. При 97 миллионах загрузок в месяц (около 3,4 млн в день) это один из самых популярных инструментов в AI-инфраструктуре.

В скомпрометированных версиях 1.82.7 и 1.82.8, опубликованных на PyPI, обнаружили встроенный стилер учётных данных. Он крал SSH-ключи, токены облачных сервисов, API-ключи и пароли, а затем расползался по Kubernetes-кластерам.

Ключевое: Версии LiteLLM 1.82.7 и 1.82.8 на PyPI содержали стилер, крадущий SSH-ключи, облачные токены и API-ключи. Версия 1.82.8 запускала вредоносный код при каждом старте Python — даже без импорта библиотеки. Если вы устанавливали LiteLLM 24 марта 2026 года — проверьте свои системы. Последняя чистая версия — 1.82.6.

Но эта атака — не изолированный инцидент. Это финал пятидневной supply chain атаки (атаки через цепочку поставок — внедрение вредоносного кода в легитимный пакет через компрометацию его инфраструктуры). За ней стоит группировка TeamPCP — ранее неизвестная группа, которая за последнюю неделю марта целенаправленно атаковала инструменты безопасности и разработки. Кампания началась с компрометации сканера уязвимостей Trivy и через цепочку украденных CI/CD-креденшалов дотянулась до LiteLLM.

Разбираем всю цепочку атаки от начала до конца — подробнее, чем где-либо ещё.

Хронология: пять дней, три вендора, пять экосистем

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

19 марта: Trivy — точка входа

Всё началось с Trivy — open-source сканера уязвимостей от Aqua Security, которым пользуются тысячи компаний для проверки контейнеров и кода.

Атакующие использовали скомпрометированные учётные данные мейнтейнера, чтобы:

• Опубликовать вредоносный релиз Trivy v0.69.4, который прошёл через стандартную release-машинерию и попал в GHCR, ECR Public, Docker Hub, deb/rpm-пакеты
• Подменить 76 из 77 тегов aquasecurity/trivy-action на вредоносные коммиты
• Заменить все 7 тегов aquasecurity/setup-trivy

Вредоносный код в GitHub Actions сканировал память процесса Runner.Worker, собирал креденшалы, шифровал данные AES+RSA и отправлял на подставной домен scan.aquasecurtiy[.]org — обратите внимание на опечатку в слове «security». Если прямая эксфильтрация не удавалась, малварь создавала публичный репозиторий tpcp-docs через GitHub-токен жертвы и сливала данные туда.

20–22 марта: npm-червь и дефейс

Уже на следующий день украденные токены пошли в дело. Атакующие запустили самораспространяющегося npm-червя: 28 пакетов в @EmilGroup, 16 в @opengov, плюс отдельные пакеты в других скоупах. Червь крал npm-токены из скомпрометированных окружений, проверял, к каким пакетам они дают доступ, поднимал patch-версию, подставлял оригинальный README для маскировки и переиздавал пакет с вредоносной начинкой.

К 22 марта та же инфраструктура начала обслуживать Kubernetes-скрипт с разделением жертв по геолокации. На иранских системах деплоился DaemonSet с контейнером kamikaze, который удалял файловую систему хоста и перезагружал ноду. На остальных — устанавливал персистентный бэкдор.

В тот же день атакующие дефейснули 44 репозитория внутренней GitHub-организации Aqua Security (aquasec-com), переименовав их с префиксом tpcp-docs- и описанием «TeamPCP Owns Aqua Security».

23 марта: Checkmarx

Кампания добралась до Checkmarx — ещё одного крупного вендора в сфере безопасности приложений. Были скомпрометированы:

• Checkmarx/kics-github-action — сканер инфраструктурного кода
• Checkmarx/ast-github-action — GitHub Action для платформы Checkmarx
• Расширения VS Code в реестре Open VSX: ast-results v2.53.0 (около 36 000 загрузок) и cx-dev-assist v1.7.0 (около 500 загрузок)

Паттерн тот же: стилер креденшалов, привязанный к домену checkmarx[.]zone, с фоллбэком на публичный репозиторий docs-tpcp для эксфильтрации.

24 марта: LiteLLM

В 10:52 UTC на PyPI появилась версия LiteLLM 1.82.8. Соответствующий тег или релиз на GitHub отсутствовал — пакет был загружен напрямую, в обход стандартного процесса. По данным ReversingLabs, был скомпрометирован GitHub-аккаунт сооснователя и CEO LiteLLM Криша Дхолакии — предположительно, через CI/CD-пайплайн, где Trivy использовался без пиннинга версии.

Через три часа команда безопасности PyPI поставила проект на карантин. Скомпрометированные версии были удалены. Последняя чистая версия — 1.82.6. Но при 3,4 миллионах загрузок в день даже три часа — это огромное окно.

Мейнтейнеры LiteLLM опубликовали security-апдейт, подтвердив компрометацию и рекомендовав всем пользователям обновиться до версии 1.82.6 или выше (после снятия карантина). Issue #24512 на GitHub, описывающий уязвимость, был закрыт — предположительно, самим атакующим через скомпрометированный аккаунт.

Как работает вредоносный код

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

Версия 1.82.7: инъекция в proxy_server.py

В версии 1.82.7 вредоносный код был внедрён в файл litellm/proxy/proxy_server.py. Малварь запускалась только при реальном использовании LiteLLM Proxy в приложении. Если пакет был установлен, но прокси-сервер не запускался, код мог не сработать.

Версия 1.82.8: .pth-файл — запуск без импорта

Версия 1.82.8 принципиально опаснее. В wheel-пакет был добавлен файл litellm_init.pth размером 34 628 байт, содержащий дважды закодированный в base64 вредоносный код.

.pth-файлы — малоизвестная особенность Python. Согласно документации модуля site, исполняемые строки в .pth-файлах выполняются автоматически при каждом запуске интерпретатора. Не при импорте библиотеки, а при запуске любого Python-процесса в окружении, где установлен пакет.

Это означает: достаточно было выполнить pip install litellm==1.82.8, и каждый последующий запуск Python на этой машине активировал стилер. Не нужно писать import litellm — даже python -c "print('hello')" запускал вредоносный код.

Три стадии: сбор, шифрование, эксфильтрация

Стадия 1 — сбор. Скрипт прочёсывает машину и собирает:

• SSH-ключи и конфигурации (~/.ssh/)
• .env-файлы с секретами
• Креденшалы AWS (Access Key, Secret Key), GCP (ADC), Azure
• Конфигурации Kubernetes (~/.kube/config)
• Docker-конфиги (~/.docker/config.json)
• Пароли баз данных
• Историю шелла (bash_history, zsh_history)
• Файлы криптокошельков
• Все переменные окружения
• Данные с облачных metadata-эндпоинтов (IMDS)

Стадия 2 — шифрование. Собранные данные упаковываются в tar-архив и шифруются гибридной схемой: случайный сессионный ключ AES-256-CBC для данных, зашифрованный захардкоженным 4096-битным RSA-публичным ключом.

Стадия 3 — эксфильтрация. Зашифрованный архив отправляется POST-запросом на models.litellm[.]cloud (домен не имеет отношения к настоящему litellm.ai) с заголовком X-Filename: tpcp.tar.gz.

Горизонтальное распространение в Kubernetes

Если на машине обнаружен токен сервисного аккаунта Kubernetes, малварь переходит в режим горизонтального распространения (lateral movement):

1. Читает все секреты кластера во всех неймспейсах
2. Создаёт привилегированный pod на каждой ноде в kube-system на основе образа alpine:latest
3. Каждый pod монтирует корневую файловую систему хоста
4. Устанавливает персистентный бэкдор в /root/.config/sysmon/sysmon.py
5. Регистрирует systemd user service для автозапуска

Таким образом, компрометация одного pip-пакета превращается в полную компрометацию всего Kubernetes-кластера.

Персистентность и бэкдор

На локальной машине малварь создаёт:

• ~/.config/sysmon/sysmon.py — скрипт-бэкдор
• ~/.config/systemd/user/sysmon.service — systemd unit для автозапуска

После установки бэкдор периодически обращается к https://checkmarx[.]zone/raw, скачивает файл в /tmp/pglog и выполняет его содержимое. Это даёт атакующим возможность удалённо выполнять произвольный код на скомпрометированных машинах в любой момент.

Как обнаружили: баг в малвари устроил fork-бомбу

Ирония истории в том, что атаку обнаружили благодаря ошибке самих хакеров.

Команда FutureSearch столкнулась с проблемой случайно: MCP-плагин в IDE Cursor подтянул LiteLLM как транзитивную зависимость. Вредоносный .pth-файл запускал дочерний Python-процесс через subprocess.Popen. Но поскольку .pth-файлы срабатывают при каждом запуске интерпретатора, дочерний процесс тоже запускал малварь, та порождала ещё один процесс — и так далее.

Результат — экспоненциальная fork-бомба, которая мгновенно съедала всю оперативную память и вешала систему. Без этого бага стилер мог бы работать незамеченным значительно дольше.

Мы были взломаны… тысячи людей, вероятно, прямо сейчас под атакой

Что делать, если вы затронуты

Если в ваших проектах, CI/CD-пайплайнах или на рабочих машинах устанавливался LiteLLM 24 марта или позже — проверьте версию:

Если обнаружена версия 1.82.7 или 1.82.8:

1. Удалите пакет и очистите кэши: pip cache purge, rm -rf ~/.cache/uv
2. Проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service
3. В Kubernetes: аудит kube-system на наличие подов node-setup-*, проверка секретов на несанкционированный доступ
4. Ротация всех креденшалов: SSH-ключи, облачные токены (AWS, GCP, Azure), API-ключи, пароли БД, .env-файлы
5. Сетевые логи: проверьте обращения к models.litellm[.]cloud, checkmarx[.]zone, scan.aquasecurtiy[.]org
6. Восстановление: не ограничивайтесь удалением пакета — пересобирайте системы из известных чистых образов с закреплёнными (pinned) зависимостями

На момент публикации публичных подтверждений массовой эксплуатации украденных ключей не зафиксировано, однако учитывая трёхчасовое окно и объём загрузок, число затронутых окружений может исчисляться тысячами.

Индикаторы компрометации (IoC)

Вредоносные домены:

• models.litellm[.]cloud — C2 для LiteLLM
• checkmarx[.]zone — C2, используемый для персистентности и Checkmarx-атаки
• scan.aquasecurtiy[.]org — C2 для Trivy-атаки

Файлы на диске:

• litellm_init.pth в site-packages/
• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• /tmp/pglog
• /tmp/.pg_state

Kubernetes-артефакты:

• Поды с именами node-setup-* в kube-system
• Контейнеры с именами kamikaze или provisioner

Инциденту присвоен идентификатор CVE-2026-33634. Полный список IoC в формате CSV доступен в репозитории Datadog Security Labs.

Частые вопросы

Что такое LiteLLM и зачем его используют?

LiteLLM — это open-source Python-библиотека и прокси-сервер, который предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами (OpenAI, Anthropic, Azure, AWS Bedrock и другие). Библиотека позволяет переключаться между моделями без изменения кода, автоматически обрабатывает фоллбэки и ретраи, отслеживает расходы. По данным PyPI, пакет загружается около 3,4 миллионов раз в день.

Какие версии LiteLLM скомпрометированы?

Скомпрометированы версии 1.82.7 и 1.82.8, опубликованные на PyPI 24 марта 2026 года. Обе версии удалены. Последняя безопасная версия — 1.82.6. Версия 1.82.8 опаснее: она запускает вредоносный код при каждом старте Python через механизм .pth-файлов, тогда как 1.82.7 активируется только при использовании прокси-сервера.

Как проверить, затронут ли я?

Выполните pip show litellm для проверки версии и find ~/.cache/uv -name "litellm_init.pth" для поиска вредоносного файла в кэше. Также проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes ищите поды node-setup-* в namespace kube-system.

Кто стоит за атакой?

Атака приписывается группировке TeamPCP, которая за последнюю неделю марта 2026 года провела серию supply chain атак на инструменты разработки и безопасности: сканер уязвимостей Trivy (Aqua Security), GitHub Actions и расширения VS Code от Checkmarx, npm-пакеты, и в финале — LiteLLM. Инциденту присвоен идентификатор CVE-2026-33634.

Что такое .pth-файл и почему он опасен?

Файлы с расширением .pth, размещённые в директории site-packages, автоматически обрабатываются модулем site Python при каждом запуске интерпретатора. Исполняемые строки в таких файлах выполняются без явного импорта библиотеки. В случае LiteLLM 1.82.8 файл litellm_init.pth содержал дважды закодированный в base64 вредоносный скрипт, который запускался при каждом вызове python в скомпрометированном окружении.

Выводы

Ирония инцидента — в том, что LiteLLM по определению хранит API-ключи ко всем LLM-провайдерам организации. Атакующие выбрали пакет, который гарантированно имеет доступ к самым ценным секретам.

Одна зависимость. Одна цепная реакция. Пять экосистем supply chain скомпрометированы менее чем за месяц

TeamPCP целенаправленно атаковали инструменты безопасности — сканер уязвимостей, анализатор инфраструктурного кода, прокси для LLM. Эти инструменты по своей природе имеют широкий доступ, и компрометация одного из них даёт атакующим доступ ко всем секретам, которые этот инструмент должен был защищать.

Устанавливать пакеты из публичного реестра без проверки хешей и без lock-файлов — значит фактически отдать root-доступ любому, кто сможет скомпрометировать аккаунт мейнтейнера. Как ёмко выразилась Ноэлль Мурата, старший инженер по безопасности в Xcape: «Это цифровой эквивалент того, чтобы съесть бутерброд, найденный в метро, и удивиться пищевому отравлению».

Подробный технический анализ от Datadog Security Labs доступен здесь. Оригинальный отчёт FutureSearch — здесь. Официальный security-апдейт LiteLLM — здесь.

Проверьте свои зависимости сегодня. Команды для аудита — в разделе выше.

Новые фичи, интеграции, поддержка Kubernetes и облаков сделали продукт мощнее... и заметно тяжелее. Это стало проблемой для serverless, IoT и контейнеров.

Вместо того чтобы урезать функциональность, команда решила «переломить кривую роста». За полгода (v7.60.0 → v7.68.0) им удалось сократить размер Go-бинарников до 77%.

Аудит зависимостей: минус 36 МБ одной правкой

Первый шаг — полный разбор зависимостей. С помощью go list, goda и go-size-analyzer разработчики искали пакеты, которые подтягиваются в бинарник случайно.

В одном случае trace-agent тащил 526 пакетов Kubernetes из-за одной функции, которая фактически не использовала k8s-код. Перенос ее в отдельный пакет позволил компилятору выбросить все лишнее — минус 36 МБ.

И таких случаев нашли десятки.

Разблокировка «скрытой» оптимизации линкера

Вторая находка дала еще ~20% выигрыша. В Go есть оптимизация method dead code elimination, но она отключается, если используется reflect.MethodByName с динамическими именами (например, в text/template).

Команда нашла проблемные вызовы через -dumpdep и утилиту whydeadcode, пропатчила зависимости и даже форкнула text/template, чтобы отключить динамические вызовы методов. Результат — еще минус около 100 МБ.

Удаление plugin = минус 245 МБ

Самый неожиданный эффект дал пакет plugin. Его импорт заставлял линкер сохранять все методы типов, отключая оптимизацию.

Выяснилось, что зависимость приходила через containerd, хотя агент ее не использовал. После добавления build-тега и обновления зависимостей, основной Linux amd64-бинарник «похудел» на 245 МБ.

Итог

• Security Agent: −77%
• Process Agent: −74%
• Trace Agent: −74%
• Общий .deb: 1,22 ГБ → 688 МБ

И главное — все это без удаления функций. Только системная чистка зависимостей, грамотные build-теги и возвращение оптимизаций линкера.

Почта Банк имеет широкую разветвленную сеть и работает в 83 регионах нашей страны, в том числе и в отделениях Почты России. У банка несколько миллионов клиентов, которые создают высокую нагрузку на цифровые каналы обслуживания, прежде всего на систему дистанционного банковского обслуживания (ДБО).

К 2023 году рост числа клиентов, их массовый переход в онлайн, а также запуск федеральных инициатив, включая проект «Пушкинская карта», привели к резкому увеличению нагрузки на ДБО.

В этих условиях банку потребовалась глубокая технологическая модернизация ДБО с переходом на современную микросервисную архитектуру и российский технологический стек, в частности — контейнерную платформу «Штурвал».

Сейчас система выдерживает 120 тысяч одновременных сеансов, позволяет добавлять новые сервисы не более чем за два часа и обеспечивает управление 30+ кластерами.

Задача: дать банку инструмент для управления десятками кластеров и простого масштабирования

До старта проекта банку необходимо было решить следующие задачи:

• сократить релизные циклы;
• ускорить обновления;
• автоматизировать масштабирование;
• импортозаместить инфраструктуру и ключевые компоненты ДБО;
• увеличить скорость вывода новых сервисов.

Почта Банк принял решение создать ДБО с нуля с переходом на микросервисную архитектуру, а также внедрить российскую платформу для управления контейнерной инфраструктурой на базе отечественной виртуализации и операционной системы.

В основе решения — контейнерная платформа «Штурвал», позволяющая централизованно управлять Kubernetes-кластерами, обеспечивать высокий уровень отказоустойчивости, безопасности и масштабируемости.

«Лаборатория Числитель», разработчик платформы «Штурвал», реализовала глубокую интеграцию с системой виртуализации zVirt, поддержку RedOS и встроенные механизмы безопасности. Платформа обеспечивает централизованное управление множеством кластеров из единого окна, автоматическое масштабирование и высокий уровень отказоустойчивости, что позволяет инфраструктуре расти вместе с цифровыми сервисами банка.

Параметры проекта

• Команда: 70 человек (со стороны банка и «Лаборатории Числитель»)
• Сроки: один год, проект завершился в Q3 2024 г.
• Масштаб клиента: несколько миллионов пользователей, 69% из которых используют онлайн-банкинг
• Инфраструктура: 6 продакшн-кластеров Kubernetes для ДБО, более 500 виртуальных машин, 2 ЦОДа
• Результаты: система выдерживает до 120 тысяч одновременных сеансов, на старте проекта было развернуто 3 кластера, теперь — больше 30

Почему банк выбрал «Штурвал»

Почта Банк сравнил шесть решений, включая Deckhouse Kubernetes Platform, OpenShift, Rancher, «ванильный» Kubernetes и другие. На «Штурвале» остановились из-за ряда причин:

• Архитектура для enterprise. Централизованное управление, простое масштабирование, отказоустойчивость компонентов доступных «из коробки».
• Готовые интеграции. «Штурвал» работал как с тем ПО, которое банк уже использовал, так и с тем, которое только собирался внедрить.
• Гибкие права доступа. Можно сегментировать доступы между командами разработки, инфраструктуры, DevOps и ИБ на уровне всей платформы.
• Высокий уровень безопасности. Механизмы информационной безопасности уже встроены в платформу.
• Масштабирование вместе с бизнесом. Платформа управляет десятками кластеров из одного окна. Новый кластер разворачивается за 15 минут.

Пять главных результатов для банка

• Скорость внедрения сервисов

Теперь на запуск нового сервиса требуется не более двух часов. Новый кластер можно создать за 15 минут, поэтому time-to-market сильно сократился.

• Нулевые простои

Обновления проходят без простоев, а клиенты не замечают, что в инфраструктуре что-то меняется.

• Нагрузка на команды уменьшилась в пять раз

Автоматизация рутинных задач освободила инженеров от ручной настройки. Теперь они занимаются развитием продуктов, а не поддержкой инфраструктуры.

• Система устойчива к высоким нагрузкам

Платформа выдерживает до 120 тысяч одновременных онлайн-сеансов. При этом остается запас по масштабированию в несколько раз, что очень важно для банка с миллионами клиентов.

• Полная независимость от западных вендоров

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

Сложности проекта

🔴 Проблема: внешние балансировщики с постоянно меняющимися адресами

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

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

✅ Решение: автоматическая синхронизация состояния кластера

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

Специалисты реализовали механизм автоматической синхронизации, который позволил связать внешний контур доступа с реальным состоянием кластеров. Это решение обеспечило стабильность сервисов для бизнеса без необходимости ручного вмешательства и снизило операционные риски.

🔴 Проблема: недостаточная отказоустойчивость на уровне виртуализации

Банк требовал размещения управляющих компонентов кластеров на разных физических хостах, чтобы сбой одной части инфраструктуры не приводил к остановке критичных сервисов. Но в системе zVirt отсутствовали готовые механизмы для автоматического обеспечения такого распределения.

✅ Решение: разработка компонента, контролирующего размещение управляющих серверов

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

🔴 Проблема: инсталляционная настройка десятков кластеров

После запуска платформы нужно было настроить большое количество кластеров.

✅ Решение: паттерн Apps-of-Apps

Команда использовала паттерн Apps-of-Apps для модуля непрерывной доставки приложений. Банк получил управляемую модель, где изменения вносятся быстро, предсказуемо и с контролируемыми рисками.

Не лобовая замена, а технологический апгрейд

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

Дорожная карта проекта

3Q 2023: подготовка — уточнение ТЗ, формирование команды, разработка план-графика.

4Q 2023: разработка документации, пилотное развёртывание «Штурвала», перенос 10 пилотных микросервисов на тестовый кластер.

1Q 2024: масштабирование кластера, подготовка платформы и развёртывание HA-кластера.

2Q 2024: перенос пилотных микросервисов в продакшен, старт доработки остальных 150 микросервисов.

3Q 2024: развёртывание новой платформы на RedOS, перенос пилотных сервисов.

Реклама. ООО «Лаборатория Числитель», ИНН 9731042193, erid: 2W5zFHR4LV7

В версии urllib3 2.6.0 разработчики удалили несколько API, которые считались проблемными еще с 2019 года и были официально помечены как устаревшие с 2022-го.

Все было сделано «по правилам»: предупреждения в документации, changelog, отдельные сообщения через DeprecationWarning при каждом использовании устаревших методов.

Казалось, что сигнал более чем очевидный. Но на практике это не сработало.

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

Почему предупреждения никто не заметил

Ключевая проблема в том, что DeprecationWarning в Python по умолчанию отключен. Он находится в списке предупреждений, которые интерпретатор просто игнорирует, если разработчик явно не включил их показ.

В итоге ситуация выглядела так: API годами «кричал» о своей устарелости, но его никто не слышал.

Когда методы удалили, пользователи и сопровождающие популярных библиотек — Kubernetes-клиента, Fastly, Airflow — столкнулись с поломками и неожиданными ошибками.

По словам Ларсона, обратная связь была однозначной: разработчики не видели предупреждений и не понимали, что API вот-вот исчезнет. В результате команде urllib3 пришлось срочно вернуть удаленные методы обратно и выпустить исправляющий релиз.

Предупреждение есть, эффекта нет

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

Парадокс в том, что сам механизм warnings в Python удобный и встроенный прямо в язык. Но именно DeprecationWarning оказался слишком «вежливым» — он не мешает, не ломает код и потому остается незамеченным.

Какие есть варианты выхода

Ларсон рассматривает несколько возможных путей:

• создавать собственные предупреждения на базе UserWarning, которые не игнорируются по умолчанию;
• отказаться от длительных периодов устаревания и делать более частые мажорные релизы по SemVer, как это принято в криптографических библиотеках;
• менять культуру работы с предупреждениями в Python — но это долгий и малореалистичный путь.

Что это значит для экосистемы

История с urllib3 показала: даже в зрелой и массовой экосистеме стандартные механизмы могут перестать выполнять свою функцию. DeprecationWarning задумывался как мягкий способ предупредить пользователей, но на практике он стал «мертвым письмом».

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

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

Стратегия развития: почему Kubernetes стал удалять больше, чем добавлять

Kubernetes вошёл в фазу зрелости. Новые функции появляются реже, чем исчезают старые. Анализ истории релизов показывает чёткий тренд. Если в 2020-2022 годах основной объем изменений составляли новые функции, то сейчас до 60% посвящено рефакторингу и удалению устаревшего кода.

Это естественный этап эволюции платформы. Разработчики стремятся уменьшить сложность кодовой базы и убрать компоненты, мешающие развитию.

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

Внешние облачные провайдеры: завершение пятилетней миграции

Самое значительное изменение в Kubernetes 1.31 — окончательное удаление встроенных облачных провайдеров. Этот процесс начался еще в 2019 году и теперь завершён.

Из кодовой базы Kubernetes удалили код для интеграции с AWS, Azure, Google Cloud, OpenStack и VMware vSphere. Теперь эти провайдеры работают исключительно как внешние компоненты.

Как проверить готовность кластера к миграции

Запустите команду для проверки текущего cloud-controller-manager:

Если вывод пустой или содержит только компоненты с префиксом external, ваш кластер уже готов к обновлению.

Если видите компоненты с названиями вроде aws-cloud-controller-manager в составе kube-controller-manager — требуется миграция.

Практические последствия для разных сценариев развертывания

Для managed-сервисов (EKS, AKS, GKE) изменение пройдёт незаметно. Провайдеры уже завершили миграцию.

Для кастомных кластеров потребуется установить внешний cloud-controller-manager. Например, для AWS используйте проект cloud-provider-aws.

Наибольшему риску подвержены локальные кластеры, использующие OpenStack или vSphere. Им требуется установка соответствующих внешних провайдеров до начала обновления.

Хранилище данных: стабильность вместо экспериментов

Версия 1.31 принесла несколько важных изменений в системе работы с постоянными томами. Эти улучшения касаются как базовых механизмов работы, так и возможностей по тонкой настройке томов.

Гарантированное соблюдение политик Reclaim Policy

Политика возврата томов (Reclaim Policy) теперь работает предсказуемо. Раньше существовал неприятный баг — при удалении PersistentVolume до PersistentVolumeClaim внешний ресурс в системе хранения мог не удалиться, даже при установленной политике Delete.

В Kubernetes 1.31 механизм получил финализаторы, которые гарантируют выполнение политики независимо от порядка удаления ресурсов.

Новые возможности управления производительностью томов

VolumeAttributesClass — новый API-объект для управления параметрами производительности томов (IOPS, пропускная способность) без пересоздания самого тома.

Проверьте работу этой функции в вашем CSI-драйвере. Без поддержки со стороны драйвера использование VolumeAttributesClass будет бесполезным.

Окончательный переход на CSI-драйверы для Ceph

Плагины CephFS и RBD окончательно удалены из кодовой базы Kubernetes. Попытка использовать том с типом cephfs или rbd теперь завершится ошибкой. Миграция на CSI-драйвер — единственный вариант. Процесс требует тщательного планирования, особенно для production-нагрузки.

Поэтапный план миграции с in-tree Ceph на CSI

Переход со встроенных плагинов CephFS и RBD на CSI-драйверы требует последовательного подхода. Неправильная миграция приведет к потере доступа к томам после обновления до Kubernetes 1.31.

Как перейти безопасно:

1. Разверните CSI-драйвер в параллельном режиме и убедитесь в его корректной работе с вашими томами.
2. Перенесите данные со старых томов на новые через CSI с использованием инструментов Velero или кастомных скриптов миграции.
3. Обновите манифесты приложений с указанием новых PVC после успешного переноса данных.

Полное завершение миграции на CSI-тома — обязательное условие перед обновлением до Kubernetes 1.31. Проверьте отсутствие обращений к старым томам через CephFS или RBD во всех пространствах имен кластера.

Сетевой стек: замена фундамента

Сетевые возможности Kubernetes постоянно эволюционируют. В версии 1.31 несколько ключевых улучшений сетевого стека перешли в бета-статус, что указывает на их скорый выход в стабильную версию.

nftables как будущая замена iptables

Бэкенд nftables для kube-proxy теперь включен по умолчанию в бета-версии. Это важный шаг в эволюции сетевого проксирования в Kubernetes.

nftables предлагает лучшую производительность на больших кластерах. Тесты показывают уменьшение времени обработки правил на 15-20% при количестве сервисов более 5000.

Проверка совместимости CNI-плагинов

Перед переходом на nftables убедитесь в совместимости вашего CNI-плагина. Некоторые плагины, особенно те, что активно манипулируют iptables, могут конфликтовать с nftables.

Проведите тестирование в staging-среде. Создайте нагрузку, имитирующую работу production-сервисов, и понаблюдайте за стабильностью сетевых соединений.

Улучшенная надежность Ingress-контроллеров

Функция Improved Ingress Connectivity Reliability перешла в стабильный статус. Она решает давнюю проблему — обрыв соединений при масштабировании нод.

Kube-proxy теперь корректно дренирует соединения для нод в состоянии Terminating. Это особенно важно для stateful-нагрузки, где разрыв соединений может привести к потере данных.

Требования для работы функции

Функция требует поддержки со стороны облачного балансировщика нагрузки. Балансировщик должен уметь использовать эндпоинт /livez kube-proxy, чтобы определять готовность ноды принимать новый трафик.

Проверьте документацию вашего облачного провайдера на предмет поддержки этой функции.

Безопасность: от эксперимента к production-готовности

Система безопасности Kubernetes продолжает развиваться. В версии 1.31 несколько ключевых функций безопасности достигли зрелости и готовы к использованию в production-среде.

AppArmor: переход к стабильному API

Поддержка AppArmor вышла из беты. Теперь это полноценная функция безопасности, готовая к использованию в production.

Важное изменение — переход с аннотаций на нативный API. Старый способ задания профилей через аннотации устарел и будет удален в будущих версиях.

Пример миграции на новый API

Старый подход через аннотации:

Новый подход через securityContext:

Миграция на новый API обязательна для долгосрочной поддержки.

Контроль анонимного доступа к API

С новой альфа-функцией можно точно указать, к каким эндпоинтам API возможен анонимный доступ. Раньше анонимная аутентификация была либо включена для всех эндпоинтов, либо отключена полностью.

Теперь можно разрешить анонимный доступ только к health-эндпоинтам (/healthz, /readyz, /livez), сохраняя требование аутентификации для всех остальных операций.

Пример конфигурации

Эта функция особенно полезна для кластеров, в которых требуется балансировка нагрузки без полного отключения анонимного доступа.

Узлы и планировщик: тонкая настройка производительности

Работа с вычислительными ресурсами продолжает совершенствоваться. Kubernetes 1.31 приносит улучшения в управлении ресурсами и планировании workload'ов.

cgroup v2: подготовка к переходу

Поддержка cgroup v1 переведена в режим maintenance. Это означает, что новые функции для cgroup v1 добавляться не будут, а баги будут устраняться по остаточному принципу.

Индустрия активно переходит на cgroup v2. Все основные дистрибутивы Linux уже поддерживают его по умолчанию.

Проверка готовности приложений к cgroup v2

Запустите тестовый под с ограничениями ресурсов в среде с cgroup v2. Убедитесь, что:

• приложения корректно читают свои ограничения;
• мониторинг и логирование продолжают работать;
• метрики приложений (Prometheus) отображают корректные данные.

Особое внимание уделите legacy-приложениям, способным делать прямые системные вызовы для работы с cgroup.

Мониторинг здоровья устройств

Новая альфа-функция позволяет отслеживать состояние hardware-устройств (GPU, FPGA) через статус пода. Раньше при сбое устройства под мог бесконечно перезапускаться без понятной причины.

Теперь информация о состоянии устройства доступна в kubectl describe pod:

В выводе команды появится секция с информацией о здоровье устройств.

CLI и инструментарий: взаимодействие с разработчиками улучшено

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

Переход с SPDY на WebSockets

Бэкенд для kubectl exec, kubectl attach и kubectl port-forward теперь использует WebSockets вместо устаревшего протокола SPDY. Это улучшает производительность и надежность интерактивных сессий.

Изменение обратно совместимо — kubectl автоматически откатывается на SPDY при работе со старыми версиями API-сервера.

Подход делает отладку в production-среде более безопасной и контролируемой.

Матрица совместимости: практическое руководство по проверке

Перед обновлением до Kubernetes 1.31 выполните следующие проверки.

Облачная инфраструктура:

• убедитесь, что используете внешние cloud-controller-manager;
• проверьте миграцию всех StorageClass на внешние модули подготовки;
• обновите конфигурации LoadBalancer-сервисов при необходимости.

Хранилище данных:

• завершите миграцию с CephFS/RBD in-tree на CSI-драйверы;
• протестируйте работу VolumeAttributesClass с вашим CSI-драйвером;
• убедитесь, что Reclaim Policy работает ожидаемо в тестовой среде.

Сеть:

• проверьте совместимость CNI-плагина с nftables;
• протестируйте дренирование соединений при масштабировании нод;
• обновите конфигурации NetworkPolicy при необходимости.

Безопасность:

• перенесите AppArmor-профили с аннотаций на securityContext;
• настройте политики анонимного доступа к API;
• проверьте работу PodSecurity-стандартов.

Приложения:

• протестируйте работу приложений под cgroup v2;
• проверьте мониторинг и логирование в новой версии;
• убедитесь, что инструменты оркестрации (Helm, Kustomize) совместимы

Процесс обновления: пошаговый план

Обновление production-кластера требует методичного подхода. Разделение процесса на этапы снижает риски и помогает выявить проблемы до их попадания в рабочую среду.

Подготовка (за 2-4 недели до обновления):

• начните с создания полного бэкапа кластера;
• разверните тестовый кластер версии 1.31;
• перенесите туда копии production-нагрузки.

Тестирование (1-2 недели):

• проверьте работу всех критичных сервисов;
• убедитесь в корректности мониторинга и системы оповещений;
• протестируйте процедуры аварийного восстановления.

Обновление staging-среды:

• обновите staging-кластер первым;
• наблюдайте за его работой в течение нескольких дней;
• исправьте обнаруженные проблемы.

Production-обновление:

• выполните обновление в запланированное техническое окно;
• заранее подготовьте план отката;
• мониторьте ключевые метрики в течение 24 часов после обновления.

Поэтапный подход позволяет контролировать риски на каждом этапе миграции.

Потенциальные риски и способы их минимизации

Основные проблемы при переходе на Kubernetes 1.31 связаны с удалением устаревших компонентов, а не с добавлением новых функций. Неподготовленное обновление может вызвать простои сервисов и потерю данных. Рассмотрим ключевые области риска и практические методы их предотвращения.

Несовместимость сетевых плагинов

Сетевые плагины представляют наибольшую опасность. Переход на nftables-бэкенд в kube-proxy может нарушить работу некоторых CNI-решений.

Выполните следующие проверки для минимизации рисков:

• проверьте совместимость вашего CNI-плагина с nftables в тестовой среде;
• подготовьте временное переключение на iptables-бэкенд через флаг --proxy-mode=iptables;
• протестируйте работу NetworkPolicy и сервисов типа NodePort под нагрузкой;
• сверьтесь с документацией поставщика CNI-плагина о поддержке nftables.

Проблемы с системой хранения

Изменения в работе с томами требуют особого внимания. Удаление встроенных плагинов Ceph и новые политики удаления могут затронуть критичные данные.

Чтобы обеспечить безопасность данных:

• убедитесь в работоспособности процедур восстановления из резервных копий;
• проведите тестовое восстановление томов в изолированной среде;
• завершите миграцию с CephFS/RBD на CSI-драйверы до начала обновления;
• проверьте работу VolumeAttributesClass с вашим провайдером хранилищ.

Изменения в политиках безопасности

Новые механизмы безопасности могут заблокировать рабочие процессы. Переход AppArmor на стабильный API и новые настройки анонимного доступа требуют адаптации.

Поэтапно вводите изменения в систему безопасности:

• внедряйте новые security-политики, начиная с тестовых окружений;
• перемещайте AppArmor-профили с аннотаций на поле securityContext.appArmorProfile;
• настройте политики анонимного доступа к API до обновления production-кластера;
• протестируйте работу сервисных аккаунтов и RBAC-правил в новой версии.

Дополнительные области внимания

Менее очевидные, но важные аспекты тоже требуют проверки. Совместимость инструментов мониторинга может нарушиться из-за изменения в метриках. Обновление утилит командной строки иногда приводит к смене форматов вывода.

Обратите внимание на следующие моменты:

• проверьте работу систем мониторинга после обновления тестового кластера;
• протестируйте совместимость Helm-чартов и инструментов развертывания;
• обновите утилиты kubectl и kubeadm на рабочих станциях администраторов;
• убедитесь в корректности работы пользовательских ресурсов (CRD).

Тщательная подготовка к каждому типу рисков повышает шансы на успешное обновление. Регулярное тестирование в условиях, приближенных к production, помогает выявить проблемы до их попадания в рабочую среду.

Итоги: стратегия обновления для enterprise-кластеров

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

Для крупных production-кластеров стоит увеличить срок тестирования — не менее 2-3 недель проверок в staging-среде. Не пытайтесь обновить кластер в авральном режиме. Разбейте процесс на этапы, каждый из которых должен иметь четкие критерии успеха.

Помните — в Kubernetes 1.31 изменились фундаментальные вещи, которые годами считались стабильными. Отнеситесь к обновлению ответственно, и ваш кластер получит все преимущества новой версии без потери стабильности.

1. DevOps Deflope News

DevOps Deflope News — один из самых известных русскоязычных каналов о DevOps, созданный инженерами компании «Флант». Здесь собирают только то, что действительно нужно специалистам: обновления инструментов, результаты исследований индустрии, новые интересные проекты и технологии. Авторы фильтруют десятки новостных потоков и выкладывают лишь проверенные и практически полезные материалы.

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

Подход и методология

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

Сценарии использования

Канал рассчитан на DevOps-инженеров уровня middle и выше: тех, кто хочет держать руку на пульсе инструментов и технологий. Что можно найти: идеи для интеграции CI/CD и оптимизации пайплайнов; материалы о тестировании инфраструктуры и автоматизации проверок; опыт внедрения DevOps-практик и управления командами. Контент подаётся без избыточных объяснений, поэтому даже короткий пост часто даёт инсайт, который экономит часы экспериментов.

Особенности и отличия

DevOps Deflope News выделяется тем, что сохраняет баланс между экспертностью и живостью подачи. Это сообщество специалистов, у которых есть мнение и чувство юмора. Канал связан с подкастом DevOps Deflope, где обсуждают свежие релизы и реальные кейсы внедрения DevOps в российских компаниях.

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

2. Mops DevOps

Mops DevOps — один из самых насыщенных по контенту русскоязычных каналов о DevOps, который уже много лет служит своеобразным путеводителем по экосистеме Kubernetes, Docker, Terraform и облачных технологий. Здесь собирают и систематизируют всё, что нужно инженеру: свежие релизы, обучающие статьи, подборки инструментов, ссылки на книги, вебинары и курсы. Канал живёт за счёт сообщества — контент обновляется несколько раз в неделю.

Подход и методология

Создатели канала делают ставку на системность и навигацию. Каждый пост сопровождается хэштегами по темам — от #kubernetes и #terraform до #aws, #book и #conference. Это превращает канал в удобный справочник: можно быстро найти нужный материал по конкретной технологии или инструменту. Подход к подаче — максимально утилитарный: короткие аннотации, конкретные ссылки, минимум воды. Авторы не пересказывают документацию, а делятся тем, что реально работает в продакшене.

Сценарии использования

Канал полезен тем, кто живёт в инфраструктуре. DevOps-инженеры находят здесь новые практики, примеры конфигов и инструменты для автоматизации; гайды по CI/CD и интеграции пайплайнов с кодом; советы по логированию, мониторингу и тестированию на уровне инфраструктуры.

Особенности и отличия

Главная фишка Mops DevOps — масштаб и удобство поиска. Благодаря продуманной системе тегов канал можно использовать как базу знаний: хочешь курс — открываешь #course, ищешь утилиты — идёшь в #tools, интересуешься конференциями — смотришь #conference. Контент подаётся в ровном ритме и не скатывается в поток случайных ссылок. Баланс между серьёзными статьями и лёгкими материалами выдержан — можно прочитать разбор безопасности AWS, а затем переключиться на мем про Docker.

Технические детали

Канал открыт и активно обновляется. Новые посты появляются несколько раз в неделю. Комментарии выключены. За контентом стоит команда инженеров и энтузиастов, которые делают это не ради трафика, а из интереса к профессии.

3. OrangeDevOps

OrangeDevOps — камерный, но один из самых живых русскоязычных каналов о системном администрировании и DevOps. Здесь нет вылизанных шаблонов и корпоративной редакции — всё строится вокруг опыта одного автора, инженера @il_da_r, который пишет по ходу работы: делится новыми инструментами, ссылками на статьи, наблюдениями из практики и собственными лайфхаками. Канал напоминает инженерный дневник, где полезные материалы чередуются с ироничными комментариями и находками из комьюнити.

Подход и методология

Подход к подаче — предельно неформальный, но выверенный по сути. Автор не пересказывает новости, а делится тем, что действительно пригодилось в деле: от обхода блокировок Docker Hub до настройки мониторинга через Selectel. Формат — короткие посты, часто с рабочими конфигами, YAML-фрагментами и ссылками на исходники. Каждый материал сопровождается коротким комментарием из жизни, что создаёт эффект личного общения, а не учебника.

Сценарии использования

Канал подойдёт прежде всего практикующим DevOps-инженерам и сисадминам, которые ищут конкретные решения и идеи. Здесь можно подсмотреть, как быстро настроить зеркало Docker Hub, найти сборник GitHub-репозиториев по инфраструктуре, вспомнить про бесплатные метрики в Selectel или почитать живое обсуждение собеседований.

Особенности и отличия

OrangeDevOps выделяется своей аутентичностью — это не медиа и не агрегатор, а личный инженерный журнал. Публикации идут неровно: сегодня может быть YAML-файл с инфраструктурой под Яндекс.Облако, завтра — ссылка на «взаимное собеседование в поезде» с ироничным комментарием. Канал создаёт ощущение присутствия в живом профессиональном кругу, где обсуждают не тренды, а реальные задачи.

Технические детали

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

4. DevOps&SRE Library

Канал, который стоит в закладках у каждого инженера, следящего за практиками DevOps и Site Reliability Engineering. DevOps&SRE Library — это библиотека по эксплуатации, инфраструктуре, автоматизации и наблюдаемости.Куратор канала — инженер @mxssl, известный своей любовью к чистому коду и точной подаче технического контента.

Подход и методология

Здесь публикуются только материалы, прошедшие фильтр технической ценности — руководства, блоги компаний, репозитории и статьи от экспертов. Каждый пост оформлен в едином лаконичном формате: краткое описание и ссылка на первоисточник. Такой подход экономит время и помогает быстро понять, стоит ли углубляться в тему.

Сценарии использования

DevOps&SRE Library подойдёт инженерам, архитекторам и техническим лидам, которые хотят оставаться в контексте инфраструктурных практик. Это место, где можно найти проверенные материалы о Kubernetes, CI/CD, миграциях баз данных, наблюдаемости, Terraform и автоматизации с элементами AI. Канал станет хорошим источником для составления внутренней библиотеки ссылок в команде или подготовки к архитектурным интервью.

Особенности и отличия

Главная особенность — высокий порог качества. Контент здесь напрямую ведёт к источникам знаний: официальным блогам, исследовательским материалам и репозиториям. Канал не перегружен комментариями, но создаёт ощущение спокойного, академичного пространства, где инженер учится думать системно. DevOps&SRE Library — это скорее инструмент самообразования, чем информационный поток.

Технические детали

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

По данным, поданным в Комиссию по ценным бумагам и биржам США (SEC), злоумышленникам удалось похитить исходный код флагманской платформы BIG-IP и документы с описанием нераскрытых уязвимостей.

Атака была обнаружена 9 августа 2025 года, однако властям США позволили компании временно не разглашать детали, чтобы не помешать расследованию.

Что известно о взломе

По данным F5, киберпреступники, предположительно связанные с «государственными структурами», длительное время сохраняли доступ к сегменту сети, связанному с разработкой и распространением обновлений BIG-IP.

Эти устройства используются 48 из 50 крупнейших корпораций мира для управления интернет-трафиком и защиты приложений.

Известно, что хакеры похитили часть файлов, включая:

• исходные коды отдельных модулей BIG-IP;
• данные о частных, еще не исправленных уязвимостях;
• конфигурации и сведения о внедрении решений у «небольшого процента клиентов».

F5 утверждает, что нет доказательств вмешательства в цепочку поставок ПО — исходники и сборочные конвейеры остались нетронутыми, а продукты NGINX, Silverline и F5 Distributed Cloud не пострадали.

Реакция компании

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

Обновления уже доступны для BIG-IP, F5OS, BIG-IP Next для Kubernetes, BIG-IQ и APM-клиентов.

Компания также опубликовала руководство по защите инфраструктуры, включая рекомендации:

• включить потоковую передачу событий BIG-IP в SIEM;
• настроить удаленные syslog-сервера;
• отслеживать неудачные входы и изменения привилегий.

Что говорят эксперты

Инцидент стал ударом по репутации F5, поставщика решений для защиты корпоративных сетей.

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

Я проанализировала около 60 образовательных программ и выделила более 48 самых эффективных, включая платные и бесплатные варианты. В статье вы найдете топ-10 курсов для уверенного старта, расширенный список из 12 продвинутых программ, подборку из 15 курсов по DevOps и 11 бесплатных ресурсов для начала изучения и первичного погружения в Kubernetes.

Я также нашла для вас эксклюзивные промокоды на некоторые курсы — все подробности уже доступны в статье!

ТОП-10 лучших курсов Kubernetes в 2026 году

1. Инфраструктурная платформа на основе Kubernetes от Skillbox.ru — developer-платформа с подготовкой к CKA и ментором-практиком.
2. Kubernetes и Helm от PurpleSchool — бесплатный старт обучения с AI-помощником и рекомендательным письмом от основателя студии для карьерного роста.
3. Инфраструктурная платформа на основе Kubernetes от OTUS.ru — доступ к Yandex Cloud и размещение резюме у партнеров-работодателей.
4. Kubernetes для разработчиков от Слерм — полный цикл разработки в Kubernetes с фокусом на практику и двумя курсами по Docker в подарок.
5. Безопасность в Kubernetes от OTUS.ru — защита кластера с eBPF и Vault при поддержке в трудоустройстве от партнеров OTUS.
6. Kubernetes База от Слерм — администрирование Kubernetes с интеграцией Ceph и CI-процессов, курсами по Docker и Ansible в подарок.
7. DevOps-инженер от Нетологии — полный стек DevOps с мобильным приложением для учебы и стажировкой на проектах Yandex Cloud.
8. Безопасность в Kubernetes от Слерм — навыки профессиональной защиты данных и демодоступ для начала обучения.
9. Системный администратор от Нетологии — отличная подготовка сисадминов и SRE-инженеров с проектной работой.
10. Kubernetes. Практикум от Level UP — освоение Kubernetes с индивидуальным подходом и автоматической проверкой заданий.

Обучение Kubernetes станет стратегическим шагом для DevOps-инженеров, стремящихся к полному контролю над жизненным циклом приложений. Оно также откроет новые горизонты для backend-разработчиков, желающих глубже понимать среду, в которой работают их сервисы. Кроме того, этот путь подойдет тем системным администраторам, которые хотят перенести навыки в современную облачную эпоху и работать с инфраструктурой как с кодом.

Онлайн-курсы Kubernetes

1. Инфраструктурная платформа на основе Kubernetes | Skillbox.ru

Используйте промокод kursfinder, чтобы получить скидку 50%

Применить промокод>>>

Курс предлагает глубокое погружение в инженерные практики разработки внутренней developer-платформы. В рамках обучения вы освоите управление кластерами с гетерогенной микросервисной архитектурой, а также научитесь эффективно управлять репликацией и строить конвейеры сборки. Курс также подготовит вас к сертификации CKA, обеспечив знания, необходимые для работы с Kubernetes в производственных средах. Вы изучите deployment-паттерны для обеспечения стабильности и масштабируемости в продакшн-окружениях.

• Стоимость: 56 796 рублей
• Длительность: 1 месяц
• Формат обучения: видеолекции, практические задания и тестирования
• Сертификат: сертификат о повышении квалификации

Кому подойдет:

• системным администраторам;
• DevOps-инженерам;
• разработчикам.

Преимущества:

• подготовка к экзамену CKA с нуля;
• ментор — практикующий сертифицированный администратор;
• реальный кейс для вашего портфолио;
• пожизненный доступ ко всем учебным материалам;
• оперативная помощь от технических специалистов;
• удобная рассрочка без переплат;
• налоговый вычет как возврат части стоимости;
• бонус — годовое обучение английскому;
• персональная консультация по карьере;
• активное комьюнити для нетворкинга.

Недостатки:

• отсутствие менторской поддержки после выпуска;
• ограниченное количество мест.

Программа обучения:

• Архитектура: от нод до control plane’а
• Объекты: поды, деплойменты, сервисы
• Безопасность: RBAC, сервисные аккаунты
• Сети: ingress-контроллеры и политики
• Хранение: персистентные тома и их типы
• Шаблонизация: Helm-чарты и Kustomize
• Автомасштабирование: HPA и VPA
• Мониторинг: счетчики, метрики, дашборды
• Service Mesh: основы Istio и Envoy
• CI/CD: пайплайны внутри кластера
• Эксплуатация: обновления и обслуживание

Ознакомиться с полной программой >>>

2. Kubernetes и Helm | PurpleSchool

В ходе обучения будет освоен YAML-синтаксис, а также принципы работы с основными объектами Kubernetes: Pod, Deployment, Services, ConfigMap. Участники курса смогут деплоить полнофункциональные приложения в кластер, настраивать сетевые взаимодействия и системы хранения данных, а также обеспечивать защиту конфиденциальной информации. В программе также предусмотрено освоение создания Helm-чартов, управления версиями приложений через Helm и работы с Helm-репозиториями, что позволит выпускникам уверенно управлять жизненным циклом приложений в Kubernetes.

• Стоимость: 3 999 рублей
• Длительность: около 1 месяца
• Формат обучения: видео, конспекты, упражнения, тесты
• Сертификат: сертификат о повышении квалификации

Кому подойдет:

• тем, кто знает основы Linux, а также Docker;
• backend-разработчикам;
• системным администраторам.

Преимущества:

• бесплатный старт обучения с возможностью сразу приступить к занятиям;
• возврат средств в течение 30 дней при несоответствии ожиданиям;
• пожизненный доступ к материалам для повторения уроков в любое время;
• бонус 300 рублей за регистрацию в качестве подарка новым студентам;
• короткие видеоуроки для обучения в перерывах при плотном графике;
• проверка проектов напрямую из GitHub через удобную интеграцию;
• мгновенный разбор ошибок от AI-помощника с оперативной поддержкой;
• рекомендательное письмо от основателя студии для карьерного роста.

Недостатки:

• не для новичков.

Программа обучения:

• Настройка рабочего окружения с подготовкой к дальнейшей работе
• Создание и запуск первого pod на практических примерах
• Эксплуатация и обслуживание кластера в ходе ежедневных операций
• Основы создания шаблонов chart с автоматизацией развертывания
• Работа с репозиториями chart через хранение и распространение пакетов
• Использование сторонних chart в проектах с применением готовых решений

Ознакомиться с полной программой >>>

3. Инфраструктурная платформа на основе Kubernetes | OTUS.ru

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

• Стоимость: 130 000
• Длительность: 3 месяца
• Формат обучения: вебинары, сдача домашних работ и получение обратной связи от преподавателя
• Сертификат: сертификация от CNCF: CKA и CKAD

Кому подойдет:

• DevOps-инженерам и системным администраторам;
• разработчикам ПО;
• техническим руководителям и архитекторам ПО.

Преимущества:

• подготовительный видеокурс по Linux при покупке основного курса;
• Yandex Cloud предоставляет бесплатные мощности для практических заданий;
• размещение вашего профиля в базе OTUS для потенциальных работодателей;
• снижение стоимости при успешной сдаче вступительного тестирования;
• бесплатные ресурсы для выполнения всех лабораторных работ;
• помощь в составлении и оформлении резюме;
• возврат средств при несоответствии обучения ожиданиям.

Недостатки:

• необходимо ждать начала обучения.

Программа обучения:

• Знакомство с Kubernetes, основными понятиями и компонентами
• Изучение сетевой подсистемы и сущностей Kubernetes
• Работа с томами, системами хранения и Stateful-приложениями
• Основы защиты и управления доступом в кластере
• Обзор контейнерных сред выполнения CRI
• Анализ существующих решений CNI для Kubernetes
• Изучение подсистем хранения данных CSI
• Отладка кластера и приложений в рабочем окружении
• Варианты создания кластера: Hard way, kubespray, rancher и аналоги

Ознакомиться с полной программой >>>

4. Kubernetes для разработчиков | Слерм

Слушатели изучат процессы конфигурирования приложений для работы в кластере, а также научатся строить CI/CD-пайплайны для автоматизации развертывания и тестирования. Программа курса включает настройку локальной среды разработки с использованием Minikube, что позволит создавать и тестировать приложения на персональных устройствах. Особое внимание уделяется архитектуре основных компонентов Kubernetes-кластера и принципам их взаимодействия. В рамках обучения рассматривается использование Job и CronJob для эффективного выполнения разовых и периодических задач.

• Стоимость: от 45 000 рублей
• Длительность: 7 недель
• Формат обучения: видеолекции, практические занятия, живое общение с преподавателями
• Сертификат: сертификат о повышении квалификации

Кому подойдет:

• разработчикам;
• новичкам.

Преимущества:

• 79% обучения составляет практическая работа со стендами;
• бесплатный подготовительный видеокурс по Docker при покупке основного курса;
• двухлетний доступ ко всем обучающим материалам после завершения программы;
• множество реальных заданий и проектов в процессе обучения;
• специальные условия для организаций и группового обучения;
• выгодные комплекты программ для комплексного образования.

Недостатки:

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

Программа обучения:

• Базовые принципы и концепции Kubernetes
• Основные объекты для описания приложений
• Организация постоянного хранения в кластере
• Настройка сетевых взаимодействий и сервисов
• Внутреннее устройство и компоненты кластера
• Выполнение одноразовых задач через Jobs и CronJobs
• Система авторизации и аутентификации в кластере
• Методы диагностики и решения проблем в приложениях
• Среда организация разработки приложений в Kubernetes
• Настройка процессов непрерывной интеграции и поставки

Ознакомиться с полной программой >>>

5. Безопасность в Kubernetes | OTUS.ru

В программе рассматриваются методы реализации расширенных политик доступа, работа с секретами через HashiCorp Vault, а также методы hardening образов и внедрение стандартов безопасности для Pod. Курс охватывает применение политик admission через OPA Gatekeeper и Kyverno, защиту сети с помощью сетевых политик и сервис-мешей, а также настройку систем мониторинга и логирования. Кроме того, слушатели изучат работу с инструментами eBPF для анализа и разработку стратегий безопасности на основе Zero Trust, Multi-tenancy, Policy-as-Code и GitOps.

• Стоимость: 80 000 рублей
• Длительность: 4 месяца
• Формат обучения: вебинары, сдача домашних работ и получение обратной связи от преподавателя
• Сертификат: сертификат о повышении квалификации

Кому подойдет:

• DevOps-инженерам и администраторам;
• специалистам и инженерам информационной безопасности;
• разработчикам и инженерам по микросервисам;
• архитекторам решений и техническим руководителям.

Преимущества:

• ваш профиль становится доступен компаниям партнерам OTUS;
• снижение цены курса после успешного прохождения вступительного теста;
• просмотр записей занятий в случае пропуска;
• профессиональная помощь в создании эффективного резюме;
• возможность вернуть деньги, если курс не оправдает ожиданий.

Недостатки:

• не всем подойдет установленное расписание занятий.

Программа обучения:

• Базовые принципы безопасности в Kubernetes
• Обеспечение безопасности узлов и контейнеров
• Настройка сети мониторинга и CI/CD процессов
• Практическое тестирование на проникновение и демонстрация атак
• Разработка комплексных мер безопасности для Kubernetes
• Самостоятельная работа над реальным кейсом безопасности

Ознакомиться с полной программой >>>

6. Kubernetes База | Слерм

Слушатели получают глубокое понимание внутреннего устройства кластера и функциональности его основных компонентов. Они осваивают навыки настройки и оптимизации кластера, деплоя приложений, а также работы с сетевыми абстракциями. Также программа включает работу с интеграцией систем хранения на базе Ceph и настройку CI-процессов, что позволяет эффективно управлять инфраструктурой и автоматизировать процессы развертывания.

• Стоимость: от 50 000 рублей
• Длительность: 6 недель
• Формат обучения: видеоуроки, практические задания
• Сертификат: сертификат о повышении квалификации или свидетельство

Кому подойдет:

• системным администраторам;
• DevOps-инженерам.

Преимущества:

• бесплатные подготовительные курсы по Docker и Ansible;
• большое количество реальных задач и лабораторных работ;
• возможность оплаты частями без первоначального взноса;
• специальные программы обучения для организаций;
• выгодные наборы курсов со скидкой;
• бесплатная профессиональная консультация перед обучением.

Недостатки:

• необходимость базовых знаний в IT и DevOps.

Программа обучения:

• Основные компоненты и архитектура Kubernetes
• Отказоустойчивость сеть и внутреннее устройство системы
• Настройка и тонкая настройка кластера через Kubespray
• Продвинутые объекты и методы управления в Kubernetes
• Организация разрешения имен и публикация сервисов
• Введение в пакетный менеджер и работу с чартами
• Приложения особенности работы с stateful приложениями
• Установка и настройка cert manager для сертификатов
• Итоговая практическая работа для проверки знаний

Ознакомиться с полной программой >>>

7. DevOps-инженер | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

Программа обучения охватывает развертывание и администрирование кластеров Kubernetes, включая запуск контейнеров в Docker Compose и балансировку нагрузки в Docker Swarm. В рамках курса слушатели освоят автоматизацию серверных задач с помощью скриптов на Golang для Terraform, а также настройку веб-серверов в виртуальных машинах с использованием Ansible. Программа включает создание пайплайнов для проектов в GitLab CI, управление задачами через GitLab Issues, а также организацию работы с облачными провайдерами, в частности на платформе Yandex Cloud, что поможет в эффективном управлении инфраструктурой и проектами.

• Стоимость: 99 800 рублей
• Длительность: 7 месяцев
• Формат обучения: онлайн, вебинары, видеолекции и практика в clouds
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет:

• разработчикам ПО, стремящимся расширить навыки;
• системным администраторам;
• администраторам баз данных;
• инженерам по качеству;
• специалистам по безопасности.

Преимущества:

• персональная консультация и специальные условия оплаты;
• полная компенсация стоимости при несоответствии курса ожиданиям;
• возврат 13% от цены обучения через налоговый вычет;
• бесплатная профессиональная консультация перед началом занятий;
• групповое обучение для сотрудников компаний;
• удобное приложение для занятий с телефона;
• регулярные уведомления о дедлайнах сдач работ;
• возможность отправлять задания прямо с мобильного устройства;
• помощь куратора на протяжении всего периода обучения;
• содействие в поиске работы после завершения курса.

Недостатки:

• редкие сбои в работе мобильной версии.

Программа обучения:

• Технологии контейнеризации и виртуальные среды
• Управление облачными ресурсами через Terraform
• Автоматизация настройки систем с помощью Ansible
• Процессы непрерывной разработки и поставки кода
• Системы сбора метрик и анализа логов
• Архитектура и особенности распределенных приложений
• Развертывание настройка и администрирование кластеров
• Организация инфраструктуры с использованием облачных платформ

Ознакомиться с полной программой >>>

8. Безопасность в Kubernetes | Слерм

В рамках курса слушатели осваивают методы защиты Kubernetes-кластеров и практическое применение платформы в контексте безопасности. Курс включает изучение использования Policy Engine и Admission Controller для контроля конфигураций, а также работу с механизмами авторизации, аутентификации и аудита в кластере. Программа направлена на подготовку к выполнению обязанностей инженера кибербезопасности в DevOps-среде, включая создание безопасных манифестов и внедрение AppSec в продакшен. По завершении курса слушатели приобретают навыки профессиональной защиты данных и инфраструктуры, что позволяет эффективно управлять безопасностью в современных распределенных системах.

• Стоимость: от 45 000 рублей
• Длительность: по запросу
• Формат обучения: видеоуроки, практические задания
• Сертификат: свидетельство о повышении квалификации

Кому подойдет:

• инженерам безопасности;
• DevOps- и SRE инженерам;
• системным и облачным администраторам;
• разработчикам, работающие с K8s;
• архитекторам Kubernetes и облачных решений.

Преимущества:

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

Недостатки:

• не указана длительность программы.

Программа обучения:

• Основы безопасности проектов на платформе Kubernetes
• Обеспечение безопасности основных компонентов Control Plane
• Настройка систем авторизации аутентификации и аудита
• Автоматическое сканирование уязвимостей и конфигураций
• Использование Policy Engine и Admission Controller
• Обеспечение безопасности контейнерных образов
• Организация защищенного хранения конфиденциальных данных
• Настройка безопасного сетевого взаимодействия в кластере
• Методы управления и предотвращения угроз в Kubernetes

Ознакомиться с полной программой >>>

9. Системный администратор | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

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

• Стоимость: 97 500 рублей
• Длительность: от 11 месяцев
• Формат обучения: живые вебинары, видеолекции и практические задания с проверкой
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет:

• системным администраторам;
• специалистам из смежных областей.

Преимущества:

• возможность работать по специальности уже через полгода обучения;
• практика на реальных задачах сформированных по требованиям компаний работодателей;
• преподаватели делятся практическим опытом и рекомендациями в прямом эфире;
• возврат средств, если программа обучения не соответствует ожиданиям;
• компенсация 13% стоимости через налоговый вычет;
• доступ ко всем урокам через специальное приложение;
• своевременные напоминания о сроках сдачи заданий;
• помощь с настройкой необходимого программного обеспечения.

Недостатки:

• долгое обучение.

Программа обучения:

• Обзор современных информационных технологий и их архитектуры
• Изучение операционной системы Linux и ее компонентов
• Управление серверами и настройка системных параметров
• Создание скриптов на языке Bash для решения типовых задач
• Развертывание виртуальных сред и контейнерных технологий
• Введение в практики непрерывной интеграции и поставки
• Обеспечение отказоустойчивости сервисов и систем
• Организация систем хранения и передачи данных
• Основы защиты информации и противодействия угрозам

Ознакомиться с полной программой >>>

10. Kubernetes. Практикум | Level UP

Слушатели освоят установку и настройку программного обеспечения как в локальной, так и в облачной среде, а также изучат базовые принципы контейнеризации приложений, типы контейнеров и их характеристики. В процессе обучения они приобретут навыки развертывания приложений с использованием различных инструментов и методик. Также слушатели ознакомятся с механизмами масштабирования в Kubernetes, управления ресурсами и оптимизации производительности приложений. В завершение курса они познакомятся с системами мониторинга и логирования, методами контроля работы приложений и анализа журналов событий, что позволит эффективно поддерживать стабильность и производительность инфраструктуры.

• Стоимость: 32 990 рублей
• Длительность: 1,5 месяца
• Формат обучения: теоретическая и практическая часть, домашние задания
• Сертификат: сертификат о повышении квалификации

Кому подойдет:

• системным администраторам, инженерам по эксплуатации;
• разработчикам;
• DevOps-инженерам.

Преимущества:

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

Недостатки:

• нет помощи в трудоустройстве.

Программа обучения:

• Концепция и архитектура Kubernetes варианты развертывания
• Развертывание и настройка полнофункционального кластера
• Инструменты для управления развертыванием приложений
• Организация коммуникации между приложениями в кластере
• Настройка cert manager для работы с SSL сертификатами
• Сетевые плагины и настройка политик NetworkPolicy
• Подключение внешних хранилищ на примере Ceph
• Отслеживание состояния компонентов кластера
• Организация процессов непрерывной интеграции и поставки

Ознакомиться с полной программой >>>

Еще 12 дополнительных курсов Kubernetes

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

• Kubernetes The Hard Way от Слерма. Курс предназначен для углубленного изучения администрирования Kubernetes с целью получения полного контроля над контейнерной инфраструктурой. Программа ориентирована на эффективное масштабирование систем в условиях enterprise-среды. Спикер разберет ваш кейс, если он наберет больше голосов.
• Kubernetes от Rebrain. Обучение объясняет внутреннее устройство Kubernetes для комфортной эксплуатации и решения проблем. На премиум-тарифах предусмотрено изучение администрирования кластера для тех, кто уже применяет основные возможности платформы.
• Kubernetes от Stepik. Вы с нуля освоите администрирование Kubernetes: разберетесь в его основных ресурсах и научитесь устанавливать платформу с нуля. На уроках вы настроите CI/CD-процессы, будете работать с Helm для шаблонизации манифестов и узнаете практические приемы, которые сразу можно применять в работе. Хотя программа заточена под DevOps-инженеров, она также отлично подойдет разработчикам, сисадминам, тестировщикам и инженерам сопровождения — каждый найдет здесь полезные навыки для задач.
• Kubernetes Workshop от Микроинформа. За три плотных дня вы с коллегами-разработчиками пройдете весь путь — от кода до работающего в Kubernetes Spring Boot микросервиса. Не в теории, а на практике разберетесь, как упаковывать приложения в контейнеры и управлять ими по всем правилам. После коротких вводных лекций сразу перейдете к делу: под руководством опытных наставников будете пробовать, ошибаться и находить решения — именно так технологии усваиваются по-настоящему.
• Kubernetes и Helm от Stepik. На курсе вы с нуля разберетесь в Kubernetes и Helm, а в конце самостоятельно развернете реальное приложение. Программа создана специально для бэкенд-разработчиков, которые хотят научиться деплоить сервисы в Kubernetes с помощью Helm-чартов, а также для системных администраторов, планирующих переход в DevOps.
• Мониторинг и логирование инфраструктуры в Kubernetes от Слерма. Обучение проводит от основ до продвинутых техник организации мониторинга и сбора логов в Kubernetes. Вы получите навыки работы с инструментами и утвержденными практиками. Освоите выбор значимых метрик, настройку уведомлений и методы оперативного восстановления кластера.
• Service mesh от Слерма. Вы освоите практическое внедрение и сопровождение Service mesh в рабочих проектах для обеспечения отказоустойчивости, безопасности и масштабируемости микросервисных систем. Обучение строится на решении бизнес-кейсов с использованием выделенных стендов.
• CI/CD с Jenkins от Слерма. Курс научит автоматизировать CI/CD процессы с сокращением времени разработки и внедрением инструментальных решений. Обучение включает переход от начальной настройки плагинов и базовых пайплайнов до работы с Jenkins as Code и развертыванием в Kubernetes. Документ о повышении квалификации предусмотрен для выполнивших 80% программы.
• RabbitMQ от Слерма. Курс готовит SRE-специалистов для билетного сервиса на основе рабочих задач и кейсов. Вы получите практические компетенции в мониторинге, предупреждении инцидентов и построении надежной инфраструктуры.
• Kubernetes на практике от DevopsTrain. Курс предназначен для DevOps-инженеров и разработчиков, работающих с k8s. Программа содержит практически значимые знания, востребованные в реальных задачах. Обучение строится по принципу от практики к теории. На всех этапах доступна обратная связь от автора курса. Предоставляется перечень распространенных вопросов с развернутыми ответами.
• Docker и Kubernetes от Softline. Программа ориентирована на Linux-администраторов, системных инженеров и специалистов DevOps и BigData. Вы освоите управление контейнерной инфраструктурой Docker, развертывание и эксплуатацию микросервисных приложений в кластере Kubernetes.
• Kubernetes x Yandex.Cloud от Rebrain. Практический онлайн-курс охватывает управление Kubernetes в облачной платформе Yandex Cloud. Обучение организовано совместно с Yandex Cloud и DevOps-агентством Fevlake. Программа предназначена для DevOps-инженеров, разработчиков и инфраструктурных специалистов.

Еще 15 дополнительных курсов DevOps

Чтобы стать востребованным специалистом и развить карьеру, важно понимать, как Kubernetes интегрируется в DevOps-культуру. Ознакомьтесь с узкоспециализированными курсами, которые помогут вам углубить знания и повысить квалификацию в ключевых аспектах работы с этой платформой.

• DevOps для эксплуатации и разработки от Яндекс Практикума. Вы освоите DevOps-подход и его инструменты, чтобы расти в профессии. Научитесь решать реальные инфраструктурные задачи в условиях, максимально приближенных к рабочим. А учиться можно в комфортном для вас темпе — программа доступна в трех вариантах продолжительности: пять, семь или девять месяцев.
• Devops инженер от ProductStar. Всего за пять месяцев вы получите востребованную IT-специальность с нуля. Программа обучения DevOps-инженеров постоянно обновляется и соответствует актуальным требованиям рынка. Вы сами выбираете, как учиться: регулируете скорость прохождения курса, уровень поддержки и число практических проектов под свои задачи.
• Devops быстрый старт от ProductStar. Этот короткий онлайн-курс погрузит вас в основы DevOps через практику и дипломный проект. Он подойдет тем, кто только начинает в IT, системным администраторам и junior-разработчикам. Вы поработаете с инструментами, которые используют профессионалы: GitLab, Python, SQL и Ansible.
• DevOps-инженер от Skillfactory. Программа научит использовать DevOps-инструментарий в практических условиях на задачах реальных клиентов. Курсовой проект моделирует работу DevOps-инженера в стартапе. Финальное портфолио программных архитектур усилит ваши позиции при трудоустройстве.
• DevOps. Уровень 1. Инфраструктура как код, основные инструменты» от учебного центра «Специалист». Вы получите навыки формирования DevOps-стратегий и управления инфраструктурой предприятия с помощью шаблонных решений. Освоите инструменты непрерывной интеграции и поставки, а также Docker и Kubernetes для развертывания приложений в контейнерах.
• DevOps-инженер с нуля от Merion Academy. Программа обучит основам CI/CD и работы с инфраструктурой как кодом. Вы освоите основной инструментарий DevOps-инженера: Docker, Kubernetes, Terraform и Ansible. Приобретете базовые навыки мониторинга и обеспечения безопасности инфраструктурных решений.
• DevOps Upgrade от Слерма. Вы приобретете весь объем hard skills, требуемых для позиции DevOps-инженера, за девять месяцев. Практические задания организованы как сквозной проект приложения SlurmTalks с последовательным наращиванием функциональности согласно учебным модулям.
• DevOps практики и инструменты от OTUS.ru. Вы освоите настройку систем развертывания и тестирования приложений для перехода в новую профессию. Сможете разобраться в построении DevOps-процессов и оптимизации нагрузок на сервисы, изучить современные инструменты и методики для смены профессиональной деятельности.
• DevOps-инженер от Rebrain. Вы систематизируете профессиональные знания и подготовите портфолио из пяти проектов, показывающих умение работать с CI/CD, контейнерами, оркестрацией и облачными платформами. Освоите теоретические основы для карьерного продвижения и практические навыки для результативной работы в DevOps. Изучите важнейшие инструменты DevOps и улучшите свои шансы на рынке вакансий.
• DevOps для программистов от Хекслета. Программа включает контейнеризацию приложения в Docker и настройку CI на Github Actions. Вы автоматизируете деплой через Ansible и развернете облачную инфраструктуру средствами Terraform. Освоите настройку мониторинга, систем логирования и сбора ошибок.
• DevOps Marathon от OTUS.ru. Онлайн-конференция, посвященная DevOps и актуальным методам доставки программных решений, проводится образовательной платформой Otus совместно с сообществом Express 42. Программа мероприятия включает выступления, которые будут полезны широкой аудитории ИТ-специалистов.
• DevOps 1C от OTUS.ru. Вы сократите вероятность некорректных изменений в работающей системе, усовершенствуете коммуникационные процессы между отделами компании, повысите общую производительность команды. Также увеличите скорость разработки и укрепите качество итогового продукта.
• DevOps: Управление инфраструктурой от Хекслета. Курс познакомит с методологией «Инфраструктура как код» и инструментарием для развертывания и управления инфраструктурой. Вы освоите работу с облачными сервисами, применение Ansible и Terraform для конфигурации серверов. Рассмотрите подходы Zerocoding и Serverless и изучите основы защиты приложений.
• DevOps Lab от Stepik. Программа охватывает весь цикл от начальных команд в терминале до deployment production-пайплайнов. Вы изучите Bash-скриптинг, Git-флоу, углубленный Python для автоматизации, администрирование Linux-серверов и основные DevOps-методики. Обучение включает практику на реальных кейсах, домашние задания и проекты для оперативного использования навыков в профессиональной деятельности.
• Проектирование и внедрение решений Microsoft DevOps от Эврики. Программа предназначена для специалистов, имеющих фундаментальную подготовку в области Azure, контроля версий, гибких методологий разработки и базовых принципов создания ПО. Опыт работы в организации, осуществляющей поставки программного обеспечения, является желательным.

Бесплатные курсы Kubernetes

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

1. Kubernetes на Русском Языке от ADV-IT. Плейлист по системе полностью на русском языке. С помощью видеоуроков вы узнаете о главных объектах, кластерах и других важных составляющих. Уроки сопровождаются понятными комментариями и объяснениями.
2. Введение в Kubernetes от Microsoft. Курс демонстрирует коммерческие задачи, которые решает платформа Kubernetes. Вы познакомитесь с возможностями оркестрации контейнеров: управление деплойментом, автоматические обновления и механизмы самовосстановления.
3. Открытая вечерняя школа. Kubernetes для разработчиков от Слерма. Программа факультета Kubernetes в Слерм обеспечивает подготовку от базовых знаний до экспертного уровня. В учебные модули включены темы безопасности Kubernetes, систем мониторинга и логирования в Kubernetes-инфраструктуре и технологии Docker.
4. Как правильно сделать Kubernetes от Фланта. Выступление технического директора «Флант» Дмитрия Столярова на DevOpsConf 2021 посвящено созданию Kubernetes-платформы, ориентированной на одновременное удовлетворение потребностей разработчиков, инженерных команд и бизнес-задач.
5. Docker и Kubernetes от Руссккого Айтишника. В этом видео автор рассматривает эволюцию контейнерных технологий от их возникновения до современного состояния, анализируя предпосылки появления и текущее развитие.
6. Kubernetes для пользователей от Stepik. Курс ориентирован на пользователей, которым требуется работа с предустановленным Kubernetes без изучения администрирования. Обучение проводится в доступной форме с фокусом на взаимодействие с базовыми ресурсами платформы.
7. Введение в Kubernetes от Слерма. Курс предоставляет одинаково ценную базу знаний для работы с Kubernetes независимо от используемой платформы развертывания.
8. Основы Kubernetes: секреты от CloudMTS. Вебинар раскрывает концепции cloud-native и микросервисной архитектуры. Рассматриваются принципы оркестрации контейнеров и сопутствующие сложности. Демонстрируется решение этих проблем через сервис управления Kubernetes-кластерами в облаке #СloudMTS. Показывается процесс развертывания приложений в Kubernetes и работа с PersistentVolume и Load Balancer.
9. Docker для начинающих + практический опыт от Stepik. Программа включает освоение начального уровня Docker, изучение ключевых команд на практике, создание образов через Dockerfiles, понимание Docker Compose и развертывание прикладных стеков с его применением.
10. Как стать DevOps? Полный roadmap для DevOps от Sergey Nemchinskiy. Видеоматериал содержит методику начала карьеры в DevOps с базового уровня. Анализируются необходимые компетенции для трудоустройства, структура обучения и предполагаемая продолжительность подготовки.
11. Расширенный курс "Введение в DevOps". Расширенная программа обучения охватывает фундаментальные аспекты DevOps: основы методологии, работу в терминале, сетевые технологии, CI/CD, Infrastructure as Code, Kubernetes, облачные платформы, управление инфраструктурой, мониторинг, базы данных и инструмент Vagrant.

Kubernetes простыми словами, зачем нужен и какие проблемы решает

Когда ваше приложение разрастается из одного-двух контейнеров до десятков или сотен, управлять всем этим вручную уже не получается. Нужно постоянно следить, какие контейнеры работают, а какие внезапно остановились, вручную их перезапускать, решать, на каком сервере, что запустить, чтобы не перегрузить машины, и как-то обновлять версии без простоев. На это уходили бы часы каждый день. Kubernetes приходит на помощь именно в такой ситуации. Его главная задача — взять на себя всю эту рутину. Вы просто говорите системе, в каком состоянии должны быть ваши приложения (например, «должно всегда работать пять копий моего сайта»), а Kubernetes самостоятельно и непрерывно старается привести реальность к этому желаемому состоянию.

Какие ключевые проблемы он решает

Раньше, до появления систем оркестрации, поддерживать работу приложений было гораздо труднее. Возьмем, к примеру, масштабирование. Когда число пользователей резко возрастает, сервер может не выдержать нагрузки. Раньше администраторам приходилось вручную добавлять новые экземпляры приложения. Kubernetes же делает это сам — следит за потреблением ресурсов и при необходимости автоматически запускает дополнительные копии.

Не менее важный аспект — надежность системы. Приложения и серверы иногда выходят из строя, это нормально. Раньше такие сбои требовали немедленного вмешательства человека. С Kubernetes все иначе: если какой-то контейнер перестает работать, система это замечает и сразу перезапускает его. Если же проблема серьезнее и ломается целый сервер, Kubernetes самостоятельно переместит все рабочие нагрузки на другие узлы кластера. Получается система, которая умеет самостоятельно лечить себя.

Также Kubernetes решает проблему управления обновлениями. Выкатить новую версию приложения без простоя — нетривиальная операция. Kubernetes предлагает разные стратегии обновления (например, сине-зеленый деплой или постепенное канареечное обновление), которые позволяют делать это плавно и безопасно. В случае если новая версия ведет себя некорректно, система позволяет одним щелчком мыши «откатиться» к предыдущей, стабильной.

Наконец, он унифицирует работу с инфраструктурой. Неважно, где развернут ваш кластер — на своих серверах, в Яндекс.Облаке, Amazon или Google Cloud. Вы описываете желаемую конфигурацию на одном и том же языке (YAML-манифесты), и Kubernetes работает везде одинаково. Это дает огромную свободу и избавляет от привязки к конкретному поставщику.

Как выглядит типичный рабочий день инженера, работающего с Kubernetes

Утренний мониторинг и диагностика

Первым делом инженер проверяет системы мониторинга — это как утренний ритуал. Он смотрит, как чувствуют себя кластеры: не перегружены ли серверы, хватает ли памяти, стабильно ли работают приложения. Быстрый просмотр логов помогает понять, не случилось ли чего-то важного за ночью.

Решение текущих инцидентов

Если в данных мониторинга видны аномалии, начинается расследование. Специалист поэтапно разбирается в проблеме: смотрит, какие компоненты ведут себя странно, анализирует логи и ищет корневую причину. В зависимости от ситуации, может понадобиться добавить ресурсов для сервиса, откатить последнее обновление или подправить конфигурацию.

Взаимодействие и развитие

Много времени уходит на общение с разработчиками — помощь в настройке приложений, советы по оптимизации, обсуждение новых требований. Параллельно инженер занимается автоматизацией: старается превратить рутинные операции в скрипты, улучшает системы оповещения и мониторинга, чтобы работать было проще и эффективнее.

Завершение рабочего дня

Перед окончанием работы выполняется финальная проверка всех ключевых метрик и состояния систем. При организации дежурств специалист остается доступным для решения критичных инцидентов. Качественно настроенные системы наблюдения позволяют минимизировать необходимость внешних вмешательств.

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

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

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

Реализация Kubernetes PKI

Итак, зачем мы вообще используем PKI в Kubernetes? С точки зрения безопасности это помогает аутентифицировать соединения между системными компонентами и шифровать передаваемые по этим соединениям данные. Всё это позволяет защититься от сниффинга трафика и атак по типу Adversary-in-the-Middle (AiTM, «злоумышленник посередине»).

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

В статье мы рассмотрим стандартный кластер, развёрнутый с помощью kubeadm, что позволит сосредоточиться на основных компонентах K8s и типичных конфигурациях. Схема TLS-соединений базовых компонентов кластера выглядит примерно так:

Большинство из них — это аутентифицируемые TLS-соединения, в которых клиент проверяет подлинность сервера, чтобы избежать подключения к «левым» системам. Но есть одно исключение, а именно подключение сервера API к kubelet’у. Соединение можно аутентифицировать, но по умолчанию этого не происходит. В итоге оно оказывается уязвимым для тех самых атак AiTM, о чём прямо говорится в документации Kubernetes.

Центры сертификации и сертификаты

Защита столь большого числа соединений, естественно, ведёт к необходимости управления множеством сертификатов. Дополнительно всё усложняется ещё и тем, что в процессе участвуют различные центры сертификации (Certificate Authority, CA). Как правило, Kubernetes задействует внутренние CA для ключей. Если вы подключитесь к кластеру с помощью инструментов вроде curl или браузера, то получите предупреждение о недоверенных сертификатах.

Все созданные сертификаты можно найти в каталоге /etc/kubernetes/pki/ на узле с управляющим слоем Kubernetes, созданном через kind:

В нашем списке присутствуют три разных центра сертификации, что довольно нетипично для одной системы. Но такое разделение необходимо из-за требований безопасности и использования клиентских сертификатов для аутентификации.

Основной центр подписывает большинство сертификатов кластера (например, тех, которые kubelet использует для подключения к API-серверу). Сертификаты также можно подписывать самим, используя OpenSSL или аналогичные инструменты, но для этого потребуется интерактивный доступ к хосту управляющего слоя. Кроме того, есть вариант использовать основной центр сертификации Kubernetes для удалённого подписания сертификатов через Certificate Signing Request API.

Помимо основного CA, у нас есть ещё два дополнительных. Первый используется для защиты соединений между etcd и API-сервером. Отдельный центр в этом случае нужен, потому что в той конфигурации, которую использует Kubernetes, etcd предоставляет полный доступ к данным для любого сертификата, подписанного центром, которому она доверяет. Если бы etcd использовало основной CA, то любой атакующий, получивший доступ к действующему клиентскому сертификату, смог бы полностью контролировать хранилище данных кластера.

Наконец, ещё один центр — requestheader-client (файл front-proxy-ca.crt) — отвечает за обработку запросов на агрегацию (когда используются дополнительные API-серверы). Здесь отдельный CA нужен из-за риска конфликтов, которые могут возникнуть при использовании одного и того же центра.

На рабочем узле кластера файлы конфигурации PKI (хранятся по адресу /var/lib/kubelet/pki) нужны kubelet’у. Он использует PEM-файл для подтверждения своей подлинности перед API-сервером, когда выступает в качестве клиента, а файлы crt и key используются kubelet API. В дефолтном развёртывании, проведённом с помощью kubeadm, файл crt содержит самоподписанный сертификат, что делает подключающихся к kubelet’у клиентов (например, API-сервер) уязвимыми для сниффинга и атак AiTM.

Суть сертификатов и их назначение подробно описываются в документации Kubernetes.

Защита сертификатов Kubernetes

С точки зрения безопасности в отношении использования PKI и сертификатов в Kubernetes есть два основных момента.

Первый заключается в необходимости обеспечивать безопасность файлов, где хранятся приватные ключи. В частности, это ca.key с ключом для основного центра сертификации Kubernetes. Если атакующий доберётся до этого файла, то без проблем обеспечит себе постоянный доступ на уровне администратора кластера, поскольку сможет с его помощью создавать новые привилегированные учётные записи.

Для защиты файлов ключей важно не размещать их в репозиториях исходного кода. Также важно тщательно контролировать резервные копии этих файлов. Способ решения этой проблемы будет зависеть от используемого дистрибутива Kubernetes. Например, Rancher Kubernetes Engine 1 (RKE1) хранит приватные ключи в ConfigMap. Пользователи с доступом к нему получают и полный доступ к кластеру. Поэтому очень важно быть в курсе всех тонкостей конкретного дистрибутива.

Риски при использовании клиентских сертификатов

В свете обсуждения защиты PKI и Kubernetes также важно затронуть вопросы безопасности, возникающие при использовании клиентских сертификатов для аутентификации. Здесь основная проблема Kubernetes — невозможность отозвать отдельные сертификаты. Дело в том, что K8s не поддерживает списки отозванных сертификатов (Certificate Revocation Lists, CRL) или протоколы вроде Online Certificate Status Protocol (OCSP).

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

Системные компоненты Kubernetes используют PKI для защиты
коммуникаций и аутентификации при использовании API. Важно понимать, как в этом механизме участвуют
разные центры сертификации, и защищать используемые ими чувствительные файлы.

1. 10-Страйк: Мониторинг Сети Pro

10-Страйк: Мониторинг Сети Pro — это российская программа для системных администраторов, которая позволяет контролировать состояние сетевых устройств, серверов, рабочих станций, коммутаторов, баз данных и других ресурсов инфраструктуры. Она отслеживает ключевые параметры — от свободного места на дисках и загрузки процессора до температуры оборудования — и в случае проблем отправляет уведомления по email, SMS или в мессенджеры. Система может не только сигнализировать о сбоях, но и автоматически устранять их, например, перезапуская службы или выполняя скрипты.

Технические возможности

Продукт поддерживает десятки видов сетевых проверок через ICMP, SNMP, HTTP, SQL, SSH и другие протоколы. Возможно мониторить серверы Windows и Linux, сетевые службы, видеокамеры, принтеры, СУБД и промышленное оборудование. Визуализация данных доступна на карте сети с графиками и индикаторами. В версии Pro предусмотрен распределённый мониторинг с несколькими серверами и аген­тами, а также веб-интерфейс для удалённого управления.

Сценарии использования

Для DevOps и системных администраторов 10-Страйк подходит как инструмент централизованного мониторинга с алертами и картой сети. IT-отделы предприятий используют его для контроля доступности каналов связи, серверов, баз данных и устройств. Руководители могут формировать отчёты по аптайму и SLA для анализа стабильности работы инфраструктуры.

Особенности

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

Тарифы и условия

Продукт распространяется по лицензии с ограничением на число сенсоров: версия Pro на 100 сенсоров стоит 40 000 рублей, стандартная версия — 20 000 рублей. Для корпоративных лицензий действует ограничение на количество серверов мониторинга.

2. Deckhouse Prom++

Deckhouse Prom++ — это Open Source-система мониторинга на базе Prometheus, которая потребляет до 10 раз меньше памяти. Она собирает метрики приложений, сервисов и инфраструктуры в реальном времени, хранит их во встроенной TSDB и поддерживает PromQL для анализа. Deckhouse Prom++ умеет формировать алерты и легко интегрируется с Grafana, оставаясь привычным для команд, которые уже работают с Prometheus.

Технические возможности

Deckhouse Prom++ может собирать любые инфраструктурные метрики напрямую или через экспортеры: состояние серверов, контейнеров, сетей, баз данных и приложений. Главная оптимизация по сравнению с «ванильным» Prometheus — переработка Write Ahead Log — позволяет снизить потребление памяти без ущерба производительности. Продукт полностью совместим с API и настройками Prometheus: дашборды, правила алертинга и интеграции продолжают работать без изменений. Prom++ уже используется на более чем 1000 кластеров и поддерживает до 10 млн активных метрик на кластер.

Сценарии использования

DevOps-инженеры и SRE могут использовать Deckhouse Prom++ для мониторинга Kubernetes и традиционной инфраструктуры. Архитекторы и CTO получают возможность сократить расходы на RAM без отказа от привычной экосистемы. Prom++ подходит и для on-prem, и для облачных окружений, а также уже встроен в Deckhouse Kubernetes Platform.

Особенности

Ключевое преимущество Deckhouse Prom++ — низкое потребление ресурсов: до 10 раз меньше памяти, чем у Prometheus, и до 3 раз меньше, чем у VictoriaMetrics. Сервис полностью совместим с экосистемой Prometheus, не создаёт вендорлока и распространяется под лицензией Apache 2.0. Поддержка осуществляется инженерами Deckhouse и сообществом через открытый Telegram-чат.

Тарифы и условия

Deckhouse Prom++ — полностью бесплатный Open Source-продукт. Ограничений по количеству пользователей или метрик нет.

Есть инструкция по миграции, потребуется только предварительная конвертация WAL-файлов. Вы также сможете без труда вернуться с Deckhouse Prom++ на Prometheus.

Инженеры Deckhouse и сообщество помогают пользователям в Telegram-чате Prom++ User Group.

3. GMONIT

GMONIT — российская платформа класса Observability, которая собирает и анализирует метрики, логи, трассировки и бизнес-показатели в едином интерфейсе. Она даёт ИТ-командам полный обзор цифрового контура: от сетей, серверов, баз данных и контейнеров до пользовательских действий и бизнес-метрик. GMONIT помогает перейти от «реактивного» реагирования на инциденты к проактивному управлению ИТ, сокращая время диагностики и повышая стабильность сервисов.

Технические возможности

GMONIT поддерживает мониторинг сетей, серверов, виртуальных машин, баз данных, контейнеров, API, реальных пользователей в браузере или мобильном приложении и бизнес-процессов. Система строится на микросервисной архитектуре, легко масштабируется и формирует дашборды для разных ролей — от инженеров до CIO. В одном интерфейсе доступны ключевые показатели доступности, SLA, конверсии, скорость обработки заказов и другие бизнес-метрики. Платформа обеспечивает предиктивную аналитику, раннее выявление аномалий и ускоренное RCA (Root Cause Analysis — анализ первопричин): TTD (Time To Detect — время до обнаружения) — менее 10 минут, RCA — около 15 минут.

Сценарии использования

• Разработчики используют GMONIT для отладки сервисов и мониторинга CI/CD, что ускоряет релизы и сокращает время устранения ошибок.
• QA-команды применяют платформу при нагрузочных тестах и фиксации ошибок в продакшене.
• DevOps и SRE получают централизованный мониторинг с алертами, предиктивной аналитикой и интеграцией в пайплайны.
• PM и CIO работают с визуальными панелями SLA, аптайма и бизнес-метрик, чтобы видеть реальное влияние инфраструктуры на продажи и пользовательский опыт.
• Поддержка сокращает время реакции на инциденты и устраняет сбои до того, как о них сообщают пользователи.

Особенности

GMONIT строится как масштабируемая система с единым «окном наблюдения»: метрики инфраструктуры, пользовательского опыта в браузере, приложений, API; а также вызовы во внешние сервисы и бизнес-процессы отображаются на одном дашборде. Архитектура ориентирована на работу с большими объёмами данных, а визуализация адаптирована как под инженеров, так и под управленцев. Сервис интегрируется с CI/CD, мессенджерами и сторонними системами через API. Поддерживаются как on-prem, так и облачные сценарии.

Тарифы и условия

Информацию о тарифах можно найти на официальном сайте GMONIT. Ограничений по числу пользователей и метрик нет. API и SDK доступны, а интеграции гибко настраиваются под нужды заказчика.

Управление и поддержка

Управление осуществляется через веб-интерфейс и API. Поддержка организована через чат, систему тикетов, SLA и подробную документацию.

4. Zabbix

Zabbix — это платформа мониторинга корпоративного уровня, которая обеспечивает полную наблюдаемость IT- и OT-инфраструктуры. Решение ориентировано на крупные компании и поставщиков управляемых услуг, отличается низкой совокупной стоимостью владения и предсказуемой моделью поддержки без лицензионных сборов. Zabbix создан для долгосрочного использования: он масштабируем, безопасен «по конструкции» и подходит для критически важных систем.

Технические возможности

Платформа поддерживает мониторинг серверов, приложений, облачных сервисов, сетевых устройств и IoT, включая многоуровневые среды. Важной функцией выступает вложенное низкоуровневое обнаружение, позволяющее автоматически создавать иерархические правила для хостов и сервисов. Zabbix предлагает мастер создания хостов, встроенную проверку форм для сокращения ошибок, расширенные сетевые карты и новый виджет карточки товара для детальной визуализации метрик. Платформа может быть развернута локально, в облаке Zabbix или в сторонних облаках (AWS, Azure, Google Cloud).

Сценарии использования

Zabbix применяют IT-отделы и DevOps-команды для централизованного мониторинга инфраструктуры и соответствия требованиям безопасности. Поставщики управляемых услуг используют его как MSP-дружественное решение с многопользовательским доступом и возможностью масштабирования под клиентов. Платформа востребована в высокозащищённых и регулируемых отраслях, где важны автономность и полный контроль над данными.

Особенности

Ключевые преимущества Zabbix — это открытый исходный код и отсутствие лицензионных ограничений. Архитектура платформы масштабируется «под будущее» и интегрируется с системами управления конфигурацией. Пользователи получают полное владение данными, гибкость в развертывании (on-premise, облако, гибрид) и широкие возможности кастомизации визуализации.

Тарифы и условия

Zabbix распространяется как решение с открытым исходным кодом и не требует лицензионных платежей. Стоимость формируется только за счет технической поддержки, которая предоставляется по фиксированным тарифам в зависимости от уровня сервиса.

5. LibreNMS

LibreNMS — это система мониторинга сетевой инфраструктуры с автоматическим обнаружением устройств и сервисов. Она ориентирована прежде всего на мониторинг сетей по SNMP, но также поддерживает серверы на Windows, Linux и FreeBSD через собственные агенты. Решение работает на базе PHP и MySQL, имеет удобный веб-интерфейс, мобильные приложения и широкий набор встроенных метрик, которые не требуют ручной настройки.

Технические возможности

Система автоматически обнаруживает топологию сети с помощью протоколов CDP, FDP, LLDP, OSPF, BGP, SNMP и ARP. Поддерживается интеграция с NfSen, collectd, SmokePing, RANCID и Oxidized. Встроенный API позволяет управлять установкой, строить графики и выгружать данные. Реализована гибкая система оповещений с поддержкой email, IRC, Slack и других сервисов, а также встроенная биллинговая система для учета использования полосы пропускания. LibreNMS поддерживает различные методы аутентификации, включая LDAP, Radius и Active Directory, и обновляется автоматически.

Сценарии использования

LibreNMS выбирают компании, которым важно быстрое развертывание мониторинга сети без сложной ручной настройки. Решение подходит интернет-провайдерам и корпоративным IT-отделам для учета трафика и выставления счетов, а также администраторам, которым нужен автоматический контроль устройств и серверов с оповещениями в удобных каналах. Благодаря мобильным приложениям и демо-версии система подходит для тестирования и удаленной работы.

Особенности

Ключевыми преимуществами LibreNMS выступают простота запуска и поддержка практически всех популярных сетевых устройств «из коробки». Автоматическое обнаружение и распределенный опрос упрощают масштабирование, а встроенный биллинг и интеграции делают систему полезной не только для мониторинга, но и для коммерческих задач.

Тарифы и условия

LibreNMS распространяется как проект с открытым исходным кодом и бесплатен для использования. Доступна онлайн-демонстрация (https://demo.librenms.org, логин: demo, пароль: demouser).

Сегодня, в условиях конкуренции, компании стремятся доставлять продукт до пользователей максимально быстро – и автоматизация ИТ-инфраструктуры может в этом помочь. Она включает автоматическое развертывание, настройку, мониторинг и управление IT-ресурсами и сервисами с помощью специализированных инструментов.

О некоторых из таких инструментов и пойдет речь в этой статье.

Мы разберем возможности Ansible, Terraform, Zabbix, Kubernetes и GitHub Actions, расскажем, как они могут помочь автоматизировать вашу инфраструктуру. Наш материал пригодится всем, кто хочет сократить время на рутинные задачи, ускорить развертывание IT-систем и управлять инфраструктурой с минимальными рисками человеческой ошибки.

Ansible

Этот сервис автоматизации с помощью простых YAML-скриптов работает через SSH и позволяет автоматизировать буквально всё – от создания учетных записей пользователей до крупных многоуровневых развертываний приложений.

С Ansible легко выполнять автоматизацию, даже если у вас нет глубоких знаний в программировании – к примеру, вот код, который установит последнюю версию Nginx на Ubuntu/Debian:

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

С помощью Ansible многие компании решают задачи, связанные с автоматизацией. Например, используя этот инструмент, NASA уменьшило время развертывания с нескольких часов до нескольких минут, разработчик ПО ITQ Group добился более прозрачной реализации задач, Hootsuite сократил время развертывания новых сред на 90%, а BMW внедрил модель “инфраструктура как код”.

У себя в Beget тоже используем Ansible: для IaC и разворачивания софта в облаке – весь софт из панели Cloud, кроме образов операционных систем, мы устанавливаем с помощью Ansible.

Если для ваших задач тоже может быть полезен Ansible и вы хотите автоматизировать процессы сборки, тестирования и развертывания приложений в собственной инфраструктуре, у нас есть готовый кейс по автоматизированному развертыванию Gitea Runner с помощью Ansible – поделились им в отдельной статье.

Terraform

Данный инструмент позволяет описать всю ИТ-инфраструктуру в виде кода – по сути, вместо ручной настройки серверов, баз данных и сетей вы просто пишете их рецепт в текстовом файле, а Terraform автоматически создает всё необходимое.

Основные преимущества Terraform:

✔ мультиоблачность – инструмент работает с AWS, Google Cloud, Azure и другими провайдерами;

✔ декларативный подход – вы описываете желаемый результат, а Terraform сам определяет, что нужно создать, изменить или удалить;

✔ версионирование инфраструктуры – вся инфраструктура хранится в Git, поэтому видна история всех изменений и можно легко откатиться к предыдущей версии;

✔ предварительный просмотр – команда terraform plan показывает, что именно изменится, так что не будет никаких сюрпризов в продакшене.

С Terraform можно развертывать среды за 5 минут вместо 2 дней и быстрее выкатывать новые фичи, поэтому он особенно полезен, если у вас несколько сред (dev, test, prod), необходим контроль затрат на инфраструктуру и соответствие стандартам безопасности.

Terraform оценили по достоинству многие компании – вот лишь несколько примеров:

• системный IT-интегратор Nixys использует манифесты Terraform для описания состояния инфраструктуры;

• компания Uber применяет Terraform для управления сложными мультиоблачными средами и масштабирует инфраструктуру в периоды высокого спроса;

• онлайн-банк Monzo запускает новые инфраструктурные среды за считанные минуты, а не часы;

• платформа Shopify успешно справляется с такими событиями с высоким трафиком, как “черная пятница”.

Примеры управления инфраструктурой Docker с помощью Terraform можно найти в официальной документации.

Zabbix

Даже самые надежные системы порой дают сбой, а в чистый код может закрасться программный баг, поэтому всегда полезно иметь перед глазами полную картину происходящего, чтобы в случае чего узнать обо всём раньше пользователей и оперативно отреагировать. В этом и может помочь система мониторинга Zabbix.

Она отлично подходит, если вам важна автоматизированная инфраструктура – Zabbix поддерживает множество протоколов и методов мониторинга (SNMP, IPMI, JMX, SSH, Telnet, ICMP, HTTP и т. д.), а также сотни готовых шаблонов для оборудования.

Примеры параметров, которые можно отслеживать в реальном времени:

► состояние серверов, сетевого оборудования, баз данных, приложений и других компонентов инфраструктуры;

► загрузка процессора;

► использование памяти;

► сетевой трафик;

► доступность сервисов;

► срок действия SSL-сертификата и т. д.

Наглядные отчеты и диаграммы помогут знать всё о работе и производительности систем, а благодаря поддержке Telegram, Discord и прочих сервисов получать оповещения максимально удобно.

Пошаговые инструкции по установке и использованию разных версий Zabbix для выполнения задач мониторинга можно найти в официальной документации.

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

Kubernetes

Kubernetes aka K8s (8 – это количество букв между “k” и “s”) – это система для автоматического управления контейнеризированными приложениями. Своего рода умный дирижер оркестра, который следит, чтобы все части вашего приложения работали слаженно, а еще – автоматически заменяет “заболевших музыкантов” и добавляет новых, когда нужно сыграть иначе.

Среди сильных сторон K8s:

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

→ самовосстановление – работа Kubernetes предполагает автоматический перезапуск упавших контейнеров и замену контейнеров при сбое серверов;

→ простое управление конфигурацией – пароли и настройки хранятся отдельно от кода, а обновление конфигураций происходит без пересборки приложения.

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

Приведем вариант использования Kubernetes.

Рассмотрим применение K8s в связке с Helm на примере одной из самых популярных баз данных “ключ-значение” – Redis.

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

helm fetch oci://registry-1.docker.io/bitnamicharts/redis

tar xf redis-21.2.7.tgz

cd redis

Затем отредактируем values.yaml, изменив параметры на:

· replica.replicaCount: количество нужных нам реплик, в данном случае 3

· sentinel.enabled: true

· sentinel.quorum: 2

После этого создадим пространство имен для кластера Redis:

kubectl create namespace redis

И установим Helm chart с названием релиза redis-cluster в пространстве имен Redis:

helm install redis-cluster ./ -n redis

Вуаля – через некоторое время поды (то есть развертываемые вычислительные единицы) успешно запустятся:

Как инструмент автоматизации процессов Kubernetes популярен среди множества компаний: Huawei, Nokia, OpenAI, Yahoo, Spotify и т. д. – подробные кейсы есть на официальном сайте.

GitHub Actions

Эта встроенная в GitHub платформа позволяет автоматизировать конвейер сборки, тестирования и развертывания. Она будет полезна, если ваш код уже хранится на GitHub, важны автоматизация из коробки, мультиплатформенная разработка, регулярные релизы и обновления.

Ключевые достоинства GitHub Actions:

■ автоматическое выполнение тестов, сборка и развертывание приложений;

■ интеграция с различными сервисами и платформами (AWS, Azure, Docker и др.);

■ уведомления в Slack и Telegram;

■ создание кастомных workflows для CI/CD и управление релизами;

■ гибкая конфигурация через YAML-файлы в репозитории.

Благодаря возможности автоматизировать рутину (запускать задачи по расписанию, обновлять зависимости, генерировать отчеты и т. д.) GitHub Actions востребован среди более 15 тыс. компаний.

Наглядные примеры рабочих процессов и вариантов использования GitHub Actions на русском языке можно найти в официальной документации, а в нашем маркетплейсе готовых решений для VPS есть удобный и совместимый с GitHub Actions сервис Gitea, который позволяет в короткие сроки развернуть вашу собственную платформу для разработки.

Чек-лист: что продумать при автоматизации инфраструктуры:

✹ Анализ текущего состояния – до начала работ с системами автоматизации инфраструктуры важно провести инвентаризацию всех сервисов, выявить болевые точки и оценить технический долг.

✹ Цели и приоритеты – сформулируйте измеримые цели (например, снижение времени деплоя, уменьшение инцидентов), приоритизируйте их и определите критерии успеха.

✹ Выбор инструментов – в зависимости от поставленных целей, изучите возможности инструментов (например, Terraform и Ansible для IaC, Jenkins и GitHub Actions для CI/CD, Prometheus и Zabbix для мониторинга, Docker и Kubernetes для контейнеризации).

✹ Безопасность – продумайте управление доступами и ролями, шифрование данных, аудит и логирование всех действий.

✹ Команда и компетенции – оцените текущие навыки сотрудников, подготовьте план обучения и распределите зоны ответственности.

✹ Мониторинг и метрики – важно продумать KPI для оценки эффективности, алертинг и оповещения, дашборды для визуализации, SLA и SLO.

✹ Риски – этот пункт предполагает наличие тестовых сред для экспериментов и плана Б с ручным вмешательством на случай сбоев.

✹ Бюджет – следует учесть стоимость инструментов и лицензий, затраты на обучение и ROI (то есть возврат инвестиций).

И главное – автоматизируйте только то, что уже хорошо работает вручную и делается регулярно 🙂

Заключение

Сегодня развертывание ПО больше не напоминает шаманские пляски с бубном, а контролировать серверы можно, сидя дома в уютном кресле или находясь где-то еще – и в этом могут помочь грамотно настроенные автоматизация, диспетчеризация и IT-инфраструктура.

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

Ведь автоматизация рабочих процессов позволяет сократить повторяющиеся задачи на 60–95% и в результате сэкономить до 77% времени, затрачиваемого на рутинные действия.

Согласитесь, это именно то, что нужно в современном стремительно развивающемся цифровом мире 🙂

Надеемся, этот материал был для вас полезен и автоматизация сетевой инфраструктуры принесет успех вашему бизнесу.

Если у вас остались вопросы, вы хотите обсудить эту статью или облачную IT-инфраструктуру, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся 🙂

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

Под капотом же работают вполне конкретные компоненты ядра Linux: namespaces, cgroups, iptables/nftables, seccomp/AppArmor, OverlayFS и eBPF.

Именно они отвечают за изоляцию, контроль ресурсов, сетевые правила, безопасность и файловые слои.

Как Kubernetes использует Linux

• Namespaces изолируют процессы, сеть, файловые системы, пользователей и IPC. Именно они позволяют подам работать как будто в собственном окружении.
• cgroups управляют ресурсами: когда в поде прописаны resources.requests и resources.limits, Kubernetes через cgroups регулирует доступ к CPU и памяти.
• iptables / nftables обеспечивают сетевые возможности: от NAT для ClusterIP-сервисов до реализации сетевых политик.
• OverlayFS делает возможной архитектуру Docker-образов и быструю работу контейнеров: базовый слой остается неизменным, поверх накладывается writable-слой.
• eBPF открывает новый уровень сетевой безопасности и наблюдаемости. Например, Cilium заменяет iptables и использует eBPF для реализации политик безопасности на уровне L3–L7, а также для трассировки трафика и сервисов.

Зачем это знать

Kubernetes и Docker — это всего лишь удобные обертки над возможностями Linux.

Чтобы понимать, что реально происходит с контейнерами, уметь оптимизировать их работу и грамотно устранять проблемы, нужно знать, как работают Linux namespaces, cgroups, сетевые фильтры и файловые подсистемы.

Именно понимание Linux превращает Kubernetes из «магического» инструмента в предсказуемый и управляемый механизм.

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

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

1. H3LLO.CLOUD: для быстрого старта

Если вы запускаете стартап, делаете MVP или просто не хотите платить больше за инфраструктуру — у H3LLO.CLOUD есть стартовый набор на 12 месяцев, который бесплатно выдается при создании аккаунта.

Специально собрали предложения под запросы небольших команд и стартапов: 2 базовые ВМ Capsule.S (1vCPU/2GB RAM/12,5 NVMe), 5GB Network SSD, 5GB Object Storage, 1 Basic LoadBalancer, 1 IPv4, мониторинг.

Этого набора более чем хватит, даже для довольно посещаемых проектов. А тем, кому нужно больше, в ассортименте полный набор IaaS и PaaS решений и дружелюбная команда, которая помогает с их внедрением.

Облако H3LLO CLOUD подойдет тем, кто:

• запускает MVP и хочет минимизировать издержки на старте;
• работает с Big Data и аналитикой;
• использует Kubernetes или контейнеризацию;
• разворачивает inference-серверы под ИИ-модели;
• делает бэкапы и настраивает восстановление после сбоев.

H3LLO CLOUD работает с посекундной тарификацией: платите только за то, чем действительно пользуетесь. Можно выставлять счета на юрлицо, есть постоплата. Обещают добавить Cloud API, шаблоны деплоя, маркетплейс SaaS-решений и serverless — но даже сейчас по функциональности всё покрыто: базы управляемые, биллинг гибкий, интерфейс понятный.

Техподдержка отвечает быстро — от пары минут до пары часов. Для крупных клиентов — приоритетный канал связи.

2. L1veStack: полный контроль бюджетов

Если вы только запускаете проект и хотите чётко контролировать, за что платите — L1veStack делает ставку на полную прозрачность. Никаких округлений, скрытых тарифов и загадочного биллинга. Всё просто: используете ресурсы — платите посекундно, не используете — не платите вообще.

Что вы получаете на старте:

• На этапе беты L1veStack можно запустить до 3 проектов, каждый из которых может использовать до 1 vCPU и 4 ГБ RAM.
• У них есть уникальный вариант тарификации: существует нетарифицируемый пороговый уровень для небольших проектов, и оплата начинается только при превышении этих значений. Идеально для пет-проектов и стартапов, когда вы еще не знаете точных потребностей в мощности.

L1veStack построен как платформа, которая растёт вместе с вами:

• Этап 1: Пет-проекты и небольшие стартапы. Здесь вы используете нетарифицируемый порог.
• Этап 2: Команды и фрилансеры. Сервис выгодно использовать для управления Dev и Stage окружениями.
• Этап 3: Инструмент разработки для команд внутри enterprise. Предлагаются выгодные тарифы для dev/stage окружений и возможность переводить продакшен на собственные сервера под контроль ваших DevOps специалистов.

Из дополнительного и про биллинг:

В целом, всё удобно, гибко, прозрачно — есть все необходимые функции: GitHub wizard, автоматический SSL-сертификат (авто-SSL) и понятные объяснения для переменных.

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

Сервис предоставляет Live-индикаторы, который отслеживает нагрузку в реальном времени, human-friendly ошибки и мгновенный preview изменений.

3. Облачная платформа Selectel: Масштаб, безопасность и опытная поддержка

Selectel предлагает более 50 продуктов — от виртуальных и выделенных серверов до готовых к работе баз данных, кластеров Kubernetes, объектного хранилища, CDN и решений для безопасности. Всё запускается за пару кликов через удобную панель управления, API или Terraform.

Для стартапов действует акция: Кешбэк до 1 000 000 бонусов. Каждый месяц Selectel возвращает 30% бонусами от расходов на инфраструктуру. Кешбэк начисляется в течение 12 месяцев.

Selectel подходит под задачи любой сложности:

1. Разворачивать MVP и первые версии приложений — настраивать среды разработки и тестирования.
2. Запускать приложение в продакшен и масштабироваться под нагрузкой.
3. Хранить и обрабатывать данные — платформа позволяет хранить большие объемы данных на дисках объемом до 10 ТБ и более.
4. Защитить данные от сетевых атак — есть готовые инструменты защиты от DDoS-атак и инструменты резервного копирования ,
5. Соответствовать требованиям безопасности — платформа хранит персональные данные до 1 уровня защищенности и следует требованиям 152-ФЗ, 21 приказа ФСТЭК, PCI DSS, ISO 27001, ГОСТ Р 57580.

Насколько удобно работать

Инфраструктура строится как конструктор: 50+ продуктов и сервисов можно объединить через глобальный роутер, связать с собственной инфраструктурой (настраивать гибридные решения), масштабироваться в несколько кликов. Не нужно разбираться со сложными настройками — запустить сервис можно в несколько кликов из панели управления или с помощью Terraform. Есть IAM-система для разграничения доступов и определения ролей пользователей, чтобы настроить федерации удостоверений через SSO и соответствовать требованиям корпоративной безопасности.

Биллинг и поддержка

Биллинг облачной платформы работает по модели pay-as-you-go: платите только за то, что реально используется. При этом можно сэкономить до 75%, с прерываемыми ВМ и функцией заморозки — удобно, если нужно приостановить проект или снизить расходы ночью.

Техподдержка работает 24/7, специалисты помогают с подбором необходимой инфраструктуры и решений, настройками и функциональностью. Берут полную ответственность за работу инфраструктуры и быстро решают любые возникающие вопросы. Для сложных задач, например, миграции на инфраструктуру Selectel можно подключить услугу Администрирования.

4. RTCLOUD: Гибридное облако для стартапов с масштабом и безопасностью

RTCLOUD — это гибридное облако, объединяющее локальные ресурсы с публичным облаком провайдера для создания гибкой, масштабируемой и безопасной ИТ-инфраструктуры. Подходит стартапам, которым нужно быстро адаптироваться к нагрузкам без крупных затрат.

RTCLOUD предлагает гибридное облако, объединяющее частное и публичное облако:

• Единый каталог приложений: Доступ к приложениям в обоих облаках без разделения.
• Единое адресное пространство: Перемещение виртуальных машин и приложений без изменения сетевых настроек.
• Унифицированное управление: Просмотр, копирование и перемещение нагрузок (виртуальные машины, vApp, шаблоны) между облаками.
• Инструменты мировых лидеров: Veeam Backup & Replication для репликации и управления восстановлением, vCloud Availability для миграции и Disaster Recovery (DR).

Поддерживаются сценарии:

• Уменьшение нагрузки на локальные ресурсы.
• Запуск сервисов с непроверенной нагрузкой.
• Организация тестовой площадки.
• Резервирование инфраструктуры.

Дополнительные возможности

• Облачный ЦОД: Инфраструктура без капитальных затрат, высокая надёжность, масштабирование.
• Резервный ЦОД: Быстрое восстановление с минимальным RTO.
• Объектное хранилище S3: Хранение архивов, резервных копий и медиа-контента.
• Kubernetes-as-a-Service: Готовая контейнерная инфраструктура с контролируемым периметром безопасности.
• Облачный десктоп (VDI и VDI GPU): Доступ к рабочим местам, включая производительные для конструкторов.
• Backup as a Service (BaaS): Управление копиями и расписанием для надёжного хранения.
• Размещение оборудования: Дата-центры TIER III с интеграцией облачных сервисов.

Биллинг и поддержка

• Гибкая оплата: Pay-as-you-go, без инсталляционных платежей, платите только за потреблённые ресурсы.
• Экономия: Нет затрат на покупку или модернизацию оборудования, масштабирование по потребностям.
• Техподдержка: 24/7, помощь с настройкой инфраструктуры, миграцией и решением задач.

На что ориентироваться при выборе облака

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

H3LLO.CLOUD делает ставку на доступность, предлагая стартовый набор за 5 000 рублей с виртуальными машинами, базами данных и объектным хранилищем, что идеально для небольших команд, работающих с Big Data или ИИ.

L1veStack выделяется прозрачным биллингом и нетарифицируемым порогом, помогая стартапам с ограниченным бюджетом точно прогнозировать расходы.

Selectel обеспечивает масштабируемость и безопасность, с инструментами для защиты данных, что важно для проектов с высокими требованиями к соответствию 152-ФЗ.

RTCLOUD предлагает гибридное облако, которое объединяет локальные и публичные ресурсы, позволяя масштабироваться под пиковые нагрузки и минимизировать расходы благодаря модели pay-as-you-go без инсталляционных платежей.

Одно из главных новшеств — container-aware GOMAXPROCS: теперь по умолчанию значение GOMAXPROCS учитывает лимиты CPU в cgroup.

На Linux это позволит процессам внутри контейнеров (например, в Kubernetes) автоматически адаптировать использование процессорных ресурсов к выделенной квоте.

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

Новый сборщик мусора — до 40% быстрее

В экспериментальном режиме появился garbage collector нового поколения с улучшенной локальностью и масштабируемостью.

Он особенно эффективен в приложениях с большим количеством мелких объектов, снижая накладные расходы на GC на 10–40%. Включается через GOEXPERIMENT=greenteagc.

Trace Flight Recorder: отладка по горячим следам

Введен runtime/trace.FlightRecorder — «черный ящик» для приложений на Go.

Он постоянно пишет трейс в кольцевой буфер, позволяя при наступлении события выгрузить последние секунды исполнения в файл.

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

Другие изменения в рантайме и инструментах

• Исправлена ошибка компилятора с отложенной проверкой nil, из-за которой некорректный код мог выполняться без паники.
• Добавлена поддержка DWARF5 — меньше отладочной информации и быстрее линковка.
• Улучшено выделение памяти для слайсов — быстрее в ряде сценариев.
• В Linux теперь можно видеть имена анонимных VMA ([anon: Go: heap]) в отладочных инструментах ядра.
• Новый пакет testing/synctest для тестирования конкурентного кода с виртуальным временем.
• Экспериментальный пакет encoding/json/v2 с ускоренным парсингом и расширенной конфигурацией маршалера.
• Новый метод WaitGroup.Go для удобного запуска горутин с учетом синхронизации.

Платформенные изменения

Go 1.25 требует macOS 12 и выше. 32-битная Windows/ARM-платформа будет удалена в следующем релизе.

На RISC-V появился режим сборки плагинов и поддержка профиля RVA23U64.

Классические ошибки повторяются с завидным постоянством. В недавнем выпуске подкаста «Техно.Логично» наши коллеги Владимир Герциков и Николай Волынкин как раз обсуждали типичные проблемы с базами данных — от выбора инструментов до падений в продакшне. Послушав коллег, мы решили не пересказывать их беседу целиком, а на основе их беседы сделать практический список вредных советов.

Получился антигайд: как гарантированно завалить базу данных — и что делать правильно. Если узнаете себя в этих советах, не расстраивайтесь. Через подобное проходят все. А если хотите услышать полную дискуссию о современных СУБД, инструментах и миграции на open source — послушайте оригинальный выпуск.

1. Временные файлы бесконечны — лейте терабайты джойнов

Берите две таблицы по миллиону записей каждая, смело делайте JOIN без WHERE, сортируйте результат — и удивляйтесь, почему закончилось место под временные данные.

Что происходит: PostgreSQL создает временные файлы в pg_tmp для обработки больших запросов. Когда места не хватает, падают конкретные запросы с ошибкой No space left on device, а не весь сервер. Особенно болезненно там, где несколько таких запросов запускаются параллельно — временное пространство переполняется быстрее, чем успевает сработать мониторинг.

Как делать правильно: Планируйте размер временных данных заранее. Добавляйте фильтры перед джойнами, разбивайте сложные запросы на этапы. Настройте temp_file_limit для ограничения временных файлов на запрос и мониторинг заполнения. Если ваш запрос генерирует терабайты промежуточных результатов, скорее всего, есть способ сделать это эффективнее.

2. Суперпользователь для всех задач — что может пойти не так

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

Реальная история: Разработчик развернул постгрес на виртуалке с дефолтными настройками — порт 5432 открыт, пользователь postgres/postgres с правами суперпользователя. Через семь (!) секунд в базу начали ломиться боты. Боты сканируют интернет на стандартные порты СУБД постоянно и превращают сервер в майнинг-ферму быстрее, чем вы успеете допить кофе. Диск переполнился от созданных таблиц, установились неизвестные расширения, начались HTTP-вызовы из базы наружу. Сервер превратился в часть ботнета.

И так все понятно, но еще раз напомним: Суперпользователь может подключить postgres_fdw, dblink и читать/писать любые базы кластера, создавая запросы, которые переполнят временное пространство за минуты. Неподписанные расширения могут содержать что угодно — от бэкдоров до майнеров. А если расширение вызовет segmentation fault, упадет вообще все.

Принцип минимальных прав: Создавайте отдельных пользователей с минимально необходимыми правами. Устанавливайте только официально поддерживаемые расширения. Закрывайте базу от внешнего доступа файрволом, настройте TLS для шифрования трафика, используйте fail2ban против брутфорса и уникальные пароли. Это кажется очевидным, но количество баз с дефолтными паролями в интернете говорит об обратном.

3. Держите транзакции открытыми — счетчик XID все стерпит

Открывайте длинные транзакции и держите их днями. Постгерс умный, сам разберется.

Что сломается: У PostgreSQL есть счетчик транзакций (XID), который может переполниться. Когда возраст транзакций становится критическим, сервер блокирует обычные подключения и пускает только суперпользователя для выполнения VACUUM FULL. Все приложения встают, начинается паника.

Как избежать: Настройте timeout для idle in transaction состояний. Разбивайте большие батчи на маленькие операции. Мониторьте возраст самых старых транзакций. И запомните: транзакция, которая висит неделю, — это не фича, это бомба замедленного действия.

4. На каждый SELECT — свой индекс

Создавайте индекс под каждый запрос. Чем больше индексов, тем быстрее будет работать.

Почему это убивает PostgreSQL: В отличие от других СУБД, PostgreSQL при UPDATE создает новую версию записи, а старую помечает как мертвую. Если у таблицы 30 индексов, каждый UPDATE генерирует 30 мертвых ссылок в индексах. VACUUM начинает работать постоянно, производительность рушится.

Правило 20/80: Покройте индексами 20% самых частых запросов, которые дают 80% нагрузки. Остальную аналитику выносите на реплику для чтения. Регулярно анализируйте статистику использования индексов — неиспользуемые безжалостно удаляйте .

5. Сайзинг не нужен

Ресурсы бесконечны. А DBA разберутся, как бэкапить ваши 100 терабайт.

Физические ограничения: Таблица в PostgreSQL не может быть больше 32 терабайт при дефолтном размере блока. Ограничение можно обойти партиционированием или пересборкой с увеличенным размером блока, но лучше планировать заранее.

Экономика: «Эта функция будет стоить как два сервера, потому что нам нужно оборудование для бэкапа 50-терабайтной базы». В этот момент «бизнес» делает большие глаза и внезапно появляется мотивация оптимизировать архитектуру.

Планирование: Считайте размер данных на год-два вперед. Внедряйте партиционирование с первого дня, если ожидаете рост. Архивируйте старые данные. Удалить лишнее проще, чем добыть дополнительные терабайты дискового пространства в пятницу вечером.

6. Пихайте СУБД в контейнеры

Kubernetes решает все проблемы! Поэтому переносим в контейнеры все, базы данных тоже. Если что-то работает на виртуалках, то в контейнерах точно будет работать лучше.

Проблемы слоеного пирога: Мы слышали, тебе нравится виртуализация, поэтому мы добавили виртуализацию в твою виртуализацию. В результате кратное усложнение отладки. Где тормозит база: железо, гипервизор, менеджер контейнеров?

Где контейнер оправдан? В CI/CD, локальной разработке, тестовых средах. В продакшне контейнеры тоже работают, если использовать Kubernetes-операторы (Patroni, CloudNativePG), правильно настроить Persistent Volumes и протестировать поведение при рестартах. База должна жить в памяти, прогревать кэши, работать стабильно. Но это требует серьезной экспертизы в Kubernetes и готовности разбираться с проблемами на стыке технологий. Если команда не готова изучать все тонкости — лучше не начинать.

Компромисс: Если выбираете контейнеры для продакшна, используйте StatefulSet, настройте правильные storage-классы и OOM-политики. Для stateless-сервисов контейнеры — отличный выбор.

7. Всю бизнес-логику держим в хранимках — так быстрее

Переносите всю логику в базу. Зачем нужны сервисы приложений?

Пример из практики: Система с хранимыми процедурами Oracle обыграла Java-реализацию в тестах производительности. Логика выполнялась рядом с данными, без сетевых задержек. Но когда нагрузка выросла в разы, уперлись в лимит CPU на сервере баз данных. Добавить ресурсы оказалось сложнее, чем масштабировать stateless-сервисы.

Компромисс: Тяжелые агрегации и отчеты делайте в функциях базы. CRUD-операции выносите в сервисы приложений. Следите за загрузкой CPU на сервере БД — когда она приближается к пределу, начинайте выносить логику наружу.

8. Коммерческая СУБД — единственный путь

Только коммерческие решения подходят для серьезных задач. Oracle и SQL Server проверены временем, а всякие open source базы — это для студентов и стартапов.

Что изменилось: События последних лет заставили многие компании пересмотреть подход к выбору СУБД. Компании массово переходят на PostgreSQL Pro и другие open source решения. Тренд только усиливается — игнорировать open source значит отстать от рынка и пропустить инновации, которые часто появляются именно в открытых проектах.

НО: Vanilla PostgreSQL без поддержки — это действительно риск. Когда расширение Oracle FDW падает с разными структурами таблиц, а автор из коммьюнити отвечает «мне в голову не приходило, что кто-то будет так делать», понимаешь ценность платной поддержки. Поэтому open source, но с поддержкой от надежных вендоров.

Заключение

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

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

Цифровой контент — актив, который требует защиты не меньше, чем банковские данные. Многие привыкли, что свежий сериал или долгожданный фильм оказывается в сети за неделю до премьеры или в день релиза, а дорогостоящий курс можно скачать бесплатно на «складчинах». В 2024 году пиратство нанесло российским правообладателям ущерб в 3,36 млрд рублей, а глобальные потери медиаиндустрии превысили $71 миллиард. Утечки контента происходят через уязвимости в системах доставки, запись экрана или взлом серверов.

Но угрозы безопасности видеконтента не ограничиваются пиратством. Кибератаки добавляют новый уровень сложности: в отличие от пиратов, которые стремятся монетизировать контент через нелегальное распространение, хакеры могут преследовать иные цели — от вымогательства до саботажа инфраструктуры. Например, говорить, что в их распоряжении есть интимные видеозаписи жертвы (ещё лучше, если это CEO известной компании) и вымогать крупную сумму денег. Или взломать Rutube и саботировать инфраструктуру сервиса, как это было в 2022 году. Киберугрозы также могут включать DDoS-атаки, эксплуатацию уязвимостей в API или кражу пользовательских данных, что приводит к последствиям:

• Коммерческие риски: снижение выручки, подрыв бизнес-модели, что особенно актуально для премиальных и эксклюзивных материалов и сервисов.
• Правовые последствия: иски от правообладателей или штрафы за утечку персональных данных.
• Репутационные издержки: утрата доверия пользователей и партнеров, особенно если платформа позиционируется как безопасная.

Важно понимать, что защита должна учитывать не только копирование контента, но и целостность всей экосистемы — от API до клиентского плеера.

Многоуровневая защита: из чего она состоит

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

1. Защита от несанкционированного доступа и копирования

Первый барьер — ограниченный доступ к контенту:

• Шифрование: AES-128 или AES-256 для защиты видеопотоков.
• Авторизация: токены JWT или OAuth для проверки прав пользователей.
• Системы управления цифровыми правами (DRM) устанавливают ограничения на воспроизведение контента — по устройствам, географическому положению и времени. Если отсутствует соответствующий ключ шифрования, выдаваемый лицензионным сервером, воспроизведение может быть заблокировано.

2. Пиратские копии

Даже если контент уже украден, важно оперативно выявить его нелегальное распространение. Технологии AI-мониторинга и цифровой форензики сканируют даркнет, соцсети и пиратские сайты. ИИ распознает видео по фрагментам, даже если оно перекодировано.

Технический нюанс: ИИ-системы используют сверточные нейросети (CNN) для анализа визуальных и аудиохарактеристик. Разработчикам стоит интегрировать такие решения через API, например, от Google Cloud Vision или специализированных вендоров.

3. Отслеживание источника утечки

Ключевой вопрос при утечке: кто и как получил доступ к контенту? Водяные знаки и «цифровые отпечатки» (fingerprinting) позволяют встраивать уникальные идентификаторы в видеофайлы. Fingerprinting, например, создает хэши аудио- и видеофрагментов для поиска копий.

Технический нюанс: сессионные водяные знаки добавляют задержку в стриминг. Проблема решается предварительной обработкой сегментов для HLS/DASH-протоколов.

4. Противодействие пиратским ресурсам

Удалить копии после обнаружения можно через:

• Обращение в РКН и к платформе, где появилось видео. Если реакции от платформы нет, РКН или провайдер хостинга заблокируют сайт по запросу.
• Автоматическую блокировку ссылок через API хостингов.
• Юридическое давление на пиратские платформы.

Технологии против пиратов: DRM, ИИ, водяные знаки и «цифровые отпечатки»

Современные решения для защиты видео объединяют несколько технологий, каждая из которых решает определенные задачи. Рассмотрим их подробнее.

DRM (управление цифровыми правами)

DRM-системы шифруют контент и управляют лицензиями на доступ к видеопотоку. DRM защищает контент на уровне клиента и сервера, предотвращая неавторизованный доступ и перехват. Такие системы интегрируются в плееры и платформы и показывают контент только авторизованным пользователям.

DRM-системы опираются на три ключевых компонента:

1. Лицензионный сервер отвечает за выдачу и проверку ключей расшифровки контента.
2. Клиентская часть DRM (Content Decryption Module, CDM) интегрирована в браузер/плеер.
3. Упаковщик контента (Packager) подготавливает видеопотоки для защищенной доставки.

Но есть техническая проблема совместимости — DRM-системы неоднородны по платформам:

• Widevine (Android, Chrome, Firefox, Opera);
• PlayReady (Windows, Xbox, некоторые Smart TV);
• FairPlay (экосистема Apple);
• WisePlay DRM (экосистема Huawei).

Решение — мульти-DRM упаковщики, поддерживающие все стандарты через единую интеграцию. Используйте библиотеки, например, Shaka Player, для упрощенной интеграции мульти-DRM.

Водяные знаки (Digital Watermarking)

Водяные знаки — метки, встроенные в видео, которые содержат информацию о правообладателе или пользователе, что помогает отследить источник утечки, если контент появляется на пиратских ресурсах. Они могут быть видимыми или незаметными: первые отпугивают пиратов, а вторые помогают отследить источник утечки.

Отслеживание «цифровых следов» (Fingerprinting)

В отличие от водяных знаков, которые внедряются в контент, технология фингерпринтинга генерирует хэши фрагментов видео и аудио для поиска копий в сети без модификации самих файлов. Это позволяет находить пиратские копии, даже если они были изменены (например, перекодированы или обрезаны). Работает это так: система создает «цифровой отпечаток» оригинального видео и затем автоматически сканирует интернет в поисках материалов с похожими характеристиками.

Например, YouTube Content ID верифицирует права на материалы и затем в автоматическом режиме отслеживает загрузки на платформе. Когда пользователь загружает видео, Content ID сравнивает его с базой отпечатков, и, если обнаруживает совпадение с материалами, может заблокировать ролик за нарушение авторских прав, перенаправить доход от рекламы правообладателю или уведомить владельца контента.

Цифровая форензика

Цифровая форензика — это сбор и исследование данных для раскрытия цифровых преступлений. Проще говоря, цифровая криминалистика. Специалисты-форензики анализируют источники пиратских копий через анализ метаданных, характеристик кодирования, артефактов сжатия и других цифровых «улик», чтобы выявить, как и когда произошла утечка. Например, уникальные артефакты в H.264-кодеке могут указать на устройство, с которого записали экран.

AI-мониторинг

Искусственный интеллект ускоряет поиск пиратских копий через анализ огромных массивов данных в интернете с помощью компьютерного зрения и машинного обучения. ИИ-системы мониторинга используют сверточные нейросети (CNN), которые способны распознавать визуальные образы и алгоритмы, такие как Mel-Frequency Cepstral Coefficients (MFCC) (используется для распознавания речи). С их помощью можно находить копии даже при перекодировании или обрезке.

Уже существует множество готовых решений на основе ИИ. Например, Red Points постоянно мониторит соцсети, видеоплатформы и пиратские сайты с применением машинного обучения, компьютерного зрения и распознавания изображений, а при обнаружении совпадений автоматически отправляет запросы на удаление через API. Piracymeter и Bytescare анализируют списки доменов, поисковые результаты Google и торрент-трекеров. Bytescare также может находить пиратские копии ПО.

Такие решения быстрее ручного мониторинга и больше подходят для больших каталогов видео. Они могут работать автономно или подключаться через REST API, но требуют настройки для снижения ложных срабатываний.

Пример комплексного подхода к защите видео

Для защиты видеоконтента компании всё чаще используют решения, которые сочетают несколько технологий. Например, разработчик систем безопасности GS Labs совместно с видеохостингом Kinescope создал систему, интегрирующую DRM, водяные знаки и цифровую форензику. Она позволяет шифровать контент, встраивать уникальные идентификаторы для отслеживания утечек и анализировать источники пиратских копий. Такое решение работает как в облаке, что даёт стриминговым платформам масштабируемость, так и локально, что важно для компаний с собственной инфраструктурой.

Модели внедрения технологий защиты видеоконтента

Выбор модели внедрения зависит от потребностей компании, ее бюджета и технических возможностей. Рассмотрим три основные модели.

Локальные решения (on-premises)

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

Облачные/SaaS-решения

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

Совет: используйте облачные решения с SOC 2 или ISO 27001 сертификацией для защиты данных.

Гибридные модели

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

Совет: используйте Kubernetes для оркестрации гибридных систем и минимизации downtime.

Что стоит сделать прямо сейчас, чтобы защитить видеоконтент

1. Подобрать постоянное комплексное решение: исследуйте вендоров и технологии на рынке.
2. Провести аудит инфраструктуры: проверьте уязвимости в CDN, API и плеере, например, с помощью OWASP ZAP.
3. Интегрировать DRM: выберите мульти-DRM решение, совместимое с Widevine, PlayReady и FairPlay.
4. Внедрить мониторинг: подключите ИИ через API для поиска копий.
5. Провести пентесты в BurpSuite, симулируя пиратские атаки и взлом.
6. Отработать реакцию на инциденты.

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

В мае 2024 по всему миру разлетелись скриншоты писем от HR с внезапными повышениями зарплат на 40%. Текучка кадров в сфере производства полупроводников выросла с 40% до 53%, и теперь компании дерутся за каждого специалиста.

Масштаб проблемы

169 отраслей пострадали из-за дефицита чипов — от автомобилестроения до бытовой техники. Tesla и Volvo останавливали заводы, цены на подержанные автомобили выросли на 10% за квартал. Даже стиральные машины подорожали из-за недостатка микросхем.

Но настоящая битва кипит в кабинетах бигтехов. США заблокировали экспорт технологий в Китай, Европа запустила программу на €43 миллиарда, а Азия удерживает 77% мирового производства чипов.

Технологическая война изменила ИТ-индустрию навсегда. Компании теперь не могут просто купить больше серверов — приходится искать тех, кто умеет делать софт быстрее и эффективнее. Apple создала собственные M1 и M2, Google разработал TPU, Amazon — процессоры Graviton. Каждый хочет стать независимым от поставок.

Обрушение цепей поставок

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

Мир оказался в заложниках у нескольких азиатских гигантов. Тайвань контролирует 65% мирового рынка чипов, TSMC делает процессоры для Apple, AMD и NVIDIA. Samsung доминирует в производстве памяти и накопителей.

Различные отрасли посыпались, как домино. Время ожидания полупроводников Broadcom выросло до 22 недель против 12 недель в феврале 2020. Автоиндустрия потеряла миллионы машин, дата-центры замедлили расширение, даже PlayStation 5 стали дефицитом.

США первыми объявили технологическую войну. Пошлины уже изменили процессы производства у Nvidia, Intel и AMD. Китай ответил санкциями против Micron Technology.

Ключевые игроки разделились на два лагеря. На стороне США — Intel, NVIDIA, AMD, Qualcomm. Китай развивает SMIC и вкладывает миллиарды в собственные технологии. TSMC и Samsung балансируют между сторонами, строя заводы и в Америке, и в Азии.

Национальные программы превратились в гонку вооружений. CHIPS Act выделил $50 миллиардов на американское производство. Европейская программа нацелена на производство 20% мировых чипов к 2030 году. Китай инвестирует $143 миллиарда в полупроводники.

Гонки в мире чипов

Рынок AI-чипов взлетел в 15 раз за десятилетие. Компании научились делать процессоры умнее, но каждое новое поколение требует больше денег и экспертизы.

Техпроцессы сжимаются в размере. TSMC освоила 3-нанометровый процесс, Samsung догоняет. Каждый нанометр стоит миллиарды инвестиций и годы разработки. Apple M4 имеет Neural Engine в три раза быстрее M1, но производство одного такого чипа требует сотни инженеров.

AI-чипы стали новой золотой жилой. Intel запустила Gaudi 3, который на 50% быстрее NVIDIA H100. NVIDIA ответила платформой Blackwell с 208 миллиардами транзисторов. Qualcomm Cloud AI 100 обошел H100 по энергоэффективности — 227 запросов на ватт против 108.

Квантовые технологии пока остаются в лабораториях, но IBM и Google уже тестируют прототипы. Нейроморфные чипы, которые имитируют работу мозга, обещают революцию в энергоэффективности.

Делать чипы стало сложнее и дороже. Современная фабрика стоит $20 миллиардов, срок окупаемости — 10 лет. Поэтому крупные компании строят собственные решения: Apple создала M-серию, Google — TPU, Amazon — Graviton.

Компании поменяли философию. Вместо покупки большего количества серверов они нанимают инженеров для оптимизации кода. Netflix использует персонализированные рекомендации и алгоритмы ранжирования для оптимизации вычислений. Meta* оптимизировала машинное обучение и уменьшила количество GPU на 40%.

Массовый переход на ARM изменил рынок. Amazon перевела часть ресурсов на собственные процессоры. Microsoft адаптировала Windows под ARM-архитектуру. Даже Intel вынуждена выпускать подобные решения.

Россия также планирует наладить массовое производство 28 нм чипов к 2030 году. Росатом присоединился к разработке нейроморфных процессоров. Сбер тестировал отечественный Эльбрус-8С, но выявил проблемы с памятью и оптимизацией.

*– компания признана в РФ экстремистской и запрещена.

Айтишники в центре шторма

Зарплаты разработчиков взлетели вместе с ценами на чипы. Средняя зарплата embedded-инженера выросла до $153,383, а топовые специалисты получают до $175,000 в год. Performance-инженеры зарабатывают в среднем $100,522, но спрос превышает предложение. Оптимизация под ARM-архитектуру, разработка драйверов для AI-ускорителей, программирование FPGA — навыки, за которые компании готовы переплачивать. IT-зарплаты в Северной Америке выросли в среднем до $113,211.

Embedded-разработчики неожиданно стали востребованнее ML-инженеров. Когда Tesla не может купить нужные чипы, она нанимает программистов, которые выжмут из имеющихся процессоров максимум. Один такой специалист экономит компании миллионы долларов на железе.

География возможностей сместилась. Калифорния лидирует по зарплатам — $126,707 в Сан-Хосе, но спрос есть везде. Даже компании из Техаса и Флориды переманивают embedded-разработчиков зарплатами в $120,000-150,000.

Системные администраторы, знающие Kubernetes и контейнеризацию, стали дефицитом. Компании переходят на микросервисы и edge-решения — нужны те, кто умеет управлять распределенной инфраструктурой.

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

Свет в конце туннеля

Эксперты расходятся в прогнозах восстановления. CEO Intel Пат Гелсингер ожидал дефицит до 2024 года, но рынок полупроводников уже показал рост на 15,2% в начале года. К 2023-му автоиндустрия в основном восстановилась, глобальное производство автомобилей выросло на 3%.

Новые фабрики меняют географию производства. Intel строит заводы в Аризоне за $20 миллиардов и расширяется в Огайо. TSMC открыла завод в Японии в феврале 2024 и планирует второй к 2027 году. Samsung инвестирует в производство в Техасе.

Европа также входит в игру. European Chips Act нацелен на производство 20% мировых чипов к 2030 году с бюджетом €43 миллиарда. Intel проектирует заводы в Ирландии и Германии, Micron строит завод в Нью-Йорке, а GlobalFoundries расширяется на Мальте.

Будущее отрасли — в диверсификации. Тайвань по-прежнему контролирует 65% производства, но объемы будут снижаться. К 2030 году США планируют удвоить свою долю в мировом производстве чипов.

За четыре года индустрия изменилась больше, чем за предыдущее десятилетие. Компании научились строить собственные чипы, программисты — выжимать максимум из доступных ресурсов, а правительства — инвестировать в технологическую независимость.

Бигтехи готовы переплачивать за надежность поставок и «мозги». Программисты в выигрыше: чем сложнее становится производство чипов, тем больше нужно людей, которые умеют эффективно их использовать.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

Когда мы говорим об углеродном следе ПО, важно понимать: код не существует в вакууме. Каждая строка, каждый запрос и каждая операция требуют физических ресурсов — электричества, серверного оборудования, систем охлаждения. В 2025 году эта цепочка стала еще сложнее из-за взрывного роста облачных вычислений и ИИ.

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

Эти тренды нацелены на долгосрочное действие и в перспективе должны полностью изменить текущую концепцию в разработке.

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

Компании, внедрившие принципы устойчивого развития в IT, уже в 2025 году получают на больше инвестиций и быстрее проходят аудит регуляторов. Экологичность перестала быть затратой — теперь это конкурентное преимущество.

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

Экологичность в IT — не благотворительность и не актуальная повестка, а реальная экономия. Плюс работа на перспективу. Оптимизация кода снижает счета за облака и повышает производительность.

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

Что такое Kaniko и зачем он был нужен

Kaniko — это инструмент от Google для сборки OCI-совместимых образов контейнеров внутри контейнеров без необходимости root-доступа и запуска Docker-демона. Он получил широкое распространение как решение для CI-сборок в Kubernetes, особенно в таких платформах, как GitHub Actions и GitLab CI.

Преимущества Kaniko

Безопасность: не требует привилегий (rootless). Kaniko может запускаться в обычном (непривилегированном) контейнере, без необходимости доступа к root. Это значительно повышает безопасность, так как сборка образа происходит изолированно и не требует доступа к системным ресурсам.

Например, в Kubernetes можно создать под с Kaniko, где контейнер работает с обычным пользователем без securityContext.runAsRoot: true. Это значит, что злоумышленник не сможет получить root-доступ через этот контейнер.

Простота: легко запускать как задачу (Job) или контейнер в Kubernetes. Kaniko легко интегрируется в Kubernetes — он просто запускается как обычный контейнер, который выполняет сборку образа и загружает его в реестр. Не нужно устанавливать и настраивать Docker-демон.

Так выглядит запуск сборки в GitLab CI/CD с использованием Kaniko:

Совместимость: поддержка стандартных Dockerfile. Kaniko понимает обычные Dockerfile и может собрать образ из них, не требуя переписывать или адаптировать существующие инструкции.

Например, если есть обычный Dockerfile…

… то можно просто указать Kaniko использовать этот Dockerfile, и он построит такой же образ.

Конец поддержки Kaniko и альтернативы

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

Несмотря на то, что вскоре начали появляться форки (самый заметный — это chainguard-dev/kaniko), они ориентированы на режим поддержки (фикс багов и безопасность), а не на дальнейшее развитие инструмента. Поэтому многие пользователи ищут замену Kaniko — если и не сегодня, то в обозримом будущем.

Наиболее популярные в сообществе альтернативы:

• BuildKit от Docker/Moby (особенно в связке с docker buildx);
• Buildah от Red Hat из экосистемы Podman. Стал Sandbox-проектом CNCF в январе 2025 года.

Почему стоит рассмотреть werf и как начать

Помимо низкоуровневых инструментов, таких как Kaniko, BuildKit и Buildah, существует также высокоуровневое решение — werf. Это production-ready-инструмент, предназначенный не только для сборки, но и для доставки контейнеров в Kubernetes. Утилита позволяет использовать любую предпочтительную CI-систему. Является Sandbox-проектом в CNCF.

Что предлагает werf:

• Native Kubernetes-ориентированная архитектура, то есть можно легко интегрировать сборку, деплой и управление приложениями прямо в Kubernetes-кластере.
• Поддержка Buildah или BuildKit в качестве backend для сборки, причём Buildah полностью интегрирован в werf и может работать в rootless-режиме. Это позволяет собирать образы без необходимости запуска процессов с правами root.
• Удобная интеграция с другими инструментами доставки софта в Kubernetes (включая GitLab, GitHub Actions и Argo CD). Например, связка из werf и Argo CD позволяет полностью интегрировать между собой любую CI/CD-систему и Argo CD. При этом от каждого из инструментов берутся свои возможности и особенности.

• Автоматическое кэширование сборки и тегирование на основе содержимого, как результат — инкрементальные сборки и оптимальное использование container registry.
• Надёжное развёртывание и управление релизами в Kubernetes. werf расширяет возможности Helm, используя встроенный инструмент Nelm, который обеспечивает точное отслеживание состояния ресурсов, умное ожидание их готовности, мгновенное завершение проблемных релизов и применяет более надёжный метод обновления ресурсов — Server-Side Apply. При этом сохраняется полная совместимость с Helm-чартами и релизами.
• Дистрибуция релизных артефактов. Утилита упаковывает Helm-чарт и связанные с ним образы контейнеров в единый бандл, который затем можно опубликовать в OCI-совместимый реестр. Кроме того, бандлы можно копировать между реестрами, выгружать на USB-флеш-накопитель и развёртывать в Kubernetes с помощью werf или других решений, которые поддерживают работу с OCI-чартами (Helm, Flux, ArgoCD).
• Умная очистка container registry, которая автоматически удаляет неактуальные теги образов с учётом их использования в Kubernetes и истории Git, что позволяет безопасно освобождать место и контролировать рост хранилища без риска удаления нужных образов.

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

Как будет выглядеть werf в CI/CD-системах? В общем случае достаточно добавить в свой пайплайн CLI-команду werf converge, которая собирает образ, пушит его в registry и выкатывает в Kubernetes.

Листинг с конфигурацией .github/workflows/converge.yml для использования werf в GitHub Actions может выглядеть так:

А использовать werf в GitLab CI/CD можно так:

Более подробные инструкции для доставки приложений в Kubernetes с werf можно найти в официальном руководстве по началу работы проекта.

В документации можно найти интерактивные сценарии, пояснения терминов, готовые CI-конфигурации и Helm-интеграцию. Всё это будет полезно и новичкам, и опытным DevOps-инженерам.

Вместо заключения

Поскольку Kaniko больше не развивается, многие могут задуматься о миграции на другой инструмент. Помимо очевидных вариантов вроде BuildKit и Buildah, рекомендуем попробовать werf. Он подойдет, если вам нужен CI-first-подход с нативной Kubernetes-интеграцией и интересны дополнительные фичи «из коробки» для CI/CD, например дистрибуция релизных артефактов и умная очистка container registry.

Чтобы попробовать werf, переходите на официальный сайт утилиты и изучайте подробную документацию с пошаговыми руководствами и примерами.

Реклама. Рекламодатель: АО «Флант». ИНН 772366143. erid: 2W5zFGNuWcp.

Давайте представим ситуацию, что нужно запустить код, минуя все эти стадии. Прям в production-среде. На первый взгляд — бред! Но если подумать, то на самом деле, не такая уж редкость. Например, некоторые системы предоставляют своим пользователям возможность расширять функциональность за счет прикладных скриптов. Наш любимый CI/CD-конвейер зачастую построен на пользовательских скриптах.

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

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

• Код, который не прошел CI, review и т.п.
• Код из ненадёжного или неизвестного источника.
• Закрытый (проприетарный) код.
• Код, содержащий уязвимости.
• Код, использующий запрещенные функции.
• Любой код, который написал коллега:)

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

Уровни изоляции кода

Можно выделить три варианта запуска внешнего кода — три уровня изоляции. Каждый следующий увеличивает дистанцию между кодом приложения и запускаемым кодом. Чем выше уровень изоляции, тем меньше вероятность, что запускаемый код нанесет вред приложению и системе.

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

Дополнительно запускаемый код можно подвергать строгому (синтаксическому) анализу, запрещая использование определенных функций, модулей, пакетов и т.п. Некоторые интерпретаторы имеют точки расширения, которые позволяют контролировать процесс исполнения. Если такой возможности нет, можно воспользоваться одной из техник самоизоляции — фильтрацией системных вызовов.

Что же касается плагинов, то они призваны расширять возможности приложения, поэтому их использование изначально не предполагает сильной изоляции. Здесь можно предложить усилить контроль взаимодействия на уровне контракта (API). В идеале — если плагины будут публиковаться в некоторый центральный репозиторий, которому вы доверяете и который может производить дополнительные проверки и тестирование до этапа запуска кода плагина.

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

Поскольку и приложение, и внешний код взаимодействуют в рамках одного узла, используя локальные ресурсы ОС (оперативная память, файловая система и т.п.), скорость межпроцессного взаимодействия очень высокая.

Этот уровень изоляции предполагает использование широкого арсенала возможностей. Как минимум, внешний код может быть запущен от имени менее привилегированного пользователя, с ограниченным доступом к ресурсам ОС. Сильные способы изоляции ограничивают ресурсы с помощью средств ОС или инструментов контейнеризации. Однако, чем сильнее контроль, тем больше накладных расходов на запуск и исполнение процесса, что при решении некоторых задач неприемлемо дорого или неоправданно сложно.

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

Это максимальный уровень изоляции из всех возможных. Здесь появляется возможность ограничить ресурсы самой песочницы (CPU, память, дисковое пространство, доступ к сети и т.п.). Если в результате исполнения внешнего кода песочница выйдет из строя, приложение продолжит свою работу.

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

Использование песочницы

Предположим, требуется максимальный уровень изоляции ненадёжного кода, следовательно, нужно остановиться на варианте запуска на отдельной машине. Если так, то для принятия последующих архитектурных решений нужно ответить на следующую пару вопросов.

Пересоздание или переиспользование песочницы

Песочницу требуется пересоздавать перед исполнением каждой задачи, если требуется особенное окружение (например, определенная версия ОС, пакетов или ресурсов) или идентичность этого окружения (для стабильности получаемых результатов). Схожие вопросы возникают, например, при интеграционном тестировании: каждому тесту нужны свои предустановки.

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

Последовательное или параллельное исполнение

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

• важен порядок следования и исполнения задач;
• задачам нужен эксклюзивный доступ к определенному ресурсу;
• задачи ёмкие и их совместное исполнение вызовет нехватку ресурсов;
• задачи могут мешать исполнению друг друга из-за борьбы за ресурсы.

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

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

Последовательное исполнение обеспечивает стабильность получаемых результатов, однако приводит к низкой пропускной способности и дороговизне масштабирования (песочница обходится дороже процесса ОС). Параллельное исполнение, напротив, увеличивает пропускную способность системы и улучшает утилизацию ресурсов песочницы, но одновременно повышает вероятность нестабильных результатов. Более того, при параллельном исполнении появляется шанс перегрузить песочницу или вывести её из строя таким образом, что приведет к увеличению времени исполнения всех запущенных задач или потере результатов их работы.

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

Управление песочницами

Допустим, переиспользование песочниц возможно. В таком случае необходимо определить способ управления ими. Можно выделить два подхода, основанные на принципах микросервисной архитектуры, но адаптированные к специфике рассматриваемой проблемы.

Оркестрация

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

Основное преимущество оркестрации в контексте решаемой проблемы — её простота и ясность. Код легко читается и сосредоточен в одном месте. Однако у этого решения есть и недостатки. Рассмотрим их в порядке от простого к сложному.

• Синхронное взаимодействие. Так или иначе, для результата приложение вынуждено ожидать окончания исполнения задачи. Для продуктивного использования ресурсов приходится прибегать к техникам асинхронного программирования: пока задача исполняется, приложение будет занято полезной работой. Это малозаметный недостаток в языках со встроенной поддержкой концепции асинхронного программирования. Для упрощения работы с асинхронным кодом в Java я создал небольшую вспомогательную библиотеку asynchronizer, снабдив её подробной документацией.

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

• Отслеживание загруженности песочниц. Оркестратор исполнения должен выбрать подходящую стратегию балансировки, основанную на состоянии песочниц, предоставляемых оператором. На практике наилучшую эффективность демонстрирует алгоритм Least connections, с помощью которого можно выбирать наименее загруженные песочницы. Для этого достаточно вести учёт количества задач, исполняемых каждой песочницей. Конечно, это не серебряная пуля, а лишь частное наблюдение, поэтому в идеале нужно предусмотреть несколько стратегий балансировки и выбрать наилучшую по результатам нагрузочного тестирования.

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

Ещё один существенный минус, который стоит упомянуть, это возможный побочный эффект, возникающий при масштабировании системы и проявляющийся в виде перегрузки песочниц. Для наглядности рассмотрим конкретный пример.

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

Добавив новый экземпляр приложения, неизвестно, сколько задач исполняет каждая песочница. Такая ситуация может произойти по разным причинам.

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

• Выделить каждому экземпляру приложения эксклюзивное подмножество песочниц. Подобное решение существенно усложнит deployment-скрипты и процесс масштабирования, а также снизит степень утилизации выделенных ресурсов, ведь нет никаких гарантий того, что экземпляр приложения сможет хорошо нагрузить все выделенные ему песочницы.

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

Основной недостаток самоорганизации — распределённый процесс обработки задач. Учитывая простоту алгоритма обработки, это не так существенно. Стоит отметить преимущества этой архитектуры.

• Максимальная изоляция ненадёжного кода. Ненадёжный код, как и в случае с оркестрацией, по-прежнему работает в песочнице в рамках отдельного процесса ОС.

• Скорость и стабильность взаимодействия. Никаких проблем с сетью из-за локальности взаимодействия между агентом и песочницей.

• Контролируемая нагрузка на песочницы. Агент, выступая в роли консюмера очереди задач, может точно контролировать степень параллелизма и выбирать новые задачи только тогда, когда он закончил обрабатывать предыдущие.

• Минимум инфраструктурного кода. Очереди избавляют от необходимости иметь оператор песочниц, отслеживать их состояние и осуществлять балансировку нагрузки.

• Простота масштабирования. Приложение и песочницы масштабируются независимо друг от друга без негативных побочных эффектов.

Запуск процесса ОС

К запуску процесса ОС, в рамках которого будет исполняться ненадёжный код, нужно подойти с особой осторожностью. Здесь важно ответить как минимум на три вопроса.

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

• Как ограничить объем используемых ресурсов. Для запускаемого процесса нужно определить доступные ресурсы и возможные действия.

• Как осуществлять анализ поведения и результатов исполнения. Наличие и решение этой проблемы целиком и полностью зависит от специфики проекта. Здесь невозможно предложить универсального решения.

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

• Лимиты узла. Физические ограничения машины, на которой исполняется процесс. В частном случае можно говорить об инфраструктурных лимитах, определённых для Docker/Kubernetes контейнера.

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

• Лимиты процесса. Программные лимиты, задаваемые средствами ОС. На этом уровне можно осуществлять гибкую настройку вариантов запуска и исполнения.

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

Между тем, важно отметить некоторые трудности, которые могут возникнуть при использовании инструментов контейнеризации.

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

Подобная вариативность осложняет анализ поведения и результатов исполнения. В этом случае можно использовать подход с программной мягкой границей (watchdog limit). Суть заключается в запуске дополнительного следящего потока (или процесса) ОС, который контролирует поведение и расход ресурсов у наблюдаемого. Как только детектируется превышение одного из лимитов, производится принудительное завершение наблюдаемого процесса, но уже не со стороны ОС, а со стороны приложения.

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

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

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

• Плохая масштабируемость. Соотношение приложение-песочница всегда один к одному. Однако не исключено, что в некоторых случаях это вполне приемлемо.

• Плохая утилизация ресурсов. Сможет ли приложение достаточно нагрузить песочницу, если количество песочниц будет в избытке; и наоборот, нужно ли столько же экземпляров приложения, сколько и песочниц.

• Возможность перегрузки песочницы. В распоряжении экземпляра приложения только одна песочница, которая может не справиться с потоком задач, обрабатываемых приложением.

• Риск нарушить работоспособность приложения. Выход песочницы из строя скорее всего приведет к перезапуску всего пода. Более того, если приложение и песочница обмениваются файлами через общий раздел (shared volume), это может стать уязвимым местом.

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

• Создать непривилегированного пользователя, ограничив ему права на доступ к ресурсам.

• Регулярно сканировать версии образов и пакетов на наличие уязвимостей.

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

• Установить приемлемый лимит на PIDs. Необходимо контролировать число активных процессов в системе. Особо вредоносный код может попытаться создать очень много дочерних процессов, поэтому при отсутствии лимита на PIDs узел быстро будет выведен из строя. Важно отметить, что лимит задаётся для пользователя, а не для запускаемого процесса. По этой причине он должен быть разумно большим.

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

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса.

Недавно сходил с Витей на запись подкаста на эту тему и настолько преисполнился, что решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

• множество библиотек и зависимостей;
• единый store, в котором живут состояние и данные;
• компоненты, которые нужно собрать, чтобы сделать из них приложение.

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

Монолитное приложение — старое доброе приложение, которое, как правило, создают один или несколько разработчиков, потом его дорабатывает армия джунов, синьоров и всех, кто оказался рядом. Каждый «чуть-чуть поправил», и вот уже никто не понимает, почему оно работает, — но трогать страшно. Монолиты пишут и сейчас — все зависит от бизнеса. Если нужно приложение для небольшого проекта, микросервисы могут и не понадобиться.

Однако наступает момент, когда бизнес расширяется, аудитория растет, нагрузка увеличивается — а масштабировать монолит становится все сложнее. Тогда и приходят на помощь микросервисы.

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

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

Распространение DevOps-культуры и инструменты оркестрации

Раньше разработчик писал код, собирал артефакт и перекидывал его через забор в поддержку. Коллеги за забором его деплоили, запускали — и разработчику можно было больше не думать про плоды своей работы.

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

Вместо того чтобы пилить отдельные сервисы для авторизации, логирования и уведомлений, команда может подумать вот над чем: все это части одного бизнес-контекста — пользовательского доступа. И целесообразно оставить их в одном сервисе. Это и есть DDD в действии.

Существует и еще одна проблема, с которой DDD помогает справиться, — неправильная нарезка сервисов с точки зрения бизнесовой функциональности. Если не понимать бизнес-контекста, можно получить «распределенный монолит»: будет много отдельно стоящих сервисов, но профита никакого, только все сложности микросервисов плюс проблемы монолита с масштабируемой базой данных. Особенно остро это проявляется, когда изменения в одной части бизнес-процесса (в одном сервисе) влекут за собой изменения еще в трех-четырех-пяти других сервисах.

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

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

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

• Если вы не можете переписать сервис за две недели, значит, возможно, он неправильно нарезан, и его нужно декомпозировать.
• Если вам страшно браться за переписывание сервиса, значит, он точно кандидат на декомпозицию.

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

И вот что важно: при проектировании и внедрении микросервисов лучше избегать «велосипедостроения». Если индустрия уже решила проблему, нет смысла изобретать новое логирование или оркестрацию. Собственное решение вряд ли будет работать лучше, а сил, времени ресурсов на него можно потратить очень много.

Поддержка микросервисной архитектуры

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

В крупных организациях микросервисов могут быть сотни: например, в некоторых системах насчитывается почти 700 микросервисов на продакшене. Каждый инстанс еще масштабирован — это тысячи подов, которые постоянно обрабатывают клиентский трафик. И при этом в современных условиях нужно стремиться к доступности системы на уровне четырех девяток (99,99%), то есть к простою всего в несколько минут в год.

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

Паттерны отказоустойчивости

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

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

Совет: возьмите на вооружение парадигму проектирования на отказ. Исходите из того, что в любой момент что угодно может пойти не так. Сеть будет нестабильной, железо начнет падать, интеграции станут работать неправильно. Если изначально придерживаться этого принципа, вы здорово подстрахуете себя завтрашнего. Это всегда спасает, особенно когда получаешь по наследству что-то, что не было спроектировано с учетом этого принципа.

Сейчас часто используют паттерны, которые помогают поддерживать отказоустойчивость системы:

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

Все это must have для абсолютно любой системы. Даже если у вас низкая нагрузка, она когда-нибудь увеличится. Лучше вовремя предусмотреть это, заранее потратив чуть больше времени и реализовав эти паттерны.

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

Совет: если вы вдруг нашли что-то, что еще не мониторится, — это повод поскорее добавить эту метрику, начать ее мониторить и ретроспективно отслеживать.

Еще одна важная вещь в работе с инцидентами — культура постмортемов. Ретроспективы по каждой аварии пишутся не просто так — их можно свести по категориям и понять, из-за чего чаще всего происходят аварии: например, из-за протухших сертификатов либо человеческого фактора в конфигурации. Категорий причин отказа обычно не так много. С постмортемами проще выработать стратегию технического инженерного развития.

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

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

Желательно, чтобы в компании был специальный ситуационный центр, в котором сразу можно создать конференцию, если случилась авария, и поделиться информацией, чтобы все подключились к решению проблемы.

Однако эти организационные моменты еще не гарантируют быстрого решения проблемы. Ключевой фактор — культура компании. На людей часто нападает отстраненность — авария случилась, и все думают: «Кто-нибудь другой разрулит. Я разработчик, ну, что я там сделаю?»

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

Из-за этого разрыва в осознании между командами поддержки и разработки возникают конфликты. У каждой разные цели, и зачастую одна команда не понимает, чего хочет другая. Чтобы лучше понять природу этих конфликтов, важно вспомнить про DevOps-культуру и SRE. В их парадигме разработчики не только пишут код, но и деплоят в продакшен.

Проще говоря, есть два варианта взаимодействия с поддержкой: классический, когда она административно отделена, и SRE-подобный, когда сотрудники «второй линии» прямо интегрированы в команду разработки. Могу сказать, что второй эффективнее.

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

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

Нейросеть будет находить протухшие сертификаты внутри инфраструктуры, работать инструментом для early warning, подсвечивать риски.Кажется, что все инструменты для этого есть уже сейчас. Надо только, чтобы кто-то сложил этот пазл в рабочее решение.

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

Все данные анализируются, и внутри самого сервиса можно понять, как работает команда: кто загружен, сколько времени уходит на задачи, где стопперы в процессе.

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

После внедрения METEOR команды замечают, что продуктивность их работы сильно повышается:

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

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

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

Инструмент подходит практически всем командам — от инди-разработчиков до крупных проектов с множеством ролей. Например, гейм-девелопер может разрабатывать персональный проект и хранить код бесплатно, стартап — разрабатывать MVP, а крупный бизнес — управлять большими командами и проектами максимально безопасно.

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

А главная фишка — встроенный ИИ, к которому можно обращаться прямо во время написания кода. Инструмент разработан с акцентом на простоту входа, командную работу и быстрое прототипирование. Поддерживает более 50 языков программирования и позволяет запускать полноценные веб-приложения в облаке.

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

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

Сейчас инструмент активно используют в стартапах — для быстрого MVP, парного программирования, хакатонов и удаленных командах — как замена локальным IDE и конфигурациям.

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

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

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Меня зовут Юрий Дубовик, я DevOps-инженер компании «Флант». Мы занимаемся DevOps-сопровождением — помогаем другим компаниям делать инфраструктуру надёжной и создавать комфортную среду для разработки.

Мы много работаем с Kubernetes, и иногда нашим инженерам нужно разобраться с настроенными правами доступа к разным объектам в K8s-кластере клиента. Приходится тратить много времени на сбор и упорядочивание информации, а потом сопоставлять, кому какие роли были назначены. Но сравнительно недавно появился Open Source-инструмент, который упрощает этот процесс, — RBAC Wizard.

RBAC Wizard позволяет быстро проанализировать конфигурации RBAC (Role-based access control) в кластере, а главное, может визуализировать всю собранную информацию. В этом обзоре я покажу, как установить этот инструмент с помощью Helm, и сравню его использование с ручным подходом.

Зачем нужен аудит конфигураций RBAC

RBAC — это механизм распределения прав доступа к объектам в Kubernetes-кластере. Подробно останавливаться на принципах работы RBAC я не буду, поскольку об этом уже написано множество материалов.

Вместо этого скажу пару слов о том, зачем нужен анализ конфигураций RBAC. Он помогает убедиться, что пользователи и сервисы имеют в кластере Kubernetes только те права, которые им действительно нужны для работы. Такой анализ позволяет выявить избыточные или ненужные привилегии, минимизировать риски случайных или злонамеренных действий, а также повысить безопасность и соответствие политике доступа в кластере.

Что такое RBAC Wizard

RBAC Wizard — это инструмент на Go с открытым исходным кодом, который помогает анализировать и визуализировать конфигурации RBAC вашего кластера Kubernetes. Он обеспечивает табличное и графическое представление объектов RBAC Kubernetes.

Хотя проект появился на GitHub недавно, в 2024 году, он уже успел привлечь интерес сообщества. Сейчас у RBAC Wizard чуть больше 270 звёзд.

Как установить RBAC Wizard

RBAC Wizard можно установить локально, запустить в контейнере или развернуть в кластере с помощью Helm. Процесс просто и понятно описан в самом репозитории.

Я выбрал вариант установки с помощью Helm:

После установки в кластере Kubernetes в пространстве имён rbac-wizard появится одноимённый ингресс rbac-wizard:

У ингресса указан хост rbac-wizard.local. Заменяем его на нужный нам адрес — домен, который находится под нашим управлением, например new.example.com. По этому адресу мы потом увидим RBAC Wizard в браузере.

Это всё! Больше никаких настроек не требуется. У меня на установку ушло 5–10 минут.

Подготовка тестовых ролей

Чтобы сравнить между собой решение задачи по анализу конфигураций в Kubernetes-кластере без RBAC Wizard и с ним, создадим тестовые ServiceAccount, ClusterRole и ClusterRoleBinding. Разумеется, если вы используете инструмент в готовом кластере, этот шаг стоит пропустить:

Анализ конфигурации RBAC без RBAC Wizard

Давайте посмотрим, как можно решить задачу без RBAC Wizard.

Если требуется найти пользователя или ServiceAccount, которые имеют определённую роль, выполняем следующий запрос:

Пример ответа:

Если же требуется найти все роли, которые закреплены за пользователем или ServiceAccount’ом, запрос будет таким:

Пример ответа:

Если мы получим большой объём ролей и связей с пользователями или ServiceAccount’ами, то придётся заносить все информацию в таблицу для дальнейшего анализа. Держать в голове все связи невозможно — такой метод сбора информации займёт очень много времени.

Анализ конфигурации с помощью RBAC Wizard

Теперь перейдём в браузере по указанному нами адресу в поле host спеки ингресса rbac-wizard и посмотрим, удобнее ли анализировать конфигурации с RBAC Wizard.

Интерфейс инструмента интуитивно понятный. В верхней его части находится RBAC Table. Как понятно из названия, здесь представлена информация о ClusterRoleBinding и RoleBinding в виде таблицы с возможностью поиска:

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

Под таблицей отображается RBAC Map — граф с визуализацией объектов RBAC и их связей. В фильтре можно выбирать ClusterRoleBinding, RoleBinding и посмотреть их взаимосвязь с Role, ClusterRole, User или Group:

А так выглядят более сложные связи:

Привязку к подам утилита не показывает, то есть узнать, кто именно использует аккаунт, не получится.

Итого, RBAC Wizard позволяет мгновенно получить таблицу со всеми ClusterRoleBinding и RoleBinding, наглядно увидеть, кому и какие роли назначены, и быстро найти нужную информацию с помощью поиска. А граф может пригодиться в случаях, когда связей много.

Заключение

Буду краток. RBAC Wizard — простой как молоток инструмент. Но он неплохо упрощает жизнь, позволяя быстро проводить аудит ролей в кластере Kubernetes.

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

Минутка рекламы

Если перед вами стоят задачи по переходу на Kubernetes, внедрению DevOps-практик или сокращению Time to Market, а своих ресурсов и опыта недостаточно, обращайтесь к нам во «Флант». Мы внедрим проверенные технологии, возьмём на себя полный цикл работ и будем сопровождать вашу инфраструктуру силами выделенной команды с гарантиями по SLA.

Его тезис прост: Kubernetes работает, но технический долг и архитектурные ошибки накапливаются — и пора перезапустить проект как Kubernetes 2.0.

В посте инженер прошёлся по истории Kubernetes с момента первых коммитов в 2014 году до текущего состояния, а затем предложил перечень изменений, которые могли бы серьёзно упростить работу с платформой — особенно для малых и средних команд.

Что работает хорошо в Kubernetes

• Масштабируемость контейнеров — от Docker Compose к кластерам из тысяч машин;
• Самовосстановление — ментальная модель «петы → скот → UUID» с переходом к полной заменяемости нод;
• Джобы и фоновые задачи — больше никакого cron01;
• Простой сервис-дискавери — DNS и стабильные IP без танцев с IP-таблицами.

Но что пора менять

1. YAML нужно заменить на HCL

Автор критикует YAML за отсутствие типизации, частые ошибки из-за отступов и странное поведение (вроде «проблемы Норвегии», где 'NO' парсится как false). Взамен он предлагает HCL — тот самый язык, что используется в Terraform. Он типизирован, валидируем, поддерживает выражения, условия, шаблоны и модули.

2. Нужно позволить заменить etcd

Автор предлагает сделать абстракцию для хранилища состояния и разрешить использовать альтернативы, вроде kine или dqlite, особенно для малых кластеров или edge-устройств.

3. Helm устарел — нужен родной пакетный менеджер

Helm вырос из временного решения и теперь тянет за собой ворох проблем: хрупкие шаблоны, сложные зависимости, неработающий механизм проверки, нестрогое семантическое версионирование. Взамен предлагается создать KubePkg — систему управления пакетами с:

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

4. IPv6 по умолчанию

Модель с NAT, приватными IPv4-диапазонами и ручной настройкой стала тормозом. Автор предлагает сделать IPv6 дефолтом, чтобы:

• упростить маршрутизацию между подами и кластерами;
• избавиться от ограничения по IP-адресам;
• сократить накладные расходы на сетевую инфраструктуру.

«По-настоящему важны не только возможности, а то, что стоит по умолчанию», — пишет автор. И предлагает не ждать, пока сторонние проекты исправят архитектурные слабости Kubernetes, а включить необходимые фичи в саму платформу.

Полный текст манифеста можно прочитать в материале по ссылке.

Этап 1: Простой MVP за $0

Изначально нужно создать максимально простое приложение для управления задачами: веб-страница с несколькими категориями и возможностью добавлять таски. На фронте разработчик использует библиотеку Shad CN UI, а на бэке — Flask. Данные хранятся просто в словаре Python. Все приложение — это один файл. Оно запускается в Docker-контейнере через docker compose.

Это MVP работает локально на компьютере разработчика и рассчитано на одного пользователя. Такой подход позволяет всё упростить, но при перезапуске контейнера все данные будут утеряны. Правда, чтобы получить прибыль, этого недостаточно.

Этап 2: Инфраструктура на $30

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

• База данных: PostgreSQL.
• Веб-сервер: Nginx для проксирования запросов и избавления от портов.
• Аутентификация: авторизация через JWT и интерфейсы входа и регистрации на фронтенде.

Все эти компоненты подключаются к существующему приложению через docker-compose.yml. Благодаря этому теперь можно запускать приложение на localhost, а не по порту, и все будет работать как полноценное веб-приложение. Размещение такой системы на бесплатном облачном тарифе или VPS обойдётся в пределах 30 долларов.

Этап 3: Допиливание до $100

Разработчик добавляет допфункции:

• Уведомления по email: вместо стороннего API — система очередей с RabbitMQ и воркером, который отправляет письма.
• Обновления в реальном времени: WebSocket’ы для синхронизации задач на разных устройствах.
• Кэширование: Redis для хранения данных в памяти, что значительно ускоряет работу.

Также подключается Docker Build Cloud — сервис для параллельной сборки контейнеров и шаринга кеша между проектами. Это повышает производительность и ускоряет разработку.

Теперь в системе работает очередь заданий, кеш, WebSocket-сервер, SMTP и полноценная база данных. Все эти компоненты увеличивают инфраструктурные затраты до примерно $100 в месяц.

Этап 4: Мониторинг и масштабирование за $500

Разработчик внедряет:

• Логирование: стек ELK (Elasticsearch, Logstash, Kibana).
• Мониторинг: Prometheus и Grafana.
• Горизонтальное масштабирование: добавляются реплики некоторых сервисов и балансировка нагрузки через Nginx.

Эти инструменты позволяют отслеживать метрики, визуализировать логи, следить за состоянием приложений и быстро выявлять сбои. Инфраструктура становится ближе к корпоративному уровню. Стоимость такого комплекса достигает уже около 400–500 долларов в месяц.

Этап 5: Целых $2000 долларов

Разработчик решает перейти на Kubernetes и развернуть приложение в разных дата-центрах по всему миру. Для управления трафиком используется глобальный балансировщик нагрузки (например, Cloudflare). А чтобы все работало стабильно, внедряются:

• Postgres с репликацией в реальном времени,
• Redis для быстрой отдачи данных.

Сейчас без ИИ приложение уже не имеет смысла. Поэтому разработчик решает добавить серверлесс-функции с категоризацией задач, приоритетами и предложениями на основе поведения пользователей, а также с использованием обработки естественного языка для создания тасков. Также подключаются правовые ограничения — поддержка GDPR и CCPA.

Для мониторинга:

• Jaeger — для распределённой трассировки,
• ELK Stack — для логов,
• Grafana + PagerDuty — для алертов и инцидентов.

Вишенка на торте — план восстановления после катастроф: бэкапы, автоматическое переключение на другие регионы и подготовка команды.

Хотя вся система началась с одного Python-файла и простого UI, шаг за шагом разработчик добавлял в нее компоненты, которые делают её пригодной для реального продакшена: защита, масштабируемость, отказоустойчивость, мониторинг, кеширование и очереди. И оно вполне может стоить несколько сотен или даже тысяч долларов в месяц при развертывании в облаке.

В чем отличия Serverless от Kubernetes?

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

Какой подход лучше подходит под разные стадии продукта?

Kubernetes — это мощная платформа для оркестрации контейнеров, предоставляющая максимальный контроль над инфраструктурой. Но именно за эту гибкость приходится платить: и в буквальном смысле, и в виде технической сложности. Kubernetes требует серьёзной подготовки, как от DevOps-специалиста, так и от команды в целом.

У Kubernetes высокий порог входа. Чтобы начать его использовать, нужно правильно его засетапить. И, как правило, приходится конфигурировать то, что на первых этапах проекта не нужно или не обязательно. А также стоит вопрос цены — на старте Kubernetes будет стоить дороже.

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

Serverless имеет модель pay-as-you-go — вы платите за использование, что очень выгодно на старте, когда необходимо получить первых платящих клиентов при минимуме затрат.

В чём принципиальное отличие парадигм?

Главное различие между подходами — уровень абстракции и контроля. Kubernetes предоставляет разработчику и администратору максимум свободы: вы сами управляете кластерами, контейнерами, ingress-контроллерами, настройками автоскейлинга. Это даёт гибкость — но требует времени и экспертизы.

Serverless же предлагает максимальную абстракцию: вы не управляете серверами, не заботитесь о подах и ресурсах. Это упрощает жизнь, но и ограничивает в возможностях. Например, вы не можете контролировать, как именно масштабируются функции или где именно они выполняются. У вас нет постоянного сервера, вы не можете использовать локальную файловую систему, а выполнение кода может прерываться.

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

Как выбор влияет на архитектуру приложения?

Архитектура проекта в Serverless и Kubernetes будет строиться по-разному.

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

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

Kubernetes требует подготовки — инфраструктура, CI/CD, мониторинг, управление секретами. Эти вещи нужны, но не сразу. Поэтому на раннем этапе, когда проекту нужно просто выйти в прод, K8s действительно может показаться избыточным.

Архитектура и принципы работы: разбираемся под капотом

Чтобы по-настоящему понять разницу между Kubernetes и Serverless, важно заглянуть внутрь — как устроены эти технологии, какие компоненты они используют и как всё это влияет на производительность, масштабирование и отладку.

Как работают контейнеры, поды, ingress, autoscaling и т.д. в Kubernetes?

Kubernetes — это система оркестрации контейнеров, и её архитектура состоит из множества компонентов, которые работают вместе, обеспечивая гибкость и контроль:

• Контейнеры и поды — основная единица развертывания в Kubernetes. Это pod, внутри которого один или несколько контейнеров. Все они разделяют сетевую среду и тома, что удобно для развертывания тесно связанных процессов.
• Ingress-контроллеры обеспечивают маршрутизацию внешнего трафика к нужным подам. Это сложная, но гибкая система, которая требует настройки, но взамен даёт возможность строить кастомные маршруты, поддерживать HTTPS, аутентификацию и прочее.
• Autoscaling в Kubernetes работает на уровне Horizontal Pod Autoscaler (HPA), который масштабирует количество подов в зависимости от нагрузки (например, CPU).

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

Что происходит в Serverless: cold start, логи, триггеры, event-driven подход

Serverless — это радикально другая архитектура. Ваша функция запускается только по событию (например, HTTP-запрос, сообщение в очереди, изменение в базе данных). Это называется event-driven подход.

• Cold start — ключевая особенность. При первом вызове функции платформа инициализирует среду выполнения, подгружает зависимости, запускает код — это может занять от десятков миллисекунд до нескольких секунд. Cold start особенно заметен на неактивных функциях.
• Триггеры — основа Serverless. Они могут быть HTTP-запросами (через API Gateway), событиями из очередей, облачных хранилищ, баз данных и прочее. Вы не пишете сервер — вы пишете реакцию на событие.
• Логирование и отладка завязаны на провайдере. Вы не можете подключиться к серверу — вы смотрите логи через облачную консоль или SDK. Это упрощает DevOps, но усложняет глубокую отладку.

Serverless требует иного мышления: каждую функцию вы проектируете как минимальную, независимую единицу логики. Это отлично для модульности, но усложняет сложные взаимодействия и обработку состояний.

Как это влияет на latency, отладку, масштабирование?

Начнем с latency. У Kubernetes задержки зависят в основном от сетевой инфраструктуры и нагрузки, но отсутствует проблема cold start. В Serverless cold start — это реальная боль, особенно на старте и при нерегулярных запросах.

Что касается отладки, в Kubernetes у вас полный контроль: можно SSH-нуться в под, включить отладчик, проксировать трафик. В Serverless всё зависит от возможностей платформы и логирования. Это быстрее на старте, но ограничивает возможности при сложных багах.

Наконец, масштабирование. Kubernetes позволяет масштабировать по кастомным метрикам, вплоть до GPU-потребления, и балансировать нагрузку между сервисами. Serverless масштабируется автоматически, мгновенно и по запросу — но вы не можете это контролировать или тонко настраивать.

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

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

Простота запуска и поддержки

Один из главных факторов при выборе технологии — насколько просто с ней стартовать. Особенно это важно для небольших команд или MVP-проектов: чем меньше времени уходит на инфраструктуру, тем быстрее продукт попадает в руки пользователей.

Что проще развернуть и поддерживать: Kubernetes с Helm или Lambda с API Gateway?

Запуск приложения в Kubernetes требует полноценной инфраструктуры:

• Создание и загрузка Docker-образа,
• Настройка Docker Registry (например, ECR),
• Подготовка Helm-чартов или манифестов YAML,
• Настройка кластера (виртуальные машины, ingress-контроллеры, сеть),
• Мониторинг, алертинг, логирование — вручную.

Это даёт гибкость и контроль, но требует ресурсов: как человеческих, так и вычислительных.

С Serverless (например, AWS Lambda) всё иначе. Вы можете написать функцию в редакторе прямо в консоли, задать один конфиг (например, триггер — HTTP-запрос), и она будет готова к работе. Инфраструктура, масштабирование, логирование и отказоустойчивость берёт на себя облако. Поддержка тоже проще: не нужно следить за серверами или контейнерами.

Кто должен уметь работать со стеком в команде?

Kubernetes требует DevOps-компетенций. Даже в небольшом проекте вам нужен человек, который понимает, как устроены кластеры, CI/CD, безопасность, ingress-контроллеры, storage и пр. Без этого можно утонуть уже на этапе деплоя.

Serverless часто позволяет обойтись усилиями самих разработчиков. Один fullstack может написать бизнес-логику, подключить API Gateway и базу, задать IAM-политику — и всё заработает. Это идеальное решение для стартапов или небольших продуктовых команд.

Что с CI/CD: где проще интегрировать и автоматизировать?

В Kubernetes CI/CD обычно реализуется через пайплайны, которые:

• Собирают образы,
• Заливают их в registry,
• Применяют Helm-чарты или YAML-манифесты,
• Вызывают kubectl apply или helm upgrade.

Это мощно, но требует настройки и инфраструктуры: Runner'ов, прав доступа, секрета для Docker registry и прочее.

В Serverless всё проще: провайдеры предлагают свои CI/CD-инструменты (например, AWS CodePipeline, Google Cloud Build), а комьюнити — фреймворки вроде Serverless Framework, которые позволяют деплоить из GitHub Actions одной командой. Для небольших проектов достаточно обычного push-to-deploy.

Какой минимальный сетап нужен, чтобы ваш подход заработал на проде?

По мнению Игоря, для Serverless вам нужно написать минимум одну функцию и один конфиг, затем загрузить их в облако. Иногда функцию можно написать прямо в интерфейсе провайдера, и, как правило, этого должно хватить для старта.

С Kubernetes всё сложнее: вам нужно сбилдить Docker-образ, создать Docker Registry и загрузить туда образ, сделать его доступным для K8s, написать K8s-темплейты и конфиги, создать пул виртуальных машин для запуска контейнеров — и всё это соединить и заставить работать.

Это отлично иллюстрирует, почему Kubernetes часто называют «тяжёлой артиллерией», даже если проект только на ранней стадии. Serverless в этом плане — минималистичный и быстрый в реализации подход.

Масштабируемость и производительность

Когда трафик стабильно растёт или возникают пиковые нагрузки — архитектура должна выдерживать всё это без сбоев. Поэтому важно понимать, как Kubernetes и Serverless справляются с масштабированием и производительностью.

Как масштабируются функции в Serverless и поды в Kubernetes?

Serverless масштабируется автоматически: вы не заботитесь о количестве инстансов. Если одновременно поступают тысячи запросов — платформа (например, AWS Lambda, Google Cloud Functions) автоматически создаёт необходимое количество контейнеров для их обработки. В теории масштабирование происходит «до бесконечности», на практике — в рамках лимитов аккаунта или конкретного региона.

Kubernetes масштабируется через Horizontal Pod Autoscaler (HPA), который отслеживает метрики (например, загрузку CPU или latency) и увеличивает количество подов при росте нагрузки. Это требует правильной настройки метрик, ресурсов и инфраструктуры (в том числе — наличия нод, на которых эти поды можно развернуть).

В обоих подходах масштабирование работает, но требует разных усилий: в Serverless — вы просто «надеетесь» на провайдера, в Kubernetes — вы должны всё спроектировать, развернуть и мониторить.

Что происходит при пике трафика — и где это может навредить?

В Serverless основная проблема — cold start: когда функция вызывается впервые (или после паузы), нужно время, чтобы её контейнер был запущен. На пике cold start'ов становится больше, что увеличивает задержки. Кроме того, облачные провайдеры могут ввести троттлинг — ограничение на количество одновременных вызовов, особенно если вы не запросили лимит вручную.

В Kubernetes всё зависит от вашего кластера. Если у вас настроен autoscaling не только подов, но и нод (через Cluster Autoscaler), то при необходимости создадутся новые ноды и на них поды — но это не мгновенно. Также нужно следить за пулом ресурсов: при перегрузке возможны очереди, ошибки, отказ в обслуживании.

Кто быстрее реагирует на нагрузку?

В теории Serverless масштабируется быстрее, потому что вся автоматика на стороне облака. Но это верно только в идеальных условиях. В реальности cold start, ограничение по инстансам и сети может привести к замедлениям.

Kubernetes масштабируется чуть медленнее, особенно если нужно создать новые VM (в облаках это может занять до минуты), но если инфраструктура настроена правильно, поды могут масштабироваться практически мгновенно.

Что быстрее справляется с нагрузкой: Kubernetes HPA или Serverless-автоскейлинг? Однозначно Kubernetes — если он был правильно настроен. Я бы даже сказал, что с Kubernetes вы можете контролировать скейлинг, а с Serverless вы должны рассчитывать на механизмы вашего провайдера.

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

Стоимость: что выгоднее?

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

Сравниваем модели оплаты: за запросы vs за инфраструктуру

Serverless работает по принципу pay-as-you-go: вы платите только за фактическое выполнение кода. Обычно это тарифицируется по времени выполнения и количеству вызовов, плюс может учитываться объём используемой памяти.

Например, если ваша функция выполняется 100 тысяч раз в месяц по 200 миллисекунд — вы платите за суммарные 20 тысяч секунд выполнения. В простой фазе жизни продукта, когда трафик небольшой, это может стоить буквально копейки.

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

Где и как можно переоптимизировать?

• В Serverless можно снизить затраты, уменьшив время выполнения функций, снизив память или объединив вызовы.
• В Kubernetes можно тюнинговать ресурсы подов, использовать spot-инстансы или автоскейлинг нод, чтобы минимизировать простои.

Но важно понимать, что в Serverless платформа делает это за вас (до определённой степени), а в Kubernetes всё ложится на инженеров.

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

Когда трафик нестабильный, Serverless показывает отличную эффективность: вы не платите за idle-инфраструктуру, функции «спят» между вызовами.

Но если у вас стабильный поток запросов, то постоянные вызовы функций могут превысить стоимость фиксированной инфраструктуры в Kubernetes.

Всё очень зависит от вашего приложения, но при росте количества пользователей неминуемо настанет точка, когда Kubernetes станет стоить дешевле, чем Serverless. На одном моём проекте Kubernetes стал выгоднее, когда суммарное время выполнения запросов на сервере в день перевалило за 6 часов — у нас было около 30 тыс. запросов в день. Но мы ещё долго использовали Serverless, потому что было важнее делать новые фичи и привлекать клиентов, чем сэкономить 100 долларов в месяц.

То есть Serverless выигрывает на ранних этапах: меньше затрат, меньше DevOps-нагрузки, можно быстрее экспериментировать. Kubernetes выигрывает в долгую, когда вы готовы инвестировать в инфраструктуру и автоматизацию — и когда каждый доллар становится важен на масштабах.

Безопасность и контроль

Когда речь заходит о продакшн-системах, вопрос безопасности выходит на первый план. Serverless и Kubernetes решают его по-разному — и с разной степенью ответственности на плечах команды.

Кто отвечает за безопасность в Serverless?

В Serverless часть задач снимается с разработчиков и ложится на провайдера. Это называется моделью shared responsibility — вы отвечаете за код и конфигурацию, а поставщик (например, AWS, Google Cloud) — за изоляцию, обновления окружения, патчи на ОС, сетевую безопасность и многое другое.

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

Но минусы тоже есть:

• Вы меньше контролируете окружение — нельзя установить свои агенты безопасности или специализированное ПО.
• Иногда трудно реализовать специфические требования — например, если заказчик требует аудита определённого уровня.

Как настраивается безопасность в Kubernetes — и почему это сложно?

В Kubernetes вы получаете полный контроль, но и полную ответственность. Здесь всё в ваших руках:

• Кто имеет доступ к API-серверу?
• Какие политики срабатывают при запуске подов?
• Как настроены роли, namespace'ы и изоляция?

Это гибко, но требует:

• понимания сетевых политик,
• настройки RBAC,
• работы с контейнерной безопасностью,
• внедрения мониторинга и алертов.

На старте эти задачи могут быть избыточны — особенно если нет выделенной DevSecOps-команды.

Что с логами, отладкой и доступами?

• Serverless предлагает встроенные решения — вы быстро получаете логи, метрики, алерты. Но ограничены их форматом и глубиной. Прямого SSH-доступа, конечно, нет.
• В Kubernetes вы сами выбираете стек наблюдаемости (Prometheus, Grafana и т. д.). Это мощно, но потребует ресурсов на установку и поддержку.

Кому проще пройти аудит: команде с Kubernetes или Serverless?

Однозначно — с Serverless. У вас меньше компонентов и, соответственно, меньший скоуп аудита. К тому же провайдер берёт на себя многие аспекты, важные для аудиторов — включая физическую безопасность, шифрование, сертификацию дата-центров.

Если вы стартап, который выходит на рынок с первым продуктом, и вам нужно быстро пройти аудит — Serverless может подойти больше. Но в крупных компаниях всё чаще наблюдается гибридный подход: Serverless для быстрой разработки и MVP, Kubernetes — для кастомных требований и полного контроля.

Что выбрать? Финальное сравнение

Kubernetes и Serverless — это не конкуренты, а инструменты для разных задач и этапов развития продукта. Важно понимать их сильные и слабые стороны, чтобы не попасть в архитектурную ловушку.

Когда выбирать Serverless?

Serverless идеально подходит, если:

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

Когда брать Kubernetes?

Kubernetes — ваш выбор, если:

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

По словам Игоря Кривоноса, берите Serverless для быстрого старта, получайте первых клиентов. А когда упрётесь в непреодолимые ограничения — переходите на Kubernetes.

Неправильная настройка инфраструктуры в CI/CD пайплайне

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

Настройте окружение

Разные окружения (dev, staging, prod) часто имеют отличия в конфигурации (например, версии библиотек, лимиты ресурсов, настройки сетей). Например, переменные окружения, заданные для staging, перезаписываются в prod — зависимости ломаются.

• Используйте Infrastructure as Code (IaC) инструменты, такие как Terraform или Pulumi, для создания идентичных окружений.
• Храните конфигурации окружений в репозитории (например, в формате YAML или JSON) и применяйте их через CI/CD.
• Настройте переменные окружения через секреты (например, HashiCorp Vault, AWS Secrets Manager) и убедитесь, что они не перезаписываются случайно.

Разворачивайте по стратегии

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

• В Kubernetes используйте RollingUpdate с настройками maxSurge и maxUnavailable, чтобы новые поды стартовали постепенно, а старые были постоянно доступны.
• Настройте readinessProbe и livenessProbe, чтобы Kubernetes не направлял трафик на неготовые поды.
• Ответственно подходите к настройке стратегии и выбору количества реплик.
• Для Helm-чартов фиксируйте версии (helm dependency update, helm package) и используйте helm upgrade --atomic для автоматического отката при сбое.

Например, в манифесте Deployment можно указать:

Избегайте race conditions

Параллельные процессы в CI/CD (например, одновременная сборка и деплой) могут вызывать состояния гонки.

• Настройте блокировки (locks) в CI/CD, чтобы не было параллельных деплоев в одно окружение (например, через environments в GitLab CI).
• Используйте атомарные операции в Helm и Server Side Apply в kubectl.

Обрабатывайте ошибки

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

• Регулярно тестируйте пайплайн на staging-окружении, симулируйте реальные сценарии деплоя.
• Проверяйте доступность сервисов после деплоя с помощью health-check скриптов.

Новую проверку можно, например, добавить так:

curl --fail http://any-app.example.com/health

Нет изоляции переменных окружения и секретов

Представьте: в staging-окружении используются тестовые ключи, а в продакшене — боевые. Но из-за ошибки в CI/CD пайплайне или конфигурации staging берет продовые credentials. Как итог — тестовое удаление данных в песочнице стирает боевую базу. Или еще хуже: токены утекают из-за слабых прав доступа к Secret Manager, и вас могут спокойно взломать. Ниже рассказываем, как это пофиксить.

Разделяйте секреты по окружениям

Если переменные окружения или ключи не разделены между dev, staging и prod, они могут быть случайно использованы в неправильном контексте.

• Храните секреты в Secret Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets) с четким разделением по окружениям (например, пути secrets/staging/db, secrets/prod/db).
• Используйте префиксы или теги для идентификации окружения (например, STAGING_API_KEY, PROD_API_KEY).
• Настройте права доступа CD так, чтобы пайплайн мог подтягивать только секреты, которые относятся к текущему окружению.

Например, в Vault это настраивается так:

Не храните секреты в коде

Иначе утечка неизбежна.

• Уберите секреты из репозиториев и .env-файлов и используйте Secret Manager.
• Для Kubernetes используйте Secret-объекты или интеграцию с внешними менеджерами (например, External Secrets Operator).
• Проверяйте репозитории на утечки с помощью инструментов типа truffleHog или gitleaks.

Вот пример Kubernetes Secret:

Ограничивайте доступ

Это принцип Scoped Permissions — с помощью него можно снизить риски случайного или намеренного использования секретов.

• Используйте IAM-роли в облаке (например, AWS IAM Roles for Service Accounts) с минимальными правами.
  
• Ограничивайте доступ разработчиков к продовым секретам через RBAC или Vault-профили.

Вот AWS IAM-политика для staging:

Ротируйте ключи

Это поможет избежать ситуации, когда после инцидента или утечки ключи не обновляются.

• Настройте автоматическую ротацию ключей в Secret Manager (например, AWS Secrets Manager поддерживает ротацию через Lambda).
• После инцидента сразу же ротируйте скомпрометированные ключи и пересоздавайте секреты.
• Логируйте доступ к секретам для аудита (например, через Vault Audit Logs).

Неправильная настройка health-checks в Kubernetes или других оркестраторах

Неправильная настройка readinessProbe и livenessProbe в Kubernetes — это, можно сказать, классика. Вы обновляете сервис, поды запускаются, но сразу же помечаются как unhealthy. Причина — неправильный readinessProbe или livenessProbe. Например, путь /healthz больше не существует, или проверка уходит в таймаут из-за долгой инициализации. В результате: контейнеры бесконечно рестартуются, сервис недоступен, кластер в панике.

Разделяйте назначение проб

readinessProbe проверяет, готов ли под принимать трафик, а livenessProbe — не завис ли он. Если их смешать, можно ждать сбой, например, трафик пойдет на не до конца инициализированный сервис.

• Используйте разные endpoints для проб. Например, /health для readinessProbe (готовность сервиса) и /alive для livenessProbe (проверка зависаний).
• Настройте readinessProbe так, чтобы она возвращала 200 только после полной инициализации (например, подключения к базе).
• Для livenessProbe проверяйте минимальную работоспособность (например, ответ сервера без проверки внешних зависимостей).

Учитывай время инициализации

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

• Установите initialDelaySeconds с запасом, чтобы учитывать время прогрева (например, загрузку кэша или подключение к базе).
• Настройте timeoutSeconds и periodSeconds так, чтобы проба не завершалась слишком быстро, но и не крутилась вечно.
• Используйте failureThreshold для нескольких попыток перед пометкой пода как unhealthy.

Вот пример для сервиса с долгим стартом:

Добавьте grace period

Он дает сервису время корректно завершиться перед рестартом.

• Установите terminationGracePeriodSeconds в манифесте Deployment, чтобы под мог завершить запросы перед остановкой.
• Настройте preStop хук, если нужно выполнить действия перед завершением.

Тестируйте на staging

Проблемы с пробами часто всплывают только в проде, если staging не идентичен.

• Убедитесь, что staging-окружение повторяет прод по конфигурации и нагрузке.
• Добавьте автоматические тесты в CI/CD для проверки endpoints (/health, /alive) перед деплоем.
• Симулируйте реальные сценарии (например, медленный старт или сбой зависимостей) на staging.

В CI/CD можно добавить:

Неправильная работа с конфигурациями через Helm или Kustomize

Представьте: обновили Helm-чарт, но в values.yaml остались старые переменные, которые ломают новые настройки. Или Kustomize патчит не тот ресурс, и манифесты применяются с ошибками. В итоге: поды падают, сервисы недоступны, и никто не знает что делать. Рассказываем, что с этим делать.

Валидируйте Helm-чарты перед деплоем

Так можно найти ошибки до применения манифестов.

• Используйте helm template или helm install –dry-run для рендеринга манифестов и их проверки.
• Включите schema validation для values.yaml с помощью JSON Schema (поддерживается Helm v3.6+).
• Проверяйте манифесты через kubeval или kubectl apply –dry-run=server для подтверждения соответствия Kubernetes API.

Тестируйте Kustomize-конфигурации

Kustomize может патчить не то, что вы ожидали, если селекторы или структура неправильные.

• Прогоняйте kustomize build для генерации итоговых манифестов и проверяйте их перед деплоем.
• Используйте kubectl apply –dry-run=server -k . для валидации в кластере.
• Проверяйте селекторы патчей в kustomization.yaml на точность (например, name и namespace).

Управляйте версиями и структурой

Несогласованность версий чартов или манифестов приводит к неожиданным изменениям.

• Фиксируйте версии Helm-чартов в Chart.yaml и используйте точные теги (например, 1.2.3, а не latest).
• Храните values.yaml отдельно для каждого окружения (values-staging.yaml, values-prod.yaml).
• Для Kustomize используйте базовые манифесты и патчи, разделённые по окружениям (например, overlays/staging, overlays/prod).

Документируйте и мониторьте

Без документации сложно понять, что изменилось, а без мониторинга — почему упало.

• Ведите CHANGELOG.md для Helm-чартов и Kustomize патчей, описывая изменения в структуре и значениях.
• Логируйте команды деплоя (helm upgrade –debug, kubectl apply -k .) для отладки.
• Настройте мониторинг статуса подов через Prometheus, чтобы сразу видеть сбои из-за ошибок конфигурации.

Вот пример получения подробного лога helm:

Нет политики управления версиями артефактов

С этой штукой шутить нельзя. Каждый новый билд заливается с тегом latest, и через неделю никто не помнит, какая именно версия работает в проде. А если что-то сломалось, откатиться просто невозможно: старый образ либо затерт в registry, либо его никто не пометил. На выходе — паника и хаос.

Используйте семантическое версионирование (semver) или уникальные теги

Так банально будет однозначность и отслеживаемость версий.

• Присваивайте образам теги по схеме semver (1.2.3), commit hash (abc1234) или временной метке (20250429-1345).
• Избегайте latest в продакшене — это бомба замедленного действия.
• В CI/CD автоматически генерируйте теги на основе версии приложения или Git commit.

Вот пример тег-образа:

docker build -t my-app:1.2.3 -t my-app:$(git rev-parse –short HEAD)

Фиксируйте версии в манифестах и пайплайнах

Immutable теги гарантируют, что деплой всегда использует ожидаемую версию.

• В Kubernetes манифестах указывайте точные теги вместо latest.
• Настройте CI/CD так, чтобы тег образа передавался в Helm или Kustomize как параметр.
• Используйте инструменты вроде helm upgrade с фиксированными версиями чартов.

Настройте retention policy для артефактов

Хранение старых образов позволяет откатиться к стабильной версии.

• В container registry (Docker Hub, AWS ECR, Harbor) настройте правила хранения, чтобы сохранять последние N версий или образы за последние X дней.
• Регулярно очищайте устаревшие артефакты, но сохраняйте критические версии (например, те, что в проде).
• Используйте теги для маркировки стабильных версий (например, prod-1.2.3).

Пример — AWS ECR lifecycle policу:

Автоматизируйте версионирование в CI/CD

• В CI/CD пайплайне генерируйте теги на основе Git тегов, commit hash или переменных окружения.
• Проверяйте, что образ с нужным тегом пушится в registry и используется в деплое.
• Добавьте шаг валидации манифестов, чтобы убедиться, что теги фиксированы.

Ошибки при деплое могут вылиться в серьезные проблемы для проекта. DevOps-инженеры не просто запускают пайплайны, а следят за жизненным циклом продукта — от инфраструктуры до мониторинга. Документируйте ошибки, создавайте чек-листы, автоматизируйте каждый шаг и учитесь на инцидентах. И главное — никогда не деплойте в пятницу вечером.

Что такое DevSecOps

DevSecOps образовано от слов development (разработка), security (безопасность) и operations (эксплуатация или операции). Это подход к разработке приложений, при котором безопасность учитывается на каждом этапе CI/CD, чтобы минимизировать стоимость и повысить скорость исправления ошибок. К нему относятся не только инструменты, по типу различных сканеров библиотек и кода, но и определённые договоренности между разработчиками, DevOpsами и безопасниками.

Разработка приложений сегодня похожа на приготовление салата: берутся овощи, мясо, масла и приправы, все смешивается — и получается блюдо. Если хоть один ингредиент окажется плохим, то весь салат будет испорчен. Разработчики не всё пишут сами: в DevOps из общедоступных репозиториев могут браться готовые библиотеки: их соединяют, и в результате получается приложение (тот самый салат).

Если хоть одна из библиотек окажется плохой или дописанный разработчиком код для объединения библиотек будет некачественным, то весь салат будет непригодным для употребления. Стоимость исправления ошибки велика, ведь нужно найти испорченный ингредиент и заменить его. Однако с ПО все еще сложнее: библиотеки постоянно обновляются, а потому не понятно, в какой момент весь салат может стать непригодным — нужно постоянно следить за всеми ингредиентами блюда.

Лицо врага

Не все библиотеки с открытым исходным кодом, выложенные в публичные репозитории, можно считать безопасными. Их авторы часто остаются неизвестными — это могут быть как энтузиасты, так и злоумышленники, включая хакеров или представителей недружественных государств. В итоге даже при использовании сложных систем защиты — межсетевых экранов, VPN, антивирусов, DLP и PAM — компания может оказаться уязвимой. Уязвимость может прийти изнутри — через стороннюю библиотеку, которая станет «троянским конём» и даст злоумышленникам доступ к данным, производственным процессам и критичной инфраструктуре.

Процент небезопасных приложений в исследованиях российских компаний, занимающихся защитой приложений, в разные годы отличается и зависит от отрасли. Так, про финансовую отрасль Positive Technologies в 2015 говорили о 90%, в 2016 г. — о 71%, а в 2017 – о 56%. Если замеченный Positive Technologies тренд защищенности приложений финансового сектора сохранился бы в тех же пропорциях, то сегодня процент был бы ещё меньше. Однако исследование «Стингрей Технолоджис» 2024 г. говорит о 56% опасных приложений в финтехе.

Ассоциация ФинТех проводила исследование, и в 2025 году 82% компаний назвали разработку на базе открытого исходного кода оптимальной с точки зрения сроков и удобства внедрения. При этом использование таких библиотек несёт в себе риски на протяжении всего жизненного цикла продукта, и риски для данных, которые используются в приложениях.

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

Какие есть риски для данных

Основные риски для данных обычно связаны с нарушением их конфиденциальности. В процессе разработки важно проводить тесты, а для этого нужны данные, причём не сильно отличающиеся от настоящих. Также важен их объём, иначе не получится провести нормальные нагрузочные тесты. Выгрузка реальных данных — самый заманчивый вариант. Но если для стендов Dev и Test используются облачные среды или в процессах разработки задействованы подрядчики, то некоторые организации могут на такое не решиться из-за требований к ИБ. И это логично, поскольку в Prod есть комплексный подход к защите, а на стендах Dev и Test меры защиты могут быть минимизированы.

Один из способов снизить риски — использовать системы маскирования: они помогают обезличить персональные и финансовые данные (например, номера карт и счетов). Сейчас действует приказ Роскомнадзора №996 от 2013 г., но, необходимо отметить, уже опубликован проект приказа Роскомнадзора «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных», который его заменит.

Контейнеры стали стандартом для запуска приложений, но вместе с удобством они приносят и риски — особенно в защите данных. Да, контейнеризация улучшает доступность и масштабируемость, но не решает проблем с конфиденциальностью и целостностью «из коробки». На российском рынке уже существуют отечественные платформы контейнеризации, например, Штурвал, DeckHouse, в которых сразу учтены механизмы безопасности либо есть накладные средства для kubernetes от Luntry, PT, Kaspersky и т.д.

Как внедрять DevSecOps

DevSecOps — подход, при котором безопасность вшита в код на всех этапах. Уязвимости ищут не в самом конце, а прямо по ходу разработки: в pull request'ах, CI/CD и при работе с зависимостями. Такой подход требует, чтобы разработчики, DevOps и специалисты по безопасности работали как одна команда, а не передавали задачи «по цепочке» в последний момент.

При этом каждой компании может требоваться сугубо индивидуальный набор инструментов — всё зависит от зрелости команды и доступных ресурсов (особенно человеческих). Важно договориться о недопустимых событиях, об уровне риск-аппетита с бизнесом, разработать модель угроз. Некоторым клиентам нужно наличие собственного доверенного репозитория, а для других достаточно GitHub, GitLab и т.д.

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

Cloud Native — это подход к разработке приложений, изначально ориентированных на работу в облачной среде и интеграцию с облачными сервисами. Сегодня большинство новых решений проектируются именно так. Для безопасной работы таких приложений важно не только адаптировать архитектуру под облако, но и выстраивать взаимодействие с провайдером: от заключения договора до работы с API. Облачные провайдеры часто предлагают инструменты, которые помогают встроить безопасность в процесс разработки. У многих есть готовые сервисы Kubernetes, в том числе с учётом требований информационной безопасности. Также доступны решения уровня WAF и инструменты анализа безопасности кода (например, SAST, DAST, SCA) — иногда по подписке, как в случае с некоторыми российскими платформами.

Начать можно с внедрения бесплатных решений — например, SAST, SCA и DAST, которые уже можно интегрировать в текущий DevOps-стек. Когда команда понимает ценность и пользу этих проверок, можно переходить к платным продуктам с расширенными возможностями.

Затем практики DevSecOps внедряются в небольших проектах — так можно оценить эффективность их работы, заметить возможные недостатки, скорректировать решения, чтобы на выходе получить отличный рабочий вариант для применения в крупных проектах с потенциальным увеличением масштабов в будущем.

Однако не стоит думать, что это финальная точка. DevSecOps — постоянный процесс: мониторинги, улучшения, обновления стандартов ИБ и поиски идеальных практик.

Цена вопроса

Вернемся к примеру с салатом. Все любят разное: кто-то — «цезарь», другой – «селёдку под шубой». Разные языки программирования, риск-аппетиты в командах в отношении принятия требований безопасности, цели внедрения DevSecOps (кому-то нужно в итоге получить сертификат, а кому-то страшно за конечный продукт и важно обеспечить реальную максимальную безопасность) — всё это не позволяет создать коробочный продукт с фиксированной ценой, хотя на рынке есть те, кто предлагает поставить 2-3 сканера и удовлетвориться этим, назвав DevSecOps.

При внедрении DevSecOps стоит учитывать затраты на разделение сред Dev, Test и Prod — это не входит в концепцию по западным лекалам. Однако от руководства компаний-клиентов нам часто поступают запросы на усиление безопасности разработки, поскольку разработчик перепутал стенд, после чего важнейшие системы компании пострадали. Вынести в облако Dev и Test и оставить у себя Prod кажется хорошей идеей (или наоборот). Для некоторых она способна полностью решить вышеупомянутую проблему.

Однако тем, кому важно углубиться именно в DevSecOps, следует внедрить процесс анализа библиотек с открытым исходным кодом. Мы не знаем разработчиков этих библиотек, в сообществах могут поменяться цели и их лидеры. Они, в свою очередь, вполне могут оказаться хакерами, желающими распространить через эти библиотеки свои инструменты.

Сканеры библиотек могут быть бесплатными и платными

Статический анализ кода (SAST) — может быть реализован через бесплатные инструментов, таких как SonarQube, semgrep, gitleaks/trufflehog, но есть и платные – PVS-Studio, Svace, Solar appScreener и т.д.

Динамический анализ кода (DAST) — можно осуществить с помощью бесплатных инструментов OWASP ZAP, Nuclei, NMAP, Burp Suite или платных, например, PT BlackBox.

И другие элементы DevSecOps (анализ мобильных приложений, API и т.д.) можно реализовать с использованием платных или бесплатных инструментов.

Таким образом, если не продавать какой-то сканер под видом DevSecOps, то сложно сказать цену для клиента, всё зависит от пожеланий. Если все же очень нужно грубо оценить DevSecOps, то его внедрение обходится примерно в одну треть от стоимости процессов DevOps, но это при использовании бесплатных инструментов. Платные автоматически увеличивают стоимость.

В процессы Ops можно также включить элемент безопасности WAF (Web Application Firewall). Доступны как бесплатные варианты (например, ModSecurity), так и платные (PTAF, Гарда WAF, Вебмониторэкс и т.д.).

Начинать стоит с бесплатных инструментов, поэтапно внедряя их в CI/СD, взаимодействуя с командой DevOps. По сути, DevSecOps – это консалтинг с возможностью применения платных инструментов, если к ним готова команда DevOps. И мы абсолютно уверены, что ради его внедрения точно не стоит жертвовать командой разработки. Кстати, для трактовки отчётов сканеров зачастую используются те же консалтеры, что внедряли DevSecOps.

Нельзя забывать и об обучении команды практикам безопасной разработки. Тут следует упомянуть, что сканеры типа CheckMarx наглядно демонстрируют эксплуатацию уязвимостей. Часто вендоры сводят DevSecOps к сканерам, консалтеры — к процессам, а про людей и их обучение — забывают.

Просто прочитать пару статей про DevSecOps — недостаточно. Команда должна понимать реальные уязвимости: как они появляются, чем опасны и как их избежать. Сейчас в России появляются обучающие платформы, которые показывают это на практике — с примерами уязвимого кода, проблемных библиотек и типовых ошибок. Но останавливать разработку ради курсов на две недели — нереально. Поэтому лучше встроить обучение в рабочий ритм: хотя бы один час в неделю на всю команду. Это немного, но в долгосрочной перспективе даёт устойчивую культуру безопасности. Стоимость зависит от числа участников и выбранных курсов — но в любом случае это обойдется дешевле, чем инцидент в проде.

Требования к безопасной разработке ПО

Уже сейчас требования по безопасной разработке (а если есть DevOps, то по сути это требования к внедрению DevSecOps) появились в:

• ГОСТ Р 57580.1-2017: СМЭ.6, СМЭ.7, ЖЦ.4, ЖЦ.5, ЖЦ.6, ЖЦ.7. ЖЦ.24;
• PCI DSS 4.0.1: 6.2, 6.3, 6.5;
• ГОСТ Р ИСО/МЭК 15408-3-2013: ALC_CMC, ALC_CMS, ALC_DEL, ALC_DVS, ALC_FLR, ALC_LCD, ALC_TAT.

Если речь идет о средствах защиты информации (СЗИ), которые нужно будет сертифицировать по требованиям ФСТЭК или ФСБ, важно помнить: инструменты, которые вы используете для сканирования кода, тоже должны быть сертифицированы. Иначе при испытаниях возникнут сложности — лаборатории не примут результаты без официальной документации.

Если же приложение не попадает под категорию СЗИ, жёстких требований к инструментам нет. Главное — понимать, от каких угроз вы защищаетесь, и подбирать инструменты под реальные задачи: будь то уязвимости в зависимостях, ошибки в логике или неправильные настройки.

Куда будет развиваться DevSecOps

Очевидно, что DevSecOps ждет намного более массовое внедрение и развитие — устранить проблемы на этапе разработки дешевле, чем позже латать пробоины в ИБ.

Скорость появления эксплоитов растёт — и это прямая угроза. Если раньше у команд была пара месяцев, чтобы закрыть уязвимость до начала атак, то теперь — всего несколько дней. Исследование Google показало: в 2018–2019 годах эксплойты появлялись в среднем через 63 дня после патча, в 2020 — через 44, в 2021 и 2022 — уже через 32, а в 2023 году — всего через 5 дней. А с развитием ИИ этот срок может сократиться ещё сильнее.

В России сильные программисты, но собственные новации в сфере ИБ традиционно появляются позже, чем на Западе — чаще в виде адаптаций или копий существующих решений. Однако импортозамещение меняет ландшафт: появляются десятки отечественных продуктов, которых просто нет в зарубежных базах уязвимостей. А значит — и в популярных сканерах кода они тоже не учтены. Это открывает окно возможностей: российские команды смогут развивать собственные инструменты безопасности — от сканеров и доверенных репозиториев до платформ для DevSecOps. Плюс эти принципы начнут постепенно проникать в программы обучения в вузах.

Уже существуют реестр отечественного ПО (ведется под патронажем Минцифры), реестр сертифицированных средств защиты ФСТЭК России, реестр ФСБ России, реестр отечественных ПАК (ведётся Минпромторгом). Чтобы попасть туда в ближайшие годы, разработчики должны будут не просто заявлять о безопасности, а доказывать на практике — в процессах, документации и архитектуре. Это станет драйвером роста: инструменты для безопасной разработки будут развиваться, а вместе с ними — и культура DevSecOps.

Загибайте пальцы:

1. Собрать Docker-образ.
2. Обновить конфигурацию в Kubernetes.
3. Применить изменения командами kubectl.
4. Проверить, что все работает.
5. Если не работает — откатить изменения, исправить, повторить.

И так каждый раз. А если на проекте не только тестовая среда, но и предпродакш, продакшн? А если команда из 10 разработчиков? Кошмар!

Инструмент Argo CD ускоряет развертывание приложений, синхронизирует Git-репозиторий с фактическим состоянием в кластере. В итоге у разработчика больше времени на написание кода и меньше проблем с деплоем. Компания тоже выигрывает — получает более быстрые и надежные релизы.

После прочтения статьи вы сможете самостоятельно настроить деплой Kubernetes с помощью ArgoCD и применить эти знания в собственных проектах.

ArgoCD раскрывается лучше, когда уже понятен весь путь до GitOps: контейнеры, CI/CD, Kubernetes, Helm, наблюдаемость и безопасность. Общий контекст собран в статье Roadmap DevOps-инженера в 2026 году, а сам подход отдельно разобран в материале что такое GitOps простыми словами.

Введение в ArgoCD: возможности и преимущества

Git коммитишь — кластер обновляется

Вася написал новую фичу и отправил ее в Git. Через 2 минуты функция уже работает в тестовой среде, но с багом. Вася исправляет код, делает коммит, — и через 2 минуты исправление снова в тестовой среде.

Когда все готово к релизу, девопс применяет изменения в ветке, и ArgoCD автоматически обновляет продакшн.

Без ArgoCD: 30+ минут ручной работы на каждый деплой, высокая вероятность ошибки.

С ArgoCD: 2 минуты автоматической работы, минимальный риск ошибок.

Изменили код, отправили в Git — работа сделана. Платформа GitOps без вашего участия обнаружит изменения и обновит приложение в кластере.

Интерактивная панель управления

В Argo CD видно все компоненты приложения — деплойменты, сервисы, конфигмапы — и их состояние. В один клик можно посмотреть историю синхронизаций, детали развертывания и логи.

ArgoCD — это быстрый доступ к событиям, управление средами и кластерами с одной панели, мгновенный откат к предыдущей версии. Также доступна проверка изменений перед их применением.

Универсальный подход к конфигурациям

Команда применяет Helm для управления зависимостями?

— ArgoCD интегрируется с ним напрямую.

Предпочитаете Kustomize для настройки под разные среды?

— ArgoCD распознает эти конфигурации автоматически.

Используете стандартные YAML-манифесты?

— Они тоже поддерживаются без дополнительной настройки.

Безопасный доступ для команды любого размера

Можно разделить доступ между участниками проекта с точностью до отдельных приложений и действий:

• Девопсы управляют всеми развертываниями.
• Разработчики получают права на просмотр логов и статуса своих сервисов.
• Тестировщики видят статус только тестовых сред.

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

Система интегрируется с корпоративными провайдерами аутентификации через OIDC, LDAP, SAML. Каждый сотрудник сможет использовать персональные учетные данные для входа.

Установка и настройка Argo CD

ArgoCD устанавливается в действующий кластер Kubernetes с помощью стандартного набора манифестов. Перед установкой потребуются: настроенный kubectl, файл kubeconfig и работающий CoreDNS.

Команды создают пространство имен argocd и устанавливают компоненты: серверы приложений, репозиториев и другие службы.

Доступ к ArgoCD осуществляется через CLI и веб-интерфейс.

CLI устанавливается из официальных релизов:

• brew install argocd — для macOS, Linux и WSL.
• бинарный файл — для Windows.

По умолчанию сервер ArgoCD не имеет внешнего IP. Это значит, что веб-интерфейс и API ArgoCD доступны только из кластера Kubernetes.

Есть три способа настройки доступа:

1. Изменение типа сервиса на LoadBalancer:

2. Настройка Ingress-ресурс для маршрутизации трафика через входной контроллер кластера.

3. Использование kubectl port-forward для временного доступа:

Начальный пароль администратора генерируется автоматически и хранится в секрете argocd-initial-admin-secret:

Вход в систему через CLI:

После первого входа необходимо сменить пароль:

Секрет argocd-initial-admin-secret следует удалить после смены пароля, так как он содержит пароль в открытом виде:

Для веб-интерфейса используется тот же адрес и учетные данные, что и для CLI.

Регистрация кластера (необходима только для внешних кластеров):

При добавлении внешнего кластера ArgoCD создает сервисный аккаунт argocd-manager в пространстве имен kube-system и выдает ему права администратора. При работе с тем же кластером, где установлен Argo CD, используется адрес https://kubernetes.default.svc.

Создание приложения:

То же самое через веб-интерфейс:

1. Нажать кнопку «New App».
2. Заполнить форму с указанием имени, Git-репозитория, пути к манифестам.
3. Выбрать целевой кластер и пространство имен.
4. Нажать «Create».

После создания приложение находится в состоянии «OutOfSync». Для развертывания ресурсов в кластер:

Через CLI:

Через веб-интерфейс:

1. Нажать «Sync» для нужного приложения.
2. В открывшейся панели выбрать «Synchronize».

Для автоматической синхронизации при изменениях в Git-репозитории используется флаг –sync-policy automatic:

При загрузке манифестов из репозитория Арго автоматически определяет формат и применяет соответствующий инструмент для развертывания.

Основные команды и работа с CLI

Рассмотрим 4 базовые команды:

• Добавление нового приложения.
• Проверка состояния развертывания.
• Автоматическая и ручная синхронизация.
• Откат изменений.

Добавление нового приложения

Команда argocd app create создает приложение в Argo CD, связывая Git-репозиторий с целевым кластером Kubernetes.

Нужно указать имя приложения, источник манифестов и целевую среду:

Альтернативой ручному созданию приложения служит определение через YAML-файл:

Проверка состояния развертывания

Команда argocd app get отображает текущее состояние приложения, включая статус синхронизации, ревизию Git и состояние ресурсов:

Для вывода информации о ресурсах приложения используется флаг -o wide:

Можно отслеживать состояние ресурсов во время синхронизации:

Еще ArgoCD сохраняет историю синхронизаций приложения:

Автоматическая и ручная синхронизация

Команда argocd app sync применяет изменения, обнаруженные в Git-репозитории, к кластеру Kubernetes:

При ручной синхронизации Argo CD:

1. Скачивает манифесты из Git.
2. Формирует план изменений.
3. Применяет его к кластеру.
4. Отслеживает состояние до завершения развертывания.

Синхронизация определенной ревизии Git:

Принудительная синхронизация:

Обновление только определенных ресурсов:

Откат изменений

Команда argocd app rollback отменяет последнюю синхронизацию и возвращает приложение к предыдущему стабильному состоянию:

По умолчанию откат выполняется на предыдущую успешную ревизию. Для отката к конкретной ревизии требуется указать ее ID:

где 5 — номер ревизии из истории.

При откате не происходит изменений в Git-репозитории — это временное изменение, направленное на быстрое восстановление работоспособности.

После отката приложение перейдет в состояние «OutOfSync», поскольку Git-репозиторий по-прежнему содержит новую версию.

Для долгосрочного решения после отката нужно:

1. Исправить ошибки в манифестах.
2. Отправить исправления в Git.
3. Синхронизировать приложение.

Работа с ArgoCD в реальных проектах

ArgoCD дополняет классические CI/CD-системы, разделяя ответственность за процесс доставки. CI-системы отвечают за сборку кода и создание артефактов, ArgoCD берет на себя развертывание в Kubernetes.

В GitHub Actions пайплайн компилирует приложение, собирает Docker-образ, обновляет манифест с новым тегом образа и отправляет изменения в Git. ArgoCD замечает изменения в репозитории и обновляет приложение в кластере.

Подробнее про интеграцию CI/CD с GitHub Actions

GitLab CI/CD использует подобную схему — сначала тестирование и сборка, затем запись актуальных версий в манифесты. CI-пайплайн завершается, как только изменения попадают в Git. Остальную работу делает ArgoCD.

Подробнее про инструменты CI/CD на практике от DevOps-инженеров

Jenkins требует дополнительной настройки для интеграции с ArgoCD. Возможна работа через REST API ArgoCD или через обновление манифестов в Git-репозитории. Для командной строки Argo CD создают отдельные сервисные аккаунты с ограниченными правами.

Настройка уведомлений

Уведомления Argo CD информируют команду о состоянии приложений. Система уведомлений настраивается в ConfigMap argocd-notifications-cm:

• Для Slack нужно определять шаблоны сообщений и триггеры событий. Соединение настраивается через токен бота. Приложения активируют уведомления через аннотации.
• Microsoft Teams работает через веб-хуки. Каждый канал получает собственный URL-адрес, который ArgoCD использует для отправки сообщений.
• Email-оповещения требуют настройки SMTP-сервера. ArgoCD поддерживает TLS-шифрование и аутентификацию. Письма содержат детальную информацию о событиях и могут включать ссылки для быстрого доступа.

Каждое приложение самостоятельно подписывается на нужный набор событий: ошибки синхронизации, успешные деплои, проблемы с доступностью.

Управление секретами

Стандартная модель GitOps требует хранения всех манифестов в Git, что небезопасно.

Популярные решения для управления секретами:

• Sealed Secrets. Публичный ключ используется для шифрования секретов перед сохранением в Git. Контроллер в кластере расшифровывает их закрытым ключом и создает стандартные Secret-объекты.
• HashiCorp Vault. Манифесты содержат переменные, которые заполняются значениями из Vault в момент синхронизации. Секреты никогда не попадают в Git-репозиторий.

3 лучшие практики использования ArgoCD

1. Организация репозитория

Структура Git-репозитория влияет на эффективность работы с Argo CD. Рассмотрим два основных подхода: «моно» и «мульти» модель.

• Монорепозиторий хранит все манифесты в одном месте. Каталоги первого уровня разделяют приложения и конфигурацию среды. Преимущество — целостная структура и возможность внесения согласованных изменений.
• Мультирепозиторная модель разделяет компоненты по нескольким репозиториям. Каждая команда управляет своим набором приложений. Конфигурации для разных окружений хранятся отдельно. Этот подход четко разграничивает ответственность.

App of Apps упрощает управление множеством приложений через главное приложение ArgoCD. Один манифест верхнего уровня содержит определения для всех приложений, что упрощает развертывание однотипной инфраструктуры.

2. Использование Kustomize и Helm

Kustomize накладывает патчи на базовые манифесты. Конфигурация определяет основные параметры приложения, оверлеи содержат изменения для конкретных сред.

Helm применяет шаблонизацию для создания манифестов. Чарты содержат шаблоны с переменными, значения которых задаются в файлах values.yaml. Для каждого окружения создается собственный файл значений.

Можно комбинировать оба инструмента. Helm создает базовые манифесты, а Kustomize настраивает их под конкретные требования.

3. Мониторинг приложений и настройка alert-уведомлений

Арго собирает метрики синхронизации, состояния здоровья, времени развертывания. Данные передаются в Prometheus для создания дашбордов в Grafana и настройки алертов.

Система уведомлений информирует команды о критичных изменениях: ошибках синхронизации, деградации здоровья, успешных развертываниях. Алерты отправляются в Slack, Teams, Email через настраиваемые триггеры и шаблоны.

6 популярных ошибок при работе с ArgoCD

Ошибка аутентификации по SSH-ключу. ArgoCD выдает «Permission denied (publickey)» при попытке доступа к репозиторию. Причина — неправильно настроенный или отсутствующий SSH-ключ.

Решение:

• Проверить корректность SSH-ключа.
• Убедиться, что в репозитории ключ добавлен как deploy key с правами чтения.
• Проверить формат ключа (должен начинаться с —–BEGIN OPENSSH PRIVATE KEY—–).

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

Решение:

• Проверить права доступа пользователя или deploy key к репозиторию.
• Убедиться, что для организации не включено SSO или 2-FA.

Несоответствие версий Helm. Argo CD использует встроенную версию Helm, которая может отличаться от локальной.

Решение:

• Проверить версию Helm в Argo CD через argocd admin helm version.
• Настроить кастомную версию Helm через конфигурацию argocd-cm.

Отсутствующие значения в values.yaml. Ошибка «Error: execution error at line X» с указанием на неопределенное значение.

Решение:

• Убедиться, что все required значения указаны в файле values или через флаги –set
• Использовать условные блоки для необязательных параметров

Одна из основных проблем в GitOps-модели — расхождение между фактическим состоянием кластера и описанием в Git.

Отказ при синхронизации из-за drifts. ArgoCD отображает ресурс как «OutOfSync» и отказывается выполнять синхронизацию.

Решение:

• Использовать флаг –force при синхронизации для перезаписи изменений.
• Включить опцию автоматического самовосстановления (self-heal) для критичных ресурсов

Ошибка Update не разрешена для некоторых полей. Kubernetes запрещает изменение определенных полей после создания ресурса.

Решение:

• Добавить аннотацию argocd.argoproj.io/sync-options: Replace=true

Подведем итоги

Поздравляем! Вы познакомились с инструментом, который спасает от ручных деплоев!

В мире, где все постоянно ломается, Argo CD — тот самый друг, который поможет собрать приложение, пока вы пьете кофе и притворяетесь, что все так и задумано.

Если после внедрения ArgoCD у вас внезапно появилось свободное время — не пугайтесь, это нормально. Используйте его, чтобы наконец-то прочитать те 348 вкладок про Kubernetes, которые вы открыли 2 года назад. А еще можете использовать его, чтобы почитать наш тг-канал, найдете больше советов!