Kubernetes: mode ipvs kube-proxy hang setelah beberapa jam, perlu restart manual

/ sig network

kesalahan yang sama. meningkatkan dari 1.11.1. Semuanya menjadi baik kecuali kube-proxy menjadi tidak stabil, kadang pod tidak dapat mengakses svc meskipun endpoint mereka baik-baik saja .. Dan sama dengan resolusi nama. jadi saya pikir mungkin ada bug penting di sini.

/ area ipvs

@ gjcarneiro apakah Anda menyelesaikan masalah ini?

Nah, saya mengalihkan cluster kembali ke mode default (iptables), tampaknya cukup stabil sejak itu ...

@ kubernetes / sig-network-bugs

@berlinsaint : Mengulangi sebutan untuk memicu pemberitahuan:
@ kubernetes / sig-network-bugs

masalah yang sama, baik 1.12.2 dan 1.13.0-beta1. @ m9372566 @ Lion-Wei

@ gjcarneiro maksud Anda bahwa di kernel 4.15, ada masalah yang sama?

@nnnnnnnnnnnnnnnnnya

masalah yang sama, baik 1.12.2 dan 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Berapa kotak surat Anda, kenali itu. .remaja

@nnnnnnnnnn

masalah yang sama, baik 1.12.2 dan 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Berapa kotak surat Anda, kenali itu. .remaja

Klik avatar saya untuk melihat

Saya juga melihat ini berulang kali dalam sistem logging terpusat saya:

  | Time | sys_name | log_lvl | tag | log_msg
  | November 27th 2018, 17:56:23.501 | k8lab2bs | 6 | kube.kube-system.kube-proxy | lw: remote out of the list: 10.12.12.1:443/TCP/10.12.100.133:6443
  | November 27th 2018, 17:56:23.500 | k8lab2bs | 6 | kube.kube-system.kube-proxy | Deleting rs: 10.12.12.1:443/TCP/10.12.100.133:6443
  | November 27th 2018, 17:56:23.497 | k8lab2bs | 6 | kube.kube-system.kube-proxy | Trying to delete rs: 10.12.12.1:443/TCP/10.12.100.133:6443

Saya menjalankan v1.12.3 (instalasi baru, bukan peningkatan).

Halo semua. Terima kasih atas laporannya, saya akan melakukan penelitian dan mencoba mencari tahu apa yang terjadi, kemajuan apa pun akan saya laporkan di sini.

Selain apa yang terjadi, yang bagus untuk mengetahuinya, saya tidak merasa yakin tentang IPVS sampai ada kode yang mendeteksi dan mengatur ulang soket netlink yang rusak. Karena dari apa yang bisa saya tebak dari log dan jejak itu adalah bahwa soket netlink menjadi rusak dan tugas yang membaca / menulis dari / ke itu akan hang selamanya. Saya pikir kube-proxy perlu memiliki kode yang mendeteksi masalah ini, dan jika itu terjadi, buat soket netlink baru dari awal, dan mungkin memulai ulang tugas yang menanganinya. Tapi, tidak, saya tidak menjadi sukarelawan, saya bahkan tidak tahu Go, maaf.

Karena dari apa yang bisa saya tebak dari log dan jejak itu adalah bahwa soket netlink menjadi rusak dan tugas yang membaca / menulis dari / ke itu akan hang selamanya.

Kami mengupgrade versi go netlink beberapa hari yang lalu untuk mendukung penghentian yang lancar. Perpustakaan netlink berjalan cukup stabil sebelumnya. Saya tidak yakin apakah itu penyebabnya.

1.12.3 dengan kesalahan yang sama.
Setelah memfilter log INFO,
jalankan kubectl -n kube-system logs kube-proxy-29zh8|egrep ^E; kubectl -n kube-system logs kube-proxy-2pqdn|egrep ^E; kubectl -n kube-system logs kube-proxy-4xw8q|egrep ^E; kubectl -n kube-system logs kube-proxy-6j4bc|egrep ^E; kubectl -n kube-system logs kube-proxy-brbjb|egrep ^E; kubectl -n kube-system logs kube-proxy-r6cg2|egrep ^E; kubectl -n kube-system logs kube-proxy-rpl6t|egrep ^E;
dan semua log node proxy

bash E1129 01:01:10.862180 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 21:09:11.422553 1 proxier.go:1485] Failed to get IPVS service, error: Expected only one service obtained=0 E1129 21:09:11.422699 1 proxier.go:1116] Failed to sync endpoint for service: 172.17.0.1:31800/TCP, err: Expected only one service obtained=0 E1129 01:01:11.618125 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 01:01:11.905626 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:01:41.771596 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:02:11.923872 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:02:42.060658 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:03:12.326762 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:03:42.718417 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:04:12.859933 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:04:42.963527 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:05:13.078486 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:05:43.185141 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:06:13.303090 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:06:43.408582 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:07:13.550358 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:07:43.686235 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:08:13.786326 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:08:43.981764 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:09:14.188053 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:09:44.316316 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:10:14.440466 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:10:44.550092 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:11:14.658190 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:11:44.765396 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:12:14.975724 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:12:45.085632 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:13:15.317679 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:13:45.432469 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:14:15.689681 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:14:45.813565 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:15:33.434931 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:16:03.578017 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:16:33.709744 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:17:03.823325 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:17:33.935191 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:18:04.053183 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:18:34.248994 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:19:04.375946 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:19:34.552779 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:19:36.596182 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:19:47.433846 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:20:17.534206 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:20:47.682350 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:21:17.825175 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:21:47.942548 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:22:18.055820 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:22:48.149494 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:23:18.564985 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:23:48.678462 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:24:18.836217 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:24:48.991344 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:25:19.091032 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:25:49.187178 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:26:19.301770 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:26:49.425812 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:27:19.606711 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:27:49.721224 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:28:20.109117 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:28:50.211574 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:29:20.405007 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:29:50.507766 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:30:20.605471 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:30:50.702798 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:31:20.807400 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:31:50.903049 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:32:21.005618 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:32:51.106378 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:33:21.224447 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:33:51.354916 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:34:21.467898 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:34:51.583216 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:35:21.691099 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:35:51.797151 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:36:21.921057 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:36:52.083821 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:37:02.445737 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:37:07.427811 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:37:37.546362 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:38:07.651769 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:38:37.797858 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:39:08.064112 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:39:38.181089 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:40:08.282892 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:40:38.390167 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:41:08.508549 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:41:38.617921 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:42:08.728384 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:42:38.844074 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:43:08.973517 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:43:39.092095 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:44:09.202329 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:44:39.363721 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:45:09.476240 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:45:39.764944 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:46:09.894587 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:46:40.013388 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:47:10.127894 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:47:40.236119 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:48:10.397111 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:48:40.600084 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:49:10.877034 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:49:41.023593 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:50:11.149894 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:50:41.262320 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:51:11.410407 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:51:41.547057 1 proxier.go:1622] Failed to unbind service addr fe80::1c5d:70ff:fef2:e97b from dummy interface kube-ipvs0: error unbind address: fe80::1c5d:70ff:fef2:e97b from interface: kube-ipvs0, err: cannot assign requested address E1129 01:52:11.609974 1 proxier.go:1544] Failed to add destination: 172.31.200.9:443, error: file exists E1129 01:52:11.610088 1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/172.31.10.38:6443" err: invalid argument E1129 01:52:11.616690 1 proxier.go:1485] Failed to get IPVS service, error: Expected only one service obtained=0 E1129 01:52:11.616767 1 proxier.go:1116] Failed to sync endpoint for service: 172.18.0.1:31645/TCP, err: Expected only one service obtained=0 E1129 01:01:12.181112 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 01:01:22.278474 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 01:01:21.459378 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 01:01:17.442316 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 20:10:17.955872 1 proxier.go:1455] Failed to add IPVS service "dev-fffrf/mysql-testportal:mysql": file exists E1129 20:10:17.955863 1 graceful_termination.go:89] Try delete rs "10.100.217.68:15004/TCP/192.100.143.225:15004" err: Failed to delete rs "10.100.217.68:15004/TCP/192.100.143.225:15004", can't find the real server E1129 20:10:17.955892 1 proxier.go:1119] Failed to sync service: 172.17.0.1:31645/TCP, err: file exists E1129 20:10:17.956412 1 proxier.go:1485] Failed to get IPVS service, error: invalid argument E1129 20:10:17.956417 1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/172.31.10.38:6443" err: Failed to delete rs "10.96.0.1:443/TCP/172.31.10.38:6443", can't find the real server E1129 20:10:17.956426 1 proxier.go:1116] Failed to sync endpoint for service: 172.31.200.67:31645/TCP, err: invalid argument E1129 20:10:17.956448 1 graceful_termination.go:89] Try delete rs "10.101.1.98:5672/TCP/192.100.29.180:5672" err: invalid argument E1129 20:10:17.956547 1 graceful_termination.go:183] Try flush graceful termination list err E1129 01:01:17.484679 1 proxier.go:430] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 7 failed E1129 02:52:17.498135 1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/172.31.10.38:6443" err: invalid argument E1129 02:52:17.498396 1 graceful_termination.go:183] Try flush graceful termination list err E1129 06:28:17.607394 1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/172.31.10.38:6443" err: device or resource busy E1129 06:28:17.607513 1 graceful_termination.go:183] Try flush graceful termination list err E1129 10:02:17.718458 1 proxier.go:1544] Failed to add destination: 192.100.183.139:3306, error: file exists E1129 10:02:17.718606 1 proxier.go:1544] Failed to add destination: 192.100.183.152:8080, error: invalid argument

