Helm: СБОЙ ОБНОВЛЕНИЯ: ресурс с именем "" не найден

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

Итак, если это установлено: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

А затем в качестве зависимости добавляется новая диаграмма:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

Когда выпуск обновляется с помощью: helm upgrade my-release my-thing helm выдает следующую ошибку:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth Я не могу воспроизвести эту проблему на мастере. Вы все еще сталкиваетесь с этой проблемой? Какую версию руля / румпеля вы используете?

Спасибо!

@elementalvoid Мне также не удалось воспроизвести новую ошибку зависимости от мастера. Вы все еще сталкиваетесь с этой проблемой? Какую версию руля / румпеля вы используете?

Спасибо.

В то время я был на альфе 4. Используя альфа 5 и

Хорошо. Я пока закрою это. Не стесняйтесь сообщить о проблеме, если вы снова увидите одну из этих проблем.

Еще раз спасибо.

@michelleN спасибо! Извините, на этой неделе у меня не было времени попытаться повторить мастер. С нетерпением жду обновления!

То же самое для меня при перемещении спецификации hostPath Deployment / Volume в PVC.
Кажется ошибка, когда манифест обновления зависит от нового ("отсутствует" в старом?)
версия: 2.7.2

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

Моя ситуация заключалась в том, что у меня был новый ресурс, и я развернул новую версию диаграммы управления с новым ресурсом. Это развертывание не удалось, потому что я нащупал немного ямла. Что ж, новые объекты были созданы в кубернетах. Я исправил yaml и снова запустил обновление на моем графике, и вуаля, появляется сообщение об ошибке, что ресурс не найден. Мне пришлось зайти в кубернеты и удалить новые ресурсы (в моем случае роль и привязку ролей), которые были созданы в результате неудачного развертывания. После этого проверка руля на наличие текущего объекта завершится ошибкой (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) не будет успешной, и ресурсы будут созданы. очередной раз. Похоже на ошибку, где, возможно, следует учитывать новые ресурсы для неудачного графика?

Получение аналогичной ошибки при обновлении:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

Configmap создана

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

Моя конфигурационная карта:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

У нас такая же проблема.

Я удалил весь выпуск, а затем снова установил. В настоящее время вроде работает.

$ helm del --purge bunny

У меня тоже есть эта проблема

Клиент: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}
Сервер: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}

Это часто случается с нашим использованием helm и требует полного --purge . Это _не_ решение.

Это не применимо, если вы используете CI / CD.
Что произойдет, если обновление не удастся, и вы используете стратегию скользящего обновления. Должен ли я удалить все еще работающий выпуск?

Я вижу ту же проблему, когда возникает проблема с развертыванием или аналогичная, но секрет / cm был создан, но затем Helm теряет его, отказываясь позволить вам многое сделать.

Я видел, что это редко случается даже с исправной версией (то есть видно, что оно прошло), но мне еще предстоит выяснить, что могло вызвать это.

Мы также можем воспроизвести эту проблему (сервер v2.8.2) при добавлении ресурсов в существующие развертывания Helm. Необходимость удалять развертывание и повторно развертывать каждый раз, когда нужно добавить новый ресурс, будет большой проблемой в производственной среде.

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

Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: нет ресурса с именем "" нашел

Примечание: мы используем 2.7.2;

Я считаю, что это происходит потому, что когда helm определяет, что изменилось, он ищет новый ресурс configmap в старой версии и не может его найти. См. Https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 для кода, откуда возникает эта ошибка.

Журналы румпеля для неудачного обновления:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

Эта проблема также возникает при изменении метки name развернутой службы, возможно, и других вещей.

Я меняю имя службы в выпуске, и ее не удается обновить с помощью:

Ошибка: ОБНОВЛЕНИЕ НЕ ПРОЙДЕНО: не найдена служба с именем "новое-имя-службы"

Я был бы готов создать PR, чтобы исправить это поведение, но я хотел бы знать, какой предполагаемый или предлагаемый способ справиться с этим. Было бы замечательно даже флаг CLI, который позволяет --force иметь приоритет.

Согласитесь с важностью.

Эта проблема может быть странной, если вы не можете просто удалить развертывание.

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

Helm не пытается выполнить очистку после неудачного развертывания, что означает создание таких вещей, как новая ConfigMap, которую я добавил выше, но без ссылки в «предыдущем» развертывании. Это означает, что при следующем развертывании helm находит ресурс в k8s и ожидает, что на него будет ссылаться последняя развернутая ревизия (или что-то в этом роде; я не уверен, какую точную логику он использует для поиска `` предыдущей '' версии), чтобы проверить, что изменения есть. Его нет в этом выпуске, поэтому он не может найти ресурс и терпит неудачу.

