Kubernetes: Der kube-proxy ipvs-Modus hängt nach einigen Stunden und muss manuell neu gestartet werden

/ sig Netzwerk

der gleiche Fehler. Upgrade von 1.11.1. Alles wird gut, außer dass kube-proxy nicht stabil wird. Manchmal kann pod nicht auf svc zugreifen, obwohl ihre Endpunkte in Ordnung sind. Und das gleiche wie die Namensauflösung. Ich denke also, dass es hier einen wichtigen Fehler geben kann.

/ area ipvs

@gjcarneiro lösen Sie dieses Problem?

Nun, ich habe den Cluster wieder in den Standardmodus (iptables) geschaltet, scheint seitdem ziemlich stabil zu sein ...

@ kubernetes / sig-network-bugs

@berlinsaint : Wiederholen Sie die Erwähnungen, um eine Benachrichtigung auszulösen:
@ kubernetes / sig-network-bugs

das gleiche Problem, sowohl 1.12.2 als auch 1.13.0-beta1. @ m1093782566 @ Lion-Wei

@gjcarneiro meinst du, dass es in Kernel 4.15 das gleiche Problem hat?

@annProg

das gleiche Problem, sowohl 1.12.2 als auch 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Wie viel kostet Ihre Mailbox, lernen Sie sie kennen. .jugendlich

@annProg

das gleiche Problem, sowohl 1.12.2 als auch 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Wie viel kostet Ihre Mailbox, lernen Sie sie kennen. .jugendlich

Klicken Sie auf meinen Avatar, um zu sehen

Ich sehe dies auch wiederholt in meinem zentralen Protokollierungssystem:

  | 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

Ich verwende v1.12.3 (Neuinstallation, kein Upgrade).

Hallo zusammen. Vielen Dank für den Bericht, ich werde eine Recherche durchführen und versuchen herauszufinden, was passiert ist und welche Fortschritte ich hier melden werde.

Abgesehen von dem, was passiert ist, was gut herauszufinden ist, bin ich nicht sicher, was IPVS betrifft, bis ein Code vorhanden ist, der einen defekten Netlink-Socket erkennt und zurücksetzt. Denn was ich aus den Protokollen und Traces erraten kann, ist, dass der Netlink-Socket in einen defekten Zustand gerät und die Aufgabe, die von / in ihn liest / schreibt, für immer hängen bleibt. Ich denke, kube-proxy muss über Code verfügen, der dieses Problem erkennt. Wenn dies passiert, erstellen Sie einen neuen Netlink-Socket von Grund auf neu und starten Sie möglicherweise die Aufgabe neu, die das Problem behandelt. Aber nein, ich melde mich nicht freiwillig, ich weiß nicht einmal Go, sorry.

Denn was ich aus den Protokollen und Traces erraten kann, ist, dass der Netlink-Socket in einen defekten Zustand gerät und die Aufgabe, die von / in ihn liest / schreibt, für immer hängen bleibt.

Wir haben vor einigen Tagen die go netlink-Version aktualisiert, um eine ordnungsgemäße Beendigung zu unterstützen. Die Netlink-Bibliothek lief zuvor ziemlich stabil. Ich bin mir nicht sicher, ob es die Ursache ist.

1.12.3 mit dem gleichen Fehler.
Nach dem Filtern des INFO-Protokolls
Führen Sie 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;
und das gesamte Proxy-Knoten-Protokoll ist

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

Übrigens. Von oben in meinen Protokollen scheint kube-proxy immer noch viele Probleme mit iptables-restore zu haben. Alle meine Knoten sind UBUNTU 16.04 mit der Version 1.6.0 von iptable.
@ m1093782566 @ Lion-Wei

Wir sehen dies beim Upgrade von 1.12.1. es muss also im Delta von 1.12.1 und 1.12.2 liegen.

Das Problem hängt mit der ordnungsgemäßen Beendigung zusammen und ich denke, wir haben den Fehler in Version 1.13.1 behoben.

@ m1093782566 Wird der Fix auf die 1.12-Zeile

Das gleiche gilt für das Upgrade von 1.11.2 auf 1.11.5.

@ m1093782566 Können Sie weitere Informationen zum Fix bereitstellen? Es würde mich interessieren, über das Commit zu schauen.

Das ist ziemlich verrückt, wir wurden heute früher richtig hart gebissen.

Wir sehen dies beim Upgrade von 1.12.1. es muss also im Delta von 1.12.1 und 1.12.2 liegen.

Das gleiche gilt für das Upgrade von 1.11.2 auf 1.11.5.

Wurde der Käfer ausgewählt?

Dies sieht aus wie die PR, die das Problem behebt: https://github.com/kubernetes/kubernetes/pull/71515

True @ Quentin-M

Ja, dies ist wahrscheinlich auf das Update in der Funktion delete (das nicht wirklich mit dem Titel der PR zusammenhängt).

@ m1093782566 Ich kann den Cherry-Pick für 1.12 erstellen. Wollen wir die vollständige PR oder nur den Fix in der Löschfunktion zurückportieren? (um zu vermeiden, dass sich das Verhalten bei UDP-Flows in 1.12 ändert)

Wurde der Käfer ausgewählt?

@ Quentin-M Es sieht so aus, als ob der Fehler von https://github.com/kubernetes/kubernetes/pull/66012 eingeführt wurde, der in den Versionen 1.11.5 und 1.12.2 ausgewählt wurde:
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 -änderungen-1

