Kubernetes: El modo ipvs de kube-proxy se cuelga después de unas horas, necesita reinicio manual

/ sig red

el mismo error. actualizar desde 1.11.1. Todo se vuelve bueno, excepto que kube-proxy se vuelve inestable, en algún momento el pod no puede acceder al svc aunque sus puntos finales están bien ... Y lo mismo que la resolución de nombres. así que creo que puede existir un error importante aquí.

/ área ipvs

@gjcarneiro ¿resuelves este problema?

Bueno, cambié el clúster nuevamente al modo predeterminado (iptables), parece ser bastante estable desde entonces ...

@ kubernetes / sig-network-bugs

@berlinsaint : Reiterando las menciones para activar una notificación:
@ kubernetes / sig-network-bugs

mismo problema, tanto 1.12.2 como 1.13.0-beta1. @ m1093782566 @ León-Wei

@gjcarneiro, ¿quiere decir que en el kernel 4.15 tiene el mismo problema?

@annProg

mismo problema, tanto 1.12.2 como 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Cuánto cuesta tu buzón, conócelo. .juvenil

@annProg

mismo problema, tanto 1.12.2 como 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Cuánto cuesta tu buzón, conócelo. .juvenil

Haga clic en mi avatar para ver

También veo esto repetidamente en mi sistema de registro centralizado:

  | 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

Estoy ejecutando v1.12.3 (instalación nueva, no una actualización).

Hola a todos. Gracias por el informe, haré una investigación y trataré de averiguar qué sucedió, cualquier progreso que reportaré aquí.

Además de lo que sucedió, lo cual es bueno saberlo, no me siento seguro acerca de IPVS hasta que haya un código que detecte y restablezca un conector de enlace de red roto. Porque por lo que puedo adivinar de los registros y trazas, es que el conector de enlace de red entra en un estado roto y la tarea que lee / escribe desde / en él se bloqueará para siempre. Creo que kube-proxy necesita tener un código que detecte este problema y, si sucede, cree un nuevo conector de enlace de red desde cero y tal vez reinicie la tarea que lo maneja. Pero no, no soy voluntario, ni siquiera lo sé. Go, lo siento.

Porque por lo que puedo adivinar de los registros y trazas, es que el conector de enlace de red entra en un estado roto y la tarea que lee / escribe desde / en él se bloqueará para siempre.

Actualizamos la versión go netlink hace unos días para admitir la terminación ordenada. La biblioteca netlink se estaba ejecutando bastante estable antes. No estoy seguro de si es la causa.

1.12.3 con el mismo error.
Después de filtrar el registro INFO,
ejecutar 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;
y todo el registro del nodo proxy es

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

Por cierto. desde arriba de mis registros, parece que kube-proxy todavía tiene muchos problemas con iptables-restore. todos mis nodos son UBUNTU 16.04 que tienen la versión 1.6.0 de iptable.
@ m1093782566 @ León-Wei

Vemos que esto sucede al actualizar desde 1.12.1. por tanto, debe estar en el delta de 1.12.1 y 1.12.2.

El problema está relacionado con la terminación elegante y creo que hemos solucionado el error en v1.13.1.

@ m1093782566 ¿la corrección se transferirá a la línea 1.12? ahora mismo, esto está bloqueando la corrección de seguridad 1.12.3 para nosotros.

Obtuve lo mismo con la actualización de 1.11.2 a 1.11.5.

@ m1093782566 ¿ puede proporcionar más información sobre la solución? Me interesaría revisar el compromiso.

Esto es bastante loco, nos han mordido muy fuerte hoy.

Vemos que esto sucede al actualizar desde 1.12.1. por tanto, debe estar en el delta de 1.12.1 y 1.12.2.

Obtuve lo mismo con la actualización de 1.11.2 a 1.11.5.

¿Fue el bicho elegido por Chery?

Este parece el PR que soluciona el problema: https://github.com/kubernetes/kubernetes/pull/71515

Verdadero @ Quentin-M

Sí, esto probablemente proviene de la corrección en la función delete (no está realmente relacionada con el título del PR).

@ m1093782566 Puedo crear la selección de cereza para 1.12. ¿Queremos exportar el PR completo o solo la corrección en la función de eliminación? (para evitar cambiar el comportamiento con los flujos UDP en 1.12)

¿Fue el bicho elegido por Chery?

@ Quentin-M parece que el error fue introducido por https://github.com/kubernetes/kubernetes/pull/66012, que se seleccionó en las versiones 1.11.5 y 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