Это в основном проблема при разработке диаграммы, поскольку неудачное развертывание помещает k8s в состояние штурвала, которое не отслеживается должным образом. Когда я понял, что это происходит, я понял, что мне просто нужно удалить ConfigMap из k8s и снова попробовать развертывание.

@krishicks Да, это один из способов воспроизвести это. Неудачное развертывание + никогда не созданный ресурс (например, недопустимая конфигурационная карта) также может вызвать это, как я заметил, что затем приводит к неустранимому состоянию

Мы тоже достигаем этого. Это та же проблема, о которой упоминают @krishicks и @jaredallard :

1. У нас неудачное развертывание:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Любые последующие изменения, в том числе и в других выпусках, завершаются ошибкой с предупреждением типа
   Error: UPGRADE FAILED: no Service with the name "…" found

Я попытаюсь использовать флаг helm upgrade --timeout … чтобы смягчить первую проблему, но неудачное развертывание, блокирующее все, для нас является серьезной проблемой. Кроме того, использование helm rollback … не помогло.

Поскольку helm upgrade … запускается автоматически в нашем варианте использования, очень полезен флаг --auto-rollback для helm upgrade , который отменяет неудачные изменения.

Это происходит у меня с v2.7.2 при добавлении новых ресурсов в диаграмму.
Есть ли какие-нибудь предположения о том, когда это будет исправлено?

Это должно быть исправлено с помощью # 4146.

РЕДАКТИРОВАТЬ: см. Ниже

Итак, я обнаружил несколько ошибок в # 4146, которые делают его нежелательным для продвижения вперед. Я сообщил о своих выводах между master, # 4146, и # 4223 здесь: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

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

Да, и кое-что, что я не упомянул: поскольку кластер находится в несогласованном состоянии, это можно легко обойти, вмешавшись вручную и удалив ресурс, о котором ошибка сообщает как «не найден». Следуя примеру, который я продемонстрировал в https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

@bacongobbler Это не всегда срабатывает. У нас были ситуации, когда его удаление действительно работало, а в некоторых случаях оно все еще не работало после этого.

это можно легко обойти, вручную вмешавшись и удалив ресурс

@bacongobbler. Пожалуйста, поймите, что этот ресурс может быть объектом Service или Deployment из производственного пространства имен, что может (и уже сделало) серьезно нарушить наши гарантии обслуживания.

Да, я знаю. Я просто объясняю и наблюдаю за поведением ошибки, чтобы другие знали, в чем дело. :)

Просто столкнитесь с этой проблемой дважды на разных кластерах. Каждый раз с configmaps. Удаление ресурсов не решило проблему, поэтому нам пришлось удалить весь выпуск.

То же самое. Не только Configmaps, у меня есть одна с ServiceAccount.

ПВХ здесь. :)

Этой ошибке подвержены практически все приоритетные объекты.

Кому-нибудь поручено это исправить? Для этого уже есть пиар? Могу я чем-нибудь помочь?

Меня укусила эта проблема не один раз, потому что в эту ситуацию легко попасть, но, видимо, нет простого способа выйти из нее. Я полагаю, что "хорошая" часть в моем случае заключается в том, что ресурсы обновляются даже с ошибкой в ​​выпуске (не уверен, радует ли это меня или беспокоит)

Я думаю, что helm должен либо запретить пользователю попадать в это неправильное состояние, либо правильно его обработать.
Есть ли какие-либо реальные исправления этого, помимо удаления всего (это применимо только для непроизводственного использования)?

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

@Draiken нет, мы пытались

а) не выполняйте обновление, как предполагалось, или
б) вводить новые ошибки

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

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

Обходной путь, который сработал для меня, - выполнить helm rollback ... прямо перед тем, как произошел сбой. Затем я проверяю, работает ли диаграмма в новом выпуске с helm install -n new-test-release . .

Как только все заработает, я очищаю тестовый выпуск и запускаю helm upgrade ... против старого выпуска; и все заработало. Это неприятный обходной путь, но, похоже, он работает.

Я не знаю, помогает ли это вообще, но я столкнулся с этой проблемой как в тестовом, так и в производственном кластерах.

Изменения, которые я внес в мои файлы руля, были довольно простыми:
У меня было 1 существующее развертывание со связанным сервисом и бюджетом poddisruptionbudget, который остался без изменений.
Я добавил 2-е развертывание с собственным сервисом и подразбиванием бюджета.
Я увеличил номер версии диаграммы.

При запуске helm я впервые получил эту ошибку:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

При повторном запуске helm я снова и снова получаю эту ошибку:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

Диаграмма руля, конечно же, работала в тесте, когда я все удалил и развернул заново. Однако на самом деле это не вариант для прод.

@veqryn Я

