Helm: Сообщение «Ошибка: транспорт закрывается» при попытке установки

У меня такая же проблема. Развертывание «явно» успешно, но не удается из-за «Ошибка: транспорт закрывается» примерно через три минуты ожидания. Это происходит независимо от того, добавляю я --wait --timeout 600 или нет. Тем более, что релиз выглядит просто отлично:

NAME                        REVISION    UPDATED                     STATUS      CHART               NAMESPACE
review-feature-ld-s9rxem    1           Tue Jan 30 18:55:42 2018    DEPLOYED    lde-nginx-941.0.0   default

Кроме того, если время ожидания простоя ELB было равно 3600, установка по-прежнему завершалась сбоем в течение 3,5 минут:

$ time helm install stable/spinnaker --name spinnaker -f values-personal.yaml --wait --timeout 3600 --debug
[debug] Created tunnel using local port: '37517'

[debug] SERVER: "127.0.0.1:37517"

[debug] Original chart version: ""
[debug] Fetched stable/spinnaker to /home/jjyooi/.helm/cache/archive/spinnaker-0.3.12.tgz

[debug] CHART PATH: /home/user/.helm/cache/archive/spinnaker-0.3.12.tgz

Error: transport is closing

real    3m31.836s
user    0m0.432s
sys 0m0.034s

Я также вижу таймауты прямо на 210 с (3,5 минуты), независимо от флага --timeout , без таймаута LB посередине. Действительно, я вижу, что FIN отправляется от клиента на двух открытых сокетах на kube-apiserver. Это происходит во время ожидания выполнения хука post-install до завершения и не требует передачи --wait .

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

[storage] 2018/02/02 19:51:45 getting release history for "spinnaker-blenderfox" [tiller] 2018/02/02 19:51:46 uninstall: Release not loaded: spinnaker-blenderfox [tiller] 2018/02/02 19:52:02 preparing install for spinnaker-blenderfox [storage] 2018/02/02 19:52:02 getting release history for "spinnaker-blenderfox" [tiller] 2018/02/02 19:52:03 rendering spinnaker chart using values 2018/02/02 19:52:07 info: manifest "spinnaker/charts/jenkins/templates/rbac.yaml" is empty. Skipping. 2018/02/02 19:52:08 info: manifest "spinnaker/charts/minio/templates/minio_statefulset.yaml" is empty. Skipping. 2018/02/02 19:52:08 info: manifest "spinnaker/templates/secrets/gcs.yaml" is empty. Skipping. 2018/02/02 19:52:08 info: manifest "spinnaker/charts/jenkins/templates/config.yaml" is empty. Skipping. 2018/02/02 19:52:08 info: manifest "spinnaker/charts/jenkins/templates/service-account.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/charts/jenkins/templates/jenkins-master-networkpolicy.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/charts/minio/templates/post-install-create-bucket-pod.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/charts/jenkins/templates/jenkins-master-ingress.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/charts/redis/templates/networkpolicy.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/charts/minio/templates/minio_networkpolicy.yaml" is empty. Skipping. 2018/02/02 19:52:11 info: manifest "spinnaker/templates/ingress/deck.yaml" is empty. Skipping. [tiller] 2018/02/02 19:52:16 performing install for spinnaker-blenderfox [tiller] 2018/02/02 19:52:16 executing 7 pre-install hooks for spinnaker-blenderfox [tiller] 2018/02/02 19:52:16 hooks complete for pre-install spinnaker-blenderfox [storage] 2018/02/02 19:52:16 getting release history for "spinnaker-blenderfox" [storage] 2018/02/02 19:52:16 creating release "spinnaker-blenderfox.v1" [kube] 2018/02/02 19:52:23 building resources from manifest [kube] 2018/02/02 19:52:28 creating 37 resource(s) [kube] 2018/02/02 19:52:39 beginning wait for 37 resources with timeout of 1h0m0s [kube] 2018/02/02 19:52:53 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:53:06 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:53:19 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:53:28 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:53:36 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:53:47 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:54:02 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:54:15 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:54:30 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:54:36 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [kube] 2018/02/02 19:54:51 Deployment is not ready: default/spinnaker-blenderfox-spi-clouddriver [tiller] 2018/02/02 19:55:01 executing 7 post-install hooks for spinnaker-blenderfox [kube] 2018/02/02 19:55:01 building resources from manifest [kube] 2018/02/02 19:55:01 creating 1 resource(s) [kube] 2018/02/02 19:55:04 Watching for changes to Job spinnaker-blenderfox-create-bucket with timeout of 1h0m0s [kube] 2018/02/02 19:55:04 Add/Modify event for spinnaker-blenderfox-create-bucket: ADDED [kube] 2018/02/02 19:55:04 spinnaker-blenderfox-create-bucket: Jobs active: 1, jobs failed: 0, jobs succeeded: 0