Ich denke, alle # 71515 sollten von Kirschen gepflückt werden. Insgesamt wurde eine anmutige Kündigung nur mit # 66012 eingeführt und ausgewählt, sodass die Verhaltensänderung bereits stattgefunden hat.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 in unseren Clustern immer noch abgestanden. 60% von ihnen steckten in weniger als 24 Stunden fest. Versuchen Sie jetzt 1.12.1.

@ Quentin-M: Können Sie die Protokolle auf kube-proxy überprüfen und bestätigen, dass diese Nachrichtentypen nicht mehr vorhanden sind:

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

Beide beziehen sich auf die in der PR festgelegte Löschfunktion. Wenn diese nicht mehr vorhanden sind und das Problem weiterhin auftritt, reicht dieses Update nicht aus

Wenn alles mit 1.12.1 funktioniert, besteht eine hohe Wahrscheinlichkeit, dass das Problem durch eine ordnungsgemäße Beendigung verursacht wird (# 66012).

Ich glaube, ich habe eine Idee: Ich frage mich, was passiert, wenn wir versuchen, einen echten Server hinzuzufügen, der sich noch in ordnungsgemäßer Beendigung befindet. In diesem Fall sollten wir das Gewicht einfach auf 1 erhöhen und es aus der Liste der ordnungsgemäßen Abbrüche entfernen.

Ich werde versuchen, dieses Szenario so schnell wie möglich zu testen (aber es wird schwierig, weil ich nächste Woche bei Kubecon bin).

@ Lion-Wei was denkst du?

Ok, kratz das, ich habe es gerade getestet und es funktioniert gut. Der dafür verantwortliche Code ist hier: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

In diesem Fall wird der RS ​​aus der Liste gracefulDelete und aus dem IPVS-RS entfernt. Ich frage mich, ob es möglicherweise nicht besser ist, das Gewicht auf 1 zurückzusetzen

Ich werde andere Dinge ausprobieren, die auf diesem Teil der Protokolle basieren, was darauf hindeutet, dass versucht wird, Endpunkte für einen gelöschten Dienst zu synchronisieren

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

Ok, nach einer kurzen Überprüfung befindet sich das Commit, das das Löschproblem behebt, weder in v1.13.1-beta.0 noch in v1.14.0-alpha.0 das am 7. November gekürzt wurde
Ich denke, es wird in der nächsten Alpha-Version 1.14 sein, die auf Master basiert

Ich werde den Kirschpickel auch für 1.13 erstellen

Ich habe ein Problem mit dem Upgrade von 1.12.0 auf 1.13.0, scheint mit diesem verbunden zu sein, ist aber nicht dasselbe.

Wir können das Problem nicht beheben, indem wir auf iptables zurückgreifen. Bitte hilf mir.

Ich habe es auf stackoverflow gepostet

Habe das gleiche am 1.11.5. Temporär von IPvs zu Iptables zurückgesetzt.

Gleiches gilt für 1.11.5. Aufgrund der darin enthaltenen Sicherheitsanfälligkeit kann kein Rollback auf 1.11.4 durchgeführt werden. Musste zu iptables wechseln. Wird das Update für 1.11.x veröffentlicht?

Sie können kube-proxy sehr spezifisch zurücksetzen, ohne von der Sicherheitsanfälligkeit betroffen zu sein.

@ Quentin-M Ja, dieser Gedanke ist mir in den Sinn gekommen, aber andererseits hätte ich, wenn ich es getan hätte, keine würdevolle Kündigung, die alle zusammen mit iptables da war. Ich bin mir nicht sicher, ob unsere Kunden die Änderung möchten.

@ Quentin-M bedeutet das, dass es für 1.11.x keine Lösung gibt, um diesen Fehler zu beheben?

@emptywee Ich habe einen Cherry-Pick für 1.11 erstellt: https://github.com/kubernetes/kubernetes/pull/71848
Hoffentlich wird es sehr bald zusammengeführt und in 1.11.6

Es wurde bereits in 1.12 (wird in 1.12.4 ) und 1.13 (wird in 1.13.1 ) zusammengeführt.

Der Kirschpickel wurde auch gerade in 1.11 zusammengeführt
Wir müssen nur auf die nächsten Patch-Releases in den 3 Zweigen warten (aber wenn Sie es testen möchten, bevor ich einfach einen benutzerdefinierten Kube-Proxy-Build erstellen kann (oder, noch einfacher, ein Hyperkube-Docker-Image mit dem Patch)

Vielen Dank @lbernail ! Ein öffentlich verfügbares Docker-Bild wäre schön zu haben! Ich würde es gerne testen!

Das Update wurde bereits in Version 1.11, Version 1.12 und Version 1.13 ausgewählt.

Würden Sie sie bitte testen, damit wir dieses Problem schließen können?

@ m1093782566 Ich

Danke @berlinsaint , bitte lassen Sie mich das Testergebnis.

Wann wird die Community die kleine Veröffentlichung dafür veröffentlichen?

Die neue kleine Version mit dem Fix wird in weniger als 2 Wochen veröffentlicht.

@emptywee : lbernail/hyperkube:v1.12.4-beta.1
Lassen Sie uns wissen, wie es bei Ihnen funktioniert!

@lbernail ist es in Ordnung, es mit allem anderen in Version 1.11.5 zu verwenden? Oder sollte ich meinen Kubernetes-Cluster zuerst auf Version 1.12.4 erhöhen? Trotzdem vielen Dank!

@emptywee ja, es sollte ohne Probleme funktionieren (ich habe kube-proxy 1.11 auf 1.10-Clustern seit Monaten ausgeführt)

Ich kann heute später auch einen 1.11 Build erstellen

@lbernail ja, wäre schön, ein Bild aus der gleichen Release-Version zu haben.

@emptywee los geht's: lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail Nach einer Nachtbeobachtung wird das IPvs-Synchronisierungsfehlerprotokoll nicht mehr angezeigt
es tritt mindestens einmal eine Nacht zuvor auf. Aber ich brauche noch mehr Zeit, um es zu überprüfen. Vielen Dank, es hat mich lange geärgert.

Ich werde morgen am 1.11 mit dem Testen beginnen und es auch ein paar Tage geben.

@lbernail Ich habe es versucht lbernail/hyperkube:v1.11.6-beta.1 (Danke dafür!)
Wir dachten sofort, dass die Dinge behoben waren, als wir die can't find the real server Protokollnachrichten nicht mehr sahen. Nach anderthalb Tagen treten jedoch Probleme mit veralteten IPvs-Einträgen auf 3/6 Clusterknoten auf.
Dies sind die IPvs-Einträge für einen Dienst auf einem defekten Clusterknoten.
Vor dem Neustart von 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

Nach dem Neustart von 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 Das war der Grund, warum ich in diesen Thread geraten bin, als ich am 1.11.5 zu IPVS gewechselt bin. Am nächsten Tag fand ich Dienste nicht zugänglich, daher dachte ich, dass der kube-Proxy hängen geblieben war und die Einträge für Dienste nicht aktualisieren würde.
Das soll Sie nur wissen lassen, dass ich ein ähnliches Problem (falsche IPs in der IPvs-Tabelle) mit v1.11.5 von kube-proxy hatte.

@bjornryden Gute Nachrichten für die

Die Tatsache, dass Backends nicht ordnungsgemäß aktualisiert werden, ist seltsam, da eine ordnungsgemäße Beendigung keine Auswirkungen auf neue Endpunkte haben sollte (wenn beispielsweise einige veraltete Endpunkte noch vorhanden wären, wäre ich weniger überrascht).

Könnten Sie die Protokolle von kube-proxy für den Dienst 10.230.65.211:9494 freigeben?

Auch ein besonderes Verhalten mit diesem Service / Bereitstellung? (Werden Pods beispielsweise sehr häufig aktualisiert oder stehen sie hinter einer HPA?)

Es läuft also seit 2 Tagen in meinem Laborcluster mit dem Image 1.11.6-beta.1 von @lbernail im IPvs-Modus.
So weit so gut, es hat nicht gehangen und aktualisiert ständig IPvs-Einträge.

Eine seltsame Beobachtung:

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         

Der erste Aufruf von ipvsadm zeigt den Anfangszustand an, bevor ich einen der Pods für den Dienst gelöscht habe. Nur wenige zeigen, dass ein Eintrag weg ist, da der Pod gelöscht wurde. Ich weiß jedoch nicht, ob es so sein soll, aber es wurde ein zweiter Eintrag mit derselben IP-Adresse wie der Pod erstellt, der noch übrig war. Und dann wurde es auf die richtige IP des neuen Pods aktualisiert, der den gelöschten Pod ersetzte.

Davon abgesehen war es okay. Aber der Laborcluster ist nicht so beschäftigt wie die anderen. Der Kommentar von @bjornryden hat mich ein wenig beunruhigt, das Bild in geschäftigeren Clustern zu

@emptywee Ich 10.158.130.24 . Ich verstehe das nicht:

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 

Es macht keinen Sinn, zweimal denselben realen Server zu haben. Kannst du es reproduzieren?

Das normale Verhalten beim Löschen von Pods sollte sein:

• Wenn keine Verbindung zu diesem Pod besteht, entfernen Sie den RS
• Wenn Verbindungen bestehen, setzen Sie das Gewicht auf 0 (hergestellte Verbindungen werden fortgesetzt, keine neuen Verbindungen).
• Überprüfen Sie jede Minute alle RS mit dem Gewicht 0 (dafür ist die Liste der ordnungsgemäßen Kündigungen vorgesehen) und entfernen Sie diejenigen, die keine Verbindungen mehr haben

@lbernail richtig. Der gelöschte Pod hatte diese IP-Adresse. Und ja, es sah für mich auch seltsam aus. Ich werde versuchen, mich zu reproduzieren, wenn ich eine Chance bekomme. Möchten Sie, dass ich die Ausführlichkeit des Protokolls erhöhe, wenn ich das gleiche Verhalten reproduzieren kann? Wenn ja, bis zu welchem ​​Niveau?

@emptywee : Es wäre großartig, danke, --v=5 sollte uns viele Informationen geben
Die Hauptsache ist, ich glaube nicht einmal, dass ein RS zweimal in einem VS in IPVS erscheinen kann (das habe ich nie gesehen). Welchen Kernel laufen Sie?

@lbernail wird es auf --v = 5 setzen und versuchen zu reproduzieren, wahrscheinlich einige Zeit über das Wochenende.

Ich bin auf CoreOS stabil:

4.14 ist sehr neu, daher wäre ich überrascht, wenn es ein IPVS-Problem gäbe
Ich werde versuchen, einen Cluster mit der gepatchten Version zu betonen, um zu sehen, ob ich das Problem von @bjornryden reproduzieren kann

@lbernail Leider konnte ich das Duplizierungsverhalten von IPvs-Einträgen, das ich nur einmal gesehen habe, nicht reproduzieren. Mehrfach versucht, mit verschiedenen Diensten. Ich habe jedoch keinen Eintrag mit dem Gewicht 0 gesehen, aber dies könnte durch die Tatsache erklärt werden, dass die von mir gelöschten Pods sehr schnell beendet werden. Außerdem reagiert kube-proxy nach mehr als 5 Tagen. Ich könnte es noch einmal versuchen, da hier mehr los ist.

@emptywee Dies sind "gute" Nachrichten (auch wenn ich lieber hätte, dass wir sie reproduzieren und verstehen könnten, war es vielleicht ein Anzeigefehler in ipvsadm?)

Das Gewicht wird nur auf 0 gesetzt, wenn es sich um ActiveConn oder InActiveConn handelt. Um dies zu sehen, öffnen Sie einfach eine langlebige Verbindung zu einem Dienst, bevor Sie den zugehörigen Pod löschen (z. B. über Telnet).

5 Tage Stabilität sind gute Nachrichten! Lassen Sie uns wissen, wie es geht, wenn Sie einen geschäftigeren Cluster anprobieren

Ich habe ein paar kleine Verbesserungen auf dem Weg:

• https://github.com/kubernetes/kubernetes/pull/71834 : Sorgen Sie dafür, dass die ordnungsgemäße Beendigung mit Diensten mithilfe von sessionAffinity funktioniert (bereits in master, Cherry Picks erstellt für 1.13, 1.12 und 1.11).
• https://github.com/kubernetes/kubernetes/pull/71895 und https://github.com/kubernetes/kubernetes/pull/72106 : Unterstützen Sie die ordnungsgemäße Beendigung beim Löschen eines Dienstes (der erste ist bereits im Master, ich bin Warten auf den zweiten, der beide in allen Zweigen pflückt)

Außerdem wurden 1.11.6 , 1.12.4 und 1.13.1 veröffentlicht und enthalten das Update in der Löschfunktion

Ich habe über das Wochenende einen kurzen Artikel über das Thema geschrieben. Ich werde sicherstellen, dass es mit der festen Version aktualisiert wird!

@lbernail Sicher, wird reichen! Ist Ihr Bild von Hyperkube dasselbe wie das, das als 1.11.6 veröffentlicht wurde? Ich habe Ihr Image für kube-proxy nur in dem stärker ausgelasteten Cluster installiert und zum Testen erneut auf ipvs umgestellt. Möchten Sie, dass ich die offizielle verwende?

@emptywee Mein Image und das 1.11.6 sind im Grunde dasselbe: Ich habe es einige Tage vor der offiziellen Veröffentlichung aus dem Leiter des Release-1.11-Zweigs erstellt, sodass der Unterschied höchstens ein paar Commits beträgt, von denen keines IPVS betrifft. Ich denke also nicht, dass es sich lohnt, Ihren Cluster erneut zu aktualisieren

Schlechte Nachrichten :( Ich habe gerade festgestellt, dass mein kube-Proxy die IPvs-Backends nicht aktualisieren konnte. Zurück zu iptables wechseln und Protokolle sammeln. Der kube-Proxy wurde mit dem Flag --v=5 .

@lbernail Ich bin mir nicht sicher, wie viele Protokolle benötigt werden, aber wir haben im Grunde ein Problem mit einigen Diensten festgestellt, bei denen die IPvs-Backend-IPs nicht aktualisiert wurden. Aus den Protokollen geht jedoch hervor, dass die Endpunkte ordnungsgemäß aktualisiert wurden:

$ 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]

Aber als ich es mit ipvsadm überprüfte, wurden immer noch die ersten beiden angezeigt: 10.148.191.69:8080 10.148.192.14:8080

Während kubectl -n c-qa4 describe svc ycsdtleuk sagte, dass die Endpunkte 10.148.183.70:8080 10.148.184.67:8080 , und auf anderen Feldern wurden IPvs-Einträge für denselben Dienst ordnungsgemäß aktualisiert.

$ 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>

Grundsätzlich habe ich mir auf zwei Kisten gleichzeitig Folgendes angesehen:

(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

Es gibt keine offensichtlichen Fehlermeldungen oder Schreie, die auf Anzeichen eines Problems hinweisen. Ich kann die vollständige Protokolldatei (18 Millionen unkomprimiert) direkt an Sie senden, wenn Sie möchten.

Lange Rede, kurzer Sinn: Es fühlt sich so an, als ob der Teil, der Änderungen an Diensten abhört, gut funktioniert, der Teil, der mit dem IPvs-Modul interagiert, jedoch nicht. Ich sehe nicht einmal, dass versucht wurde, die ersten beiden IP-Adressen zu löschen, nachdem sie hinzugefügt wurden. Irgendwo bleibt etwas stecken.

@emptywee Vielen Dank für den ausführlichen Bericht. Nichts Seltsames in diesen Protokollen.

Was überrascht, ist, dass syncProxyRules mindestens alle 30 Sekunden ausgeführt wird (Standard) und echte IPVS-Server mit Endpunkten abgleichen sollte. Es ruft syncEndpoints was AddRealServer und ipvsHandle.NewDestination auslöst

All dies geschieht vor dem Löschen alter Endpunkte und sollte daher nicht durch eine ordnungsgemäße Beendigung beeinträchtigt werden

Könnten Sie mir die vollständigen Protokolle senden, damit ich genau sehen kann, was zwischen 21:26 und 21:29 passiert?

Zwei zusätzliche Fragen:

• ein einzelner kube-proxy war betroffen, oder?
• war ein einzelner Dienst betroffen (wurde der andere weiterhin normal aktualisiert?)

Versuchen Sie beim nächsten Mal, SIGABRT an den Prozess zu senden, damit Aufgabenstatus gedruckt werden.

Wenn ich das Problem hatte, tat es immer etwas in libnetwork/ipvs/netlink.go , was mich vermuten lässt, dass der Netlink-Systemaufruf aus irgendeinem Grund hängen bleibt.

Tut mir leid wegen meiner Abwesenheit, aber am Wochenende und musste mich dann darauf konzentrieren, für unser Setup auf iptables zurückzugreifen.

Wenn wir auf die angeforderten Protokolle für den Dienst @lbernail zurückblicken , haben wir viele davon:

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
...

Wir haben auch diese gesehen:

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

Genau wie andere berichtet haben, geschah dies nur auf einigen Knoten. Als ich das Problem fand, hatten wir 3 Clusterknoten, die für diesen bestimmten Dienst defekt waren.

@lbernail Auf jeden Fall . Hier ist das angeforderte Teil der Protokolle. Ich habe auch das Startteil hinzugefügt: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Lassen Sie mich wissen, wenn Sie die gesamte Datei benötigen. Wenn ja, wohin soll ich es senden oder hochladen?

So beantworten Sie Ihre Fragen:

1. Der Cluster hat mehr als 60 Knoten. Ich habe einige andere Knoten überprüft. Der IPVS-Eintrag war korrekt. Ich bin mir jedoch nicht sicher über alle Einträge. Auf dem Masterknoten, über den wir den gesamten Datenverkehr an Dienste weiterleiten, wurden jedoch mindestens zwei Dienste nicht ordnungsgemäß aktualisiert. Es könnte noch mehr geben, aber als wir anfingen, Beschwerden von Kunden zu erhalten, hörten wir sofort, dass zwei Dienste nicht zugänglich waren. Ich habe Protokolle gesammelt und kube-proxy neu gestartet, um die Auswirkungen zu minimieren. Ich habe den Status der IPvs-Einträge auf diesem Masterknoten und einem der Worker-Knoten im Rahmen der Fehlerbehebung verglichen und festgestellt, dass dies anders ist. Es besteht die Möglichkeit, dass andere Knoten andere Einträge haben, die nicht ordnungsgemäß aktualisiert wurden. Da der Datenverkehr jedoch nicht über sie erfolgt, haben wir keine Auswirkungen festgestellt.

2. Nein, mindestens zwei Dienste waren betroffen. Möglicherweise mehr, aber das habe ich nicht überprüft.

Zwei interessante Dinge aus den Protokollen:

• 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] wird nie von IPVS verarbeitet, aber kein Fehler, da Sie die beiden alten RS behalten (wir können nicht sicher sein, dass das Hinzufügen eines RS kein Protokoll generiert).
• 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] löst nicht den Löschaufruf für 10.148.192.14:8080 (wir sollten dort Protokolle haben)

@emptywee hat IPVS vor der

@ m1093782566 / @ Lion-Wei eine Idee, was hier los sein könnte?

@lbernail Wir haben gewartet, bis wir auf 1.11 aktualisiert haben, um auf IPvs umzusteigen (ich glaube, es war der Zeitpunkt, an dem die GA-Version für diese Funktion veröffentlicht wurde). Wir haben direkt auf 1.11.5 aktualisiert und es war unser erster Versuch, IPvs zu verwenden.

@emptywee : Ich werde einige weitere Protokolle auf Info-Ebene hinzufügen, um das Problem zu lokalisieren. Wäre es in Ordnung, ein paar Stunden lang eine ausführlichere Version auszuführen? (Ich verstehe vollkommen, wenn Sie es lieber nicht möchten, aber ich konnte mich noch nicht auf meiner Seite reproduzieren.)

Wir verwenden IPVS seit Mai und hatten in 1.12.1 und 1.11.1 keine Probleme.

Wir haben dies auch auf mehreren, aber bei weitem nicht allen Knoten nach dem Upgrade auf 1.12.3 gesehen. Die betroffenen Knoten haben einige Stunden nach dem Upgrade die Aktualisierung von IPVS abgebrochen, jedoch nicht auf eine koordinierte Weise, die ich erkennen konnte.

Eine Sache, die zu beachten ist, ist, dass kube-proxy zu diesem Zeitpunkt auch die Protokollierung vollständig beendet hat, so dass es so aussieht, als ob es vollständig hängen geblieben ist.

Protokolldatei, die zeigt, dass sie hängen bleibt, und ein Goroutine-Dump nach SIGQUIT (leicht redigiert)

@matthiasr ‚s Protokolldatei zeigt wieder eine goroutine aus netlink Steckdose stecken zu lesen. Genau wie ich.

Sie könnten argumentieren, dass ein logischer Fehler vorliegt, der zu viele Interaktionen mit dem Netlink-Socket verursacht. Aber wenn die Kommunikation mit Netlink nicht solide ist, bleiben IPvs irgendwann hängen. Wenn der logische Fehler behoben wird, kann es viel länger dauern, bis dieser Status erreicht ist. Dies bedeutet jedoch nicht, dass er bei genügend Zeit nicht auftreten kann.

Aus diesem Grund würde ich empfehlen, bei Netlink-Interaktionen eine Art Zeitüberschreitung zu haben. Wenn der Vorgang abläuft, schließen Sie den Netlink-Socket und öffnen Sie automatisch einen neuen als Wiederherstellungsmechanismus.

@matthiasr OK, das sind gute Nachrichten (wir verwenden IPVS auch seit mehr als 6 Monaten ohne Probleme, haben jedoch noch keine Versionen auf Versionen aktualisiert, die eine ordnungsgemäße Beendigung in unseren am stärksten frequentierten Clustern verwenden.)

Sieht so aus, als hätten wir irgendwo einen Deadlock

@lbernail Während es etwas umständlich ist, den gesamten Cluster auf IPvs umzustellen, bin ich unten, wenn dies helfen wird, dieses Problem zu beheben. Sagen Sie mir den zu verwendenden Bildnamen und ich werde alles in meiner Macht stehende tun, um Ihnen dabei zu helfen.

Wir haben in 1.11.6 auf IPVS zurückgegriffen, um zu prüfen, ob wir unser Problem erneut erstellen können. Die Protokollierung wurde auf 5 gesetzt und in den nächsten Tagen werden einige Aktivitäten im Cluster ausgeführt. Ich werde morgen nicht arbeiten, aber ich werde online gehen, um zu sehen, ob es ein Bild mit erhöhter Protokollierung gibt, zu dem ich wechseln sollte.

@matthiasr : 1.12.3 definitiv ein Problem (siehe den Rest dieses Threads). Ein Teil davon wird in 1.12.4 gelöst. Sie erhalten viel weniger Fehler in den Protokollen. All dies sollte verschwinden: Failed to add destination: 10.zz.yy.xx, error: file exists

Wir haben immer noch das Problem, dass der Kube-Proxy zu hängen scheint und die Real-Server nicht mehr aktualisiert werden.
Ich habe es mir etwas genauer angesehen:

• Aus @emptywee geht hervor, dass nach dem Start des Problems keine Protokolle von proxier.go, ipset.go oder graceful_termination.go angezeigt werden, was darauf hindeutet, dass wir irgendwo festsitzen. @emptywee können Sie überprüfen, ob Sie nach 21:30 Protokolle für diese Dateien haben?
• Im Go-Routine-Dump werden zwei Systemaufrufe auf einem Netlink-Socket empfangen. Wir könnten dort also ein Problem haben. Darüber hinaus wurde libnetwork / ipvs zur Unterstützung einer ordnungsgemäßen Beendigung aktualisiert, sodass sich das Verhalten möglicherweise geändert hat. Der libnetwork-Code scheint jedoch Sende- / RCV-Zeitüberschreitungen für den Netlink-Socket festzulegen (und wenn er nicht funktioniert, sollte die Anzahl der Minuten angezeigt werden): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Interessanterweise hat nur die neue Version von libnetwork Netlink-Timeouts:

libnetwork wurde in allen Release-Zweigen (1.11, 1.12 und 1.13) aktualisiert, um eine ordnungsgemäße Beendigung zu ermöglichen. Wir gingen von: ba46b928444931e6865d8618dc03622cac79aa6f zu a9cd636e37898226332c439363e2ed0ea185ae92

In der älteren Version lautete der Code: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

Die einzigen Unterschiede im IPVS-Code in libnetwork zwischen diesen beiden Commits sind:

• Einführung des Timeouts
• Hinzufügen von ActiveConnections und InactiveConnections zu Destination (was für eine ordnungsgemäße Kündigung erforderlich war)

Ich frage mich, ob dies verwandt sein könnte.

Nachdem ich einige weitere Gedanken zu diesem Thema gemacht habe, denke ich, dass dies darauf zurückzuführen ist, dass wir jetzt zwei Goroutinen haben, die denselben Netlink-Socket verwenden (da der gracefulTerminationManager in einer eigenen Goroutine ausgeführt wird und die utilipvs.Interface mit dem Proxy teilt).

Wir könnten wahrscheinlich bei allen Aufrufen in pkg/util/ipvs/ipvs_linux.go einen Mutex hinzufügen, um sicherzustellen, dass eine einzelne Goroutine zu einem bestimmten Zeitpunkt den Netlink-Socket verwendet.

@ m1093782566 was denkst du?

@lbernail Nein, nach 21:30 gibt es nirgendwo Einträge aus diesen Dateien.
Hier sind die letzten Einträge für verschiedene Dateien:

Letzte Einträge von 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

Letzte Einträge von 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

Letzte Einträge von 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

Sie alle beendeten die Protokollierung gegen 21:18 Uhr ... Gibt es irgendwelche Hinweise?

@emptywee Ja, es bestätigt die Hypothese, dass zwischen den beiden Goroutinen, die sich den Netlink-Socket teilen, ein Deadlock besteht. Sie warten beide darauf, Nachrichten zu empfangen, und versuchen es erneut ohne Erfolg (aufgrund der Zeitüberschreitung beim Empfang der 3er).

Ich werde versuchen, die Hypothese zu validieren und so schnell wie möglich an einem Fix arbeiten

Ich habe 1.12.4 in einen Testcluster gestellt und mit der erneuten Bereitstellung einer App begonnen, die das Problem in 1,5 Stunden reproduzierte. Daher denke ich, dass ich eine potenzielle Lösung ziemlich zuverlässig testen kann.

Es hängen wieder 2 Goroutinen (1 und 107) an einem Netlink-Empfang.

Ich habe eine mögliche Lösung für den Fehler. Der Code ist hier verfügbar: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
Die Idee ist, alle Netlink-Anrufe mit einem Mutex zu schützen, um den Deadlock zu vermeiden. Ich bin nicht sicher, ob dies die beste Lösung ist, aber es könnte das Problem lösen (und wenn es funktioniert, bestätigen Sie, dass wir den Fehler identifiziert haben).

Wenn Sie es testen möchten / können, habe ich zwei Bilder mit dem Fix erstellt:

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

Wenn Sie testen, lassen Sie uns wissen, ob es funktioniert, und wenn dies nicht der Fall ist, teilen Sie bitte interessante Protokolle und sehen Sie sich die Goroutinen an, um festzustellen, ob einige in Netlink-Anrufen stecken bleiben.

(Ich habe einige Tests auf meiner Seite durchgeführt, mich aber auf einen kleinen Cluster beschränkt.)

Ich könnte es am Montag, den 24. Dezember versuchen!

Probieren Sie es heute aus. Gibt gegebenenfalls Ergebnisse an.

Dies ist ein Fehler. Ich habe in den iptables-Modus gewechselt.

Ich habe auch auf die Beta-Version aktualisiert und in Kürze wieder mit unseren Auslastungstests begonnen. Wir brechen normalerweise schnell (weniger als einen Tag) und ziemlich konsequent ... Daumen drücken.

@ Li-Sen definitiv ein Fehler. Wir arbeiten daran

@emptywee und @bjornryden vielen Dank für das Testen!

@lbernail mein Vergnügen! Es ist also ungefähr zwei Tage her, seit ich kube-proxy mit dem Image 1.11.7-beta.1 gestartet habe. Es hat uns noch nicht aufgehängt. Ich kann sehen, dass proxier.go und andere Goroutinen noch am Leben sind und in die Protokolle drucken. Ich werde noch etwas Zeit darauf verwenden, da die letzten Tage sehr langsam und leise waren und nicht viele Bereitstellungen stattfanden. In jedem Fall habe ich das Gefühl, dass die Mutexe, die @lbernail hinzugefügt hat, helfen :)