РЕДАКТИРОВАТЬ : Если кому-то интересно попробовать, я могу отправить его в общедоступное хранилище докеров и включить быстрый фрагмент того, как его использовать.

@jaredallard мы заинтересованы. Спасибо!

Я знаю, что сопровождающие могут не рекомендовать его, но это лучше, чем ничего.

@jaredallard, мы не можем рекомендовать этот патч просто потому, что он не работает сам по себе (ссылка: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Он обходит ошибку, но не обновляет ресурсы, поэтому исправление не выполняет то, что пользователь изначально намеревался сделать. Он устраняет одну проблему, но вводит другую, не устраняя исходную проблему, которую пользователи намереваются решить: обновить ресурс.

Однако это интригует:

Я в основном использую свою сборку в # 4146 всякий раз, когда сталкиваюсь с этой проблемой, а затем переключаюсь на основную.

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

а) обходит ошибку
б) позволяет обновлять ресурсы так, как они изначально планировались

выполнив 2 helm upgrade s: один с патчем, а другой без? Это может помочь нам лучше определить основную причину и способы исправления этой ошибки.

@bacongobbler Мне пришлось бы еще раз вернуться к этому, чтобы на 100% убедиться, что это так. Я обновлю этот комментарий или опубликую еще один, когда у меня будет.

Я знаю, что сопровождающие могут не рекомендовать его, но это лучше, чем ничего.

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

Я до сих пор не понимаю, почему мой руль вышел из строя в первый раз.
Ошибка no X with the name Y возникла только во второй раз, когда я попытался применить ее.

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

Для ленивых: https://github.com/helm/helm/pull/4223#issuecomment -397413568

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

Однако ни один из моих сервисов или ресурсов ни разу не изменил названия.

И, перечитав ваш комментарий и поговорив с моей командой, мы выяснили причину нашей ошибки:
Я столкнулся с версией своего руля Chart.
Эта версия диаграммы упоминалась как метка в моих развертываниях и сервисах.
Kube / helm не любит, когда меняется ваш лейбл, и именно это вызвало исходную ошибку.

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

это (уродливое) исправление работает для меня:

1. Я получаю сообщение об ошибке:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. найти последние РАЗЛОЖЕННЫЕ ревизии

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (Важно) Найдите все ресурсы, существующие новые ресурсы были добавлены с момента последнего развертывания (v16), и удалите их, например
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Запустите helm upgrade ... и увидите Happy Helming

Как сказал @ kosta709 , возврат к последней развернутой версии, исправление (вручную) диаграммы или текущего статуса (что не так) и выполнение нового обновления обычно работают.

Helm - отличная программа, от которой можно отказаться в некоторых автоматических рабочих процессах (CI / CD), если результат команды нестабилен.

Есть ли вариант, когда известные решения в конечном итоге будут реализованы в рулевом управлении, чтобы (попытаться) решить эту хорошо известную (и немного раздражающую) проблему? Спасибо.

Итак, в последнее время я тоже часто сталкиваюсь с этим, достаточно, чтобы заставить меня работать над этой проблемой самостоятельно. Для начала я создал обходной путь (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686), что в основном заставляет Tiller использовать существующий ресурс в качестве отправной точки вместо ресурса, взятого из старого манифеста. Для меня работает как шарм, хотя я считаю, что основные разработчики не захотят объединять его, поскольку он содержит жестко запрограммированное поведение.

За одним и тем же поведением могут быть скрыты две ошибки, поскольку, по крайней мере, однажды, когда эта ошибка укусила меня, мне пришлось удалить много (> 40) ресурсов, включая те, которые присутствовали в более чем 20 успешных версиях выпуска. Но в 99% случаев достаточно просто удалить только что созданные (но пока неизвестные Helm) ресурсы.

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

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

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

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

• --ignore-old-manifest=never (по умолчанию, текущее поведение)
• --ignore-old-manifest=create-only (применимо к этому случаю, когда старый манифест не имеет понятия о ресурсе, но ресурс уже существует, мы можем принять это как новую базу и просто исправить ее, если необходимо) - я бы рекомендовал это быть новым По умолчанию. Это также позволит helm начать владение ресурсами, созданными вручную.
• --ignore-old-manifest=always - просто для полноты, вероятно, не обязательно. Он всегда будет создавать патч между текущим ресурсом и новейшим манифестом, в основном удаляя все пользовательские изменения.

Конечно, вы можете переименовать флаг, чтобы использовать обратную логику: --use-current-resources=never(currently default)/create-only/always или что-то в этом роде.

Позже этот флаг можно было взять из аннотаций ресурсов, например:

annotations:
  helm.io/ignore-old-manifest: always

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

Итак, что вы думаете об этом предложении?

См. Также выпуск №3805, в котором разработчики Helm рассматривают возможность трехстороннего слияния.

Здесь та же проблема.
Попытка настроить среду CD / CI с помощью сборки Google Cloud.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

Самое смешное, что развертывание существует:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

Это первая диаграмма, которую я создаю, и я ожидал, что helm будет решением, позволяющим справиться со сложностью развертывания сложных приложений в среде CI / CD.

Является ли намерение helm способным работать в конвейере CI / CD?

Спасибо

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Я тоже сталкиваюсь с этим, пытаясь обновить helm 0.8.0 до helm 1.0.0.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

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

Проверьте последние обсуждения в https://github.com/helm/helm/issues/3805

Имея это, все еще происходит в последней версии Helm 2.10

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

С большим количеством звезд GitHub налагаются большие обязанности

@ brendan-rius Вы можете внести свой код для исправления этой проблемы или придумать идеи. См. # 3805 и # 4146 для некоторых указателей.

В частности, @ brendan-rius, # 3805 содержит самые свежие обсуждения этой ошибки. Я настоятельно рекомендую прочитать эту ветку, чтобы понять, с чем мы сталкиваемся.

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

Если трехстороннее слияние неприменимо для новых развертываний в Helm 2.yz, когда будет исправлен # 1193? Ошибка существует уже почти два года, и четкого решения для Helm 2.0 не запланировано.

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

Например, ранее на этой неделе мы с @michelleN провели мозговой штурм и придумали два возможных решения, ни одно из которых не является особенно фантастическим:

1. В случае сбоя обновления мы автоматически откатываем и удаляем ресурсы, созданные во время этого выпуска.

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

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

Это чрезвычайно рискованно, поскольку Helm может удалять объекты, которые были установлены через другие пакеты или через kubectl create , и ни то, ни другое пользователи не захотят.

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

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

@bacongobbler , если не планируется поддержка функции трехстороннего слияния, нам нужна альтернатива или обходной путь. В противном случае # 1193 - очень болезненный боксер.

Чтобы повторить проблему и способ ее решения:

Когда обновление, при котором устанавливаются новые ресурсы, не удается, выпуск переходит в состояние FAILED и останавливает процесс обновления. В следующий раз, когда вы вызовете helm upgrade , Helm выполнит сравнение с последним DEPLOYED выпуском. В последнем DEPLOYED выпуске этот объект не существовал, поэтому он пытается создать новый ресурс, но терпит неудачу, потому что он уже существует. Сообщение об ошибке полностью вводит в заблуждение, как указывает @arturictus .

Это можно легко обойти, вмешавшись вручную и удалив ресурс, о котором ошибка сообщает как «не найден». Следуя примеру, который я продемонстрировал в https://github.com/helm/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

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

Прежде всего, чем именно заключается проблема при обновлении с Istio 0.8.0 до Istio 1.0.0, которая вызывает проблему, или полностью ли она соответствует вашему описанию проблемы. Я предполагаю, что примерно за 3 дня до выпуска некоторые объекты, которые ранее были неуправляемыми (т. Е. Добавлены в задание после установки), были перенесены, чтобы не устанавливаться в задании после установки.

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

Мы готовы принять однократное обновление с 0.8.0 до 1.0.0. Если обновление постоянно нестабильно - это уже другая проблема.

Я выполнил разделение пополам на Istio - обновление работало до 27 июля (за 3 дня до выпуска Istio 1.0.0) и обнаружил, что эта фиксация проблематична: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

Этот PR по существу удалил регистрацию объекта из заданий после установки. Я полагаю, но не уверен, что мы удалили все экземпляры постустановочных заданий за 3 дня запуска Istio 1.0.0.

Можете ли вы дать совет по поводу конкретной диаграммы Helm Istio, связанной с обновлением? Поможет ли отказ от регистрации объекта в заданиях после установки решить наши проблемы с обновлением навсегда?

Я не могу дать никаких убедительных советов или предложений по устранению этой проблемы в масштабе всего руля, поскольку люди с более недавним опытом работы с Helm не смогли найти общего решения (и не из-за того, что проблема не была рассмотрена). Не думаю, что смогу сделать лучше.

Ваше здоровье
-Стив

Обновлен заголовок, чтобы лучше отразить ошибку.

Мы также затронуты этой проблемой. Мы используем последнюю версию helm 2.10 с GKE 10.6.
Когда я могу ожидать, что это будет исправлено?
Есть ли у нас какое-нибудь разумное решение этой проблемы? Удаление всего развертывания с опцией --purge - это так плохо.

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

