helm 🚀 - tulis: pipa rusak

Masalah yang sama dengan klien Linux 64bit

matus-vacula pada 9 Feb 2018

Saya menghadapi masalah yang sama. Ada solusi yang disarankan? Ini sangat mengganggu.

eldada pada 12 Mar 2018

Melihat hal yang sama; tidak ada masalah yang jelas ditemukan di log anakan terkait dengan bagan yang saya terapkan.

Klien: & version.Version {SemVer: "v2.8.2", GitCommit: "a80231648a1473929271764b920a8e346f6de844", GitTreeState: "clean"}
Server: & version.Version {SemVer: "v2.8.2", GitCommit: "a80231648a1473929271764b920a8e346f6de844", GitTreeState: "clean"}

Server adalah (ubuntu 16.04) linux, klien adalah (10.13.3) macOS

Hal ini biasanya terjadi setelah berhasil menerapkan bagan yang dimaksud, tetapi ini menyebabkan kami banyak pusing karena kesalahan helm keluar (dan kami bergantung pada pemasangan helm yang berhasil sebelum kami melakukan hal-hal lain).

Kami memiliki enam contoh bagan yang sama yang diterapkan secara berurutan, dan yang pertama mungkin gagal, atau yang kedua, atau yang kelima. Saya tidak dapat menemukan pola mengapa.

oivindoh pada 15 Mar 2018

@albrechtsimon @eldada @ matus-vacula apakah kalian menjalankan musik metal atau cloud publik?

oivindoh pada 16 Mar 2018

@oivindoh Saya menjalankan k8s di AWS. Biasanya baik-baik saja hingga 2.7.2.

albrechtsimon pada 16 Mar 2018

👍1

Saya menggunakan gke. Helm 2.8.1.

eldada pada 16 Mar 2018

Di reddit, kami melihat ini terjadi sesekali dan membuat pengalaman yang sangat buruk. Kami menggunakan helm bersama dengan helmfile dan tampaknya ketika kami "menyinkronkan" (cukup banyak menjalankan banyak pembaruan helm) terkadang kami melihat masalah dengan pipa yang rusak

foklepoint pada 24 Mar 2018

Jadi kesalahan ini mungkin terkait dengan grpc dan mungkin tidak berarti apa pun selain logger yang terlalu verbose: https://github.com/grpc/grpc-go/issues/1362

Helm mungkin harus memperbarui ke rilis terbaru dari grpc untuk memperbaikinya

foklepoint pada 24 Mar 2018

Masalah yang sama menjalankan helm diff plugin. Ketika saya menjalankan beberapa perintah helm-diff secara berurutan, saya selalu mendapat kesalahan 38012 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:53526->127.0.0.1:53530: write tcp4 127.0.0.1:53526->127.0.0.1:53530: write: broken pipe . Menjalankan satu per satu selalu berhasil

gianrubio pada 17 Apr 2018

Masih melihat ini di 2.9.0 vs semua kluster yang telah saya terapkan di Azure melalui mesin acs.

E0427 10: 11: 49.952856 28158 portforward.go: 303] kesalahan menyalin dari aliran jarak jauh ke koneksi lokal: readfrom tcp4 127.0.0.1:36679->127.0.0.1:51582: tulis tcp4 127.0.0.1:36679->127.0.0.1: 51582: tulis: pipa rusak
/helm/2.9.0/x64/helm gagal dengan kode pengembalian: 0

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-18T23:58:35Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

$ helm version
Client: &version.Version{SemVer:"v2.9.0", GitCommit:"f6025bb9ee7daf9fee0026541c90a6f557a3e0bc", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.0", GitCommit:"f6025bb9ee7daf9fee0026541c90a6f557a3e0bc", GitTreeState:"clean"}

Edit: Sama di 2.9.1

oivindoh pada 27 Apr 2018

Memiliki masalah yang sama persis dengan helm-diff & helm 2.9.0

lostick pada 2 Mei 2018

E0510 16:06:06.478944 19746 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:38750->127.0.0.1:41234: write tcp4 127.0.0.1:38750->127.0.0.1:41234: write: broken pipe

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:55:54Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
$ helm version
Client: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}

IvanBiv pada 10 Mei 2018

E0515 11: 25: 06.883101 170075 portforward.go: 303] kesalahan menyalin dari aliran jarak jauh ke koneksi lokal: baca dari tcp4 * tulis tcp4 127.0.0.1:38769->127.0.0.1:36224: tulis: pipa rusak