Creo que todo el # 71515 debería ser elegido. La terminación elegante en general solo se introdujo y se seleccionó con el número 66012, por lo que el cambio de comportamiento ya se produjo.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 todavía está obsoleto en nuestros clústeres. El 60% de ellos se atascó en menos de 24 horas. Probar 1.12.1 ahora.

@ Quentin-M: ¿Puede verificar los registros en kube-proxy y confirmar que estos tipos de mensajes se han ido?

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

Ambos están relacionados con la función de eliminación fijada en el PR. Si desaparecieron y aún ve el problema, esta solución no es suficiente

Además, si todo funciona con 1.12.1 , existe una gran probabilidad de que el problema provenga de una terminación ordenada (# 66012)

Creo que tengo una idea: me pregunto qué sucede si intentamos agregar un servidor real que todavía está en finalización elegante. En este caso, deberíamos simplemente aumentar el peso a 1 y eliminarlo de la lista de terminación elegante.

Intentaré probar este escenario tan pronto como pueda (pero será complicado porque estaré en Kubecon la próxima semana)

@ Lion-Wei, ¿qué opinas?

Ok, borre eso, acabo de probar y funciona bien. El código responsable está aquí: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

En ese caso, el RS se elimina de la lista gracefulDelete y de IPVS RS. Me pregunto si volver a poner el peso en 1 no sería mejor

Intentaré otras cosas basadas en esta parte de los registros, que parece apuntar a intentar sincronizar los puntos finales de un servicio eliminado

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

De acuerdo, después de una verificación rápida, la confirmación que soluciona el problema de eliminación no está en v1.13.1-beta.0 ni en v1.14.0-alpha.0 que se eliminó el 7 de noviembre
Creo que será en la próxima versión alfa 1.14 que se basará en master

También voy a crear la selección de cereza para 1,13

Tengo un problema con la actualización de 1.12.0 a 1.13.0, parece estar relacionado con este, pero no es el mismo.

No podemos solucionarlo volviendo a iptables. Por favor, ayúdame.

Lo he publicado en stackoverflow

Obtuve lo mismo en 1.11.5. Revertido temporalmente de ipvs a iptables.

Lo mismo en 1.11.5. No se puede revertir a 1.11.4 debido a la vulnerabilidad presente en él. Tuve que cambiar a iptables. ¿La solución para esto se lanzará para 1.11.x?

Puede deshacer kube-proxy de manera muy específica, sin verse afectado por la vulnerabilidad.

@ Quentin-M Sí, ese pensamiento me ha golpeado la mente, pero por otro lado, si lo hiciera, no tendría una terminación elegante, que ha estado ahí todo el tiempo con iptables. No estoy seguro de que a nuestros clientes les guste el cambio.

@ Quentin-M, ¿significa que no habrá solución para 1.11.x para solucionar este error?

@emptywee Creé una selección de cereza para 1.11: https://github.com/kubernetes/kubernetes/pull/71848
Con suerte, se fusionará muy pronto y estará en 1.11.6

Ya se ha fusionado en 1.12 (estará en 1.12.4 ) y 1.13 (estará en 1.13.1 )

La selección de cereza también se fusionó en 1.11
Solo tenemos que esperar a los próximos lanzamientos de parches en las 3 ramas (pero si desea probarlo antes de que pueda crear fácilmente una compilación de kube-proxy personalizada (o, incluso más fácil, una imagen de hiperkube con el parche)

¡Muchas gracias @lbernail ! ¡Sería bueno tener una imagen de Docker disponible públicamente! ¡Me encantaría probarlo!

La solución ya está seleccionada para las versiones 1.11, 1.12 y 1.13.

¿Podría probarlos para que podamos solucionar este problema?

@ m1093782566 Estoy probando esto. Por cierto, ¿cuándo publicará la comunidad el pequeño lanzamiento para esto?

Gracias @berlinsaint , déjame el resultado de la prueba.

¿Cuándo publicará la comunidad el pequeño lanzamiento para esto?

La nueva versión pequeña con la corrección se publicará en menos de 2 semanas.

@emptywee : aquí tienes: lbernail/hyperkube:v1.12.4-beta.1
¡Háganos saber como funciona para usted!

@lbernail, ¿ está bien usarlo con todo lo demás en v1.11.5? ¿O debería pasar primero mi clúster de kubernetes a la versión 1.12.4? De todos modos, ¡muchas gracias!

@emptywee sí, debería funcionar sin ningún problema (he estado ejecutando kube-proxy 1.11 en clústeres 1.10 durante meses)

También puedo hacer una compilación 1.11 más tarde hoy

@lbernail sí, sería bueno tener una imagen de la misma versión de lanzamiento.

@emptywee aquí tienes: lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail Después de una noche de observación, el registro de errores de sincronización de ipvs ya no se ve, mientras
ocurre al menos una vez una noche antes. Pero aún necesito más tiempo para verificarlo, muchas gracias, me molestó mucho tiempo.

Comenzaré a probar mañana el 1.11 y también le daré unos días.

@lbernail Te probé lbernail/hyperkube:v1.11.6-beta.1 (¡Gracias por eso!)
Inmediatamente pensamos que las cosas estaban arregladas, ya que dejamos de ver los mensajes de registro can't find the real server . Sin embargo, después de un día y medio, estamos viendo problemas con entradas ipvs obsoletas en 3/6 nodos de clúster.
Estas son las entradas de ipvs para un servicio en un nodo de clúster roto.
Antes de reiniciar 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

Después de reiniciar 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 Esa fue la razón por la que me metí en este hilo cuando cambié a IPVS en 1.11.5. Al día siguiente encontré servicios inaccesibles, así que pensé que kube-proxy se había bloqueado y no actualizaría las entradas de los servicios.
Eso es solo para hacerle saber que tuve un problema similar (IP incorrectas en la tabla ipvs) con v1.11.5 de kube-proxy.

@bjornryden Buenas noticias para los errores de eliminación (esto era lo que estaba abordando el parche)

El hecho de que los backends no se actualicen correctamente es extraño porque la terminación elegante no debería afectar a los nuevos puntos finales (si algunos puntos finales obsoletos todavía estuvieran allí, por ejemplo, me sorprendería menos)

¿Podría compartir los registros de kube-proxy relacionados con el servicio 10.230.65.211:9494 ?

Además, ¿algún comportamiento especial con este servicio / implementación? (por ejemplo, ¿se actualizan los pods con mucha frecuencia o detrás de un HPA?)

Así que ha estado funcionando durante 2 días en mi grupo de laboratorio con la imagen 1.11.6-beta.1 de @lbernail en el modo ipvs.
Hasta ahora todo va bien, no se ha bloqueado y sigue actualizando las entradas de ipvs.

Sin embargo, una observación extraña:

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         

La primera llamada a ipvsadm muestra el estado inicial antes de eliminar uno de los pods para el servicio. A continuación, pocos muestran que una entrada se ha ido, ya que se eliminó el pod. Sin embargo, no sé si es así como se supone que debe ser, pero creó una segunda entrada con la misma dirección IP que el pod que había dejado. Y luego lo actualizó a la IP correcta del nuevo pod que surgió para reemplazar el eliminado.

Aparte de eso, ha estado bien. Pero el grupo de laboratorios no está tan ocupado como los demás. El comentario de @bjornryden me preocupó un poco al probar la imagen en clústeres más ocupados, donde puede afectar a nuestros clientes.

@emptywee Supongo que el pod eliminado era 10.158.130.24 . No entiendo esto:

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 

Tener el mismo servidor real dos veces no tiene sentido. ¿Puedes reproducirlo?

El comportamiento normal en la eliminación de pod debe ser:

• si no hay conexiones a este pod, retire el RS
• si hay conexiones, establezca el peso en 0 (las conexiones establecidas continúan, no hay nuevas conexiones)
• cada minuto verifique todos los RS con peso 0 (para esto es la lista de terminación elegante) y elimine los que ya no tienen conexiones

@lbernail correcto. La cápsula eliminada tenía esa dirección IP. Y sí, también me pareció extraño. Intentaré reproducirme cuando tenga la oportunidad. ¿Le gustaría que aumente la verbosidad del registro si puedo reproducir el mismo comportamiento? Si es así, ¿a qué nivel?

@emptywee : sería genial gracias, --v=5 debería darnos mucha información
Lo principal es que ni siquiera creo que un RS pueda aparecer dos veces en un VS en IPVS (nunca vi eso). ¿Qué kernel está ejecutando?

@lbernail lo establecerá en --v = 5 e intentará reproducirlo, probablemente en algún momento del fin de semana.

Estoy en CoreOS estable:

4.14 es muy reciente, por lo que me sorprendería si hubiera un problema de IPVS
Voy a intentar estresar un clúster con la versión parcheada para ver si puedo reproducir el problema de @bjornryden

@lbernail Desafortunadamente, no pude reproducir ese comportamiento de duplicación de entrada de ipvs que solo he visto una vez. Intenté varias veces, con diferentes servicios. Sin embargo, no he visto ninguna entrada con peso 0, pero esto podría explicarse por el hecho de que los pods que elimino salen muy rápidamente. Además, kube-proxy ha respondido después de ejecutarse durante más de 5 días. Podría intentarlo de nuevo en el clúster más ocupado de aquí.

@emptywee Esta es una "buena" noticia (incluso si prefiero que podamos reproducirla y entenderla, ¿tal vez fue un error de visualización en ipvsadm?)

El peso solo se establece en 0 si son ActiveConn o InActiveConn. Para verlo, simplemente abra una conexión de larga duración a un servicio antes de eliminar el pod asociado (por ejemplo, usando telnet)

¡5 días de estabilidad son buenas noticias! Háganos saber cómo le va cuando / si prueba en un clúster más ocupado

Tengo algunas pequeñas mejoras en camino:

• https://github.com/kubernetes/kubernetes/pull/71834 : haga que la terminación elegante funcione con los servicios que usan sessionAffinity (ya en el maestro, selecciones de cereza creadas para 1.13, 1.12 y 1.11)
• https://github.com/kubernetes/kubernetes/pull/71895 y https://github.com/kubernetes/kubernetes/pull/72106 : admite la terminación elegante al eliminar un servicio (el primero ya está en master, estoy esperando que el segundo elija ambos en todas las ramas)

Además, 1.11.6 , 1.12.4 y 1.13.1 se han publicado y contienen la corrección en la función de eliminación

Escribí un breve artículo sobre el tema durante el fin de semana /. ¡Me aseguraré de actualizarlo con la versión fija!

@lbernail ¡ Seguro, lo haré! ¿Su imagen de hiperkubo es la misma que la que se publicó como 1.11.6? Instalé su imagen para kube-proxy solo en el clúster más ocupado y cambié a ipvs nuevamente para probar. ¿Quieres que use el oficial?

@emptywee Mi imagen y la 1.11.6 son básicamente las mismas: la construí desde el encabezado de la rama de la versión 1.11 unos días antes del lanzamiento oficial, por lo que la diferencia es de algunas confirmaciones como máximo, ninguna de las cuales involucra IPVS. Así que no creo que valga la pena el esfuerzo de actualizar su clúster nuevamente

Malas noticias :( Acabo de recibir mi kube-proxy que no pudo actualizar los backends de ipvs. Volviendo a iptables y recopilando registros. Tenía kube-proxy ejecutándose con la bandera --v=5 .

@lbernail Entonces, no estoy seguro de cuántos registros se necesitan, pero básicamente encontramos un problema con algunos servicios, que no tenían sus IP de backends ipvs actualizadas. Sin embargo, los registros nos dicen que estaba actualizando los puntos finales correctamente:

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

Pero cuando lo verifiqué con ipvsadm, todavía mostraba los dos primeros: 10.148.191.69:8080 10.148.192.14:8080

Mientras que kubectl -n c-qa4 describe svc ycsdtleuk estaba diciendo que los puntos finales son 10.148.183.70:8080 10.148.184.67:8080 , y en otros cuadros, las entradas de ipvs para el mismo servicio se estaban actualizando correctamente.

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

Básicamente, estaba mirando lo siguiente en dos cajas al mismo tiempo:

(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

No hay ningún mensaje de error obvio ni ningún grito que indique signos de un problema en cualquier lugar. Puedo enviarle el archivo de registro completo (18M sin comprimir) directamente, si lo desea.

En pocas palabras: parece que la parte que escucha los cambios de servicios funciona bien, pero la parte que interactúa con el módulo ipvs no lo está. Ni siquiera veo que estuviera intentando eliminar las dos direcciones IP iniciales una vez que las agregó. Algo se atasca en alguna parte.

@emptywee Gracias por el informe detallado. Nada extraño en estos registros.

Lo sorprendente es que syncProxyRules se ejecuta al menos cada 30 segundos (predeterminado) y debería reconciliar los servidores reales IPVS con los puntos finales. Llama a syncEndpoints que dispara AddRealServer y ipvsHandle.NewDestination

Todo esto sucede antes de la eliminación de los puntos finales antiguos, por lo que no debería verse afectado por una terminación ordenada

¿Podrías enviarme los registros completos para que pueda ver exactamente qué sucede entre 21:26 y 21:29 ?

Dos preguntas adicionales:

• un solo proxy de kube se vio afectado, ¿verdad?
• se vio afectado un solo servicio (¿el otro continuó actualizándose normalmente?)

La próxima vez, intente enviar SIGABRT al proceso, para que imprima los estados de las tareas.

Cuando tuve el problema, siempre estaba haciendo algo dentro de libnetwork/ipvs/netlink.go , lo que me lleva a sospechar que la llamada al sistema netlink se atasca por alguna razón.

Perdón por mi ausencia, pero el fin de semana y luego tuve que concentrarme en volver a iptables para nuestra configuración.

Mirando hacia atrás en los registros solicitados para el servicio, @lbernail , tenemos muchos de estos:

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

También vimos estos:

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

Tal como han informado otros, esto solo sucedió en algunos nodos. Cuando encontré el problema, teníamos 3 nodos de clúster que estaban rotos para este servicio específico.

@lbernail Por supuesto . Aquí está la parte solicitada de los registros, también he incluido la parte de inicio: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Avísame si necesitas el archivo completo. En caso afirmativo, adónde desea que lo envíe o suba.

Para responder tu pregunta:

1. El clúster tiene más de 60 nodos, verifiqué algunos otros nodos, la entrada de ipvs era correcta. Sin embargo, no estoy seguro de todas las entradas. Pero en el nodo principal, a través del cual enrutamos todo el tráfico a los servicios, al menos dos servicios no se actualizaban correctamente. Podría haber más, pero una vez que comenzamos a recibir quejas de los clientes, inmediatamente nos enteramos de que dos servicios no eran accesibles. Recopilé registros y reinicié kube-proxy para minimizar el impacto. Comparé el estado de las entradas de ipvs en ese nodo maestro y uno de los nodos trabajadores como parte de la resolución de problemas y me di cuenta de que era diferente. Existe la posibilidad de que otros nodos tengan diferentes entradas que no se actualicen correctamente, pero como el tráfico no pasa por ellos, no notamos ningún impacto.

2. No, al menos dos servicios se vieron afectados. Posiblemente más, pero no lo comprobé.

Dos cosas interesantes de los registros:

• IPVS nunca procesa 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] pero no hay error porque mantiene los dos RS antiguos (no podemos estar seguros, agregar un RS no genera el registro)
• 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] no activa la llamada de eliminación para 10.148.192.14:8080 (deberíamos tener registros allí)

@emptywee ¿ IPVS estaba funcionando para usted antes de la terminación

@ m1093782566 / @ Lion-Wei ¿

@lbernail Esperamos hasta que actualizamos a 1.11 para cambiar a ipvs (creo que fue cuando se lanzó el lanzamiento de GA para esta función) y actualizamos directamente a 1.11.5 y fue nuestro primer intento de comenzar a usar ipvs.

@emptywee : Voy a agregar más registros de nivel de información para intentar identificar el problema. ¿Estaría bien ejecutar una versión más detallada durante unas horas? (Entiendo completamente si prefieres no hacerlo, pero aún no he podido reproducirme de mi lado)

Hemos estado usando IPVS desde mayo y no tuvimos problemas en 1.12.1 y 1.11.1.

También vimos que esto sucedió en varios, pero no en todos los nodos, después de actualizar a 1.12.3. Los nodos afectados dejaron de actualizar IPVS unas horas después de la actualización, pero no de una manera coordinada que yo pudiera discernir.

Una cosa a tener en cuenta es que kube-proxy también dejó de iniciar sesión por completo en ese momento, por lo que parece que se atascó por completo.

Archivo de registro que muestra que se atasca y un volcado goroutine después de SIGQUIT (ligeramente redactado)

El archivo de registro de @matthiasr nuevamente muestra una lectura atascada de goroutine desde el conector netlink. Igual que yo.

Se podría argumentar que existe un error lógico que provoca demasiadas interacciones con el conector netlink. Pero si la comunicación con netlink no es sólida, ipvs eventualmente se atascará. Si se soluciona el error lógico, es posible que lleve mucho más tiempo alcanzar este estado, pero no significa que no pueda suceder con el tiempo suficiente.

Es por eso que aconsejaría tener algún tipo de tiempo de espera en las interacciones de netlink; Si la operación se agota, cierre el conector netlink y abra uno nuevo automáticamente, como mecanismo de recuperación.

@matthiasr OK, eso es una buena noticia (también hemos estado usando IPVS durante más de 6 meses sin ningún problema, pero aún no hemos actualizado a las versiones que utilizan terminación elegante en nuestros clústeres más ocupados)

Parece que podemos tener un punto muerto en alguna parte

@lbernail Si bien es un poco engorroso cambiar todo el clúster a ipvs, si esto va a ayudar a resolver este problema, estoy abajo. Dime el nombre de la imagen que usaré y haré todo lo que esté a mi alcance para ayudarte con esto.

Hemos vuelto a IPVS en 1.11.6 para ver si podemos recrear nuestro problema. Registro establecido en 5 y ejecución de alguna actividad en el clúster durante los próximos días. No trabajaré mañana, pero apareceré en línea para ver si hay una imagen con mayor registro a la que debería cambiar.

@matthiasr : 1.12.3 definitivamente tiene un problema (ver el resto de este hilo). Parte de esto se resuelve en 1.12.4 . Obtendrá muchos menos errores en los registros. Todos estos deberían desaparecer: Failed to add destination: 10.zz.yy.xx, error: file exists

Todavía tenemos el problema en el que kube-proxy parece bloquearse y ya no actualiza los servidores reales.
Lo miré un poco más:

• de @emptywee parece que después de que ha comenzado el problema no vemos ningún registro de proxier.go, ipset.go o graceful_termination.go, lo que parece indicar que estamos atascados en algún lugar. @emptywee, ¿ puede comprobar si tiene registros de estos archivos después de las 21:30?
• en el volcado de rutina go, hay dos syscall recibiendo en un socket netlink. Entonces podríamos tener un problema allí. Además, para admitir la terminación elegante, libnetwork / ipvs se actualizó, por lo que es posible que el comportamiento haya cambiado. Sin embargo, el código libnetwork parece establecer tiempos de espera de envío / rcv en el socket netlink (y si estaba atascado deberíamos ver la cantidad de minutos que han pasado): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Curiosamente, solo la nueva versión de libnetwork tiene tiempos de espera de netlink:

libnetwork se actualizó en todas las ramas de la versión (1.11, 1.12 y 1.13) para permitir una terminación ordenada. pasamos de: ba46b928444931e6865d8618dc03622cac79aa6f a a9cd636e37898226332c439363e2ed0ea185ae92

En la versión anterior, el código era: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

Las únicas diferencias en el código IPVS en libnetwork entre estas 2 confirmaciones son:

• introducción del tiempo de espera
• adición de ActiveConnections y InactiveConnections a Destination (que era necesaria para una terminación elegante)

Me pregunto si esto podría estar relacionado.

Después de reflexionar un poco más sobre el tema, creo que se debe al hecho de que ahora tenemos dos goroutines usando el mismo socket de netlink (porque el gracefulTerminationManager se ejecuta en su propia goroutine y comparte la interfaz utilipvs.Interface con el proxier).

Probablemente podríamos agregar un mutex en todas las llamadas en pkg/util/ipvs/ipvs_linux.go para asegurarnos de que una sola goroutine esté usando el conector netlink en un momento dado.

@ m1093782566 ¿qué opinas?

@lbernail No, no hay entradas de esos archivos después de las 21:30.
Aquí están las últimas entradas para varios archivos:

Últimas entradas de 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

Últimas entradas de 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

Últimas entradas de 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

Todos terminaron registrando alrededor de las 21:18 ... ¿Da alguna pista?

@emptywee Sí, confirma la hipótesis de que tenemos un punto muerto entre las dos gorutinas que comparten el conector netlink. Ambos están atascados esperando recibir mensajes y siguen intentando sin éxito (debido al tiempo de espera de recepción de 3 segundos).

Intentaré validar la hipótesis y comenzaré a trabajar en una solución tan pronto como pueda.

Puse 1.12.4 en un clúster de prueba y comencé a volver a implementar una aplicación, que reproducía el problema en 1,5 horas, así que creo que podré probar una solución potencial de manera bastante confiable.

De nuevo hay 2 gorutinas (1 y 107) colgadas en una recepción de netlink.

Tengo una posible solución para el error, el código está disponible aquí: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
La idea es proteger todas las llamadas de netlink con un Mutex para evitar el punto muerto. No estoy seguro de que esta sea la mejor solución, pero podría resolver el problema (y si funciona, confirme que hemos identificado el error).

Si quieres / puedes probarlo, creé dos imágenes con la solución:

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

Si lo prueba, háganos saber si funciona y, si no funciona, comparta registros interesantes y mire las goroutines para ver si algunas parecen atascadas en las llamadas de netlink.

(Hice algunas pruebas por mi parte, pero me limité a un pequeño grupo)

¡Podría intentarlo el lunes 24 de diciembre!

Dale una oportunidad hoy. Informará los resultados, si los hay.

Esto es un error. He cambiado al modo iptables.

También me actualicé a la versión beta y comencé de nuevo nuestras pruebas de carga en breve. Por lo general, rompemos rápidamente (menos de un día) y de manera bastante consistente ... cruzamos los dedos.

@ li-sen definitivamente un error. Estamos trabajando en ello

@emptywee y @bjornryden ¡muchas gracias por las pruebas!

@lbernail mi placer! Así que han pasado aproximadamente dos días desde que lancé kube-proxy con la imagen 1.11.7-beta.1. Aún no nos ha afectado. Puedo ver que proxier.go y otras goroutines todavía están vivas e imprimiendo en los registros. Le daré más tiempo ya que los últimos días fueron muy lentos y silenciosos, no hubo muchas implementaciones. De cualquier manera, tengo la sensación de que los mutex que agregó @lbernail están ayudando :)

Actualizaré este tema / hilo para el final de la semana.

@lbernail

¿Podrías plantear un PR para solucionar este problema?

/reabrir
(para estar atento a los comentarios de las pruebas y antes de crear selecciones si todo funciona bien)

@lbernail : no puede volver a abrir un problema / relaciones públicas a menos que sea el autor o un colaborador.

@ m1093782566 ¿ puede volver a abrir el problema hasta que estemos completamente seguros de que se ha solucionado?

Tengo el mismo problema de ipvs de Kube-proxy, versión 1.12.3.
Los servidores reales están equivocados y el proxy de Kube no puede actualizar las reglas de ipvs.

Aquí están los últimos registros y se quedó aquí, ya no imprimió nuevos registros.

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 : hay dos problemas:

• eliminaciones fallidas: corregido en 1.12.4
• kube-proxy se atasca debido a un punto muerto (que es el problema que está describiendo): ojalá se solucione con el PR de ayer. Estamos esperando comentarios de @emptywee y @bjornryden, quienes actualmente están probando el parche. Tan pronto como tengamos la confirmación de que el problema ya no está presente, crearé las selecciones de cereza para 1.13, 1.12 y 1.11 (si el parche funciona, probablemente se fusionará en todas las ramas a principios de la próxima semana y será parte de los próximos lanzamientos de parches)

También estoy volviendo a ejecutar mi experimento https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 nuevamente, con el parche actualizado a 1.12.4. Informaré de nuevo!

No hemos tenido ningún problema con el acceso a los servicios mientras kube-proxy se estaba ejecutando (y está) ejecutándose en el modo IPVS y hemos tenido bastantes implementaciones y cambios en los servicios. Hasta ahora diría que el parche nos está funcionando bien.

@lbernail ¡Buen trabajo para solucionarlo! ¡Muy apreciado!

Ok, esperemos hasta el lunes para que también recibamos comentarios de @matthiasr y @bjornryden (quiero evitar apresurar las elecciones y asegurarme de que tengamos una solución limpia esta vez)

@lbernail Buenas noticias, gracias a tu respuesta.

No hay problemas después de más de 12 horas en 1.12.4 con https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f ; sin eso, obtuve un bloqueo en 1.5 horas, ¡así que esto se ve muy bien!

@lbernail Tengo otra pregunta, por favor. ¿Si el próximo parche es la versión 1.12.5?
Si actualizo kube-proxy a 1.12.5, otras unidades (apiserver, kubelet, controller-manager, planificador ...) guardan 1.12.3, ¿está bien? ¿O tengo que actualizar todas las unidades?

@VincentFF Con suerte, llegará a 1.12.5 sí. Puede ejecutar kube-proxy 1.12.5 con otras unidades que ejecutan 1.12.3, no hay problema

Actualización: después de 24 horas, todavía no hay problemas, detengo mi experimento ahora y considero que esto es un éxito total. ¡Esperamos la versión 1.12.5!

Ok, estas son muy buenas noticias. Voy a crear la selección de cerebros para todas las ramas con el fin de obtener la solución en los lanzamientos oficiales lo antes posible.
¡Muchas gracias por su participación para ayudar a resolver el problema y las pruebas!

Selecciones de cereza:
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

Puedo unirme al coro de probadores felices. 4 días sin problemas.

Muchas gracias a todos los involucrados, especialmente a @lbernail. ¡Feliz año nuevo!

Lo construyo y lo implemento para probar env, más de 24 horas no tienen problemas. Feliz año nuevo.

Hola mi env es
Ubuntu 16.04.4 LTS
Versión de Kubernetes (use la versión de kubectl): v1.13.0
Proveedor de nube o configuración de hardware: bare metal, Linux de 64 bits
Kernel 4.4.0-75-genérico

mismo error:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Intentando eliminar rs: 10.200.198.70:9090/TCP/172.200.101.32:9090
E0101 22: 20: 09.742975 267576 proxier.go: 1519] Error al obtener el servicio IPVS, error: se esperaba que solo se obtuviera un servicio = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] No se pudo sincronizar el punto final para el servicio: 10.200.36.192:80/TCP, err: Se esperaba solo un servicio obtenido = 0