BTW. dari atas log saya, kube-proxy sepertinya masih memiliki banyak masalah dengan iptables-restore. semua node saya adalah UBUNTU 16.04 yang memiliki versi 1.6.0 iptable.
@ m9372566 @ Lion-Wei

Kami melihat ini terjadi saat meningkatkan dari 1.12.1. sehingga harus berada di delta 1.12.1 dan 1.12.2.

Masalahnya adalah terkait penghentian anggun dan saya pikir kami telah memperbaiki bug di v1.13.1.

@ m1093782566 akankah perbaikan tersebut di-backport ke baris 1,12? sekarang ini memblokir perbaikan keamanan 1.12.3 untuk kami.

Begitu pula dengan peningkatan dari 1.11.2 ke 1.11.5.

@ m1093782566 dapatkah Anda memberikan informasi lebih lanjut tentang perbaikan? Saya akan tertarik untuk melihat komit tersebut.

Ini sangat gila, kami digigit sangat keras hari ini.

Kami melihat ini terjadi saat meningkatkan dari 1.12.1. sehingga harus berada di delta 1.12.1 dan 1.12.2.

Begitu pula dengan peningkatan dari 1.11.2 ke 1.11.5.

Apakah serangga itu sudah dipetik?

Sepertinya PR yang memperbaiki masalah: https://github.com/kubernetes/kubernetes/pull/71515

Benar @ Quentin-M

Ya, ini mungkin berasal dari perbaikan dalam fungsi delete (tidak benar-benar terkait dengan judul PR).

@ m1093782566 Saya dapat membuat pilihan-ceri untuk 1,12. Apakah kita ingin mem-backport PR lengkap atau hanya memperbaiki fungsi delete? (untuk menghindari perubahan perilaku dengan aliran UDP di 1,12)

Apakah serangga itu sudah dipetik?

@ Quentin-M sepertinya bug tersebut diperkenalkan oleh https://github.com/kubernetes/kubernetes/pull/66012 yang dipilih secara ceri ke rilis 1.11.5 dan 1.12.2:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#changelog -since-v1114
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md#other -notable-changes-1

Saya pikir semua # 71515 harus dipilih. Pengakhiran yang tertib secara keseluruhan hanya diperkenalkan dan dipilih dengan # 66012 sehingga perubahan perilaku telah terjadi.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 masih basi di kluster kami. 60% dari mereka terjebak dalam waktu kurang dari 24 jam. Mencoba 1.12.1 sekarang.

@ Quentin-M: Dapatkah Anda memeriksa log di kube-proxy dan mengonfirmasi bahwa jenis pesan ini telah hilang:

Nov 15 07:49:52 hex-48b-pm kube-proxy[5389]: I1115 07:49:52.393664    5389 graceful_termination.go:160] Trying to delete rs: 10.128.33.237:6379/TCP/10.125.6.34:6379
Nov 15 07:49:52 hex-48b-pm kube-proxy[5389]: E1115 07:49:52.393690    5389 graceful_termination.go:89] Try delete rs "10.128.33.237:6379/TCP/10.125.6.34:6379" err: Failed to delete rs "10.128.33.237:6379/TCP/10.125.6.34:6379", can't find the real server
Nov 15 07:49:52 hex-48b-pm kube-proxy[5389]: I1115 07:49:52.393697    5389 graceful_termination.go:93] lw: remote out of the list: 10.128.33.237:6379/TCP/10.125.6.34:6379

Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420950    5389 proxier.go:1455] Failed to add IPVS service "monitoring/extradata-inserter:": file exists

Keduanya terkait dengan fungsi hapus yang diperbaiki di PR. Jika ini hilang dan Anda masih melihat masalahnya, perbaikan ini tidak cukup

Selain itu, jika semuanya berfungsi dengan 1.12.1 , ada kemungkinan besar bahwa masalah tersebut berasal dari penghentian yang tertib (# 66012)

Saya pikir saya punya ide: Saya ingin tahu apa yang terjadi jika kita mencoba menambahkan server nyata yang masih dalam penghentian anggun. Dalam hal ini kita hanya harus menambah bobot menjadi 1 dan menghapusnya dari daftar penghentian anggun.

Saya akan mencoba menguji skenario ini sesegera mungkin (tetapi ini akan rumit karena saya berada di Kubecon minggu depan)

@ Lion-Wei bagaimana menurut Anda?

Ok gores itu, saya baru saja menguji dan berfungsi dengan baik. Kode yang bertanggung jawab ada di sini: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

Dalam hal ini, RS dihapus dari daftar gracefulDelete dan dari IPVS RS. Saya ingin tahu apakah menyetel bobot kembali ke 1 mungkin tidak lebih baik

Saya akan mencoba hal lain berdasarkan bagian log ini, yang tampaknya mengarah ke mencoba menyinkronkan titik akhir untuk layanan yang dihapus

Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420734    5389 proxier.go:1496] Failed to list IPVS destinations, error: invalid argument
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420763    5389 proxier.go:809] Failed to sync endpoint for service: 10.128.33.156:8125/TCP, err: invalid argument
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420889    5389 proxier.go:1485] Failed to get IPVS service, error: Expected only one service obtained=0
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420903    5389 proxier.go:809] Failed to sync endpoint for service: 10.128.35.150:6379/TCP, err: Expected only one service obtained=0
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420950    5389 proxier.go:1455] Failed to add IPVS service "monitoring/extradata-inserter:": file exists
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.420961    5389 proxier.go:812] Failed to sync service: 10.128.34.54:80/TCP, err: file exists
Nov 15 07:51:22 hex-48b-pm kube-proxy[5389]: E1115 07:51:22.421886    5389 proxier.go:1544] Failed to add destination: 10.125.27.66:80, error: file exists

Oke setelah pemeriksaan cepat, komit yang memperbaiki masalah penghapusan bukan di v1.13.1-beta.0 atau di v1.14.0-alpha.0 yang dipotong pada tanggal 7 November
Saya pikir itu akan ada di rilis alfa 1,14 berikutnya yang akan didasarkan pada master

Saya akan membuat cherry pick untuk 1,13 juga

Punya masalah dengan upgrade dari 1.12.0 ke 1.13.0, sepertinya terkait dengan yang satu ini, tapi tidak sama.

Kami tidak dapat memperbaikinya dengan kembali ke iptables. Tolong bantu aku.

Saya telah mempostingnya di stackoverflow

Punya hal yang sama di 1.11.5. Dipulihkan sementara dari ipvs ke iptables.

Sama di 1.11.5. Tidak dapat memutar kembali ke 1.11.4 karena kerentanan yang ada di dalamnya. Harus beralih ke iptables. Apakah perbaikan untuk ini akan dirilis untuk 1.11.x?

Anda dapat melakukan rollback kube-proxy dengan sangat spesifik, tanpa terpengaruh oleh kerentanan.

@ Quentin-M Ya, pikiran itu telah terlintas di benak saya, tetapi di sisi lain saya berpikir jika saya melakukannya, saya tidak akan memiliki penghentian yang anggun, yang telah ada selama ini bersama dengan iptables. Tidak yakin bahwa pelanggan kami menginginkan perubahan tersebut.

@ Quentin-M apakah itu berarti tidak akan ada perbaikan untuk 1.11.x untuk mengatasi bug ini?