versi $ kubectl
Versi Klien: version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.7", GitCommit: "dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState: "clean", BuildDate: "2018-04-19T00: 05: 56Z ", GoVersion:" go1.9.3 ", Penyusun:" gc ", Platform:" linux / amd64 "}
Versi Server: version.Info {Mayor: "1", Minor: "9", GitVersion: "v1.9.7", GitCommit: "dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState: "clean", BuildDate: "2018-04-18T23: 58: 35Z ", GoVersion:" go1.9.3 ", Penyusun:" gc ", Platform:" linux / amd64 "}

versi $ helm
Klien: & version.Version {SemVer: "v2.9.1", GitCommit: "20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState: "clean"}
Server: & version.Version {SemVer: "v2.9.1", GitCommit: "20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState: "clean"}

yunghoy pada 15 Mei 2018

+1

benkeil pada 15 Mei 2018

Baru saja berurusan dengan masalah serupa dan melakukan helm init --upgrade --history-max=0 sepertinya sudah memperbaikinya untuk saya.

kesalahan:

E0531 14:54:27.094118   97288 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:53496->127.0.0.1:53498: write tcp4 127.0.0.1:53496->127.0.0.1:53498: write: broken pipe
Error: UPGRADE FAILED: "dev" has no deployed releases

kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:21:50Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

helm version
Client: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}

ssalaues pada 1 Jun 2018

👍8

@ssalaues Saya pikir itu hanya memperbaiki masalah "Kesalahan: UPGRADE GAGAL:" dev "tidak memiliki rilis yang diterapkan" (Saya menduga Anda hanya memiliki rilis "dev" yang gagal sebelumnya), bukan pesan portforward, yang tampaknya sangat terputus-putus.

oivindoh pada 1 Jun 2018

@oivindoh Hal yang aneh adalah bahwa saya mendapatkan kesalahan portforward yang sama terlepas dari apakah saya sedang melakukan pemasangan helm baru dari penerapan baru dengan nama rilis baru atau mencoba untuk mengemudikan pembaruan (itulah yang membawa saya ke utas ini karena menghentikan kerja). Dalam kasus tertentu yang saya tempel di pesan saya sebelumnya, itu saat menguji upaya peningkatan helm (Anda benar memiliki masalah dengan rilis sebelumnya) tetapi terus mendapatkan kesalahan portforward ketika mencoba melakukan banyak perintah terkait helm lainnya sepenuhnya keluaran terbaru.

Masalah komunikasi yang aneh dan berharap itu diselesaikan dengan cara apa pun

ssalaues pada 1 Jun 2018

Saya telah melihat kesalahan ini hanya menjalankan helm list

a1dutch pada 6 Jun 2018

Melihat ini setelah meningkatkan dari 2.7.2 ke 2.9.1:

14:50:28 helm upgrade --install ...
14:50:28 E0606 21:50:28.120334     271 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44899->127.0.0.1:34138: write tcp4 127.0.0.1:44899->127.0.0.1:34138: write: broken pipe

dalam cluster 1.8.4. Tampaknya tidak memengaruhi penerapan, setidaknya kali ini, tetapi saya lebih suka tidak melihat kesalahan di log penerapan jika tidak relevan dengan penerapan.

diversario pada 6 Jun 2018

Masih melihat ini secara teratur pada k8s 1.10.4 + helm 1.9.1

oivindoh pada 11 Jun 2018

Ditemukan di K8S v1.10.0 dan helm v2.7.3

E0619 03:23:34.043302   22164 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:45405->127.0.0.1:47392: write tcp4 127.0.0.1:45405->127.0.0.1:47392: write: broken pipe
LAST DEPLOYED: Tue Jun 19 03:23:30 2018

dove-young pada 19 Jun 2018

Ya - masih di sini:

helm install helm/kube-prometheus --name kube-prometheus --namespace monitoring --tls
NAME:   kube-prometheus
E0709 18:06:25.276408    4526 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:56929->127.0.0.1:56931: write tcp4 127.0.0.1:56929->127.0.0.1:56931: write: broken pipe
LAST DEPLOYED: Mon Jul  9 18:06:21 2018
NAMESPACE: monitoring
STATUS: DEPLOYED

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"}

 kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-28T20:03:09Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-28T20:13:43Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

helm list --tls
NAME                REVISION    UPDATED                     STATUS      CHART                       NAMESPACE 
kube-prometheus     1           Mon Jul  9 18:06:21 2018    DEPLOYED    kube-prometheus-0.0.78      monitoring
prometheus-operator 1           Mon Jul  9 17:54:02 2018    DEPLOYED    prometheus-operator-0.0.25  monitoring

Xtigyro pada 9 Jul 2018

write: broken pipe tampak seperti kesalahan jaringan, di mana koneksi terowongan antara helm, kube-proxy dan tiller terputus. Agak sulit untuk menentukan di mana (atau apa) yang menginterupsi koneksi dari kesalahan, yang berasal dari API port-forward kubectl.

Bagi siapa pun yang mengalami masalah ini, dapatkah mereka mencoba langkah-langkah berikut untuk menyiapkan terowongan secara manual dan melihat apakah mereka masih melihat kesalahannya? Beginilah cara Helm memulai koneksi ke anakan.

$ TILLER_POD=$(kubectl get pods -n kube-system | grep tiller | awk '{ print $1 }')
$ kubectl -n kube-system port-forward $TILLER_POD 44134:44134
$ export HELM_HOST=:44134
$ helm list # or whatever command you were using when hitting this bug

Terima kasih!

bacongobbler pada 14 Agu 2018

@bacongobbler Tidak bekerja untuk saya

rkleine pada 6 Sep 2018

Maukah Anda menjelaskan sedikit lebih detail? Apa yang tidak berhasil untuk Anda dan mengapa? Apakah Anda memiliki log? Itu akan sangat membantu.

bacongobbler pada 6 Sep 2018

👍1

Kami mengalami ini pada sekitar setengah dari penerapan kami dan sayangnya membuat sistem CD berpikir bahwa penerapan gagal.

2018-09-20T10:54:29.4029987Z E0920 10:54:26.165265   25441 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:34899->127.0.0.1:42674: write tcp4 127.0.0.1:34899->127.0.0.1:42674: write: broken pipe
2018-09-20T10:54:29.4182951Z ##[error]E0920 10:54:26.165265   25441 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:34899->127.0.0.1:42674: write tcp4 127.0.0.1:34899->127.0.0.1:42674: write: broken pipe

Diuji menggunakan Helm 2.10 ,, 2.8.2 di linux dan windows.
Menggunakan TLS dan Azure's Kubernetes 1.11.2

Itu terjadi sangat teratur dan sangat merepotkan kita.

Vhab pada 20 Sep 2018

👍8

masalah yang sama seperti @Vhab;

menggunakan helm / anakan 2.11.0 dengan TLS dan AKS 1.11.2.

helm client dijalankan melalui image buruh pelabuhan vsts-agent yang berjalan di AKS; bagian dari beberapa pipeline CD azure devops. Saya juga menerima kesalahan saat menjalankan klien helm secara lokal di peregangan Debian.

Saya hanya mengalami kesalahan dengan peningkatan helm dan / atau perintah instal dan biasanya setelah laporan pasca penerapan

E1004 08:10:19.411418   14567 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:35543->127.0.0.1:41728: write tcp4 127.0.0.1:35543->127.0.0.1:41728: write: broken pipe

jadilah baik jika ada perbaikan sehingga pipa CD saya berhenti memperingatkan kegagalan ketika penerapan helm yang sebenarnya berfungsi dengan baik dll 😄

edit: mencoba saran @bacongobbler untuk mengatur koneksi secara manual dan kesalahan berikut kadang-kadang terjadi menggunakan kubectl port-forward untuk beberapa perintah. kubectl port-forward untuk kegunaan lain selain helm berfungsi dengan baik di cluster saya.

E1004 10:30:03.107023      35 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:38992: write tcp4 127.0.0.1:44134->127.0.0.1:38992: write: broken pipe

garethmorris78 pada 4 Okt 2018

👍4

masalah yang sama saat menjalankan tugas dari VSTS, yang diterapkan ke AKS dengan warna biru:

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Kubernetes: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

E1002 11:57:35.278788 207 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:38037->127.0.0.1:40594: write tcp4 127.0.0.1:38037->127.0.0.1:40594: write: broken pipe

agak menakutkan masalah itu menggantung sejak Februari ...

ghmulti pada 4 Okt 2018

🚀2

Sama di sini, kami mendapatkan kesalahan ini sekitar 50% dari waktu saat menerapkan ke AKS dari VSTS

rigerosa pada 4 Okt 2018

Saya yakin orang-orang AKS mengetahui bug ini dan telah mengalaminya sendiri. Tampaknya menjadi masalah hulu, belum tentu masalah helm. Saya akan melihat apakah saya dapat melakukan ping ke salah satu dari mereka dan melihat apakah mereka dapat memberikan pembaruan apa pun tentang tiket ini.

bacongobbler pada 4 Okt 2018

👍6

Kami juga sering melihat ini pada cluster non-AKS.

booninite pada 11 Okt 2018

Saya mengalami masalah yang sama dengan salah satu anakan kami (total 3) di klaster kubernetes setelah meningkatkan dari 2.9.1 ke 2.11.0. Semua anakan ditingkatkan dan hanya satu yang mengalami masalah ini.

Setelah menghapus pod yang bermasalah, tiller-deploy-xxxxxxx-yyyy yang sedang dibuat ulang oleh deployment tiller-deploy, Semua perintah helm akan cepat kembali. Satu-satunya yang tersisa adalah kesalahan muncul 1 dari 5 kali. (Ini adalah 5 node cluster, jadi ini mungkin berkorelasi.)

jzandbergen pada 19 Okt 2018

@bacongobbler ada pembaruan tentang ini? Sekali lagi Azure DevOps / VSTS host agent dan AKS. Terima kasih.

marrobi pada 29 Okt 2018

👍2

Masalahnya sekarang telah teratasi (untuk saat ini) di pihak saya setelah meningkatkan ke kubernetes v1.11.2. Selama proses ini saya juga telah me-reboot 2 dari 3 node etcd / control-plane saya. Jadi saya tidak yakin apakah itu pembaruan atau reboot.

edit: Juga selama proses upgrade runtime buruh pelabuhan saya di-restart pada setiap node di cluster.

jzandbergen pada 30 Okt 2018

@marrobi tidak ada pembaruan untuk dibagikan saat ini, maaf.

bacongobbler pada 30 Okt 2018

😕3

masih melihat ini terjadi dalam penerapan kami, dan menyebabkan beberapa masalah dengan alat yang kami tulis untuk Helm.

Informasi versi jika itu membantu sama sekali:

ubuntu<strong i="7">@kubenode01</strong>:/opt/flagship$ helm version
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
ubuntu<strong i="8">@kubenode01</strong>:/opt/flagship$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
ubuntu<strong i="9">@kubenode01</strong>:/opt/flagship$

Keluaran alat kami, tetapi ini benar-benar hanya memuntahkan informasi yang dikembalikan ke Helm:

ubuntu<strong i="13">@kubenode01</strong>:/opt/flagship$ barrelman apply --diff barrelman-testing.yaml
INFO[0000] Using config                                  file=/home/ubuntu/.barrelman/config
NewSession Context:
INFO[0000] Connected to Tiller                           Host=":44160" clientServerCompatible=true tillerVersion=v2.11.0
INFO[0000] Using kube config                             file=/home/ubuntu/.kube/config
INFO[0000] syncronizing with remote chart repositories
Enumerating objects: 25, done.
Counting objects: 100% (25/25), done.
Compressing objects: 100% (24/24), done.
Total 30 (delta 7), reused 6 (delta 1), pack-reused 5
E1201 18:12:09.572396   16908 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44160->127.0.0.1:60512: read: connection reset by peer
E1201 18:12:10.122456   16908 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44160->127.0.0.1:60532: write tcp4 127.0.0.1:44160->127.0.0.1:60532: write: broken pipe
E1201 18:12:10.379437   16908 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44160->127.0.0.1:60546: write tcp4 127.0.0.1:44160->127.0.0.1:60546: write: broken pipe
E1201 18:12:11.184402   16908 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44160->127.0.0.1:60556: write tcp4 127.0.0.1:44160->127.0.0.1:60556: write: broken pipe
ERRO[0003] Failed to get results from Tiller             cause="rpc error: code = Unknown desc = \"kube-proxy\" has no deployed releases"
ubuntu<strong i="14">@kubenode01</strong>:/opt/flagship$

v1k0d3n pada 1 Des 2018

👍1

Masalah yang sama untuk saya, saya mendapatkan kesalahan ini sepanjang waktu (GKE k8s 1.11.5). Helm versi 2.12.0.

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

arthurk pada 17 Des 2018

sama di sini mendapatkan kesalahan saat menjalankan helm install untuk bagan jenkins di EKS

NAME:   jenkins
E1221 11:08:49.491480   92770 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:61585->127.0.0.1:61588: write tcp4 127.0.0.1:61585->127.0.0.1:61588: write: broken pipe

ada pembaruan tentang ini?

imalik-rms pada 21 Des 2018

Ada pembaruan tentang ini?

deepanvermag3 pada 31 Des 2018

Mengalami masalah yang sama di sini :( - tetapi tampaknya hanya terjadi saat berjalan di Docker. Versi helm yang sama yang digunakan di luar, tidak pernah memberi saya masalah ini.

KlavsKlavsen pada 7 Jan 2019

Milik saya tampaknya telah hilang, setelah saya memperbaiki jalur ke .Files.Get .. (helm mana yang tidak mengeluh karena tidak ada) ..

KlavsKlavsen pada 7 Jan 2019

sejak masalah dengan Helm 2.9.1, k8s 1.10.3

itu terjadi ketika saya menjalankan helm upgrade --install ... yang memiliki hook pre-install membutuhkan waktu 4 menit.

missedone pada 14 Jan 2019

Masalah yang sama di sini, menggunakan helm install
EKS Kubernetes versi: 1.11.0
Helm Klien: 2.12.1
Helm Server: 2.12.0

Jeskz0rd pada 14 Jan 2019

👍2

Hanya ingin berpadu bahwa kami memiliki masalah yang sama dalam satu cluster. Itu terjadi lebih sering daripada tidak, dan menempatkan bangunan kami pada tingkat keberhasilan hanya 29% karena ini, yang berarti 71% adalah kegagalan, di mana hampir semuanya adalah positif palsu. Ini selama 7 hari terakhir.

Versi Helm:

Client: &version.Version{SemVer:"v2.12.2", GitCommit:"7d2b0c73d734f6586ed222a567c5d103fed435be", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.2", GitCommit:"7d2b0c73d734f6586ed222a567c5d103fed435be", GitTreeState:"clean"}

Versi Kubernetes:

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", 
GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"archive", BuildDate:"2018-12-08T11:33:56Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", 
GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-11-26T14:31:35Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

TLS diaktifkan dan Tiller ada di namespace kustom, tetapi selain itu saya rasa tidak ada sesuatu yang 'kustom' yang terjadi.

Saya tidak ingat kapan pertama kali muncul tetapi sudah berlangsung untuk beberapa versi helm. Dan tampaknya memengaruhi cluster dengan Helm TLS diaktifkan lebih banyak (70% kasus yang dilemparkannya) daripada cluster tanpa TLS diaktifkan (hanya terjadi sesekali, tetapi tidak memiliki perkiraan yang jelas tentang itu). Mungkinkah itu terkait dengan TLS yang diaktifkan? Kedua kluster dihosting di Azure menggunakan layanan AKS mereka.

simpers pada 20 Jan 2019

Memposting ulang permintaan sebelumnya

$ TILLER_POD=$(kubectl get pods -n kube-system | grep tiller | awk '{ print $1 }')
$ kubectl -n kube-system port-forward $TILLER_POD 44134:44134
$ export HELM_HOST=:44134
$ helm list # or whatever command you were using when hitting this bug

Di belakang layar, Helm menghasilkan kubectl port-forward . Ada kemungkinan bahwa ada sedikit perbedaan antara versi library Kubernetes yang dikompilasi oleh Helm dan versi yang didukung oleh Kubernetes. Tapi kami tidak tahu apa masalahnya. Kami membutuhkan lebih banyak informasi. Jika dapat direproduksi dengan kubectl , itu memberi kita beberapa petunjuk ke mana mencarinya.

technosophos pada 24 Jan 2019

Memposting ulang permintaan sebelumnya
$ TILLER_POD=$(kubectl get pods -n kube-system | grep tiller | awk '{ print $1 }')
$ kubectl -n kube-system port-forward $TILLER_POD 44134:44134
$ export HELM_HOST=:44134
$ helm list # or whatever command you were using when hitting this bug
Di belakang layar, Helm menghasilkan kubectl port-forward . Ada kemungkinan bahwa ada sedikit perbedaan antara versi library Kubernetes yang dikompilasi oleh Helm dan versi yang didukung oleh Kubernetes. Tapi kami tidak tahu apa masalahnya. Kami membutuhkan lebih banyak informasi. Jika dapat direproduksi dengan kubectl , itu memberi kita beberapa petunjuk ke mana mencarinya.

Penggarap kami ada di namespace kustom, jadi saya menjalankan ini:

Tab iTerm 1:

$ TILLER_POD=$(kubectl get pods -n $TILLER_NAMESPACE | grep tiller | awk '{ print $1 }')
$ kubectl -n $TILLER_NAMESPACE port-forward $TILLER_POD 44134:44134

Tab iTerm 2:

$ export HELM_HOST=:44134
$ helm status <a deployent that was listed>
$ helm install .....
$ helm ls
$ helm status <freshly installed>

Di tab iTerm 1 saya mendapatkan yang berikut:

Forwarding from 127.0.0.1:44134 -> 44134
Forwarding from [::1]:44134 -> 44134
Handling connection for 44134
E0124 11:33:00.989027    4143 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:50435: write tcp4 127.0.0.1:44134->127.0.0.1:50435: write: broken pipe
Handling connection for 44134
Handling connection for 44134
E0124 11:33:20.690219    4143 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:50443: write tcp4 127.0.0.1:44134->127.0.0.1:50443: write: broken pipe
Handling connection for 44134
Handling connection for 44134
Handling connection for 44134
E0124 11:35:31.232146    4143 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:50465: write tcp4 127.0.0.1:44134->127.0.0.1:50465: write: broken pipe
Handling connection for 44134
E0124 11:35:40.701135    4143 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:50468: write tcp4 127.0.0.1:44134->127.0.0.1:50468: write: broken pipe

Saya dapat menghitung 4 kesalahan, satu untuk setiap perintah.

simpers pada 24 Jan 2019

Sepertinya saya mendapatkan kesalahan yang sama dari template helm, ketika saya tidak memberikannya -f valuesfile (dan gagal rendering karena itu)

KlavsKlavsen pada 24 Jan 2019

@simpers Apakah saya memahami ini dengan benar: Anda melihat kesalahan yang sama yang berasal dari kubectl yang Anda lihat menjalankan Helm? Itu tidak seperti yang saya harapkan. Apakah hangup segera terjadi? Atau apakah ada penundaan yang lama?

Saya kira kita tidak dapat mengesampingkan bahwa Tiller sedang menutup telepon ... meskipun menurut saya itu akan menghasilkan beberapa entri log di pod Tiller. Dapatkah Anda juga memverifikasi untuk saya bahwa Tiller tidak mogok / dimulai ulang?

Pada titik ini, tampaknya ada dua penyebab berbeda:

Proksi itu sendiri dapat dihentikan di sisi Kubernetes. Ini kemungkinan besar akan meninggalkan jejak pesan log ... mungkin di server API kube? (Saya tidak sepenuhnya yakin)
Tiller mungkin mengalami beberapa kondisi abnormal, yang (menurut saya) akan menghasilkan pesan log Tiller atau pod dimulai ulang.

Terima kasih atas pembaruannya.

technosophos pada 24 Jan 2019

@KlavsKlavsen Itu sangat mengejutkan, karena helm template tidak seharusnya terhubung ke cluster sama sekali. Bisakah Anda memasukkan perintah yang tepat dan pesan kesalahan?

technosophos pada 24 Jan 2019

Selain itu, bagi Anda yang terkena dampak ... apakah Anda menggunakan TLS? Saya tidak memikirkan apakah lapisan gRPC mungkin mengalami masalah terkait TLS.

technosophos pada 24 Jan 2019

👍3

Ya, saya menggunakan TLS, dan sepertinya banyak yang di atas adalah.

marrobi pada 24 Jan 2019

@simpers Apakah saya memahami ini dengan benar: Anda melihat kesalahan yang sama yang berasal dari kubectl yang Anda lihat menjalankan Helm? Itu tidak seperti yang saya harapkan. Apakah hangup segera terjadi? Atau apakah ada penundaan yang lama?
Saya kira kita tidak dapat mengesampingkan bahwa Tiller sedang menutup telepon ... meskipun menurut saya itu akan menghasilkan beberapa entri log di pod Tiller. Dapatkah Anda juga memverifikasi untuk saya bahwa Tiller tidak mogok / dimulai ulang?
Pada titik ini, tampaknya ada dua penyebab berbeda:
Proksi itu sendiri dapat dihentikan di sisi Kubernetes. Ini kemungkinan besar akan meninggalkan jejak pesan log ... mungkin di server API kube? (Saya tidak sepenuhnya yakin)
Tiller mungkin mengalami beberapa kondisi abnormal, yang (menurut saya) akan menghasilkan pesan log Tiller atau pod dimulai ulang.
Terima kasih atas pembaruannya.

Tidak ada hangup sama sekali. Saya akan menjalankannya sekali lagi hanya untuk memastikan kita membicarakan hal yang sama haha.

Jadi, alih-alih mengarahkan port-forwardingnya sendiri ke cluster untuk melakukan thang-nya, sh-line yang Anda berikan memungkinkan saya untuk menggunakan kembali koneksi yang ada, bukan?

➜  ~ TILLER_POD=$(kubectl get pods -n tiller | grep tiller | awk '{ print $1 }')
➜  ~ kubectl -n $TILLER_NAMESPACE port-forward $TILLER_POD 44134:44134
Forwarding from 127.0.0.1:44134 -> 44134
Forwarding from [::1]:44134 -> 44134

Jadi karena saya telah mengaturnya di terminal satu, saya pergi ke tab kedua dari iTerm2 saya dan melakukan hal berikut:

➜  ~ export HELM_HOST=:44134
➜  ~ helm ls
NAME                    REVISION    UPDATED                     STATUS      CHART                   APP VERSION NAMESPACE
<deployments>

Saya jelas tidak ingin memposting seluruh daftar di sini, tetapi intinya adalah tidak ada kesalahan yang muncul di sini. Perintah tidak gagal.

Tapi saya mendapatkan yang berikut kembali di tab 1, meskipun:

➜  ~ TILLER_POD=$(kubectl get pods -n tiller | grep tiller | awk '{ print $1 }')
➜  ~ kubectl -n $TILLER_NAMESPACE port-forward $TILLER_POD 44134:44134
Forwarding from 127.0.0.1:44134 -> 44134
Forwarding from [::1]:44134 -> 44134
Handling connection for 44134
E0124 18:22:16.865652   18795 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44134->127.0.0.1:58549: write tcp4 127.0.0.1:44134->127.0.0.1:58549: write: broken pipe

Ini akan terjadi untuk hampir setiap perintah, dengan hampir berarti lebih dari 90%. Tugas HelmDeploy pipeline DevOps kami ditandai sebagai gagal karena error , saat perintah sebenarnya tidak gagal.

Selain itu, bagi Anda yang terkena dampak ... apakah Anda menggunakan TLS? Saya tidak memikirkan apakah lapisan gRPC mungkin mengalami masalah terkait TLS.

Ya, TLS diaktifkan dan saya perhatikan bahwa tanpanya (kami memiliki dua cluster secara paralel, salah satunya tidak mengaktifkan TLS untuk Helm karena ini adalah cluster pertama yang kami buat dan belum mempelajari tali) helm berfungsi dengan baik dan jarang melakukan hal-hal aneh.

Untuk cluster yang tidak mengaktifkan TLS, hal ini jarang terjadi, tetapi terkadang terjadi, tetapi dengan TLS yang diaktifkan, hal itu terbalik, jarang hal itu tidak terjadi.

simpers pada 24 Jan 2019

Saya membuka PR yang memperbarui kami ke versi gRPC yang lebih baru, yang tampaknya memiliki sekitar selusin perbaikan jaringan dan TLS sejak versi terakhir kami. Saya berharap itu akan memperbaiki masalah ini.

technosophos pada 24 Jan 2019

🎉5 👍3 ❤1

ya untuk tls

KlavsKlavsen pada 24 Jan 2019

dan ulang template helm .. itu yang terlihat seperti di keluaran CI gitlab .. dan itu hilang ketika saya menambahkan -f di depan file nilai yaml .. Saya akan mencoba dan mengembalikannya besok untuk memverifikasi.

KlavsKlavsen pada 24 Jan 2019

@KlavsKlavsen Itu sangat mengejutkan, karena helm template tidak seharusnya terhubung ke cluster sama sekali. Bisakah Anda memasukkan perintah yang tepat dan pesan kesalahan?

Yah .. Saya mencoba melakukan apa yang terakhir saya lakukan .. dan itu tidak mulai menyemburkan kesalahan pipa yang rusak .. jadi itu pasti "sesuatu" yang menyebabkannya .. Setidaknya saya saat ini tidak terganggu olehnya :)

KlavsKlavsen pada 25 Jan 2019

@technosophos adakah kemungkinan ini dapat dirilis sebagai tambalan untuk 2.12?

simpers pada 25 Jan 2019

Saya khawatir ini harus ditangguhkan hingga 2.13 karena memerlukan regenerasi salah satu kelas protobuf (karena perubahan internal gRPC). Akibatnya, protokol biner mungkin tidak kompatibel dengan versi 2.12 sebelumnya. Ini sebenarnya alasan mengapa kami hanya memperbarui gRPC jika diperlukan.

Karena itu, saya akan melihat apakah kami dapat mempercepat proses rilis 2.13 sama sekali. Jika ini memperbaiki masalah besar, ada baiknya keluar dari pintu.

technosophos pada 25 Jan 2019

👍13

Terima kasih, @technosophos , berharap peningkatan gRPC memperbaiki masalah ini.

rtpro pada 1 Feb 2019

@techosophy

Hai, saya juga menghadapi masalah ini di Mac dan menemukan masalah ini setelah beberapa googling. Saya sudah mencoba menggunakan helm client 2.13.0-rc.1, error sudah hilang, tapi klien hang.

Versi GKE: 1.11.6-gke.2
Versi Tiller (diinstal oleh Gitlab): v2.12.2

Output untuk Helm Client v2.12.3:

$ helm version --tiller-namespace gitlab-managed-apps
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Error: cannot connect to Tiller

$ helm ls --tiller-namespace gitlab-managed-apps
Error: transport is closing

$ helm install --name my-release --tiller-namespace gitlab-managed-apps stable/mongodb
E0216 20:08:46.435297   69434 portforward.go:331] an error occurred forwarding 58711 -> 44134: error forwarding port 44134 to pod 3fbbaff7bdeb4606f59f2e48c46544066abc658e2d0156519f7648e975ca8118, uid : exit status 1: 2019/02/16 22:08:46 socat[68417] E write(5, 0x558c5b292c50, 8192): Broken pipe
Error: transport is closing

Output untuk Helm Client v.2.13.0-rc.1

$ ./helm version --tiller-namespace gitlab-managed-apps
Client: &version.Version{SemVer:"v2.13.0-rc.1", GitCommit:"e0e5197f8d9b3fa13626a273ad8b3f49a8aab67e", GitTreeState:"clean"}
(... hangs ...)
^C

$ ./helm ls --tiller-namespace gitlab-managed-apps
(... hangs ...)
^C

./helm install --name my-release --tiller-namespace gitlab-managed-apps stable/mongodb
(... hangs ...)
^C

Jika saya mencoba melakukan trik kubectl port-forward , semuanya sama saja ... Satu-satunya perbedaan, tampaknya, adalah bahwa 2.13.0-rc.1 terus mencoba menyambung kembali dan saya melihat beberapa Handling connection for 44134 , bukan hanya satu di 2.12.3.

Tidak ada log yang relevan di pod anakan setelah semua ini dan tidak ada mulai ulang:

$ kubectl logs tiller-deploy-5d96b489cc-rcjn8 -f -n gitlab-managed-apps
[main] 2019/02/16 20:30:07 Starting Tiller v2.12.2 (tls=true)
[main] 2019/02/16 20:30:07 GRPC listening on :44134
[main] 2019/02/16 20:30:07 Probes listening on :44135
[main] 2019/02/16 20:30:07 Storage driver is ConfigMap
[main] 2019/02/16 20:30:07 Max history per release is 0

DSTOLF pada 16 Feb 2019

Saya juga mencoba membenturkan versi gambar tiller ke 2.13.0-rc.1, tetapi hasilnya sama.

Saya dapat membuka edisi lain, jika Anda mau.

DSTOLF pada 16 Feb 2019

Maaf telah melakukan spamming pada banyak pesan, tetapi tampaknya saat menginstal tiller di kube-system namespace dengan helm init , semuanya berfungsi dengan baik.

DSTOLF pada 17 Feb 2019

'Memperbaiki' ini dengan menghapus --wait dari perintah penerapan saya

alexdrans pada 21 Feb 2019

Ditingkatkan ke 2.13.0 dan masalah ini masih terjadi, @technosophos.

Kubectl v1.13.4
Helm 2.13.0
AKS 1.11.3
Menggunakan TLS

Menggunakan agen yang dihosting Azure Devops

2019-03-01T06:39:43.4897111Z [command]C:\hostedtoolcache\windows\helm\2.13.0\x64\windows-amd64\helm.exe upgrade --tiller-namespace [tillerns] --namespace [snip] --install --values [values] --wait --tls --tls-ca-cert D:\a\_temp\ca.cert.pem --tls-cert D:\a\_temp\helm-vsts.cert.pem --tls-key D:\a\_temp\helm-vsts.key.pem --values [values] --values [values] --values [values] --values [values] [release] [chart]
2019-03-01T06:40:01.6728072Z E0301 06:39:44.751630    3996 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:1704->127.0.0.1:1706: write tcp4 127.0.0.1:1704->127.0.0.1:1706: wsasend: An established connection was aborted by the software in your host machine.
2019-03-01T06:40:01.6739267Z Release "[release]" has been upgraded. Happy Helming!
2019-03-01T06:40:01.6762749Z E0301 06:40:00.814924    3996 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:1704->127.0.0.1:1707: write tcp4 127.0.0.1:1704->127.0.0.1:1707: wsasend: An established connection was aborted by the software in your host machine.

Versi klien dan server untuk kelengkapan,

2019-03-01T07:03:22.2064935Z Client: &version.Version{SemVer:"v2.13.0", GitCommit:"79d07943b03aea2b76c12644b4b54733bc5958d6", GitTreeState:"clean"}
2019-03-01T07:03:22.2065659Z Server: &version.Version{SemVer:"v2.13.0", GitCommit:"79d07943b03aea2b76c12644b4b54733bc5958d6", GitTreeState:"clean"}

2019-03-01T07:09:04.9754415Z [command]C:\hostedtoolcache\windows\kubectl\1.13.2\x64\kubectl.exe version -o json
2019-03-01T07:09:05.8327359Z {
2019-03-01T07:09:05.8327545Z   "clientVersion": {
2019-03-01T07:09:05.8327674Z     "major": "1",
2019-03-01T07:09:05.8327817Z     "minor": "13",
2019-03-01T07:09:05.8327886Z     "gitVersion": "v1.13.2",
2019-03-01T07:09:05.8327992Z     "gitCommit": "cff46ab41ff0bb44d8584413b598ad8360ec1def",
2019-03-01T07:09:05.8328073Z     "gitTreeState": "clean",
2019-03-01T07:09:05.8328164Z     "buildDate": "2019-01-10T23:35:51Z",
2019-03-01T07:09:05.8328241Z     "goVersion": "go1.11.4",
2019-03-01T07:09:05.8328355Z     "compiler": "gc",
2019-03-01T07:09:05.8328441Z     "platform": "windows/amd64"
2019-03-01T07:09:05.8328539Z   },
2019-03-01T07:09:05.8328646Z   "serverVersion": {
2019-03-01T07:09:05.8328712Z     "major": "1",
2019-03-01T07:09:05.8328796Z     "minor": "11",
2019-03-01T07:09:05.8328863Z     "gitVersion": "v1.11.3",
2019-03-01T07:09:05.8328972Z     "gitCommit": "a4529464e4629c21224b3d52edfe0ea91b072862",
2019-03-01T07:09:05.8329052Z     "gitTreeState": "clean",
2019-03-01T07:09:05.8329146Z     "buildDate": "2018-09-09T17:53:03Z",
2019-03-01T07:09:05.8329265Z     "goVersion": "go1.10.3",
2019-03-01T07:09:05.8329352Z     "compiler": "gc",
2019-03-01T07:09:05.8329437Z     "platform": "linux/amd64"
2019-03-01T07:09:05.8329507Z   }
2019-03-01T07:09:05.8329588Z }



md5-6caedccc088691194ed9efcc738243bc



2019-03-01T08:24:47.4912692Z E0301 08:24:34.921142    4263 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:40201->127.0.0.1:35456: write tcp4 127.0.0.1:40201->127.0.0.1:35456: write: broken pipe

Vhab pada 1 Mar 2019

😕5

Dapat mengonfirmasi bahwa ini masih menjadi masalah di 2.13

$ helm install appscode/kubedb-catalog --name kubedb-catalog --version 0.10.0 --namespace kube-system 
NAME:   kubedb-catalog                                                                                                                     
E0303 20:13:56.088186   21260 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:33299->127.0.0.1:44514: write tcp4 127.0.0.1:33299->127.0.0.1:44514: write: broken pipe
LAST DEPLOYED: Sun Mar  3 20:13:54 2019
NAMESPACE: kube-system
STATUS: DEPLOYED
...

Saya baru saja mencoba kubedb sekarang dan mendapatkan ini. Saya melihat banyak orang mengatakan bahwa menghapus --wait memecahkan masalah bagi mereka, tetapi yang menurut saya terjadi adalah ketika Anda memiliki bendera itu, Anda kemungkinan besar akan mengalami hal ini, seperti yang akan Anda lakukan. pertahankan koneksi sampai Anda selesai. Tapi itu tidak menghapus masalah sepenuhnya.

Hanya memastikan itu termasuk:

Azure AKS menjalankan k8 versi 1.12.6

export TILLER_NAMESPACE="tiller"
export HELM_TLS_ENABLE="true"

Apakah ada hal lain yang bisa kami sediakan untuk men-debug ini?

simpers pada 3 Mar 2019

👍5

Saya pikir Anda harus menjalankan tiller 2.13 dan helm 2.13 agar tls berfungsi dengan benar.

willejs pada 6 Mar 2019

@willejs , @simpers menyebutkan dia menggunakan Helm 2.13. : P

tulis tcp4 127.0.0.1:1704->127.0.0.1:1707: wsasend: Sambungan yang dibuat dibatalkan oleh perangkat lunak di mesin host Anda.

@Vhab menarik bahwa pesan kesalahan berubah berdasarkan OS. Kesalahan pertama itu mungkin benar-benar mengkonfirmasi beberapa laporan di sini bahwa koneksi sedang diputus di suatu tempat antara klien, server API, kubelet dan tiller, tetapi sayangnya ini tidak mengidentifikasi di mana (atau apa) yang mengakhiri koneksi.

Mungkin mencari tahu siapa yang menjalankan 127.0.0.1:1704 mengirim permintaan ke 127.0.0.1:1707 dapat membantu kami mengidentifikasi masalah.

Pastikan laporan ini datang! Kami masih tidak yakin apa yang menyebabkan kegagalan jaringan yang mendasarinya, tetapi kami akan terus mencoba untuk mendapatkan log yang dapat kami temukan dan melihat apakah kami dapat mengidentifikasi perbaikan. Terima kasih banyak atas laporan lanjutannya, kami sangat menghargainya!

bacongobbler pada 6 Mar 2019

@simpers berdasarkan laporan kesalahan Anda:

tulis tcp4 127.0.0.1:33299->127.0.0.1:44514: tulis: pipa rusak

Jika Anda ingin mencoba mencari tahu siapa yang mendengarkan pada port 33299 dan 44514, itu mungkin berguna untuk mendiagnosis di mana koneksi terputus.

bacongobbler pada 6 Mar 2019

Saya pikir saya sebenarnya salah dan ini masih bug. Ceritanya panjang, kebanyakan dengan saya mengkompilasi ulang helm-diff dengan 2.13 untuk memperbaikinya, tetapi ternyata tidak. Saya curiga ini upstream?

willejs pada 6 Mar 2019

Terima kasih, saya lupa membuka kembali ini. Ya, saat ini rambu-rambu mengarah ke bug di bagian hulu yang memengaruhi Helm.

Sisi baiknya, masalah ini seharusnya tidak menjadi masalah bagi Helm 3 karena kami telah menghapus anakan dan berinteraksi langsung dengan server API. :)

bacongobbler pada 6 Mar 2019

🚀1

Ya, saat ini rambu-rambu mengarah ke bug di bagian hulu yang memengaruhi Helm.

Rasanya seperti itu.

Agak terlalu sibuk untuk mengolok-oloknya dan mencoba mendapatkan lebih banyak diagnostik saat ini, tetapi mencari-cari di Google untuk kemungkinan masalah terkait.
https://github.com/kubernetes/kubernetes/issues/74551
https://github.com/pachyderm/pachyderm/issues/2815
Ini memiliki gejala yang serupa.

Di samping catatan, apakah ada cara untuk mengubah kesalahan ini menjadi peringatan? Efektif operasi itu masih berhasil.
Tapi saya kira sumber kesalahan ini tidak cukup berbutir halus untuk memisahkan "tampaknya tidak membahayakan" vs "ini buruk".

Vhab pada 6 Mar 2019

Tidak, saya khawatir itu tidak berhasil ... Ini hanya mulai terjadi setelah saya meningkatkan semua perkakas dan klaster saya beberapa hari yang lalu (k8s dari 1.10.5 -> 1.11.8; helm [Saya rasa saya punya 2.7 .x] -> 2.13.0). Sekarang saya terus-menerus mengalami ini ketika mencoba untuk melakukan peningkatan, atau bahkan menjalankannya ...

~ Hai teman-teman, saat membaca utas saya mencoba beberapa hal dan saya mungkin (secara tidak sengaja) menemukan (setidaknya satu dari) alasan kesalahan - penerusan port ke layanan lain pada klien yang sama. Saya memiliki port-forward pada port 3000 dan segera setelah saya menghentikannya - kesalahan berhenti muncul. Saya membayangkan klien CI tidak mem-port-forward ke cluster saat membangun (atau pernah), jadi itu mungkin sesuatu di sisi cluster (terlepas dari klien mana yang benar-benar menggunakannya)? ~

~ Maaf jika saya benar-benar salah paham tentang apa yang terjadi di sini - Saya hanya berpikir untuk memposting memo ini dalam kemungkinan kecil sehingga dapat mengurangi rasa sakit. Cheers. ~

nicroto pada 19 Mar 2019

Untuk apa layak bagi mereka yang mencoba memahami dasar dari masalah ini ...

Diupgrade ke 2.13.1. Saya dapat mencari versi dari dalam cluster k8s dari pod lain.

user@app-pod-9qtnz:/opt/app$ /helm/linux-amd64/helm --tiller-namespace mynamespace version --tls --tls-ca-cert /opt/app/tiller-tls-secrets/ca.cert.pem --tls-cert /opt/app/tiller-tls-secrets/helm-cert --tls-key /opt/app/tiller-tls-secrets/helm-key
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

Di atas mengasumsikan konfigurasi cluster lokal dari pod.

Tidak dapat melakukannya dari "luar" cluster menggunakan kubeconfig. Gagal 100%.
Blok atas adalah port-forward, bagian bawah menanggapi helm cli mencoba untuk mendapatkan versi.

$ kubectl -nmynamespace --kubeconfig=/Users/me/kubeconfig port-forward tiller-deploy 44134:44134
Forwarding from 127.0.0.1:44134 -> 44134
Forwarding from [::1]:44134 -> 44134
Handling connection for 44134
Handling connection for 44134
Handling connection for 44134
E0325 14:48:23.291109   72782 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44134->127.0.0.1:65378: read: connection reset by peer
Handling connection for 44134
E0325 14:48:24.742180   72782 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44134->127.0.0.1:65379: read: connection reset by peer
Handling connection for 44134
E0325 14:48:26.876715   72782 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44134->127.0.0.1:65380: read: connection reset by peer
Handling connection for 44134
E0325 14:48:29.782902   72782 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44134->127.0.0.1:65381: read: connection reset by peer
Handling connection for 44134
E0325 14:48:34.851637   72782 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:44134->127.0.0.1:65383: read: connection reset by peer
Handling connection for 44134
...

$ HELM_HOST=127.0.0.1:44134 helm version --tls --tls-verify --tls-ca-cert ~/ca-cert --tls-cert ~/helm-cert --tls-key ~/helm-key
Client: &version.Version{SemVer:"v2.13.0", GitCommit:"79d07943b03aea2b76c12644b4b54733bc5958d6", GitTreeState:"clean"}
...(hangs)



md5-d9d6f280ef7bf71d5bbbc6c43d1ebd52



$ kubectl -napp-ns-403 --kubeconfig=/Users/me/kubeconfig port-forward tiller-deploy-8d8cb7f47-f8mqm 44135:44135
Forwarding from 127.0.0.1:44135 -> 44135
Forwarding from [::1]:44135 -> 44135
Handling connection for 44135



md5-0c4a71223f15124df7f24360c8cc1876



$ curl localhost:44135/liveness -v
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 44135 (#0)
> GET /liveness HTTP/1.1
> Host: localhost:44135
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 25 Mar 2019 19:59:52 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact



md5-8fde931e38314bce9d22243a1c02a707



$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T22:29:25Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.13-eks-g484b8", GitCommit:"484b857e3134d55ac6373fea2f51798fefa0533f", GitTreeState:"clean", BuildDate:"2019-03-08T05:32:36Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

cguethle pada 25 Mar 2019

Inilah masalahnya, kesalahan dalam validasi TLS menutup koneksi secara tidak terduga dan proxy kubectl di latar belakang mengeluh tentang hal itu tanpa helm mencetak kesalahan yang sebenarnya .

Dalam kasus saya, itu sesederhana menambahkan "localhost" ke host sertifikat server dan

export HELM_TLS_HOSTNAME=localhost

openssl s_client -connect adalah kunci untuk mempersempitnya, lalu menerjemahkannya ke bendera helm.

Ini harus ditandai dengan jelas sebagai bug.
Kesalahan sebenarnya benar-benar diam bahkan dengan --debug

miguelangel-nubla pada 15 Apr 2019

👍1

Saya menerapkan magento di ibm cloud private dan saya mendapatkan kesalahan ini
NAMA: magento
E0416 18: 45: 41.935993 106642 portforward.go: 303] kesalahan menyalin dari aliran jarak jauh ke koneksi lokal: readfrom tcp4 127.0.0.1:35733->127.0.0.1:58668: tulis tcp4 127.0.0.1:35733->127.0.0.1: 58668: tulis: pipa rusak
TERAKHIR DEPLOYED: Sel 16 Apr 18:45:39 2019
NAMESPACE: ace
STATUS: DEPLOYED

jgra26 pada 17 Apr 2019

Inilah masalahnya, kesalahan dalam validasi TLS menutup koneksi secara tidak terduga dan proxy kubectl di latar belakang mengeluh tentang hal itu tanpa helm mencetak kesalahan yang sebenarnya .
Dalam kasus saya, itu sesederhana menambahkan "localhost" ke host sertifikat server dan
export HELM_TLS_HOSTNAME=localhost
openssl s_client -connect adalah kunci untuk mempersempitnya, lalu menerjemahkannya ke bendera helm.
Ini harus ditandai dengan jelas sebagai bug.
Kesalahan sebenarnya benar-benar diam bahkan dengan --debug

Konfirmasikan, itu membantu. Saya dulu

export HELM_TLS_HOSTNAME=tiller-server

feksai pada 22 Apr 2019

@ miguelangel-nubla @feksai Sayangnya ini tidak berhasil bagi kami.
Meskipun menggunakan --tls-verify memang mereproduksi kesalahan serupa, yang kemudian dapat kita hapus dengan --tls-verify --tls-hostname [hostname] , ini tidak menghapus kemunculan semi-acak dari kesalahan selama panggilan helm yang lebih lama.

helm upgrade --tiller-namespace [tillerns] --namespace [ns] --install --values [values] --wait --tls --tls-ca-cert [cert] --tls-cert [cert] --tls-key [key] --tls-verify --tls-hostname [tillerhost] --values [values] [release] [chart]

2019-04-24T10:43:30.6030274Z E0424 10:43:29.393264    3780 portforward.go:363] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:1698->127.0.0.1:1701: write tcp4 127.0.0.1:1698->127.0.0.1:1701: wsasend: An established connection was aborted by the software in your host machine.