Ich werde dieses Problem / diesen Thread bis Ende der Woche aktualisieren.

@ Lbernail

Würden Sie bitte eine PR zur Behebung dieses Problems erstellen?

/wieder öffnen
(um das Feedback von Tests und vor dem Erstellen von Kirschpicks im Auge zu behalten, wenn alles in Ordnung ist)

@lbernail : Sie können ein Problem / eine PR nur dann erneut öffnen, wenn Sie es verfasst haben oder ein Mitarbeiter sind.

@ m1093782566 Können Sie das Problem erneut öffnen, bis wir sicher sind, dass es behoben ist?

Ich habe das gleiche Problem mit Kube-Proxy-IPvs, Version 1.12.3.
Die realen Server sind falsch und Kube-Proxy kann die IPvs-Regeln nicht aktualisieren.

Hier sind die letzten Protokolle, die hier hängen geblieben sind und keine neuen Protokolle mehr gedruckt haben.

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 : Es gibt zwei Probleme:

• Fehlgeschlagene Löschungen: behoben in 1.12.4
• kube-proxy bleibt aufgrund eines Deadlocks hängen (das ist das Problem, das Sie beschreiben): hoffentlich mit der PR von gestern behoben. Wir warten auf Feedback von @emptywee und @bjornryden , die derzeit den Patch testen. Sobald wir die Bestätigung haben, dass das Problem nicht mehr vorliegt, werde ich die Cherrypicks für 1.13, 1.12 und 1.11 erstellen (wenn der Patch funktioniert, wird er wahrscheinlich Anfang nächster Woche in allen Zweigen zusammengeführt und Teil von sein die nächsten Patch-Releases)