@emptywee Saya membuat cherry-pick untuk 1.11: https://github.com/kubernetes/kubernetes/pull/71848
Mudah-mudahan ini akan segera digabungkan dan akan menjadi 1.11.6

Ini telah digabungkan di 1.12 (akan menjadi 1.12.4 ) dan 1.13 (akan menjadi 1.13.1 )

Pilihan ceri baru saja digabungkan di 1,11 juga
Kita hanya perlu menunggu rilis tambalan berikutnya di 3 cabang (tetapi jika Anda ingin mengujinya sebelum saya dapat dengan mudah membuat kube-proxy build khusus (atau, lebih mudah, gambar buruh pelabuhan hyperkube dengan tambalan)

Terima kasih banyak @lbernail ! Gambar buruh pelabuhan yang tersedia untuk umum akan menyenangkan untuk dimiliki! Saya ingin mengujinya!

Perbaikannya sudah dipilih untuk v1.11, v1.12 dan v1.13.

Maukah Anda mengujinya sehingga kami dapat menutup masalah ini.

@ m1093782566 saya sedang menguji ini. btw, kapan komunitas akan mempublikasikan rilis kecil untuk ini?

Terima kasih @berlinsaint , izinkan saya hasil tesnya.

kapan komunitas akan menerbitkan rilis kecil untuk ini?

Rilis kecil baru dengan perbaikan akan dipublikasikan dalam waktu kurang dari 2 minggu.

@emptywee : ini dia: lbernail/hyperkube:v1.12.4-beta.1
Beri tahu kami cara kerjanya untuk Anda!

@ lbernail apakah boleh menggunakannya dengan semua yang lain di v1.11.5? Atau haruskah saya mengganti cluster kubernetes saya ke v1.12.4 terlebih dahulu? Pokoknya, terima kasih banyak!

@emptywee ya seharusnya berfungsi tanpa masalah (saya telah menjalankan kube-proxy 1.11 pada 1.10 cluster selama berbulan-bulan)

Saya juga bisa melakukan build 1,11 hari ini

@ lbernail ya, alangkah baiknya memiliki gambar dari versi rilis yang sama.

@emptywee ini dia: lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail Setelah satu malam obversasi, log kesalahan sinkronisasi ipvs tidak terlihat lagi, sementara
itu terjadi setidaknya sekali satu malam sebelumnya. Tapi masih butuh waktu lagi untuk verifikasi, makasih banyak bikin kesal lama sekali.

Saya akan mulai menguji besok pada 1,11 dan saya akan memberikannya beberapa hari juga.

@ lbernail Saya mencoba Anda lbernail/hyperkube:v1.11.6-beta.1 (Terima kasih untuk itu!)
Kami segera mengira semuanya telah diperbaiki, karena kami berhenti melihat pesan log can't find the real server . Namun, setelah satu setengah hari, kami melihat masalah dengan entri ipvs lama pada node cluster 3/6.
Ini adalah entri ipvs untuk layanan pada node cluster rusak.
Sebelum memulai ulang kube-proxy:

-A -t 10.230.65.211:9494 -s rr
-a -t 10.230.65.211:9494 -r 10.230.158.10:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.158.57:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.213.245:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.216.170:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.216.180:9494 -m -w 0
-a -t 10.230.65.211:9494 -r 10.230.222.151:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.222.158:9494 -m -w 0
-a -t 10.230.65.211:9494 -r 10.230.222.160:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.226.82:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.226.85:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.226.117:9494 -m -w 0
-a -t 10.230.65.211:9494 -r 10.230.242.229:9494 -m -w 1

Setelah memulai ulang kube-proxy:

-A -t 10.230.65.211:9494 -s rr
-a -t 10.230.65.211:9494 -r 10.230.158.36:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.213.236:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.216.129:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.216.163:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.226.84:9494 -m -w 1
-a -t 10.230.65.211:9494 -r 10.230.226.124:9494 -m -w 1

@ lbernail @bjornryden Itulah alasan saya masuk ke utas ini ketika saya beralih ke IPVS di 1.11.5. Hari berikutnya saya menemukan layanan tidak dapat diakses, jadi saya pikir kube-proxy telah hang dan tidak akan memperbarui entri untuk layanan.
Itu hanya untuk memberi tahu Anda bahwa saya memiliki masalah yang sama (IP salah di tabel ipvs) dengan v1.11.5 dari kube-proxy.

@bjornryden Kabar baik untuk kesalahan penghapusan (ini yang

Fakta bahwa backend tidak diperbarui dengan benar itu aneh karena penghentian yang anggun seharusnya tidak memengaruhi titik akhir baru (jika beberapa titik akhir basi masih ada, misalnya, saya akan kurang terkejut)

Bisakah Anda membagikan log kube-proxy yang terkait dengan layanan 10.230.65.211:9494 ?

Juga, apakah ada perilaku khusus dengan layanan / penerapan ini? (misalnya pod sangat sering diperbarui, atau di belakang HPA?)

Jadi sudah berjalan selama 2 hari di cluster lab saya dengan gambar 1.11.6-beta.1 oleh @lbernail dalam mode ipvs.
Sejauh ini bagus, itu belum macet dan terus memperbarui entri ipvs.

Namun ada satu pengamatan yang aneh:

lvdkbm501 ~ # ipvsadm -L -n -t 10.158.9.61:443
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
  -> 10.158.130.24:8443           Masq    1      0          0         
lvdkbm501 ~ # ipvsadm -L -n -t 10.158.9.61:443
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
lvdkbm501 ~ # ipvsadm -L -n -t 10.158.9.61:443
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
lvdkbm501 ~ # ipvsadm -L -n -t 10.158.9.61:443
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
  -> 10.158.128.28:8443           Masq    1      0          0         
lvdkbm501 ~ # ipvsadm -L -n -t 10.158.9.61:443
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
  -> 10.158.129.28:8443           Masq    1      0          0         

Panggilan pertama ke ipvsadm menunjukkan status awal sebelum saya menghapus salah satu pod untuk layanan tersebut. Beberapa acara selanjutnya bahwa satu entri hilang, karena pod telah dihapus. Namun, saya tidak tahu apakah seharusnya seperti itu, tetapi itu membuat entri kedua dengan alamat IP yang sama dengan pod yang tersisa. Dan kemudian itu diperbarui ke IP yang benar dari pod baru yang muncul untuk menggantikan yang dihapus.

Selain itu tidak apa-apa. Tapi cluster lab tidak sesibuk yang lain. Komentar dari @bjornryden membuat saya sedikit khawatir untuk mencoba gambar di cluster yang lebih sibuk, yang dapat berdampak pada pelanggan kami.

@emptywee Saya berasumsi pod yang dihapus adalah 10.158.130.24 . Saya tidak mengerti ini:

TCP  10.158.9.61:443 rr
  -> 10.158.128.28:8443           Masq    1      0          0         
  -> 10.158.128.28:8443           Masq    1      0          0 

Memiliki server nyata yang sama dua kali tidak masuk akal. Bisakah Anda mereproduksinya?

Perilaku normal pada penghapusan pod harus:

• jika tidak ada koneksi ke pod ini, hapus RS
• jika ada koneksi, atur bobot ke 0 (koneksi mapan terus, tidak ada koneksi baru)
• setiap menit periksa semua RS dengan bobot 0 (untuk inilah daftar terminasi anggun) dan hapus yang tidak memiliki koneksi lagi

@ lberail benar. Pod yang dihapus memiliki alamat IP tersebut. Dan ya, itu juga tampak aneh bagiku. Saya akan mencoba mereproduksi ketika saya mendapat kesempatan. Apakah Anda ingin saya meningkatkan verbositas log jika saya dapat mereproduksi perilaku yang sama? Jika ya, sampai level apa?

@emptywee : --v=5 seharusnya memberi kami banyak informasi
Hal utama adalah saya bahkan tidak berpikir RS dapat muncul dua kali dalam VS di IPVS (saya tidak pernah melihatnya). Kernel mana yang Anda jalankan?

@lbernail akan menyetelnya ke --v = 5 dan akan mencoba mereproduksi, mungkin beberapa saat selama akhir pekan.

Saya menggunakan CoreOS stable:

4.14 sangat baru, jadi saya akan terkejut jika ada masalah IPVS
Saya akan mencoba dan menekankan cluster dengan versi patch untuk melihat apakah saya dapat mereproduksi masalah dari @bjornryden

@ lbernail Sayangnya, saya tidak dapat mereproduksi perilaku duplikasi entri ipvs yang saya lihat hanya sekali. Mencoba beberapa kali, dengan layanan berbeda. Namun, saya belum melihat entri apa pun dengan bobot 0, tetapi ini mungkin dijelaskan oleh fakta bahwa pod yang saya hapus keluar dengan sangat cepat. Selain itu, kube-proxy telah responsif setelah berjalan selama lebih dari 5 hari. Saya mungkin akan mencobanya lagi dengan cara yang lebih banyak kelompok sibuk di sini.

@emptywee Ini adalah berita "baik" (meskipun saya lebih suka kami dapat mereproduksi dan memahaminya, mungkinkah itu kesalahan tampilan di ipvsadm?)

Bobot hanya disetel ke 0 jika merupakan ActiveConn atau InActiveConn. Untuk melihatnya, cukup buka koneksi berumur panjang ke layanan sebelum menghapus pod terkait (misalnya menggunakan telnet)

Stabilitas 5 hari adalah kabar baik! Beri tahu kami bagaimana kelanjutannya ketika / jika Anda mencoba di cluster yang lebih sibuk

Saya memiliki beberapa perbaikan kecil dalam perjalanan:

• https://github.com/kubernetes/kubernetes/pull/71834 : jadikan penghentian yang lancar bekerja dengan layanan menggunakan sessionAffinity (sudah di master, cherry picks dibuat untuk 1.13, 1.12 dan 1.11)
• https://github.com/kubernetes/kubernetes/pull/71895 dan https://github.com/kubernetes/kubernetes/pull/72106 : mendukung penghentian yang lancar saat menghapus layanan (yang pertama sudah ada di master, saya menunggu yang kedua untuk memetik ceri di semua cabang)

Juga, 1.11.6 , 1.12.4 dan 1.13.1 telah dirilis dan berisi perbaikan dalam fungsi hapus

Saya menulis artikel pendek tentang masalah ini selama akhir pekan /. Saya akan memastikan untuk memperbaruinya dengan versi tetap!

@ lbernail Tentu, akan berhasil! Apakah gambar hyperkube Anda sama dengan yang dirilis di 1.11.6? Saya telah menginstal gambar Anda hanya untuk kube-proxy di cluster yang lebih sibuk dan beralih ke ipv lagi untuk pengujian. Apakah Anda ingin saya menggunakan yang resmi?

@emptywee Gambar saya dan 1.11.6 pada dasarnya sama: Saya membuatnya dari kepala cabang rilis-1.11 beberapa hari sebelum rilis resmi jadi perbedaannya paling banyak adalah beberapa komitmen, tidak ada yang melibatkan IPVS. Jadi menurut saya tidak ada gunanya mengupdate cluster Anda lagi

Kabar buruk :( baru saja kube-proxy saya gagal memperbarui backend ipvs. Beralih kembali ke iptables dan mengumpulkan log. Kube-proxy berjalan dengan flag --v=5 .

@lbernail Jadi, tidak yakin berapa banyak log yang dibutuhkan, tapi pada dasarnya kami mengalami masalah dengan beberapa layanan, yang IP backend ipvs mereka tidak diperbarui. Log, bagaimanapun, memberi tahu kami bahwa itu memperbarui titik akhir dengan benar:

$ cat kube-proxy-issue.log | egrep -e 'c-qa4/ycsdtleuk|10.148.191.69|10.148.192.14|10.148.183.70|10.148.184.67'
I1217 19:12:52.849863       1 graceful_termination.go:160] Trying to delete rs: 10.148.6.202:80/TCP/10.148.192.14:8080
I1217 19:12:52.849948       1 graceful_termination.go:173] Deleting rs: 10.148.6.202:80/TCP/10.148.192.14:8080
I1217 19:12:52.850000       1 graceful_termination.go:160] Trying to delete rs: 10.148.6.202:80/TCP/10.148.191.69:8080
I1217 19:12:52.850069       1 graceful_termination.go:173] Deleting rs: 10.148.6.202:80/TCP/10.148.191.69:8080
I1217 19:12:53.425438       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:13:00.501203       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.191.69,tcp:8080,10.148.191.69 from ip set: KUBE-LOOP-BACK
I1217 19:13:00.543691       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.192.14,tcp:8080,10.148.192.14 from ip set: KUBE-LOOP-BACK
I1217 19:13:06.916777       1 service.go:309] Adding new service port "c-qa4/ycsdtleuk:http" at 10.148.6.202:80/TCP
I1217 19:13:08.345142       1 proxier.go:1465] Adding new service "c-qa4/ycsdtleuk:http" 10.148.6.202:80/TCP
I1217 19:13:13.939763       1 ipset.go:148] Successfully add entry: 10.148.191.69,tcp:8080,10.148.191.69 to ip set: KUBE-LOOP-BACK
I1217 19:13:14.002663       1 ipset.go:148] Successfully add entry: 10.148.192.14,tcp:8080,10.148.192.14 to ip set: KUBE-LOOP-BACK
I1217 19:27:53.485483       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:27:53.485526       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:42:53.388638       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:42:53.388673       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:57:53.643829       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 19:57:53.644032       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:12:53.541080       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:12:53.541129       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:27:53.368129       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:27:53.368306       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:42:53.539517       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:42:53.539542       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:57:53.624320       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 20:57:53.624371       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:12:53.630561       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:12:53.630585       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:20.897397       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:20.897463       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:46.630013       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:46.630084       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:57.995544       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.191.69:8080 10.148.192.14:8080]
I1217 21:26:57.995657       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.191.69:8080 10.148.192.14:8080]
I1217 21:27:24.296606       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080 10.148.191.69:8080 10.148.192.14:8080]
I1217 21:27:53.678172       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080 10.148.191.69:8080 10.148.192.14:8080]
I1217 21:28:21.517538       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080 10.148.191.69:8080]
I1217 21:28:21.595632       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080]
I1217 21:42:53.491595       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080]
I1217 21:57:53.492214       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080]
I1217 22:05:45.760620       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080]
I1217 22:06:24.890429       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080]
I1217 22:07:15.463144       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.183.68:8080]
I1217 22:07:43.201415       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080]
I1217 22:08:18.268005       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080]
I1217 22:08:58.774066       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.192.70:8080]
I1217 22:12:53.528515       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.192.70:8080]
I1217 22:27:53.522197       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.192.70:8080]
I1217 22:29:20.396794       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.192.70:8080]
I1217 22:29:43.994895       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.192.70:8080]
I1217 22:29:54.382253       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.183.70:8080 10.148.192.70:8080]
I1217 22:30:17.895084       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.183.70:8080 10.148.184.67:8080 10.148.192.70:8080]
I1217 22:31:45.791871       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.134.231:8080 10.148.183.70:8080 10.148.184.67:8080]
I1217 22:31:45.855011       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.70:8080 10.148.184.67:8080]
I1217 22:42:53.652587       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.70:8080 10.148.184.67:8080]
I1217 22:57:53.509372       1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.70:8080 10.148.184.67:8080]