@ huang-jy В моем случае это очень похоже на таймаут CLI руля, поскольку он отправляет пакет FIN.

Одна вещь, которую я собирался попробовать, - это использовать более старую версию helm.

Я подозреваю, что моя проблема возникает @ https://github.com/grpc/grpc-go/blob/424e3e9894f9206fca433fb4ba66f639be56e325/stream.go#L299 -L300. У меня такая проблема и с 2.7.2, и с 2.8.0. Далее попробую с мастером.

Что ж, master не подходит, потому что мне придется обновить Tiller в моей производственной установке kube.

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

Я использовал 2.6.0, и у меня не было тайм-аута. (использовался спинакер 0.3.12). Ждал как следует. Моя установка спинакера не удалась (некоторые контейнеры застряли в CrashLoopBackoffs)

Итак, я использовал 2.8.0 и последнюю версию спинакера. Он истек на полпути, но, судя по журналам румпеля, он все еще продолжался.

Когда я использовал 2.6.0 и последнюю диаграмму спинакера, он ждал ресурсов, хотя они, казалось, никогда не были готовы (возможно, проблема со спинакером, а не со штурвалом)

Просто любопытно, но кто-нибудь пробовал посмотреть FAQ и посмотреть, решило ли это для них это? https://github.com/kubernetes/helm/blob/29358ef9cef85c8467434008a42bc07e5a0d2a85/docs/install_faq.md#getting -started

Интересный отзыв, @ huang-jy.

@bacongobbler Я посмотрю. При этом я не вижу первых двух строк из цитируемого FAQ. Все, что я вижу, это Error: transport is closing . Но, может быть, «недостающие» строчки взяты из разных источников? Какие источники?

E1014 02:26:32.885226   16143 portforward.go:329] an error occurred forwarding 37008 -> 44134: error forwarding port 44134 to pod tiller-deploy-2117266891-e4lev_kube-system, uid : unable to do port forwarding: socat not found.
2016/10/14 02:26:32 transport: http2Client.notifyError got notified that the client transport was broken EOF.
Error: transport is closing

@bacongobbler @Nowaker Я также не вижу этих первых двух строк, и установка работает нормально, если я не включаю свой удаляю проверки работоспособности контейнера , которые не работают до тех пор, пока ловушка не будет выполнена). Установка фактически завершается, несмотря на тайм-аут (и приложение работает), но развертывание никогда не помечается как завершенное, и последующее обновление не выполняется. Это не чисто функциональная проблема, а реальный тайм-аут.

Прикомандированный @benlangfeld. Релиз заканчивается как DEPLOYED хотя Error: transport is closing попадает в меня через пару минут.

@bacongobbler: в моем случае произошло одно из трех:

1. Закрытие транспорта произошло в 2.8.0 и 2.8.1 во время установки, но установка продолжала происходить за кулисами даже после ошибки.
2. Версии до 2.8.0 (проверено с 2.7 и 2.6) не отображали это сообщение и продолжали ждать
3. Во время установки Tiller убивается кластером (не выселяется)

Обратите внимание, что @ huang-jy, похоже, единственный, у кого проблемы с Тиллером (выселение), и только в 1/3 его случаев. Эта проблема обычно не имеет ничего общего с Tiller и, по всей видимости, связана с тайм-аутом на стороне клиента. В моем случае Tiller никогда не переставал работать, и это чисто клиентское отключение.

@benlangfeld Да, это отключение клиента и что-то, что я думаю, в версии 2.8.0. Когда я использовал версию <2.8.0 в этом кластере, я не получаю сообщение об ошибке закрытия транспорта. Конечно, спинакер не устанавливается должным образом, но, вероятно, дело в диаграмме, а не в штурвале.