Necesito reiniciar kube-proxy arreglarlo

@daigong v1.13.1 ha solucionado esto. En mi caso, no hay problemas después de más de una semana.

@daigong : la solución completa estará en 1.13.2 (depende de la rapidez con la que se fusiona # 72426)

@lbernail @FrostyLeaf
gracias, uso el # 72426 para probar este error

Todo está bien ahora

El RP se ha fusionado en todas las ramas de la versión, por lo que estará presente en:

• 1.11.7
• 1.12.5
• 1.13.2

@annProg

mismo problema, tanto 1.12.2 como 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Cuánto cuesta tu buzón, conócelo. .juvenil

mismo

¿Alguna posibilidad de una nueva compilación en v1.11.x?

He estado actualizando las páginas de lanzamientos casi cada hora durante los últimos días con la esperanza de que aparezca la versión 1.12.5 para poder corregir este error en varios clústeres. :-)

@verwilst jaja, lo mismo, no puedo esperar a que se publique v1.11.7 para actualizar los clústeres de producción actuales. Y v1.12.5 también para comenzar a actualizar en entornos más bajos.

He estado actualizando las páginas de lanzamientos casi cada hora durante los últimos días con la esperanza de que aparezca la versión 1.12.5 para poder corregir este error en varios clústeres. :-)