Tetapi ketika saya memeriksanya dengan ipvsadm, itu masih menunjukkan dua yang pertama: 10.148.191.69:8080 10.148.192.14:8080

Sedangkan kubectl -n c-qa4 describe svc ycsdtleuk mengatakan bahwa titik akhir adalah 10.148.183.70:8080 10.148.184.67:8080 , dan di kotak lain entri ipvs untuk layanan yang sama diperbarui dengan benar.

$ kubectl -n c-qa4 describe svc ycsdtleuk
Name:              ycsdtleuk
Namespace:         c-qa4
Labels:            country=uk
                   env=qa
                   run=ycsdtleuk
                   stack=c
                   track=4
Annotations:       run: ycsdtleuk
Selector:          load-balancer-ycsdtleuk=true
Type:              ClusterIP
IP:                10.148.6.202
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         10.148.183.70:8080,10.148.184.67:8080
Session Affinity:  None
Events:            <none>

Saya pada dasarnya melihat yang berikut pada dua kotak pada saat yang bersamaan:

(incorrect ipvs config)
rnqkbm401 ~ # ipvsadm -L -t 10.148.6.202:80
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  rnqkbm401:http rr
  -> 10.148.191.69:http-alt       Masq    1      0          0
  -> 10.148.192.14:http-alt       Masq    1      0          0