Ich führe mein Experiment https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 erneut aus, wobei der Patch auf 1.12.4 zurückportiert wird. Werde zurück berichten!

Wir hatten keine Probleme mit dem Zugriff auf Dienste, während kube-proxy im IPVS-Modus ausgeführt wurde (und wird), und wir hatten einige Bereitstellungen und Änderungen an den Diensten. Bisher würde ich sagen, dass der Patch für uns gut funktioniert.

@lbernail Großartige Arbeit bei der

Ok, warten wir bis Montag, damit wir auch Feedback von @matthiasr und @bjornryden erhalten (ich möchte vermeiden, dass die

@lbernail Gute Nachrichten, dank Ihrer Antwort.

Keine Probleme nach mehr als 12 Stunden am 1.12.4 mit https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f - ohne das habe ich in 1,5 Stunden eine Sperre bekommen, das sieht also sehr gut aus!

@lbernail Ich habe noch eine Frage, bitte. Wenn der nächste Patch Version 1.12.5 ist?
Wenn ich nur kube-proxy auf 1.12.5 aktualisiere, behalten andere Einheiten (Apiserver, Kubelet, Controller-Manager, Scheduler ...) 1.12.3 bei. Ist das in Ordnung? Oder muss ich alle Einheiten aktualisieren?

@ VincentFF Hoffentlich

Update: Nach 24 Stunden, immer noch keine Probleme, stoppe ich mein Experiment jetzt und betrachte dies als vollen Erfolg. Ich freue mich auf 1.12.5!

Ok, das sind sehr gute Nachrichten. Ich werde den Cherry-Pick für alle Branchen erstellen, um das Update so schnell wie möglich in offiziellen Releases zu erhalten.
Vielen Dank für Ihr Engagement bei der Lösung des Problems und beim Testen!

Kirschpicks:
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

Ich kann mich dem Chor der glücklichen Tester anschließen. 4 Tage ohne Probleme.

Vielen Dank an alle Beteiligten, insbesondere an @lbernail. Frohes neues Jahr!

Ich baue es und stelle es bereit, um env zu testen. Über 24 Stunden habe ich keine Probleme. Frohes neues Jahr.

Hallo, meine Umgebung ist
Ubuntu 16.04.4 LTS
Kubernetes-Version (verwenden Sie die kubectl-Version): v1.13.0
Cloud-Anbieter oder Hardwarekonfiguration: Bare Metal, 64-Bit-Linux
Kernel 4.4.0-75-generic

gleicher Fehler:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Versuch, rs: 10.200.198.70:9090/TCP/172.200.101.32:9090 zu löschen
E0101 22: 20: 09.742975 267576 proxier.go: 1519] IPVS-Dienst konnte nicht abgerufen werden, Fehler: Es wurde nur ein Dienst erwartet = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] Fehler beim Synchronisieren des Endpunkts für den Dienst: 10.200.36.192:80/TCP, Fehler: Es wurde nur ein Dienst erwartet = 0