Vhab pada 24 Apr 2019

@Vhab ya, kegembiraan saya berumur pendek. Masih mengalami kesalahan yang sama dengan hasil langka yang berhasil. Diketahui jika upgrade helm membutuhkan waktu lebih dari 15 detik maka akan gagal. Dalam rilis yang berhasil, butuh waktu tidak lebih lama dari tepi itu

feksai pada 24 Apr 2019

@technosophos meskipun # 5210 kami masih mengalami masalah yang sama. Apakah menurut Anda ini bisa diperbaiki atau haruskah kita menunggu helm 3?

luigi-riefolo pada 28 Apr 2019

Pemikiran saat ini adalah bahwa ini adalah bug upstream. Jadi saya tidak yakin masih banyak yang bisa kami lakukan. Tapi itu pasti tidak akan memengaruhi Helm 3, yang tidak lagi menggunakan aspek penerusan / penerusan port Kubernetes.

technosophos pada 29 Apr 2019

👍3

setuju dengan @technosophos. Dengan Helm 3 di depan mata, apakah perlu memperbaiki masalah ini?
Saya menemukan kesalahan tidak mengganggu pemasangan / peningkatan helm yang sebenarnya, karena itu berfungsi, bagi saya itu selalu muncul di akhir laporan pasca penyebaran helm dumps. Yang saya abaikan dan kemudian menggunakan langkah-langkah selanjutnya di pipeline untuk memeriksa ulang penerapannya baik-baik saja. Tidak bagus saya akui tetapi cukup solusi sampai Helm 3 datang.