Обходной путь был повторен несколько раз в этом потоке. Прочтите https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Мне нравится идея функции автоматического отката руля ( вариант 1 ) для решения этой проблемы. Мы знаем, что последний РАЗВЕРТЫВАЕМЫЙ выпуск Helm работал и кластер был в хорошем состоянии, поэтому к нему можно безопасно вернуться. Если это опасно для некоторых случаев использования, это может быть отказ с помощью флага для обновления руля.

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

Я думаю, что многие пользователи helm используют helm в автоматическом режиме через инструмент CD или CM, и более рискованно оставлять выпуск helm в состоянии FAILED. Эти неполные ресурсы в неудачном выпуске могут неожиданно повлиять на другие ресурсы и сами по себе могут вызвать простои. Например, если спецификация модуля содержит отсутствующую версию изображения, которая каким-то образом попала в рабочую среду, ваша рабочая нагрузка будет в нерабочем состоянии ImagePullBackOff. Для нашей компании это еще хуже, поскольку у нас есть некоторые локальные клиенты, которые могут обновиться через наш пользовательский интерфейс, и в случае сбоя мы должны получить доступ к их системе для отладки.

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

@bacongobbler может использовать следующий подход для новых развертываний:

• Добавить флаг - -three-way-merge
• Разрешить использование этого флага только в helm install (новое развертывание)
• Как только этот флаг включен, обновление всегда будет использовать трехстороннее слияние.
• Существующие развертывания застряли бы без пути миграции - стандартное обходное решение, которое люди, похоже, используют на этом этапе, - это helm delete --purge за которым следует helm reinstall так что это может быть не так неприятно, как кажется на первый взгляд.

Действительно ли это решило бы проблему?

Некоторые люди рассматривают возможность внедрения Оператора, чтобы обойти это ограничение Helm. Это было бы серьезным позором. См. Https://github.com/istio/istio/issues/8841#issue -361871147

Ваше здоровье
-Стив

Возвращаясь к предыдущему комментарию @bacongobbler :

1. Если во время обновления мы создаем новый ресурс и видим, что он уже существует, мы вместо этого применяем эти изменения к существующему ресурсу или удаляем / воссоздаем его.
   Это очень рискованно, поскольку Helm может удалять объекты, которые были установлены с помощью других пакетов или с помощью kubectl create, и ни то, ни другое пользователи не захотят.

Интересно, можем ли мы снизить этот риск, включив новое поведение? В данном пространстве имен я обычно использую исключительно helm, и я подозреваю, что это так для многих. Если бы я мог установить / обновить Helm флаг, чтобы сообщить ему, что все в данном пространстве имен, не являющееся частью существующей версии, можно удалить / перезаписать, это поможет?

Поскольку вы также сказали «через другие пакеты», я предполагаю, что вы не хотите, чтобы Helm проверял другие выпуски в рамках выполнения выпуска, поэтому мое предложение не сработает, кроме как в модели с одним выпуском на пространство имен. Чтобы ответить на это возражение, я бы сказал: если вы хотите управлять несколькими пакетами в пространстве имен и при этом сохранять такое поведение, создайте зонтичную диаграмму, единственная цель которой - указать нужные вам зависимости диаграммы. Затем используйте новый флаг («--exclusive»?) При развертывании этой зонтичной диаграммы.

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

@bacongobbler Я мог бы быть далеко отсюда. Я столкнулся с аналогичными проблемами при обновлении. Судя по тому, насколько сложно решить эту проблему, мне интересно, нужно ли пересматривать что-то более фундаментальное. Частично сложность, по-видимому, связана с тем, что Helm поддерживает свою собственную версию известной конфигурации, отдельно от фактического источника истины, которым является кубернет. Была бы система более надежной, если бы Helm хранил только копию ранее развернутых диаграмм управления для целей истории и отката, но не использовал бы ее вообще во время обновления. Вместо этого Helm будет получать правду от самого kubectl, а затем всегда иметь двухстороннюю разницу для выполнения?

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

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

Если в диаграмме руля указано, что у него должен быть ресурс X, а согласно kubectl его нет, то Helm создает его.

Если kubectl сообщает, что у него есть ресурс Y, помеченный как управляемый этой диаграммой управления, и в этой диаграмме управления нет ресурса Y, то helm удаляет этот ресурс.

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

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

Мы тоже наблюдаем эту проблему. Наши шаги воспроизведения:

1. helm install диаграмма, успешно устанавливающая развертывание
2. Обновите диаграмму, чтобы включить настраиваемый ресурс в дополнение к существующему развертыванию.
3. Измените образ подспецификации развертывания, чтобы имитировать сбой развертывания
4. helm install новый график. Это вызовет непрерывное обновление развертывания, которое мы намеренно настроили на сбой.
5. Установка руля должна завершиться ошибкой. Но кастомный ресурс нужно оставить в k8s etcd. (проверьте, используя kubectl )
6. (На данный момент штурвал в плохом состоянии)
7. Исправьте диаграмму - поместите образ goot в podspec развертывания.
8. helm install . Мы ожидаем, что это сработает, но это не так. Сообщает «Нет ресурса с именем ___». Это имя настраиваемого ресурса.
9. Восстановление: удалите остаточный пользовательский ресурс с помощью kubectl . Теперь helm install будет работать.

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