Я заметил, что есть комментарий об увеличении ОЗУ. Я мог бы оценить рабочие узлы и посмотреть, поможет ли это.

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

Бревна от мотоблока

[tiller] 2018/02/07 09:19:21 preparing install for spinnaker-blenderfox
[storage] 2018/02/07 09:19:21 getting release history for "spinnaker-blenderfox"
[tiller] 2018/02/07 09:19:21 rendering spinnaker chart using values
2018/02/07 09:19:25 info: manifest "spinnaker/charts/minio/templates/post-install-create-bucket-pod.yaml" is empty. Skipping.
2018/02/07 09:19:25 info: manifest "spinnaker/templates/secrets/gcs.yaml" is empty. Skipping.
2018/02/07 09:19:25 info: manifest "spinnaker/templates/ingress/deck.yaml" is empty. Skipping.
2018/02/07 09:19:25 info: manifest "spinnaker/charts/jenkins/templates/rbac.yaml" is empty. Skipping.
2018/02/07 09:19:25 info: manifest "spinnaker/charts/minio/templates/minio_networkpolicy.yaml" is empty. Skipping.
2018/02/07 09:19:25 info: manifest "spinnaker/charts/jenkins/templates/config.yaml" is empty. Skipping.
2018/02/07 09:19:26 info: manifest "spinnaker/charts/redis/templates/networkpolicy.yaml" is empty. Skipping.
2018/02/07 09:19:26 info: manifest "spinnaker/charts/minio/templates/minio_statefulset.yaml" is empty. Skipping.
2018/02/07 09:19:26 info: manifest "spinnaker/charts/jenkins/templates/jenkins-master-ingress.yaml" is empty. Skipping.
2018/02/07 09:19:26 info: manifest "spinnaker/charts/jenkins/templates/service-account.yaml" is empty. Skipping.
2018/02/07 09:19:26 info: manifest "spinnaker/charts/jenkins/templates/jenkins-master-networkpolicy.yaml" is empty. Skipping.
[tiller] 2018/02/07 09:19:31 performing install for spinnaker-blenderfox
[tiller] 2018/02/07 09:19:31 executing 7 pre-install hooks for spinnaker-blenderfox
[tiller] 2018/02/07 09:19:31 hooks complete for pre-install spinnaker-blenderfox
[storage] 2018/02/07 09:19:31 getting release history for "spinnaker-blenderfox"
[storage] 2018/02/07 09:19:31 creating release "spinnaker-blenderfox.v1"
[kube] 2018/02/07 09:19:35 building resources from manifest
[kube] 2018/02/07 09:19:39 creating 37 resource(s)
[kube] 2018/02/07 09:19:44 beginning wait for 37 resources with timeout of 5m0s
[kube] 2018/02/07 09:20:06 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:20:35 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:21:06 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:21:21 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:21:40 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:22:01 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:22:31 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver
[kube] 2018/02/07 09:22:54 Deployment is not ready: spinnaker/spinnaker-blenderfox-spi-clouddriver

>>Container crashed out here, pod restarted<<

[main] 2018/02/07 09:23:08 Starting Tiller v2.8.0 (tls=false)
[main] 2018/02/07 09:23:08 GRPC listening on :44134
[main] 2018/02/07 09:23:08 Probes listening on :44135
[main] 2018/02/07 09:23:08 Storage driver is ConfigMap
[main] 2018/02/07 09:23:08 Max history per release is 0

Журналы пода

  Normal   Killing                6m                kubelet, ip-10-10-20-112.eu-west-2.compute.internal  Killing container with id docker://tiller:Container failed liveness probe.. Container will be killed and recreated.

Итак, я воспроизвел это без использования хуков, против minikube и с минимальной диаграммой: https://gist.github.com/benlangfeld/005f5d934c074d67a34fe9f881c84e89

Хотя это конкретное развертывание, конечно, никогда не будет успешным (из-за невозможности проверки работоспособности), я бы не ожидал, что он истечет через 210 секунд, как это происходит, а продолжится до тех пор, пока тайм-аут в 300 секунд, указанный в журнале Tiller, как первичный разногласия в этом билете.