Saya benar-benar tidak akan menginvestasikan lebih banyak waktu dan tenaga untuk masalah ini.

garethmorris78 pada 30 Apr 2019

Masalah terbesar yang kami miliki dengan ini adalah CI / CD kami melihatnya sebagai kegagalan.

Meskipun penerapan berhasil, pelaporan tersebut mengatakan gagal.

Ini adalah perilaku yang merugikan sehingga menyebabkan orang mengabaikan kesalahan yang muncul di CI / CD karena "oh, benda itu selalu keluar."

codejnki pada 30 Apr 2019

@codejun setuju. Saya melanjutkan kesalahan untuk langkah penerapan helm sehingga peringatan dimunculkan dan kemudian saya memvalidasi kerjanya di langkah berikutnya dan jika gagal maka saatnya untuk memperhatikan. Tidak bagus tetapi dengan Helm 3 datang dan ppl dididik secara internal tentang kesalahan itu masih membuat kami menggunakan Helm.

garethmorris78 pada 30 Apr 2019

Masalah ini ada pada cara kubectl port forwarding ditangani dan tidak terkait dengan helm itu sendiri. Ada masalah terbuka di kubernetes repo tentang ini.

Saya menghadapi masalah serupa dalam pengaturan berbeda di mana saya mengunggah file ke dalam pod dan alasannya
Saya mendapatkan pipa rusak ternyata batas memori yang ditetapkan pada pod. File yang saya unggah lebih besar dari batas memori pod sehingga saya mendapatkan kesalahan berikut:
portforward.go:400] an error occurred forwarding 5000 -> 5000: error forwarding port 5000 to pod 9d0e07887b021ac9a2144416bc7736ce9b22302da25483ac730c5737e2554d7c, uid : exit status 1: 2019/05/17 03:54:30 socat[13000] E write(5, 0x186ed70, 8192): Broken pipe
Saat meningkatkan batas pod, saya berhasil mengunggah file.