Ich muss kube-proxy neu starten, um es zu beheben

@daigong v1.13.1 haben dies behoben. In meinem Fall keine Probleme nach mehr als einer Woche.

@daigong : Der vollständige Fix befindet sich tatsächlich in 1.13.2 (dies hängt davon ab, wie schnell # 72426 zusammengeführt wird).

@lbernail @FrostyLeaf
Danke, ich benutze # 72426, um diesen Fehler zu testen

Alles ist jetzt in Ordnung

Die PR wurde in allen Release-Zweigen zusammengeführt, sodass sie in folgenden Bereichen vorhanden sein wird:

• 1.11.7
• 1.12.5
• 1.13.2

@annProg

das gleiche Problem, sowohl 1.12.2 als auch 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Wie viel kostet Ihre Mailbox, lernen Sie sie kennen. .jugendlich

gleich

Gibt es eine Chance für einen neuen Build in v1.11.x?

Ich habe die Veröffentlichungsseiten in den letzten Tagen fast stündlich aktualisiert, in der Hoffnung, dass 1.12.5 angezeigt wird, damit ich diesen Fehler auf mehreren Clustern beheben kann. :-)

@verwilst haha,

Ich habe die Veröffentlichungsseiten in den letzten Tagen fast stündlich aktualisiert, in der Hoffnung, dass 1.12.5 angezeigt wird, damit ich diesen Fehler auf mehreren Clustern beheben kann. :-)