Такая же проблема с 2.8.0 . Статус развертывания Helm - DEPLOYED , но клиент Helm завершает работу с ошибкой Error: Transport is closing . Это началось после того, как я обновил Tiller & Helm с 2.6.0 до 2.8.0 . Есть идеи, как решить эту проблему? Довольно раздражает, особенно в среде CI.

Это результат работы Tiller при возникновении ошибки:

[kube] 2018/02/07 20:04:33 Watching for changes to Job staging-stored-value-migration-job with timeout of 10m0s
[kube] 2018/02/07 20:04:34 Add/Modify event for staging-stored-value-migration-job: ADDED
[kube] 2018/02/07 20:04:34 staging-stored-value-migration-job: Jobs active: 1, jobs failed: 0, jobs succeeded: 0 

Мое воспроизведение имеет ожидаемое поведение на версии 2.7.2 (как клиент, так и Tiller), тайм-аут составляет 300 секунд. То же самое верно для клиента v2.7.2 против сервера Tiller v2.8.0. Итак, ошибка находится в клиентском коде где-то здесь: https://github.com/kubernetes/helm/compare/v2.7.2...v2.8.0 . Я посмотрю, смогу ли я завтра разделить это пополам, чтобы определить фиксацию проблемы. Самая подозрительная фиксация, конечно, https://github.com/kubernetes/helm/commit/838d7808946b554865e0fc897e7db8e8dfd63bde.

Я понизил рейтинг до 2.6.0 . Больше нет проблемы. У меня установлен тайм-аут 10 минут. Tiller соблюдает тайм-аут, а клиент Helm - нет.

@cmdshepard Tiller соблюдал таймаут даже на 2.8, Helm - нет.

@ huang-jy Да. Я могу подтвердить это поведение на 2.8.0 .

Результаты деления пополам:

803f7c706ef4ce44aa6418c42c77dbf7e60ac66d is the first bad commit
commit 803f7c706ef4ce44aa6418c42c77dbf7e60ac66d
Author: Helgi Þormar Þorbjörnsson <[email protected]>
Date:   Wed Nov 22 08:30:25 2017 -0800

    add a keepalive of 30s to the client (#3183)

:040000 040000 3b1218a94f23f51ccbbf253676e1457f0c42d663 3d207d79bad28de7dc17f922e44d5faa1e31cf45 M  pkg

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

Я подозреваю, что у нас есть несовместимость в конфигурации между штурвалом и румпелем; соответствующие документы находятся по адресу https://godoc.org/google.golang.org/grpc/keepalive.

Это исправлено для меня https://github.com/kubernetes/helm/pull/3482. Если вы хотите попробовать это, сделайте helm init --force-upgrade --tiller-image powerhome/tiller:git-3b22ecd . Буду признателен за отзывы, особенно от @ huang- jy , @cmdshepard

Awesom, @benlangfeld спасибо за это, завтра проверю, когда я буду в офисе

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

Давайте оставим это открытым, пока изменения не будут объединены.

@benlangfeld Я тоже могу подтвердить. Клиент Helm успешно дождался завершения обработки после установки. Спасибо за ваш вклад!

это все еще происходит в румпеле 2.9.2

Также: это происходит сразу после того, как рулевой говорит: «Релиз« xxx »был обновлен. Удачи, Helming!». Это происходит без флага --wait (с флагом ожидания все в порядке) и задолго до тайм-аута (таймаут 300 секунд, сбой после 100 секунд).

@sheerun пробовали с версией выше?

Еще новости: tiller также вылетает с флагом --wait . Причина, по-видимому, в слишком большом количестве исправлений, потому что он вылетает после следующих журналов. Кроме того, пока я могу попробовать только v2.5.1, потому что я использую старые kubernetes, а tillers автоматически понижает свою версию.

[main] 2018/05/15 21:49:53 Starting Tiller v2.5.1 (tls=false)
[main] 2018/05/15 21:49:53 GRPC listening on :44134
[main] 2018/05/15 21:49:53 Probes listening on :44135
[main] 2018/05/15 21:49:53 Storage driver is ConfigMap
[tiller] 2018/05/15 21:50:37 getting history for release xxx
[storage] 2018/05/15 21:50:37 getting release history for "xxx"
[tiller] 2018/05/15 21:50:53 preparing update for xxx
[storage] 2018/05/15 21:50:53 getting last revision of "xxx"
[storage] 2018/05/15 21:50:53 getting release history for "xxx"

Я не нашел решения для этого. Мне нужно было перейти на новый кластер.

это все еще происходит в румпеле 2.9.2

2.9.2 не существует ... вы имели в виду 2.8.2 или 2.9.1? Это должно быть исправлено в 2.8.2, как указывает @ huang-jy. :)