AkarshES pada 17 Mei 2019

👍1

Saya dapat mengonfirmasi export HELM_TLS_HOSTNAME=<tiller-deployment-name> berfungsi dengan baik, saya tidak mendapatkan kesalahan pipa rusak. :)

zrsm pada 2 Agu 2019

👀1 🎉1 👎1

Dp maksudnya nama podnya, seperti "tiller-deploy-d8cbf88b8-dcvjk".
Tetapi itu berubah pada setiap penerapan, bagaimana saya harus mengaturnya?

cforce pada 3 Agu 2019

Error ini tidak boleh ada di Helm 3 karena Helm tidak lagi mengandalkan logika portforwarder di Kubernetes untuk mendapatkan koneksi ke Tiller (karena Tiller telah dihapus).

Saya akan menutup ini setelah diselesaikan, namun jika ada perbaikan, kami dapat menerapkan ke Helm 2 untuk memperbaiki situasi yang akan menyenangkan untuk didengar dan kami akan menyukai PR. Terima kasih!

bacongobbler pada 14 Agu 2019

Jadi kamu akhiri pemeliharaan helm 2 sekarang, di mana Helm3 bahkan belum stabil dan penggabungan semuanya juga akan memakan waktu.?

cforce pada 22 Sep 2019

👎10 😕5 ❤4