Es ist hier :-P

Ich habe die Veröffentlichungsseiten in den letzten Tagen fast stündlich aktualisiert, in der Hoffnung, dass 1.12.5 angezeigt wird, damit ich diesen Fehler auf mehreren Clustern beheben kann. :-)

Es ist hier :-P

Warum ist es nicht für 1.11 da? :(

Wurde dieser Fehler in 1.11.7 behoben? Ich habe keine Versionshinweise gesehen.

Ja, es ist 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)

Ja, ich habe vergessen, "IPVS" in den Release-Hinweis in der PR aufzunehmen. Tut mir leid
Lassen Sie uns wissen, ob es jetzt in Ordnung funktioniert! (Wir lassen das Thema für alle Fälle für eine Woche offen)

Wir hatten seit dem Upgrade auf 1.12.5 🎉 keine Probleme mehr

Großartige Neuigkeiten!

@ m1093782566 , @thockin Ich denke, wir können dieses Problem schließen (keine neuen Berichte in ca. 2 Monaten)

Als Referenz wirkt sich der Fehler auf Erstversionen mit ordnungsgemäßer Beendigung aus:

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

Fix ist vorhanden nach:

• 1.11.7
• 1.12.5
• 1.13.2

/schließen

@ m1093782566 : Schließen dieses Problems.