Да, 2.9.1, но оказалось, что tiller в Azure автоматически понизился до 2.5.1, поэтому я не знаю, осталась ли проблема в 2.9.1. Скорее всего, ошибка возникла из-за слишком большого количества изменений (более 600).

Я также видел ошибку Error: transport is closing когда я запускал helm install , и после выполнения rm -rf ~/.helm ошибка больше не появлялась. Предположительно, удаление кэша руля ( rm -rf ~/.helm ) может устранить ошибку.

@vhosakot Я считаю, что стирает состояние руля

Это просто стирает ваш местный штат, но не состояние румпеля. Не уверен, как это решает проблему, но если это сработает, отлично

/ пожимать плечами

В нашем случае мы заметили, что это происходит, когда запущенный tiller контейнера уходит во время установки выпуска из-за обновления Docker Engine. Поиск контейнеров tiller (например, docker ps -a | grep tiller ), проверка журналов контейнера, который вышел, и сопоставление временных меток с событиями в /var/log/syslog помогли нам разобраться в нашей проблеме. YMMV ¯\_(ツ)_/¯

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

Я все еще сталкиваюсь с этой проблемой. Мой env находится на k8s, helm client: 2.8.2, helm server: 2.9.1.
Я получаю сообщение об ошибке всякий раз, когда у меня есть работа в моем графике, настроенная как обработчик после установки, и я пытаюсь «обновить - установить» или «удалить» выпуск диаграммы после ровно 1 минуты ожидания клиента Helm завершения установки / удаления. .
Если я не настрою задание как обработчик после установки, проблема исчезнет.

@ uxon123 У меня это было изначально - оказалось, что

дополнительный румпельный узел? вы имеете в виду дополнительную гондолу для развертывания мотоблока или что?

Нет, дополнительный узел Kubernetes.

Хм, не знаю, полностью ли я это понимаю. Вы говорите, что причина вашей проблемы (идентичной той, с которой я сталкиваюсь) заключалась в нехватке ресурсов на k8s?
В этом случае выполнение задания не из пост-установки, на мой взгляд, не должно решить проблему (для этого требуется такое же количество ресурсов, верно?). Tiller отвечает, если я тем временем попытаюсь установить или удалить некоторые другие выпуски.
Проблема возникает только тогда, когда я использую задание после установки, поэтому, когда я заставляю ждать ответа. Я получаю сообщение об ошибке каждый раз примерно через 1 минуту ожидания (но румпель продолжает выполнять свою работу в кластере).

Вы можете проверить это, выполнив watch kubectl get pods и следя за tiller pod во время установки Helm.

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

Хорошо, я сделал то, что ты сказал. Я посмотрел на румпель и выполнил upgrade --install. Стручок румпеля не исчез и не разбился. Я также проверил набор реплик румпеля с помощью команды описать, и ни один контейнер не был поврежден и т.д. Так что я думаю, что могу устранить проблему с румпелем. Спасибо за ваш вклад :)

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