Mungkin ini masih akan membantu seseorang. Saya mendapatkan kesalahan yang sama

E1008 11:23:47.418883    4367 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:40737->127.0.0.1:38472: write tcp4 127.0.0.1:40737->127.0.0.1:38472: write: broken pipe

memasang grafik yang berisi CRD dengan

  annotations:
    "helm.sh/hook": crd-install

(misalnya https://github.com/helm/charts/tree/master/stable/ambassador)

Error terjadi jika di upgrade dari rilis yang sudah ada, jadi saat CRD sudah ada.
Menghapus anotasi hook membantu saya.

Helm v.2.11.0

abinet pada 8 Okt 2019

Saya mendapatkan kesalahan yang sama dan menambah memori atau mengekspor HELM_TLS_HOSTNAME =tidak membantu saya

psergiovieira pada 14 Okt 2019

Mengapa masalah ditutup? Saat ini, tidak mungkin untuk menggunakan helm dengan CI / CD dengan TLS karena masalah ini.
Apakah kita harus menunggu Helm 3?

Pembaruan: Saya percaya harus dinyatakan di halaman depan bahwa ada masalah besar sehingga orang tidak akan membuang waktu dengan kemudi untuk saat ini?

Perbarui 2, solusi sementara saya: Sebagai solusi sementara dalam skrip CI / CD sebelum menjalankan perintah pemasangan / peningkatan Helm apa pun, saya menonaktifkan keluar pada kode bukan 0 (set + e), jalankan perintah helm, aktifkan kembali keluar pada bukan 0 kode (set -e) dan gunakan status peluncuran kubectl untuk menunggu penerapan tersedia dengan set batas waktu. Jika batas waktu tercapai, itu berarti ada yang tidak beres. Dalam kasus saya, saya hanya peduli tentang penerapan yang tersedia.
Sebagai contoh:
set +e
helm upgrade --install prometheus stable/prometheus
set -e
kubectl rollout status --timeout=30s deployment/prometheus-server

GytisT pada 4 Nov 2019

👍8

Masih terjadi:

$ helm version
Client: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"}

vkukk pada 7 Nov 2019

Masalah yang sama tetap ada pada cluster K8S yang dihosting di GCP.

Perintah: helm upgrade --install ******

Versi helm: v2.14.2

Versi Kubernetes. Info: {Major:"1", Minor:"13+", GitVersion:"v1.13.11-gke.9", GoVersion:"go1.11.13b4", Compiler:"gc", Platform:"linux/amd64"}

Kesalahan:
E1109 00:08:37.767306 269 portforward.go:372] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44603->127.0.0.1:38070: write tcp4 127.0.0.1:44603->127.0.0.1:38070: write: broken pipe E1109 00:08:37.767306 269 portforward.go:372] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:44603->127.0.0.1:38070: write tcp4 127.0.0.1:44603->127.0.0.1:38070: write: broken pipe log: exiting because of error: log: cannot create log: open /tmp/helm.bf54a0af24f1.root.log.ERROR.20191109-000837.269: no such file or directory\n

