Kubernetes — Подталкивать Helm К Обновлению Развертывания?

Я использую Flux для автоматического развертывания выпуска Helm из репозитория git в кластер Kubernetes. Если я напрямую редактирую полученный результат развертывание спецификация объекта (с использованием kubectl edit or k9s , например чтобы временно попробовать другую версию образа контейнера), тогда Kubernetes развернет новые модули без простоев. Как я могу отменить такие изменения, то есть как я могу запустить обновление развертывание (и другие объекты) в соответствии с час, не прерывая обслуживания?

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

#kubernetes #helm

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

У Helm есть версия в Chart.yaml, я предполагаю, что несущественный коммит не обновит эту версию, поэтому Flux может предполагать, что ему не нужно ничего делать. Можно было бы попробовать изменить версию.

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

на каждом объекте развертывания, чтобы дождаться завершения, прежде чем приступать к тестам). Сам демон/агент Flux также может периодически проверять и выполнять синхронизацию (а также проверять реестры контейнеров на наличие новых тегов изображений для фиксации манифестов в репозитории). Предполагая, что репозиторий git состоит из выпусков Helm, Flux должен гарантировать, что количество часов в кластере соответствует количеству часов в репозитории. Но поток не должен влиять на какие-либо объекты кластера, которые нет напрямую представлены в репо. Вместо, Шлем

отвечает за обеспечение того, чтобы в кластере были развертывания, соответствующие hr. (И затем контроллер развертывания отвечает за обеспечение соответствия модулей развертыванию спецификации развертывания.) fluxctl sync then kubectl delete hr foo .

Синхронизация потока, по-видимому, ничего не делает, если фиксация головы git не изменилась (или даже если изменения в репозитории не кажутся значительными?). Если вы не хотите создавать новый коммит, вариант с коротким временем простоя будет следующим: kubectl rollout status (although this isn't guaranteed to succeed cleanly).

Предполагая, что было изменено только развертывание (а не hr), другой возможностью может быть выдача Если развертывание было только отредактированоодин раз fluxctl sync is appropriate.