Está aquí :-P

He estado actualizando las páginas de lanzamientos casi cada hora durante los últimos días con la esperanza de que aparezca la versión 1.12.5 para poder corregir este error en varios clústeres. :-)

Está aquí :-P

¿Por qué no está ahí para la versión 1.11? :(

¿Se corrigió este error en 1.11.7? No vi ninguna nota de la versión.

Sí, es 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)

Sí, me olvidé de agregar "IPVS" en la nota de publicación del PR, lo siento.
¡Háganos saber si funciona bien ahora! (dejaremos el problema abierto durante una semana por si acaso)

No hemos tenido problemas desde la actualización a 1.12.5 🎉

¡Una gran noticia!

@ m1093782566 , @thockin Creo que podemos cerrar este problema (no hay nuevos informes en aproximadamente 2 meses)

Como referencia, el error afecta las versiones iniciales con una finalización elegante:

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

La corrección está presente después de:

• 1.11.7
• 1.12.5
• 1.13.2

/cerca

@ m1093782566 : Cerrando este problema.

¿Podemos reabrir? Estamos viendo este problema en 1.12.7.

sí, también estamos viendo los problemas en 1.12.9

¿Estás seguro de que es el mismo problema?
¿Puede publicar los registros de una instancia de proxy de kube?

lo siento, puede haber sido una alerta falsa ... Vemos que estos son los registros y no es el mismo error

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

por alguna razón, cuando el clúster está bajo carga, no se puede enrutar a algunas de las direcciones IP del servicio de clúster. Todavía no estamos seguros de si se trata de un problema de IPVS.

¿Quizás la propagación del punto final está tomando tiempo si el apiserver está sobrecargado?

Los mensajes son mensajes normales de nivel de información:
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

Puedo confirmar el mismo registro en 1.14.4. ¿Cuándo sale este registro?

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

Estos son solo registros de información:

• Trying to delete rs : se eliminó un pod de backend, intentando eliminarlo. Si tiene conexiones existentes, hágalo entrar en terminación elegante, de lo contrario elimine la identificación
• Deleting rs : el backend no tiene conexión, eliminándolo de IPVS

@andrewsykim ¿ Quizás ahora podríamos disminuir el nivel de estos registros para que solo se muestren por encima de v = 5, por ejemplo?

En https://github.com/kubernetes/kubernetes/pull/78395 aumentamos el nivel de registro de v = 0 a v = 2, creo que v = 5 tiene sentido. https://github.com/kubernetes/kubernetes/pull/80100 para actualizar