(correct ipvs config)
rnqkbw401 ~ # ipvsadm -L -t 10.148.6.202:80
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  rnqkbw401:http rr
  -> 10.148.183.70:http-alt       Masq    1      0          0
  -> 10.148.184.67:http-alt       Masq    1      0          0

Tidak ada pesan kesalahan yang jelas atau teriakan apa pun yang menunjukkan tanda-tanda masalah di mana pun. Saya dapat mengirim file log lengkap (18 juta tidak terkompresi) kepada Anda secara langsung, jika Anda mau.

Singkat cerita: rasanya sementara bagian yang mendengarkan perubahan layanan berfungsi dengan baik, tetapi bagian yang berinteraksi dengan modul ipvs tidak. Saya bahkan tidak melihatnya mencoba menghapus dua alamat IP awal setelah menambahkannya. Sesuatu terjebak di suatu tempat.

@emptywee Terima kasih atas laporan

Yang mengejutkan adalah bahwa syncProxyRules dijalankan setidaknya setiap 30 detik (default) dan harus merekonsiliasi server IPVS yang sebenarnya dengan titik akhir. Ini menyebut syncEndpoints yang memicu AddRealServer dan ipvsHandle.NewDestination

Semua ini terjadi sebelum penghapusan titik akhir lama sehingga tidak akan terpengaruh oleh penghentian yang anggun

Bisakah Anda mengirimi saya log lengkap sehingga saya dapat melihat dengan tepat apa yang terjadi antara 21:26 dan 21:29 ?

Dua pertanyaan tambahan:

• satu kube-proxy terpengaruh, bukan?
• apakah satu layanan terpengaruh (apakah yang lain terus memperbarui secara normal?)

Lain kali, coba kirim SIGABRT ke proses, sehingga ia mencetak status tugas.

Ketika saya mendapat masalah, itu selalu melakukan sesuatu di dalam libnetwork/ipvs/netlink.go , yang membuat saya curiga bahwa panggilan sistem netlink macet karena beberapa alasan.

Maaf tentang ketidakhadiran saya, tetapi akhir pekan dan kemudian harus fokus untuk kembali ke iptables untuk pengaturan kami.

Melihat kembali log yang diminta untuk layanan, @lbernail , kami memiliki banyak dari ini:

I1214   11:48:44.889081       1   graceful_termination.go:160] Trying to delete rs:   172.17.0.1:31663/TCP/10.230.213.204:9300
I1214 11:48:44.889099       1 graceful_termination.go:173]   Deleting rs: 172.17.0.1:31663/TCP/10.230.213.204:9300
I1214 11:48:44.889113       1 graceful_termination.go:160] Trying   to delete rs: 172.17.0.1:31663/TCP/10.230.226.83:9300
I1214 11:48:44.889130       1 graceful_termination.go:173]   Deleting rs: 172.17.0.1:31663/TCP/10.230.226.83:9300
...

Kami juga melihat ini:

I1214 12:15:44.920364       1 graceful_termination.go:160] Trying to delete rs: 10.230.65.211:9494/TCP/10.230.226.124:9494
I1214 12:15:44.920489       1 graceful_termination.go:173] Deleting rs: 10.230.65.211:9494/TCP/10.230.226.124:9494
I1214 12:15:44.920512       1 graceful_termination.go:93] lw: remote out of the list: 10.230.65.211:9494/TCP/10.230.226.124:9494

Seperti yang dilaporkan orang lain, ini hanya terjadi pada beberapa node. Pada saat saya menemukan masalahnya, kami memiliki 3 node cluster yang rusak untuk layanan khusus ini.

@ lberail Tentu saja. Inilah bagian log yang diminta, saya telah menyertakan bagian startup juga: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Beri tahu saya jika Anda membutuhkan seluruh file. Jika ya, ke mana Anda ingin saya mengirimkannya, atau mengunggahnya.

Untuk menjawab pertanyaan Anda:

1. Cluster ini memiliki lebih dari 60+ node, saya memeriksa beberapa node lain, entri ipvs benar. Tidak yakin tentang semua entri. Namun pada node master, yang melaluinya kami merutekan semua lalu lintas ke layanan, setidaknya dua layanan tidak diperbarui dengan benar. Mungkin ada lebih banyak, tetapi begitu kami mulai mendapat keluhan dari pelanggan, kami segera mendengar tentang dua layanan yang tidak dapat diakses. Saya mengumpulkan log dan memulai ulang kube-proxy untuk meminimalkan dampak. Saya membandingkan status entri ipv pada node master itu dan salah satu node pekerja sebagai bagian dari pemecahan masalah dan menyadari bahwa itu berbeda. Ada kemungkinan bahwa node lain dapat memiliki entri berbeda yang tidak diperbarui dengan benar, tetapi karena lalu lintas tidak melewatinya, kami tidak melihat adanya dampak apa pun.

2. Tidak, setidaknya dua layanan terkena dampak. Mungkin lebih, tapi saya tidak memeriksanya.

Dua hal menarik dari log:

• I1217 21:26:57.995657 1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.191.69:8080 10.148.192.14:8080] tidak pernah diproses oleh IPVS tetapi tidak ada kesalahan karena Anda menyimpan dua RS lama (kami tidak dapat memastikan, menambahkan RS tidak menghasilkan log)
• I1217 21:28:21.517538 1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080 10.148.191.69:8080] tidak memicu panggilan penghapusan untuk 10.148.192.14:8080 (kita harus memiliki log di sana)

@emptywee apakah IPVS bekerja untuk Anda sebelum penghentian yang

@ m1093782566 / @ Lion-Wei tahu apa yang terjadi di sini?

@lbernail Kami menunggu sampai kami meningkatkan ke 1.11 untuk beralih ke ipvs (saya yakin saat rilis GA terjadi untuk fitur ini) dan kami meningkatkan langsung ke 1.11.5 dan itu adalah upaya pertama kami untuk mulai menggunakan ipvs.

@emptywee : Saya akan menambahkan beberapa log tingkat Info lagi untuk mencoba dan menunjukkan masalahnya. Apakah Anda tidak masalah menjalankan versi yang lebih panjang selama beberapa jam? (Saya benar-benar mengerti jika Anda lebih suka tidak, tetapi saya belum dapat mereproduksi di sisi saya)

Kami telah menggunakan IPVS sejak Mei dan tidak memiliki masalah di 1.12.1 dan 1.11.1.

Kami juga melihat ini terjadi pada beberapa, tetapi sejauh ini tidak semua node, setelah meningkatkan ke 1.12.3. Node yang terpengaruh berhenti memperbarui IPVS beberapa jam setelah peningkatan, tetapi tidak dengan cara terkoordinasi yang dapat saya lihat.

Satu hal yang perlu diperhatikan adalah bahwa kube-proxy juga berhenti melakukan logging sepenuhnya pada saat itu, jadi sepertinya macet sepenuhnya.

File log yang menunjukkannya macet, dan goroutine dump setelah SIGQUIT (disunting ringan)

File log

Anda bisa membantah bahwa ada beberapa kesalahan logika yang menyebabkan terlalu banyak interaksi dengan soket netlink. Tetapi jika komunikasi dengan netlink tidak solid, ipvs pada akhirnya akan macet. Jika kesalahan logika diperbaiki, mungkin perlu waktu lebih lama untuk mencapai status ini, tetapi itu tidak berarti itu tidak dapat terjadi dalam waktu yang cukup.

Itulah mengapa saya menyarankan untuk memiliki semacam batas waktu dalam interaksi netlink; jika waktu operasi habis, tutup soket netlink dan buka yang baru secara otomatis, sebagai mekanisme pemulihan.

@matthiasr Oke, itu kabar baik (kami juga telah menggunakan IPVS selama lebih dari 6 bulan tanpa masalah apa pun tetapi belum memperbarui ke versi menggunakan penghentian anggun pada cluster tersibuk kami)

Sepertinya kita mengalami kebuntuan di suatu tempat

@ lbernail meskipun agak merepotkan untuk mengalihkan seluruh cluster ke ipvs, jika ini akan membantu menyelesaikan masalah ini, saya kecewa. Beri tahu saya nama gambar yang akan digunakan dan saya akan melakukan apa pun yang saya bisa untuk membantu Anda dalam hal ini.

Kami telah kembali ke IPVS di 1.11.6 untuk melihat apakah kami dapat membuat ulang masalah kami. Logging disetel ke 5 dan menjalankan beberapa aktivitas di cluster selama beberapa hari berikutnya. Saya tidak akan bekerja besok, tetapi saya akan muncul online untuk melihat apakah ada gambar dengan peningkatan logging yang harus saya ubah.