Я проверил еще раз, и в моем случае проблем с румпелем нет (логи чистые, пода не перезагружается и т. Д.).
Кажется, что тайм-аут в 1 минуту не такой уж и большой по совпадению. Я обнаружил, что все подключения к моему кластеру k8s маршрутизируются балансировщиком нагрузки, для которого настроено время ожидания 60 секунд. Таким образом, соединения прерываются балансировщиком нагрузки после 60 секунд бездействия.
Таким образом, похоже, что между клиентом tiller и сервером нет сообщений keepalive. Разве клиент tiller не должен отправлять сообщения поддержки активности каждые 30 секунд? (https://github.com/helm/helm/pull/3183)

Вы работаете на AWS? Затем вы должны проверить тайм-аут соединения вашего api loadbalancer. Если я правильно помню, по умолчанию всего 60 секунд.

Добавьте флаг --tls в команду установки helm.

@makandas --tls относится к связи между штурвалом и румпелем, IIRC.

Если бы эта ошибка возникла без установки чего-либо, я бы согласился, что переключатель будет вариантом. Но это не так. Здесь Helm может поговорить с Tiller, инициировать установку, но соединение каким-то образом прерывается слишком рано. Этот тикет уже закрыт решением и был проверен несколькими пользователями.

Я еще не столкнулся с этой проблемой. Событие на последней доступной версии 2.12.3.

Я вижу, что румпель просто вылетает с журналом ошибок

[tiller] 2019/01/23 16:25:50 preparing install for my-release
[storage] 2019/01/23 16:25:50 getting release history for "my-release"
[tiller] 2019/01/23 16:25:50 rendering my-release chart using values
panic: should not happen [recovered]
    panic: should not happen

goroutine 29 [running]:
k8s.io/helm/vendor/gopkg.in/yaml%2ev2.handleErr(0xc00078af78)
    /go/src/k8s.io/helm/vendor/gopkg.in/yaml.v2/yaml.go:164 +0x9a
....

Я использую GCP (версия GKE: 1.11.5-gke.5)

@alanwds и здесь.

@alanwds из усеченной трассировки стека паники, я могу только видеть, что он исходит от парсера yaml. Каков результат helm template на этой диаграмме? У вас есть где-нибудь полный вывод этой трассировки стека?

Тот же вопрос к тебе, @AndrewDryga :)

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

Name:               tiller-deploy-58b6bf5687-2498x
Namespace:          kube-system
Priority:           0
PriorityClassName:  <none>
Node:               gke-staging-default-pool-4c48bc57-n6kx/10.142.0.7
Start Time:         Mon, 11 Feb 2019 22:01:37 +0200
Labels:             app=helm
                    name=tiller
                    pod-template-hash=1462691243
Annotations:        cni.projectcalico.org/podIP: 10.16.0.51/32
Status:             Running
IP:                 10.16.0.51
Controlled By:      ReplicaSet/tiller-deploy-58b6bf5687
Containers:
  tiller:
    Container ID:   docker://c5d2f01465da5f3b309fcc8b2b39c21015de204d125a944ba79333c514649901
    Image:          gcr.io/kubernetes-helm/tiller:v2.12.3
    Image ID:       docker-pullable://gcr.io/kubernetes-helm/tiller<strong i="7">@sha256</strong>:cab750b402d24dd7b24756858c31eae6a007cd0ee91ea802b3891e2e940d214d
    Ports:          44134/TCP, 44135/TCP
    Host Ports:     0/TCP, 0/TCP
    State:          Running
      Started:      Tue, 12 Feb 2019 20:08:52 +0200
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Tue, 12 Feb 2019 20:05:28 +0200
      Finished:     Tue, 12 Feb 2019 20:05:54 +0200
    Ready:          False
    Restart Count:  18
    Liveness:       http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
    Readiness:      http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
    Environment:
      TILLER_NAMESPACE:    kube-system
      TILLER_HISTORY_MAX:  0
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from tiller-token-r74zd (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  tiller-token-r74zd:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  tiller-token-r74zd
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                   From                                             Message
  ----     ------     ----                  ----                                             -------
  Warning  Unhealthy  10m (x15 over 20h)    kubelet, gke-staging-default-pool-4c48bc57-n6kx  Liveness probe failed: Get http://10.16.0.51:44135/liveness: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  10m (x28 over 12h)    kubelet, gke-staging-default-pool-4c48bc57-n6kx  Readiness probe failed: Get http://10.16.0.51:44135/readiness: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Normal   Killing    6m51s (x14 over 22h)  kubelet, gke-staging-default-pool-4c48bc57-n6kx  Killing container with id docker://tiller:Container failed liveness probe.. Container will be killed and recreated.
  Warning  BackOff    2m4s (x104 over 22h)  kubelet, gke-staging-default-pool-4c48bc57-n6kx  Back-off restarting failed container

logs -p возвращает пустой результат :(.

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

Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

helm зависает с командой --wait

@JPWKU , не могли бы вы предоставить некоторую информацию о том, сколько ресурсов для развертывания tilelr? Спасибо