BlueMaverick pada 12 Nov 2019

Saya melihat masalah yang sama pada versi:
Kemudi:
Server: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}
Kubernetes:
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"

Ada ide?

nazaga pada 27 Jan 2020

Helm3 keluar. Coba gunakan itu.

oivindoh pada 28 Jan 2020

👎6 👍3

gunakan safari, bukan chrome

ishanaldo pada 4 Feb 2020

👎10 😄9

Saya menemukan masalahnya. Masalahnya adalah dengan penyimpanan, penggarap dapat menyelesaikan masalah laporan akhir dengan mengalokasikan sumber daya penyimpanan. Tapi itu menarik bagaimana penanganan kesalahan diimplementasikan;)

nazaga pada 4 Feb 2020

Saya dapat melacak penyebab masalah ini pada sertifikat Tiller dan Helm yang kedaluwarsa.

Deskripsi masalah

Saya awalnya mengamankan instalasi Tiller saya dengan mengikuti petunjuk ini https://v2.helm.sh/docs/using_helm/#using -ssl-between-helm-and-tiller. Dalam tutorial, durasi validitas sertifikat Helm dan Tiller diatur ke 365 hari. Saya awalnya membuat sertifikat dengan nilai ini, tetapi lebih dari 365 hari yang lalu.

Saat menjalankan perintah Helm (mis. helm version atau helm list ), saya menerima pesan kesalahan seperti ini:

an error occurred forwarding 49855 -> 44134: error forwarding port 44134 to pod 4106da54d86955cc3f88c866cf45afdaf0c6edf9f471ad669f23ba56dc77e6ab, uid : exit status 1: 2020/05/27 21:33:00 socat[15077] E write(5, 0x5642d8387150, 24): Broken pipe

Resolusi Masalah

Cadangkan sertifikat Anda yang sudah ada
Menggunakan kunci Tiller keluar, Kunci Helm, Kunci CA, dan sertifikat CA, buat sertifikat Helm dan Tiller baru dengan mengikuti petunjuk asli yang dijelaskan di https://v2.helm.sh/docs/using_helm/#using -ssl-between-helm -dan-anakan
Tingkatkan penyiapan Tiller Anda dengan sertifikat baru ini. Saya tidak perlu mengedit rahasia Tiller di cluster secara manual, karena perintah berikut memperbarui rahasia untuk saya (perhatikan bahwa ini juga akan mengupgrade Tiller di cluster Anda ke versi Helm yang sesuai yang Anda gunakan):

helm init \
--service-account tiller \
--tiller-namespace tiller \
--tiller-tls \
--tiller-tls-cert tiller.crt \
--tiller-tls-key ~/.ssh/tiller.key \
--tiller-tls-verify \
--tls-ca-cert ~/.ssh/ca.helm.crt \
--upgrade

danielhanold pada 28 Mei 2020

❤2

Helm: tulis: pipa rusak

Komentar yang paling membantu

Semua 98 komentar

Deskripsi masalah

Resolusi Masalah

Masalah terkait