@matthiasr : 1.12.3 pasti bermasalah (lihat sisa utas ini). Sebagian diselesaikan dalam 1.12.4 . Anda akan mendapatkan lebih sedikit kesalahan dalam log. Semua ini akan hilang: Failed to add destination: 10.zz.yy.xx, error: file exists

Kami masih memiliki masalah di mana kube-proxy tampaknya hang dan tidak lagi memperbarui server nyata.
Saya memeriksanya sedikit lagi:

• dari @emptywee tampaknya setelah masalah dimulai, kami tidak melihat log apa pun dari proxier.go, ipset.go, atau graceful_termination.go, yang sepertinya menunjukkan bahwa kami terjebak di suatu tempat. @emptywee dapatkah Anda memeriksa apakah Anda memiliki log untuk file ini setelah pukul 21:30?
• dalam dump rutin go, ada dua syscall yang menerima pada soket netlink. Jadi kita bisa mendapat masalah di sana. Selain itu, untuk mendukung penghentian yang anggun libnetwork / ipvs telah diupgrade sehingga perilakunya mungkin telah berubah. Namun, kode libnetwork tampaknya menyetel waktu tunggu kirim / rcv pada soket netlink (dan jika macet, kami akan melihat jumlah menitnya): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Menariknya, hanya libnetwork versi baru yang memiliki waktu tunggu netlink:

libnetwork diupgrade di semua cabang rilis (1.11, 1.12 dan 1.13) untuk memungkinkan penghentian yang lancar. kami beralih dari: ba46b928444931e6865d8618dc03622cac79aa6f menjadi a9cd636e37898226332c439363e2ed0ea185ae92

Di versi yang lebih lama, kodenya adalah: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

Satu-satunya perbedaan dalam kode IPVS di libnetwork antara 2 komit ini adalah:

• pengenalan batas waktu
• penambahan ActiveConnections dan InactiveConnections menjadi Destination (yang diperlukan untuk penghentian yang anggun)

Saya ingin tahu apakah ini mungkin terkait.

Setelah memikirkan lebih banyak tentang masalah ini, saya pikir itu berasal dari fakta bahwa kita sekarang memiliki dua goroutine menggunakan soket netlink yang sama (karena gracefulTerminationManager berjalan di goroutine-nya sendiri dan berbagi utilipvs.Interface dengan proxier).

Kita mungkin bisa menambahkan mutex di semua panggilan di pkg/util/ipvs/ipvs_linux.go untuk memastikan satu goroutine menggunakan soket netlink pada waktu tertentu.

@ m1093782566 bagaimana menurut Anda?

@ lbernail Tidak, tidak ada entri dari file-file itu di mana pun setelah pukul 21:30.
Inilah entri terakhir untuk berbagai file:

Entri terakhir dari graceful_termination.go

$ cat kube-proxy-issue.log | grep 'graceful_termination.go' | tail
I1217 21:18:20.757262       1 graceful_termination.go:66] Adding rs 10.148.11.105:8080/TCP/10.148.174.35:8081 to graceful delete rsList
I1217 21:18:52.267340       1 graceful_termination.go:160] Trying to delete rs: 10.148.0.145:80/TCP/10.148.188.28:8080
I1217 21:18:52.267456       1 graceful_termination.go:173] Deleting rs: 10.148.0.145:80/TCP/10.148.188.28:8080
I1217 21:18:52.267638       1 graceful_termination.go:160] Trying to delete rs: 10.148.0.145:80/TCP/10.148.145.194:8080
I1217 21:18:52.267755       1 graceful_termination.go:173] Deleting rs: 10.148.0.145:80/TCP/10.148.145.194:8080
I1217 21:18:52.405770       1 graceful_termination.go:160] Trying to delete rs: 10.148.0.145:80/TCP/10.148.188.28:8081
I1217 21:18:52.405906       1 graceful_termination.go:173] Deleting rs: 10.148.0.145:80/TCP/10.148.188.28:8081
I1217 21:18:52.406052       1 graceful_termination.go:160] Trying to delete rs: 10.148.0.145:80/TCP/10.148.145.194:8081
I1217 21:18:52.406156       1 graceful_termination.go:173] Deleting rs: 10.148.0.145:80/TCP/10.148.145.194:8081
I1217 21:18:53.240664       1 graceful_termination.go:160] Trying to delete rs: 10.148.11.105:8080/TCP/10.148.174.35:8081

Entri terakhir dari proxier.go:

$ cat kube-proxy-issue.log | grep 'proxier.go' | tail
I1217 21:18:52.570282       1 proxier.go:1023] Port "nodePort for kube-system/kube-dns:dns-tcp" (:30054/tcp) was open before and is still needed
I1217 21:18:52.663609       1 proxier.go:1023] Port "nodePort for ingress-nginx/ingress-nginx:http" (:31513/tcp) was open before and is still needed
I1217 21:18:53.241144       1 proxier.go:1465] Adding new service "c-qa4/yardchange-ws:http" 10.148.1.136:80/TCP
E1217 21:18:53.241277       1 proxier.go:1467] Failed to add IPVS service "c-qa4/yardchange-ws:http": file exists
E1217 21:18:53.241350       1 proxier.go:821] Failed to sync service: 10.148.1.136:80/TCP, err: file exists
I1217 21:18:53.241624       1 proxier.go:1465] Adding new service "c-qa4/receiving-ws-v2-uk:http-admin" 10.148.13.141:8080/TCP
E1217 21:18:53.241723       1 proxier.go:1467] Failed to add IPVS service "c-qa4/receiving-ws-v2-uk:http-admin": file exists
E1217 21:18:53.241761       1 proxier.go:821] Failed to sync service: 10.148.13.141:8080/TCP, err: file exists
E1217 21:18:53.242506       1 proxier.go:1496] Failed to get IPVS service, error: Expected only one service obtained=0
E1217 21:18:53.242558       1 proxier.go:818] Failed to sync endpoint for service: 10.148.11.84:8080/TCP, err: Expected only one service obtained=0

Entri terakhir dari ipset.go:

$ cat kube-proxy-issue.log | grep 'ipset.go' | tail
I1217 21:17:14.768694       1 ipset.go:148] Successfully add entry: 10.148.134.229,tcp:8080,10.148.134.229 to ip set: KUBE-LOOP-BACK
I1217 21:17:14.774040       1 ipset.go:148] Successfully add entry: 10.148.134.229,tcp:8081,10.148.134.229 to ip set: KUBE-LOOP-BACK
I1217 21:17:26.643709       1 ipset.go:148] Successfully add entry: 10.148.172.59,tcp:8080,10.148.172.59 to ip set: KUBE-LOOP-BACK
I1217 21:17:26.648504       1 ipset.go:148] Successfully add entry: 10.148.172.59,tcp:8081,10.148.172.59 to ip set: KUBE-LOOP-BACK
I1217 21:17:31.049667       1 ipset.go:148] Successfully add entry: 10.148.136.14,tcp:8080,10.148.136.14 to ip set: KUBE-LOOP-BACK
I1217 21:17:31.053901       1 ipset.go:148] Successfully add entry: 10.148.136.14,tcp:8081,10.148.136.14 to ip set: KUBE-LOOP-BACK
I1217 21:18:18.920550       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.181.11,tcp:8080,10.148.181.11 from ip set: KUBE-LOOP-BACK
I1217 21:18:18.924752       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.181.11,tcp:8081,10.148.181.11 from ip set: KUBE-LOOP-BACK
I1217 21:18:21.232725       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.174.35,tcp:8080,10.148.174.35 from ip set: KUBE-LOOP-BACK
I1217 21:18:21.237619       1 ipset.go:140] Successfully delete legacy ip set entry: 10.148.174.35,tcp:8081,10.148.174.35 from ip set: KUBE-LOOP-BACK

Mereka semua mengakhiri penebangan sekitar pukul 21:18 ... Apakah itu memberi petunjuk?

@emptywee Ya, ini menegaskan hipotesis bahwa kita mengalami kebuntuan antara dua goroutine yang berbagi soket netlink. Mereka berdua terjebak menunggu untuk menerima pesan dan terus mencoba lagi tanpa hasil (karena batas waktu penerimaan 3s).

Saya akan mencoba untuk memvalidasi hipotesis dan akan mulai mengerjakan perbaikan secepat mungkin