@ rbair23 мы пробовали это раньше , но это не сработало. Есть рабочая группа Apply, которая стремится улучшить состояние декларативного управления объектами, исправив kubectl apply, переместив логику с клиента на сервер , но это все еще находится на начальной стадии. Kubectl (и tiller) должны сохранить копию последней примененной конфигурации для выполнения сравнения. Вы не можете сравнивать текущее состояние кластера, не выполнив трехстороннюю стратегию исправления слияния, возвращающуюся к этому тикету.

Поскольку # 3275 был закрыт как дубликат этого: у нас аналогичная ситуация, как в # 3275

Уже есть выполняющееся задание my-long-running-job . И мы пытаемся обновить выпуск:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

Работа существует:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

Удаление этой работы:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

Устраняет это препятствие:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

По крайней мере, сообщение no Job with the name "my-long-running-job" found вводит в заблуждение, но я ожидал, что задание тоже будет обновлено.

Это все еще наблюдается в v2.9.1 (в настоящее время выпущена стабильная версия)

Я не согласен с тем, что отказываться от обновления «очень опасно». Думаю, это правильное решение.

Kubernetes декларативен. Снимок состояния кластера до попытки обновления.
Если при выполнении возникла ошибка, вернитесь к снимку.
Если у кого-то есть обработчики сценариев, которые при этом оставляют кластер в плохом состоянии, то это их собственная вина. (Возможно, это тоже можно решить с помощью хуков отката)

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

Привет,

Была такая же проблема с:

Клиент: v2.10.0 + g9ad53aa
Сервер: v2.10.0 + g9ad53aa

Удаление serviceAccount, configMap и service было единственным способом заставить Helm обновить выпуск.

Привет,

у нас та же проблема, что и описанная

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

Зайдите в это на v2.9.1.

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

В итоге мы получили несколько повторяющихся развертываний FAILED в helm list но последнее рабочее развертывание было DEPLOYED . Создание новых развертываний привело к потере No resource with the name x found .

Удалось исправить, запустив helm rollback для последней версии, которая находилась в состоянии DEPLOYED на helm list . После этого обновления все прошло без ошибок.

Проверьте это https://github.com/helm/helm/pull/4871.

Судя по всему, эта ошибка, как и другие, возникает у меня чаще всего (я не уверен, что всегда), когда мое последнее развертывание не удавалось, и новые активы из этого развертывания оставались установленными.

Я понимаю, что удаление компонентов из неудачного развертывания Helm может быть сложным и / или нежелательным, но каково идеальное поведение Helm в такой ситуации?

Во-первых, я думаю, что Helm должен быть в порядке с уже существующими пространствами имен и другими ресурсами, если он пытается (пере) установить их. Kubernetes - это «сделайте конфигурацию правильно, и пусть kube выяснит, как заставить мир соответствовать конфигурации».
Во-вторых, я думаю, что Хелм должен действовать по принципу «все или ничего». В случае сбоя развертывания кластер должен находиться в том состоянии, в котором он был до начала развертывания.
Если есть два выпуска, в которых требуется создать пространство имен X, возникает проблема с подсчетом ссылок. Если есть выпуск, который хочет создать пространство имен X, но он уже существует, тогда существует проблема происхождения. Однако helm может записывать это, используя аннотации к объектам, и делать правильные вещи.

Я также сталкиваюсь с этой проблемой с последними версиями helm 2.12.0 и kubernetes 1.10.11, даже откат до последней хорошей версии, как предложил @aguilarm , не сработал, также удаление ресурсов, на которые жалуется helm, не помогает, и после обновления сбой команды, он оставляет те же ресурсы как фактически частично воссозданные. Очень неприятно для продукта env ...

У меня есть 2 кластера с очень похожей средой, основная разница между двумя - это общее количество узлов. В одном случае helm delete --purge последующим новым helm install сработало, но в другом - нет, и мне еще предстоит придумать способ внести это в последние изменения шаблона.

Есть ли здесь какое-либо расчетное время прибытия?

Я смог обойти это с помощью helm rollback и указав самую последнюю версию (ту, которая не удалась)

Была такая же проблема сегодня,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback сработало.

