обратная связь от масштабной миграции

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

ХелмВыпуск

пользовательский ресурс ХелмВыпуск описывает развертывание диаграммы Хелма компанией Flux. В Flux v1 это был отдельный компонент ( рулевой), на Flux v2 это теперь контроллер интегрирован во Flux.

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

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

• Перестать смеяться рулевой
• Развертывание новостей пользовательские ресурсы HelmRepository/ХелмВыпуск
• Оставлять штурвал-контролер перераспределить диаграмму, чтобы присвоить все проявляется создано Хелмом

Название выпуска du HelmRelease

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

С Flux v1 рулевой использовать {{spec.targetNamespace}}-{{metadata.name}} (с spec.targetNamespace что стоит metadata.namespace если не указано).

С Flux v2 то же самое кроме и spec.targetNamespace == metadata.namespace : в данном случае значение равно {{metadata.name}}. В этом случае необходимо явно указать то же самое название выпуска таким образом штурвал-контролер повторно развертывает диаграмму вместо развертывания нового экземпляра.

Автоматизация обновления изображений

Л’автоматизация обновления изображений как правило, не самая известная часть Flux, она позволяет обновлять образы контейнеров, когда новая версия доступна на реестр.

В целом операция выглядит следующим образом:

• Мы определяем реестр где искать новые изображения (с критерием выбора изображения)
• Это указано в проявляется Kubernetes под управлением Flux, какие образы обновляются автоматически
• Когда новое изображение доступно на реестрFlux изменяет манифестировать чтобы обновить образ и отправить изменения в репозиторий git, чтобы новый манифестировать быть развернут на следующем примириться потока

В Flux v1 настройка выполнялась с помощью аннотаций на странице проявляется для автоматического обновления.

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

ImageUpdateAutomation и пространства имен

В отличие от всех остальных пользовательские ресурсы потока, эти не являются (пока?) межпространственными именами. Итак, если мы хотим разместить в одном пространстве имен рабочие нагрузки, Репозиторий изображений и др. Политика изображенияон застрянет, потому что они должны быть в то же пространство имен что’ImageUpdateАвтоматизация и GitРепозиторий партнеры.

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

Сортировка тегов изображений

Одним из важных изменений, которое может потребовать адаптации конвейеров сборки, является способ Flux. сортировать изображения восстановлен из реестр для определения более новых версий.

Flux v1 использовал время сборки изображения по умолчанию, тогда как в Flux v2 это больше невозможно. Теперь вам необходимо отсортировать теги, используя один из следующих методов:

• По алфавиту
• Численно
• Через семантическое управление версиями

Eсть специальный гид чтобы при необходимости изображения можно было сортировать.

Доступ к частному реестру

Секрет получения больше не извлекается автоматически из нагрузкаэто надо уточнить явно в Л’Репозиторий изображений. Есть полезные примеры в ла документация для разных облачных провайдеров.

Переход на версию Flux v2 с черным поясом

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

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

Автоматизировать обновление манифеста

Имея около сотни HelmReleases для обновления примерно десяти кластеров, автоматизировать обновление проявляется стало необходимым.

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

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

Применить миграцию на Flux v2

Как только мы создали нашу мельницу для переработки всех проявляется в их версии Flux v2 развертывание плана миграции становится легкой частью 🙂

1. На шкала в 0 вкл. Развертывание Flux v1 и рулевой
2. Мы применяем проявляется Поток v2, созданный flux install --export
3. Однажды контролеры запустились, мы kubectl apply тот GitРепозиторий и Кастомизация который соответствует нашему git-репозиторию со всеми нашими проявляется
4. Мы генерируем новую версию проявляется с нашей катушкой
5. И мы git commit и др. git push все наши модификации

Остается только проверить, все ли в порядке с flux get all -A 😎: каждый элемент переместится в Ready=True поскольку Flux v2 применит содержимое.

Обычно в кластере ничего не должно меняться, поскольку Flux просто применяет то же самое. проявляется Kubernetes, чем раньше. Небольшая разница возможна для ХелмВыпуск : первый раз, штурвал-контролер выполняет helm upgradeчто может вызвать перераспределение (например, в случае, когда диаграмма генерирует значения).

Когда все в статусе readyпочти готово !

Осталось убедиться, что каждый ХелмВыпуск ранее управлялся CRD helmreleases.helm.fluxcd.io теперь ясно видно с помощью команды flux get helmreleases -A.

Затем мы можем удалить Развертывание Поток v1 и рулевой Затем CRD helmreleases.helm.fluxcd.io (⚠️ будьте осторожны, не удаляйте новость!).

Все кончено, вам остается только наслаждаться всем прекрасным новые возможности Flux v2 !

---

Не пропустите наши следующие статьи DevOps и др. Облачный родной! Следовать Эникс на Твиттер!