Saya menempatkan 1.12.4 pada cluster pengujian dan mulai menerapkan ulang aplikasi, yang mereproduksi masalah dalam 1,5 jam, jadi saya rasa saya akan dapat menguji potensi perbaikan dengan cukup andal.

Ada lagi 2 goroutine (1 dan 107) tergantung di Receive netlink.

Saya memiliki potensi perbaikan untuk bug tersebut, kodenya tersedia di sini: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
Idenya adalah untuk melindungi semua panggilan netlink dengan Mutex untuk menghindari kebuntuan. Saya tidak yakin ini adalah solusi terbaik tetapi dapat menyelesaikan masalah (dan jika berhasil, konfirmasikan bahwa kami telah mengidentifikasi bug).

Kalau mau / bisa mengujinya, saya buat dua gambar dengan fix:

• lbernail / hyperkube: v1.11.7-beta.1
• lbernail / hyperkube: v1.12.5-beta.1

Jika Anda mengujinya, beri tahu kami jika berhasil dan jika tidak, bagikan log yang menarik dan lihat goroutine untuk melihat apakah ada yang terjebak dalam panggilan netlink.

(Saya melakukan beberapa pengujian di sisi saya tetapi terbatas pada cluster kecil)

Saya mungkin akan mencobanya pada hari Senin, 24 Desember!

Coba hari ini. Akan melaporkan hasil, jika ada.

Ini adalah bug. Saya telah beralih ke mode iptables.

Saya juga telah meningkatkan ke versi beta dan segera memulai uji beban kami lagi. Kami biasanya istirahat dengan cepat (kurang dari sehari) dan cukup konsisten ... semoga saja.

@ li-sen pasti bug. Kami sedang mengerjakannya

@emptywee dan @bjornryden terima kasih banyak untuk pengujian!

Dengan senang hati mutex yang ditambahkan

Saya akan memperbarui masalah / utas ini pada akhir minggu.

@bayu_joo

Maukah Anda meningkatkan Humas untuk memperbaiki masalah ini?

/ buka kembali
(untuk mengawasi umpan balik dari tes dan sebelum membuat pilihan ceri jika semuanya berfungsi dengan baik)

@ lbernail : Anda tidak dapat membuka kembali masalah / PR kecuali Anda yang membuatnya atau Anda adalah kolaborator.

@ m1093782566 dapatkah Anda membuka kembali masalah hingga kami benar-benar yakin bahwa masalah telah diperbaiki?

Saya memiliki masalah yang sama dengan Kube-proxy ipvs, versi 1.12.3.
Server sebenarnya salah dan Kube-proxy tidak dapat menyegarkan aturan ipvs.

Ini log terakhir dan macet di sini, tidak lagi mencetak log baru.

27 23:31:24.113927       1 graceful_termination.go:93] lw: remote out of the list: 10.96.0.1:443/TCP/10.6.40.32:6443
E1227 23:31:24.113935       1 graceful_termination.go:183] Try flush graceful termination list err
I1227 23:32:24.114182       1 graceful_termination.go:160] Trying to delete rs: 10.96.0.1:443/TCP/10.6.40.32:6443
E1227 23:32:24.114316       1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/10.6.40.32:6443" err: Failed to delete rs "10.96.0.1:443/TCP/10.6.40.32:6443", can't find the real server
I1227 23:32:24.114332       1 graceful_termination.go:93] lw: remote out of the list: 10.96.0.1:443/TCP/10.6.40.32:6443
I1227 23:32:24.114348       1 graceful_termination.go:160] Trying to delete rs: 10.96.0.1:443/TCP/10.6.40.33:6443
I1227 23:32:24.114397       1 graceful_termination.go:160] Trying to delete rs: 10.6.40.25:32444/TCP/10.244.20.41:32444
E1227 23:32:24.114446       1 graceful_termination.go:183] Try flush graceful termination list err
I1227 23:33:24.114853       1 graceful_termination.go:160] Trying to delete rs: 10.96.0.1:443/TCP/10.6.40.32:6443
E1227 23:33:24.115043       1 graceful_termination.go:89] Try delete rs "10.96.0.1:443/TCP/10.6.40.32:6443" err: Failed to delete rs "10.96.0.1:443/TCP/10.6.40.32:6443", can't find the real server
I1227 23:33:24.115106       1 graceful_termination.go:93] lw: remote out of the list: 10.96.0.1:443/TCP/10.6.40.32:6443
I1227 23:33:24.115128       1 graceful_termination.go:160] Trying to delete rs: 10.96.0.1:443/TCP/10.6.40.33:6443

@VincentFF : ada dua masalah:

• penghapusan gagal: diperbaiki di 1.12.4
• kube-proxy macet karena kebuntuan (yang merupakan masalah yang Anda gambarkan): semoga diperbaiki dengan PR kemarin. Kami menunggu umpan balik dari @emptywee dan @bjornryden yang saat ini sedang menguji tambalan. Segera setelah kami mendapat konfirmasi bahwa masalah sudah tidak ada lagi, saya akan membuat cherrypicks untuk 1.13, 1.12 dan 1.11 (jika tambalan berfungsi, mungkin akan digabungkan di semua cabang pada awal minggu depan dan akan menjadi bagian dari rilis patch berikutnya)

Saya juga menjalankan kembali eksperimen saya https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 lagi, dengan patch yang di-porting kembali ke 1.12.4. Akan melaporkan kembali!

Kami tidak memiliki masalah apa pun dengan mengakses layanan saat kube-proxy berjalan dalam mode IPVS dan kami memiliki cukup banyak penerapan dan perubahan pada layanan. Sejauh ini menurut saya tambalan berfungsi dengan baik untuk kami.

@lbernail Kerja bagus untuk memperbaikinya! Sangat dihargai!

Ok mari kita tunggu sampai hari Senin jadi kita juga mendapat umpan balik dari @matthiasr dan @bjornryden (saya ingin menghindari terburu-buru memilih ceri dan memastikan bahwa kita memiliki perbaikan yang bersih kali ini)

@lbernail Kabar baik, terima kasih atas balasan Anda.

Tidak ada masalah setelah 12+ jam di 1.12.4 dengan https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f - tanpa itu saya mendapatkan lockup dalam 1,5 jam, jadi ini terlihat sangat bagus!

@ lbernail Saya punya pertanyaan lain. Jika patch berikutnya adalah versi 1.12.5?
Jika saya hanya memutakhirkan kube-proxy ke 1.12.5, unit lain （apiserver, kubelet, controller-manager, scheduler ...) simpan 1.12.3, apakah oke? Atau saya harus meningkatkan semua unit?

@VincentFF Semoga berhasil mencapai 1.12.5 ya. Anda dapat menjalankan kube-proxy 1.12.5 dengan unit lain yang menjalankan 1.12.3, tidak masalah

Pembaruan: setelah 24 jam, masih tidak ada masalah, saya menghentikan eksperimen saya sekarang & menganggap ini sukses penuh. Menantikan 1.12.5!

Oke, ini kabar baik. Saya akan membuat pilihan ceri untuk semua cabang untuk mendapatkan perbaikan dalam rilis resmi sesegera mungkin.
Terima kasih banyak atas keterlibatan Anda dalam membantu memecahkan masalah dan pengujian!

Petik ceri:
1.13 : https://github.com/kubernetes/kubernetes/pull/72426
1.12 : https://github.com/kubernetes/kubernetes/pull/72429
1.11 : https://github.com/kubernetes/kubernetes/pull/72430

Saya bisa bergabung dengan paduan suara penguji yang bahagia. 4 hari tidak ada masalah yang terjadi.

Terima kasih banyak untuk semua yang terlibat, terutama @lbernail. Selamat Tahun Baru!

Saya membangunnya dan menerapkannya untuk menguji env, lebih dari 24 jam tidak ada masalah. Selamat Tahun Baru.

Halo, Env saya
Ubuntu 16.04.4 LTS
Versi Kubernetes (gunakan versi kubectl): v1.13.0
Penyedia cloud atau konfigurasi perangkat keras: bare metal, 64 bit linux
Kernel 4.4.0-75-generik

bug yang sama:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Mencoba menghapus rs: 10.200.198.70:9090/TCP/172.200.101.32:9090
E0101 22: 20: 09.742975 267576 proxier.go: 1519] Gagal mendapatkan layanan IPVS, error: Diharapkan hanya satu layanan yang diperoleh = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] Gagal menyinkronkan titik akhir untuk layanan: 10.200.36.192:80/TCP, err: Diharapkan hanya satu layanan yang diperoleh = 0