Мы довольно регулярно сталкиваемся с этим при обновлении руля - это происходит после успешных развертываний, а не только после неудачных. Мы не можем использовать команду delete --purge, поскольку это производственные системы с нетривиальными компонентами, которые 1) не могут быть недоступны и 2) для полного восстановления с нуля потребуется слишком много времени, чтобы быть приемлемым.

См. Диагностику и обходной путь, которые я опубликовал выше. Сообщите мне, если это сработает для вас.

@bacongobbler Спасибо за ответ. Фактически, это обходной путь, который я придумал, и на данный момент его должно хватить, но мы используем обновления руля десятки раз в день через наш CICD, поэтому это возникает достаточно часто, чтобы стать головной болью. Я не уверен, что все вышеперечисленное - это вся история, хотя, поскольку названные ресурсы часто уже существуют, являются частью успешного развертывания и не изменяются в текущем развертывании - iirc это почти всегда самый последний набор ресурсов в последнем успешном развертывании хотя довольно интересно.

+1 к @ajcann и спасибо @bacongobbler
Я в точно такой же ситуации.
Наш CICD автоматизирован, и часто развертывание выполняется слабым ботом для более низких сред.
В случае сбоя я должен вручную выполнить откат руля и снова развернуть его.
Проблема не постоянная, но частая.
Для меня это происходит пока только во время второго развертывания диаграммы / ресурса.
Ресурс всегда есть.

мы наблюдаем ту же проблему. Это происходит, если у вас есть шаблон, который либо:

• в выписке {{if $condition -}}
• или в {{ range $index, $value := $array-}}

@jkroepke только что указал мне, что PR # 5143 обеспечивает хорошее решение этой проблемы. Когда флаг --atomic будет выпущен в следующей младшей версии, вы сможете использовать его для автоматической очистки или отката при возникновении ошибки.

@bacongobbler, учитывая, что вы участвовали в большей части этого, есть ли что-то еще, что можно сделать, чтобы полностью исправить это, или будет ли достаточно флага --atomic ?

Я думаю, что @distorhead может захотеть взглянуть на него и посмотреть, решит ли он его опасения, которые он поднял в https://github.com/helm/helm/pull/4871. Помимо этого, похоже, что --atomic должно решить проблему, если вы всегда используете флаг --atomic .

Я не верю, что есть какие-либо предлагаемые решения для решения проблемы, когда вы попадаете в это конкретное состояние, но я могу ошибаться. Если стратегия смягчения этой проблемы

• вручную пройти через текущее состояние кластера и исправить его в соответствии с обходным путем
• обновитесь до Helm 2.13.0 и используйте helm upgrade --atomic дальнейшем

Тогда я думаю, что это безопасно закрыть.

Надеюсь, Helm 2.13.0 не так уж и далек.
Эта ошибка нарушает CI, если где-то в выпуске произошла ошибка.

Atomic не решит проблему

Пример диаграммы: https://github.com/distorhead/ex-helm-upgrade-failure

1. Проверить мастер, запустить развертывание.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

Диаграмма содержит 2 развертывания - myserver1 и myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. Сделайте критическое изменение. Удалите развертывание myserver1 из диаграммы и измените развертывание myserver2 с ошибкой пользователя (например, удалите поле изображения):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. Запускаем развертывание:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

Снова поздоровайся с нашим другом:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead, каково было ваше ожидаемое поведение в этом сценарии?

Немного оффтоп про откаты, но все равно.