Können wir wieder öffnen? Wir sehen dieses Problem am 1.12.7.

Ja, wir sehen die Probleme auch in 1.12.9

Sind Sie sicher, dass es das gleiche Problem ist?
Können Sie die Protokolle einer Kube-Proxy-Instanz veröffentlichen?

Entschuldigung, es könnte eine falsche Warnung gewesen sein ... Wir sehen, dass dies die Protokolle sind und es nicht der gleiche Fehler ist

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

Aus irgendeinem Grund konnte der Cluster unter Last nicht an einige der IP-Adressen des Clusterdienstes weitergeleitet werden. Wir sind uns immer noch nicht sicher, ob es sich um ein IPVS-Problem handelt.

Vielleicht braucht die Endpunktausbreitung Zeit, wenn der Apiserver überlastet ist?

Die Nachrichten sind normale Nachrichten auf Info-Ebene:
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

Ich kann das gleiche Protokoll in 1.14.4 bestätigen. Wann kommt dieses Protokoll heraus?

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

Dies sind nur Informationsprotokolle:

• Trying to delete rs : Ein Backend-Pod wurde entfernt und versucht, ihn zu löschen. Wenn bereits Verbindungen bestehen, geben Sie die ordnungsgemäße Beendigung ein, andernfalls löschen Sie die ID
• Deleting rs : Das Backend hat keine Verbindung und wird aus IPVS entfernt

@andrewsykim Vielleicht könnten wir jetzt die Ebene dieser Protokolle verringern, sodass sie beispielsweise nur über v = 5

In https://github.com/kubernetes/kubernetes/pull/78395 haben wir die Protokollstufe von v = 0 auf v = 2 erhöht. Ich denke, v = 5 ist sinnvoll. https://github.com/kubernetes/kubernetes/pull/80100 zum Update