Saya perlu restart kube-proxy memperbaikinya

@daigong v1.13.1 telah memperbaikinya. Dalam kasus saya, tidak ada masalah setelah lebih dari satu minggu.

@daigong : perbaikan penuh sebenarnya akan berada di 1.13.2 (tergantung seberapa cepat # 72426 digabungkan)

@lbernail @FrostyLeaf
terima kasih, saya menggunakan # 72426 untuk menguji bug ini

Semuanya baik-baik saja sekarang

PR telah digabungkan di semua cabang rilis, jadi akan ada di:

• 1.11.7
• 1.12.5
• 1.13.2

@nnnnnnnnnn

masalah yang sama, baik 1.12.2 dan 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Berapa kotak surat Anda, kenali itu. .remaja

sama

ada peluang untuk membangun baru di v1.11.x?

Saya telah menyegarkan halaman rilis hampir setiap jam selama beberapa hari terakhir dengan harapan 1.12.5 akan muncul sehingga saya dapat menambal bug ini di beberapa cluster. :-)

@verwilst haha, sama, tidak sabar menunggu v1.11.7 dirilis untuk memutakhirkan kluster prod saat ini. Dan v1.12.5 juga untuk mulai meningkatkan di lingkungan yang lebih rendah.

Saya telah menyegarkan halaman rilis hampir setiap jam selama beberapa hari terakhir dengan harapan 1.12.5 akan muncul sehingga saya dapat menambal bug ini di beberapa cluster. :-)

Di sini :-P

Saya telah menyegarkan halaman rilis hampir setiap jam selama beberapa hari terakhir dengan harapan 1.12.5 akan muncul sehingga saya dapat menambal bug ini di beberapa cluster. :-)

Di sini :-P

Mengapa tidak ada untuk 1,11? :(

Apakah bug ini diperbaiki di 1.11.7? Saya tidak melihat catatan rilis apa pun.

Ya, https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#v1117 :

Fix race condition introduced by graceful termination which can lead to a deadlock in kube-proxy (#72361, @lbernail)

Ya saya lupa menambahkan "IPVS" di release-note di PR, maaf ya
Beri tahu kami jika berfungsi dengan baik sekarang! (kami akan membiarkan masalah terbuka selama beberapa minggu untuk berjaga-jaga)

Kami tidak mengalami masalah sejak meningkatkan ke 1.12.5 🎉

Kabar baik!

@ m1093782566 , @thockin Saya rasa kami dapat menutup masalah ini (tidak ada laporan baru dalam waktu sekitar 2 bulan)

Sebagai referensi, bug memengaruhi rilis awal dengan penghentian yang lancar:

• 1.11.5 - 1.11.6
• 1.12.2 - 1.12.4
• 1.13.0 - 1.13.1

Perbaikan ada setelah:

• 1.11.7
• 1.12.5
• 1.13.2

/Menutup

@ m1093782566 : Menutup masalah ini.

Bisakah kita buka kembali? Kami melihat masalah ini di 1.12.7.

ya, kami juga melihat masalah di 1.12.9

Apakah Anda yakin ini masalah yang sama?
Dapatkah Anda memposting log dari instance kube-proxy?

maaf, ini mungkin peringatan palsu ... Kami melihat ini adalah log dan ini bukan kesalahan yang sama

I0709 11:59:48.640888       1 graceful_termination.go:160] Trying to delete rs: 192.168.240.51:80/TCP/172.30.71.181:5050
I0709 11:59:48.640304       1 graceful_termination.go:93] lw: remote out of the list: 192.168.240.51:80/TCP/172.30.106.125:5050

karena alasan tertentu, saat cluster sedang dimuat, cluster tidak dapat merutekan ke beberapa IP layanan cluster. Kami masih belum yakin apakah ini masalah IPVS.

Mungkin propagasi titik akhir membutuhkan waktu jika apiserver kelebihan beban?

Pesannya adalah pesan tingkat Info normal:
https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/graceful_termination.go#L94

https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/graceful_termination.go#L161

Saya dapat mengonfirmasi log yang sama di 1.14.4. Kapan log ini keluar?

I0712 01:34:49.925012       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.22.42:443
I0712 01:34:49.925057       1 graceful_termination.go:175] Deleting rs: 11.3.0.1:443/TCP/10.0.22.42:443
I0712 01:35:11.907742       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.10:53/TCP/11.2.5.13:53
I0712 01:35:11.907874       1 graceful_termination.go:175] Deleting rs: 11.3.0.10:53/TCP/11.2.5.13:53
I0712 01:35:11.908006       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.10:53/UDP/11.2.5.13:53
I0712 01:35:11.908059       1 graceful_termination.go:175] Deleting rs: 11.3.0.10:53/UDP/11.2.5.13:53
I0712 01:35:21.992487       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.10:53/TCP/11.2.4.11:53
I0712 01:35:21.992594       1 graceful_termination.go:175] Deleting rs: 11.3.0.10:53/TCP/11.2.4.11:53
I0712 01:35:21.992784       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.10:53/UDP/11.2.4.11:53
I0712 01:35:21.992858       1 graceful_termination.go:175] Deleting rs: 11.3.0.10:53/UDP/11.2.4.11:53
I0712 01:36:29.411592       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.199:44134/TCP/11.2.0.5:44134
I0712 01:36:29.411660       1 graceful_termination.go:175] Deleting rs: 11.3.0.199:44134/TCP/11.2.0.5:44134
I0712 01:36:29.534158       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.17:8085/TCP/11.2.0.3:8085
I0712 01:36:29.534394       1 graceful_termination.go:175] Deleting rs: 11.3.0.17:8085/TCP/11.2.0.3:8085
I0712 01:36:50.745469       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:36:50.745508       1 graceful_termination.go:172] Not deleting, RS 11.3.0.1:443/TCP/10.0.22.162:443: 0 ActiveConn, 12 InactiveConn
I0712 01:37:37.475724       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:37:37.475841       1 graceful_termination.go:172] Not deleting, RS 11.3.0.1:443/TCP/10.0.22.162:443: 0 ActiveConn, 4 InactiveConn
I0712 01:38:37.475956       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:38:37.476201       1 graceful_termination.go:172] Not deleting, RS 11.3.0.1:443/TCP/10.0.22.162:443: 0 ActiveConn, 4 InactiveConn
I0712 01:39:37.476324       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:39:37.476585       1 graceful_termination.go:175] Deleting rs: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:39:37.476628       1 graceful_termination.go:94] lw: remote out of the list: 11.3.0.1:443/TCP/10.0.22.162:443
I0712 01:40:36.883345       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.245:5473/TCP/10.0.22.25:5473
I0712 01:40:36.883566       1 graceful_termination.go:175] Deleting rs: 11.3.0.245:5473/TCP/10.0.22.25:5473
I0712 01:40:36.886079       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.17:8085/TCP/11.2.1.3:8085
I0712 01:40:36.886310       1 graceful_termination.go:175] Deleting rs: 11.3.0.17:8085/TCP/11.2.1.3:8085
I0712 01:40:46.927450       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.245:5473/TCP/10.0.22.191:5473
I0712 01:40:46.927525       1 graceful_termination.go:175] Deleting rs: 11.3.0.245:5473/TCP/10.0.22.191:5473
I0712 01:40:56.968884       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.245:5473/TCP/10.0.22.75:5473
I0712 01:40:56.968936       1 graceful_termination.go:175] Deleting rs: 11.3.0.245:5473/TCP/10.0.22.75:5473
I0712 01:41:16.747362       1 graceful_termination.go:161] Trying to delete rs: 11.3.0.1:443/TCP/10.0.23.45:443

Ini hanya log informasi:

• Trying to delete rs : pod backend dari dihapus, mencoba untuk menghapusnya. Jika memiliki koneksi yang ada, buat itu memasuki penghentian anggun, jika tidak hapus id
• Deleting rs : backend tidak memiliki koneksi, menghapusnya dari IPVS

@andrewsykim Mungkin sekarang kita bisa menurunkan level log ini sehingga mereka hanya ditampilkan di atas v = 5 misalnya?

Di https://github.com/kubernetes/kubernetes/pull/78395 kami menaikkan level log dari v = 0 ke v = 2, menurut saya v = 5 masuk akal. https://github.com/kubernetes/kubernetes/pull/80100 untuk pembaruan