Для тех людей, которые хотят использовать откат, но также не хотят, чтобы откат происходил сразу после развертывания, как в --atomic по некоторым причинам. Потому что, например, у пользователя нет возможности вручную проверить плохое состояние кластера после сбоя, и потому что флаг --wait не заставляет helm регистрировать любую информацию о сбоях в развертываемых ресурсах. Тогда есть способ: откатиться при следующем запуске, перед обновлением (подробнее https://github.com/helm/helm/issues/3149#issuecomment-462271103)

Чтобы повторить проблему и способ ее решения:

Когда обновление, при котором устанавливаются новые ресурсы, не удается, выпуск переходит в состояние FAILED и останавливает процесс обновления. В следующий раз, когда вы вызовете helm upgrade , Helm выполнит сравнение с последним DEPLOYED выпуском. В последнем DEPLOYED выпуске этот объект не существовал, поэтому он пытается создать новый ресурс, но терпит неудачу, потому что он уже существует. Сообщение об ошибке полностью вводит в заблуждение, как указывает @arturictus .

Это можно легко обойти, вмешавшись вручную и удалив ресурс, о котором ошибка сообщает как «не найден». Следуя примеру, который я продемонстрировал в # 4223 (комментарий) :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

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

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

Вы можете написать плагин, похожий на helm diff который бы перечислял шаблоны, созданные в последней версии. Вы даже можете потреблять pkg/kube прямо из Helm. client.Update есть некоторая бизнес-логика, написанная для отслеживания / удаления ресурсов helm, которую можно повторно использовать, получив две версии из Tiller и изменив порядок сравнения. target.Difference(original) должен дать вам результат всех ресурсов, которые были введены с момента предыдущего выпуска.

@bacongobbler Какое решение вы бы порекомендовали: взять приложение, развернутое как часть выпуска A (например, более крупный выпуск, состоящий из нескольких приложений), и разбить его из выпуска A на его собственный выпуск (или наоборот) без простоев (обходной путь для удаления ресурсов может вызвать некоторое время простоя) ... Попытка обновить ресурс через другую версию приводит к ошибке, описанной в этой проблеме Github.

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

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

1. Запустите helm list и найдите последнюю версию затронутой диаграммы

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. Перейдите оттуда и найдите последнюю версию с состоянием DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. Как только вы найдете последнюю РАЗРЕШЕННУЮ ревизию, измените ее состояние с DEPLOYED на SUPERSEDED и сохраните файл.
4. Попробуйте сделать helm upgrade раз, в случае успеха - все готово!
5. Если вы столкнулись с такой ошибкой обновления:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   затем измените статус самой последней ревизии с FAILED на DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Попробуйте сделать helm upgrade раз, если снова не удастся, просто переверните стол ...

@bacongobbler @michelleN
Есть ли что-нибудь, что затрудняет исправление сообщения об ошибке для этой проблемы?

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

@selslack Я бы очень хотел улучшить сообщение об ошибке 👍

@michelleN Я подготовил PR для изменения текста ошибки: # 5460.

У меня возникла эта проблема, и я не знаю, как ее решить.

Я пробовал все шаги, перечисленные здесь @reneklacan : https://github.com/helm/helm/issues/1193#issuecomment -470208910

К сожалению, это не сработало. Единственное, что решает проблему, - это удалить ресурс, генерирующий сообщение об ошибке, а затем снова helm upgrade , что будет успешным.

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

У меня есть две среды, в которых я использую helm для развертывания в рамках нашего процесса CI: QA и производственная среда.

В среде контроля качества была такая же проблема, поэтому я использовал helm delete --purge , а затем helm upgrade - это навсегда устранило проблему.

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

@zacharyw с какой ошибкой вы столкнулись в данный момент? No resource with the name ... или "fetlife-web" has no deployed releases ?

Не могли бы вы поделиться какой-либо дополнительной информацией, которая могла бы помочь в отладке этого?

Возможно вывод kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (замените YOUR_RELEASE_NAME )

Не стесняйтесь отправить мне электронное письмо с дополнительной информацией, если вы не хотите спамить эту проблему потенциально несвязанными данными (rene (at) klacan (dot) sk).

См. Https://github.com/helm/helm/issues/1193#issuecomment -419555433 для возможной диагностики и обходного пути, @zacharyw.

@reneklacan Это no resource with the name ... . В нашем случае мы добавили вход, он вроде бы работал, но затем последующие обновления начали давать сбои с этой ошибкой ... хотя вход уже существовал.

Статус моего последнего выпуска (после удаления вредоносного входящего трафика и разрешения обновления Helm для его воссоздания): DEPLOYED :

STATUS=DEPLOYED
VERSION=197

Однако, если бы я попытался обновить снова, это не удалось.

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

@reneklacan в https://github.com/helm/helm/issues/1193#issuecomment -470208910 спас мне жизнь.

К сожалению, у Хелма это не получается. Удаление вещей практически в любой среде далеко от идеала.

Было бы здорово, если бы helm обновил свою базу данных при появлении такой ошибки, а затем повторил бы попытку.

Я считаю, что с включенным флагом --cleanup-on-fail этот случай ошибки должен исчезнуть. Закрытие согласно решению № 4871 и № 5143.

Если без этих флагов возникают другие проблемы, повторно откройте новый выпуск. Спасибо!

Проблема закрыта, я решил добавить комментарий о том, как решить эту проблему, не удаляя выпуск Helm или текущие развертывания.

Итак, я воспроизвел проблему, выполнив следующие действия:

1. Установите диаграмму test-chart-failure с шаблоном службы.
2. Добавьте поддиаграмму с шаблоном службы, у которого есть строка (например, "тест") в порту службы.
3. Обновите диаграмму. Произойдет сбой с ошибкой Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

Я смог выполнить обновление после исправления порта до числа без запуска helm delete , применив предложение на http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. Обнаружена неудавшаяся ревизия с helm history test-chart-failure
2. Удалена карта конфигурации конкретной ревизии с помощью kubectl delete cm -n kube-system test-chart-failure.v2
3. Выполнено helm upgrade с исправленным графиком