Helm: `helm delete` meldet "Verbindung zum Pod verloren" "Fehler: Transport wird geschlossen" trotz scheinbarem Erfolg

Erstellt am 28. Sept. 2017  ·  3Kommentare  ·  Quelle: helm/helm

helm 2.6.1 Client und Server
k8s 1.7.4 (gleiches Verhalten mit 1.7.0 auch)

Ich habe mehrere Probleme gesehen, in denen es um "Verbindung zum Pod verloren" ging, aber keine, die ich als passend zu unserem Fall erkenne.

Wenn ich helm delete --purge _releaseName_ Helmberichte ausführe

portforward.go:178] lost connection to pod
Error: transport is closing

Doch das delete scheint gelungen zu sein. Alle im Diagramm definierten k8s-Ressourcen werden wie erwartet bereinigt. Das Pinnenprotokoll sieht so aus:

[storage] 2017/09/28 14:14:19 getting release history for "xxx"
[tiller] 2017/09/28 14:14:19 uninstall: Deleting xxx
[tiller] 2017/09/28 14:14:19 executing 0 pre-delete hooks for xxx
[tiller] 2017/09/28 14:14:19 hooks complete for pre-delete xxx
[storage] 2017/09/28 14:14:19 updating release "xxx.v1"
 (many lines of "Starting delete for yyy" and "Using reaper for deleting yyy" omitted here)
[tiller] 2017/09/28 14:16:42 executing 0 post-delete hooks for xxx
[tiller] 2017/09/28 14:16:42 hooks complete for post-delete xxx
[tiller] 2017/09/28 14:16:42 purge requested for xxx
[storage] 2017/09/28 14:16:42 deleting release "xxx.v1"

Das ist das Ende des Protokolls. Es enthält keine Fehler oder Ausnahmen.

k8s meldet keine Neustarts der Pinne.

Die verstrichene Zeit, sowohl von außen als auch aus dem Protokoll, beträgt ca. 2m 30s, deutlich unter dem Standard-Timeout-Wert für die Operation delete .

Wo sonst kann ich nach weiteren Informationen suchen, was schief läuft, das diesen Fehler verursacht?

Vielen Dank.

questiosupport

Hilfreichster Kommentar

Ich konnte dies korrigieren, indem ich die Informationen zum Pinnen-Host zum Befehl helm install hinzufügte.
--host=10.111.221.14:443

Sie können Ihre Pinnen-IP über diese Methode erhalten
$ kubectl get svc -n kube-system tiller-deploy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34h

Vollständiges Befehlsbeispiel
helm install stable/grafana --name=grafana --host=10.111.221.14:4413

Ich weiß, dass dies ein bisschen umständlich ist, aber alle anderen Funktionen von Helm funktionieren nach der Installation mit dieser Methode ordnungsgemäß. Ich musste die Hostinformationen nach der Erstinstallation nicht erneut hinzufügen, um Upgrades oder Rollbacks durchzuführen. Hoffe das hilft!

Alle 3 Kommentare

Dies sieht wie https://github.com/kubernetes/helm/issues/2025 aus, wenn es deutlich unter dem Standard-Timeout (5 Minuten) liegt. Können Sie den Load Balancer überprüfen, der Ihrer Kubernetes-Master-API vorgeschaltet ist, und sich zu diesem Problem in der Zukunft äußern? Auf diese Weise können wir die Diskussion an einem Ort halten. Danke! ️

Ich habe auch den Fehler Error: transport is closing , als ich helm install , und nachdem ich rm -rf ~/.helm , wurde der Fehler nicht mehr angezeigt. Vermutlich kann das Löschen des Helm-Cache ( rm -rf ~/.helm ) den Fehler beheben.

Ich konnte dies korrigieren, indem ich die Informationen zum Pinnen-Host zum Befehl helm install hinzufügte.
--host=10.111.221.14:443

Sie können Ihre Pinnen-IP über diese Methode erhalten
$ kubectl get svc -n kube-system tiller-deploy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34h

Vollständiges Befehlsbeispiel
helm install stable/grafana --name=grafana --host=10.111.221.14:4413

Ich weiß, dass dies ein bisschen umständlich ist, aber alle anderen Funktionen von Helm funktionieren nach der Installation mit dieser Methode ordnungsgemäß. Ich musste die Hostinformationen nach der Erstinstallation nicht erneut hinzufügen, um Upgrades oder Rollbacks durchzuführen. Hoffe das hilft!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen