Разное

Nelm — полноценная замена Helm

15.01.2025

Введение

Разработка в системе Kubernetes обычно включает создание образов контейнеров с помощью Docker, управление конфигурациями и оркестровку развертывания. Несмотря на эти мощные возможности, развертывание приложений остается сложной задачей.

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

Краткая история Helm

Helm — проект компании Deis Labs, которая впоследствии была приобретена Microsoft. С тех пор некоторые сотрудники Deis Labs перешли к другим интересным проектам, например к работе с WebAssembly. Так кто же стоит у руля Helm?

Проект был первоначально разработан в 2015 году, передан Фонду облачно-ориентированных вычислений (CNCF) в 2018 году и завершен к 2020 году (Подкаст Kubernetes, Microsoft Open Source, Википедия).

Хороший, плохой, злой

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

Источник: создано автором на основе данных GitHub (коммиты без учета слияний и изменений версий)

Необходимость альтернативы Helm

Учитывая эти проблемы, сообщество Kubernetes только выиграет, если получит совместимую с предыдущими версиями и жизнеспособную альтернативу Helm. Желательно, чтобы такой инструмент устранил недостатки Helm, обеспечив при этом расширенную функциональность. К счастью, на горизонте появилось нечто, обещающее стать достойной альтернативой Helm.

Проект Werf

Werf — проект CNCF, представляющий собой изолированную программную среду («песочницу»), разработанную для оптимизации и улучшения процесса непрерывной интеграции и непрерывного развертывания (CI/CD) для Kubernetes. Werf легко интегрируется в существующую систему CI и использует такие знакомые разработчикам технологии, как Git, Docker, Helm и Buildah.

Источник: создано автором на основе https://werf.io/

Усовершенствованная версия Helm

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

В настоящее время Nelm встроен в Werf и не может использоваться как отдельный инструмент. Однако в будущем планируется выпустить автономный CLI, что сделает его доступным для пользователей, которым не нужен полный набор возможностей Werf.

3 ключевые особенности Nelm:

Server-Side Apply (SSA). В отличие от Helm, использовавшего 3-Way Merge, в Nelm обновление ресурсов Kubernetes происходит с помощью механизма SSA, обеспечивающего лучшую согласованность и надежность;

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

Оптимизированное управление чартами. Nelm продолжает поддерживать Helm-чарты, но оптимизирует процессы управления и развертывания.

Добавление werf (и nelm) в существующий проект

Чтобы увидеть оптимизации в действии, попробуем использовать werf (и nelm «под капотом») в существующем проекте (источник — моя страница на GitHub).

Поскольку Werf требует Helm, нужно создать Helm-чарт. Самый простой способ сделать это — использовать helmify.

Helmify считывает список поддерживаемых объектов k8s из stdin или файловой системы и преобразует его в Helm-чарт.

Запустив helmify -f k8s/docs-manifest.yaml .helm, получим необходимую структуру каталогов:

Сборка

Сборка в Werf больше похожа на кэширование изображений. Каждый слой экспортируется в предоставленный реестр OCI.

➜ werf build --repo piotrzan/dcaguide

│ │ ┌ Store stage into piotrzan/dcaguide
│ │ └ Store stage into piotrzan/dcaguide (28.01 seconds)
│ ├ Info
│ │      name: piotrzan/dcaguide:708d75bea338ead28774442dafb52b6fc25711044f54f1d0613f4108-1721736490437
│ │        id: eb939036aada
│ │   created: 2024-07-23 14:08:09 +0200 CEST
│ │      size: 176.2 MiB
│ └ Building stage backend/dockerfile (67.99 seconds)
└ ⛵ image backend (68.58 seconds)

Каждый слой изображения помещается в репозиторий

Прогресс развертывания в режиме реального времени

Одной из отличительных особенностей Werf является отслеживание хода развертывания в режиме реального времени. В отличие от Helm, который оставляет разработчика в догадках о состоянии развертывания, Werf предоставляет «живые» обновления о том, что происходит в кластере Kubernetes. С помощью команды werf converge получаем подробную обратную связь, включая журналы по запущенным контейнерам и события ресурсов.

Альтернатива механизму Helm «установка/обновление — ожидание»

Другие особенности Werf

Мы увидели только одно преимущество Werf перед Helm, но их гораздо больше. Вот их краткий перечень.

Расширенная обработка ошибок

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

Упорядоченное развертывание ресурсов

С помощью аннотации werf.io/weight ресурсы могут быть развернуты в определенном порядке как последовательно, так и параллельно, что обеспечивает большую гибкость по сравнению с хуками helm и контейнерами init.

Server-Side Apply и режим «dry-run» (пробного запуска)

Механизм Server-Side Apply, доступный в ядре Kubernetes спустя несколько релизов, обеспечивает более надежные обновления, позволяя избегать подводных камней 3-Way Merge Helm. Команда werf plan показывает предлагаемые изменения перед их применением, аналогично terraform plan.

Последовательность и безопасность развертывания

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

Управление внешними ресурсами

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

Более высокий уровень поддержки CRD

CRD в каталоге crd обновляются при обновлениях, что обеспечивает актуальность пользовательских определений ресурсов и улучшает управление и версионирование.

Интерактивные учебные ресурсы

Испытать Werf позволит отличный интерактивный скрипт в killercoda, предоставленный Королевским технологическим институтом (KTH) в рамках курса DevOps. Обязательно ознакомьтесь с ним.

Аналогичные инструменты

Помимо Nelm, процесс развертывания на Kubernetes может облегчить другой новейший инструмент — Kluctl. Он призван объединить сильные стороны Helm и Kustomize, устраняя их ограничения. Kluctl обеспечивает более гибкий и декларативный подход к развертыванию Kubernetes.

Являясь обратно совместимой заменой Helm, nelm без проблем интегрируется с существующей экосистемой и инструментами. Интересен этап развертывания с использованием GitOps, где для улучшения интеграции с существующими процессами можно использовать такие инструменты, как ArgoCD и Flux.

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

Заглядывая в будущее, можно сказать, что Nelm открывает многообещающие возможности для сообщества Kubernetes. Его способность интегрироваться с существующими приложениями на основе Dockerfile и Helm-чартами гарантирует, что миграция и внедрение новых технологий будут плавными и беспроблемными. Nelm не только сохраняет обратную совместимость с Helm, но и предоставляет значительные улучшения, которые могут ускорить и упростить управление развертыванием Kubernetes.

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

В будущем ключевым фактором будет дальнейшее развитие и внедрение Nelm, который может либо стимулировать развитие Helm, либо заменить его.