Kubernetes: Режим kube-proxy ipvs зависает через несколько часов, требуется перезапуск вручную

/ sig сеть

та же ошибка. обновление с 1.11.1. Все стало хорошо, кроме того, что kube-proxy стал нестабильным, некоторое время pod не может получить доступ к svc, хотя их конечные точки в порядке .. И то же самое, что и разрешение имени. поэтому я думаю, что здесь может быть важная ошибка.

/ area ipvs

@gjcarneiro, решите ли вы эту проблему?

Ну, я переключил кластер обратно в режим по умолчанию (iptables), с тех пор он выглядит довольно стабильным ...

@ kubernetes / сиг-сети-ошибки

@berlinsaint :
@ kubernetes / сиг-сети-ошибки

та же проблема, как в 1.12.2, так и в 1.13.0-beta1. @ m1093782566 @ Lion-Wei

@gjcarneiro вы имеете в виду, что в ядре 4.15 такая же проблема?

@annProg

та же проблема, как 1.12.2, так и 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Сколько стоит ваш почтовый ящик, узнайте это. .малолетний

@annProg

та же проблема, как 1.12.2, так и 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Сколько стоит ваш почтовый ящик, узнайте это. .малолетний

Нажмите на мой аватар, чтобы увидеть

Я также неоднократно наблюдаю это в своей централизованной системе ведения журнала:

  | 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

Я использую v1.12.3 (свежая установка, а не обновление).

Привет всем. Спасибо за отчет, я проведу исследование и попытаюсь выяснить, что произошло, о любом прогрессе я сообщу здесь.

Помимо того, что произошло, что хорошо узнать, я не уверен в IPVS до тех пор, пока не появится код, который обнаруживает и сбрасывает сломанный сокет netlink. Потому что из того, что я могу догадаться из журналов и трассировок, сокет netlink переходит в неработающее состояние, и задача, которая читает / пишет из / в него, будет зависать навсегда. Я думаю, что kube-proxy должен иметь код, который обнаруживает эту проблему, и, если это произойдет, создайте новый сокет netlink с нуля и, возможно, перезапустите задачу, которая его обрабатывает. Но нет, я не волонтер, я даже не знаю го, извините.

Потому что из того, что я могу догадаться из журналов и трассировок, сокет netlink переходит в неработающее состояние, и задача, которая читает / пишет из / в него, будет зависать навсегда.

Несколько дней назад мы обновили версию go netlink для поддержки корректного завершения. Библиотека netlink и раньше работала довольно стабильно. Я не уверен, что это причина.

1.12.3 с той же ошибкой.
После фильтрации журнала INFO,
выполнить 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;
и весь журнал прокси-узла

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

Кстати. из моих журналов, похоже, что у kube-proxy все еще много проблем с iptables-restore. все мои узлы - это UBUNTU 16.04 с версией iptable 1.6.0.
@ m1093782566 @ Lion-Wei

Мы видим это при обновлении с 1.12.1. таким образом, он должен быть в дельте 1.12.1 и 1.12.2.

Проблема связана с постепенным завершением, и я думаю, что мы исправили ошибку в версии 1.13.1.

@ m1093782566 будет ли исправление перенесено в строку 1.12? прямо сейчас это блокирует исправление безопасности 1.12.3 для нас.

Получил то же самое при обновлении с 1.11.2 до 1.11.5.

@ m1093782566 не могли бы вы предоставить дополнительную информацию об исправлении? Мне было бы интересно просмотреть коммит.

Это довольно безумие, сегодня нас очень сильно укусили.

Мы видим это при обновлении с 1.12.1. таким образом, он должен быть в дельте 1.12.1 и 1.12.2.

Получил то же самое при обновлении с 1.11.2 до 1.11.5.

Была ли выбрана ошибка Chery?

Это похоже на PR, который устраняет проблему: https://github.com/kubernetes/kubernetes/pull/71515

Правда @ Квентин-М

Да, это, вероятно, связано с исправлением в функции delete (на самом деле не связано с заголовком PR).

@ m1093782566 Я могу создать

Была ли выбрана ошибка Chery?

@ Quentin-M похоже, что ошибка была внесена https://github.com/kubernetes/kubernetes/pull/66012, которая была выбрана для выпусков 1.11.5 и 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

Я думаю, что все # 71515 нужно тщательно отобрать. Изящное завершение в целом было введено только в # 66012, поэтому изменение поведения уже произошло.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 все еще устаревает в наших кластерах. 60% из них застряли менее чем за 24 часа. Пробую 1.12.1 сейчас.

@ Quentin-M: Можете ли вы проверить логи на kube-proxy и убедиться, что эти типы сообщений исчезли:

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

Оба связаны с функцией удаления, зафиксированной в PR. Если они исчезли, а проблема все еще видна, этого исправления недостаточно.

Кроме того, если все работает с 1.12.1 , высока вероятность того, что проблема связана с постепенным завершением (# 66012)

Думаю, у меня есть идея: интересно, что произойдет, если мы попытаемся добавить реальный сервер, который все еще находится в плавном завершении. В этом случае мы должны просто увеличить вес до 1 и удалить его из списка постепенного завершения.

Я постараюсь протестировать этот сценарий, как только смогу (но это будет сложно, потому что я буду на Kubecon на следующей неделе)

@ Lion-Wei, что ты думаешь?

Хорошо, поцарапайте это, я только что протестировал, и он отлично работает. Код, отвечающий за это, находится здесь: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

В этом случае RS удаляется из списка gracefulDelete и из IPVS RS. Интересно, не лучше ли установить вес обратно на 1?

Я попробую другие вещи на основе этой части журналов, которая, похоже, указывает на попытку синхронизации конечных точек для удаленной службы.

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

Хорошо, после быстрой проверки, фиксация, которая устраняет проблему с удалением, не находится ни в v1.13.1-beta.0 ни в v1.14.0-alpha.0 которая была вырезана 7 ноября.
Я думаю, это будет в следующей альфа-версии 1.14, которая будет основана на master

Я собираюсь создать вишневый выбор и для 1.13

Возникла проблема с обновлением с 1.12.0 до 1.13.0, похоже, связана с этим, но не то же самое.

Мы не можем исправить это, вернувшись к iptables. Пожалуйста, помогите мне.

Я разместил это в stackoverflow

Получил так же 1.11.5. Временно вернулся с ipvs на iptables.

То же самое с 1.11.5. Невозможно выполнить откат до версии 1.11.4 из-за уязвимости в ней. Пришлось перейти на iptables. Будет ли выпущено исправление для версии 1.11.x?

Вы можете откатить kube-proxy очень точно, не подвергаясь уязвимости.

@ Quentin-M Да, эта мысль пришла мне в голову, но с другой стороны, если бы я сделал это, у меня не было бы изящного завершения, которое было всегда вместе с iptables. Не уверен, что нашим клиентам понравятся изменения.

@ Quentin-M означает ли это, что в 1.11.x не будет исправления для устранения этой ошибки?

@emptywee Я создал вишневый выбор для 1.11: https://github.com/kubernetes/kubernetes/pull/71848
Надеюсь, он очень скоро будет объединен и будет в 1.11.6

Он уже был объединен в 1.12 (будет в 1.12.4 ) и 1.13 (будет в 1.13.1 )

Выбор вишни только что был объединен в 1.11
Нам просто нужно дождаться следующих выпусков патчей в 3 ветках (но если вы хотите протестировать его, прежде чем я смогу легко создать настраиваемую сборку kube-proxy (или, что еще проще, образ докера гиперкуба с патчем)

Большое спасибо @lbernail ! Было бы неплохо иметь общедоступный образ докера! Я бы с удовольствием это протестировал!

Исправление уже выбрано для версий v1.11, v1.12 и v1.13.

Не могли бы вы протестировать их, чтобы мы могли закрыть эту проблему.

@ m1093782566 я тестирую это. кстати, когда сообщество опубликует для этого небольшой релиз?

Спасибо @berlinsaint , дайте мне результат теста.

когда сообщество опубликует для этого небольшой релиз?

Новый небольшой выпуск с исправлением будет опубликован менее чем через 2 недели.

@emptywee : вот и все: lbernail/hyperkube:v1.12.4-beta.1
Сообщите нам, как это работает для вас!

@lbernail, можно ли использовать его со всем остальным на v1.11.5? Или я должен сначала установить кластер Kubernetes до версии 1.12.4? В любом случае, большое спасибо!

@emptywee да, он должен работать без проблем (я уже несколько месяцев использую kube-proxy 1.11 на кластерах 1.10)

Я также могу сделать сборку 1.11 позже сегодня

@lbernail да, было бы неплохо получить образ из той же версии выпуска.

@emptywee вот и все: lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail После одной ночной беседы журнал ошибок синхронизации ipvs больше не отображается, а
это происходит по крайней мере один раз накануне вечером. Но все же нужно больше времени, чтобы проверить это, большое спасибо, это меня долго раздражало.

Завтра начну тестировать 1.11 и еще пару дней отдаю.

@lbernail Я пробовал тебя lbernail/hyperkube:v1.11.6-beta.1 (Спасибо за это!)
Мы сразу подумали, что все исправлено, так как перестали видеть сообщения журнала can't find the real server . Однако через полтора дня мы наблюдаем проблемы с устаревшими записями ipvs на 3/6 узлах кластера.
Это записи ipvs для службы на сломанном узле кластера.
Перед перезапуском 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

После перезапуска 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 Это была причина, по которой я попал в эту ветку, когда перешел на IPVS 1.11.5. На следующий день я обнаружил, что сервисы недоступны, поэтому я подумал, что kube-proxy завис и не обновляет записи для сервисов.
Это просто для того, чтобы вы знали, что у меня была аналогичная проблема (неправильные IP-адреса в таблице ipvs) с v1.11.5 kube-proxy.

@bjornryden Хорошие новости об ошибках удаления (это то, что исправлял патч)

Тот факт, что серверные модули не обновляются должным образом, является странным, потому что изящное завершение не должно влиять на новые конечные точки (например, если бы некоторые устаревшие конечные точки все еще были там, я был бы менее удивлен)

Не могли бы вы поделиться журналами kube-proxy, связанными с сервисом 10.230.65.211:9494 ?

Кроме того, есть ли какое-либо особое поведение с этой службой / развертыванием? (например, модули обновляются очень часто или за HPA?)

Итак, он работал в течение 2 дней в моем лабораторном кластере с изображением 1.11.6-beta.1 от @lbernail в режиме ipvs.
Пока все хорошо, он не зависает и продолжает обновлять записи ipvs.

Однако одно странное наблюдение:

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         

Первый вызов ipvsadm показывает начальное состояние до того, как я удалил один из модулей службы. Несколько следующих показывают, что одна запись исчезла, поскольку модуль был удален. Однако я не знаю, как должно быть, но он создал вторую запись с тем же IP-адресом, что и оставшийся модуль. А затем он обновил его до правильного IP-адреса нового модуля, который пришел взамен удаленного.

В остальном все было хорошо. Но лабораторный кластер не так загружен, как другие. Комментарий от @bjornryden заставил меня немного побеспокоиться, чтобы попробовать изображение в более загруженных кластерах, где это может повлиять на наших клиентов.

@emptywee Я предполагаю, что удаленный модуль был 10.158.130.24 . Я этого не понимаю:

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 

Дважды иметь один и тот же реальный сервер не имеет смысла. Вы можете воспроизвести это?

Нормальное поведение при удалении модуля должно быть следующим:

• если нет подключений к этому модулю, удалите RS
• если есть соединения, установите вес на 0 (установленные соединения продолжаются, новых соединений нет)
• каждую минуту проверяйте все RS с весом 0 (это то, для чего нужен список изящных завершений) и удаляйте те, у которых больше нет соединений

@lbernail правильно. У удаленного модуля был этот IP-адрес. И да, мне это тоже показалось странным. Я постараюсь воспроизвести, когда у меня будет возможность. Хотели бы вы, чтобы я увеличил количество подробностей журнала, если я смогу воспроизвести то же поведение? Если да, то на каком уровне?

@emptywee : было бы здорово, спасибо, --v=5 должен дать нам много информации
Главное, я даже не думаю, что RS может появиться дважды в VS в IPVS (я этого никогда не видел). Какое ядро ​​вы используете?

@lbernail установит для него значение --v = 5 и попытается воспроизвести, возможно, когда-нибудь в выходные.

Я использую стабильную версию CoreOS:

4.14 совсем недавно, поэтому я был бы удивлен, если бы возникла проблема с IPVS
Я собираюсь попробовать усилить кластер с исправленной версией, чтобы посмотреть, смогу ли я воспроизвести проблему из @bjornryden

@lbernail К сожалению, мне не удалось воспроизвести то поведение дублирования записей ipvs, которое я видел только однажды. Пробовал несколько раз с разными сервисами. Однако я не видел ни одной записи с весом 0, но это можно объяснить тем, что удаляемые мной поды выходят очень быстро. Кроме того, kube-proxy работает более 5 дней. Я мог бы попробовать еще раз в более загруженном кластере здесь.

@emptywee Это "хорошие" новости (даже если бы я предпочел, чтобы мы смогли воспроизвести и понять это, может, это был сбой дисплея в ipvsadm?)

Вес устанавливается на 0 только в том случае, если они являются ActiveConn или InActiveConn. Чтобы увидеть это, просто откройте долгоживущее соединение с сервисом перед удалением связанного модуля (например, с помощью telnet).

5 дней стабильности - хорошая новость! Сообщите нам, как это происходит, когда / если вы пробуете более загруженный кластер

У меня есть несколько небольших улучшений:

• https://github.com/kubernetes/kubernetes/pull/71834 : сделайте изящное завершение работы со службами с использованием sessionAffinity (уже в мастере, избранные варианты созданы для 1.13, 1.12 и 1.11)
• https://github.com/kubernetes/kubernetes/pull/71895 и https://github.com/kubernetes/kubernetes/pull/72106 : поддерживайте плавное завершение при удалении службы (первый уже находится в мастере, я ждем, пока второй соберет оба во всех ветках)

Также были выпущены 1.11.6 , 1.12.4 и 1.13.1 которые содержат исправление в функции удаления.

На выходных я написал небольшую статью об этой проблеме /. Обязательно обновлю на исправленную версию!

@lbernail Конечно, подойдет! Ваш образ гиперкуба такой же, как тот, что был выпущен в 1.11.6? Я установил ваш образ для kube-proxy только в более загруженном кластере и снова переключился на ipvs для тестирования. Вы хотите, чтобы я использовал официальную?

@emptywee Мой образ и 1.11.6 в основном одинаковы: я построил его из главы ветки release-1.11 за несколько дней до официального релиза, так что разница составляет самое большее несколько коммитов, ни один не связан с IPVS. Поэтому я не думаю, что стоит снова обновлять кластер

Плохие новости :( только что мой kube-proxy не смог обновить бэкэнды ipvs. Переключение обратно на iptables и сбор логов. Был запущен kube-proxy с флагом --v=5 .

@lbernail Итак, не уверен, сколько журналов необходимо, но мы в основном столкнулись с проблемой с несколькими службами, у которых не были обновлены IP-адреса бэкэндов ipvs. Журналы, однако, говорят нам, что конечные точки обновлялись правильно:

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

Но когда я проверил его с помощью ipvsadm, он все еще показывал первые два: 10.148.191.69:8080 10.148.192.14:8080

В то время как kubectl -n c-qa4 describe svc ycsdtleuk говорил, что конечные точки - это 10.148.183.70:8080 10.148.184.67:8080 , а в других ящиках записи ipvs для той же самой службы обновлялись правильно.

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

Я в основном смотрел на две коробки одновременно:

(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

Нет очевидного сообщения об ошибке или чего-то кричащего, что указывало бы на какие-либо признаки проблемы. Я могу отправить вам полный файл журнала (18M без сжатия), если хотите.

Короче говоря: кажется, что часть, которая отслеживает изменения сервисов, работает нормально, а часть, которая взаимодействует с модулем ipvs, - нет. Я даже не вижу, чтобы он пытался удалить первые два IP-адреса после их добавления. Что-то где-то застревает.

@emptywee Спасибо за подробный отчет. В этих журналах ничего странного.

Что удивительно, так это то, что syncProxyRules запускается по крайней мере каждые 30 секунд (по умолчанию) и должно согласовывать реальные серверы IPVS с конечными точками. Он вызывает syncEndpoints который запускает AddRealServer и ipvsHandle.NewDestination

Все это происходит перед удалением старых конечных точек, поэтому постепенное завершение не должно влиять на

Не могли бы вы прислать мне полные журналы, чтобы я мог точно увидеть, что происходит между 21:26 и 21:29 ?

Два дополнительных вопроса:

• затронул единственный кубе-прокси, верно?
• была затронута одна служба (другая продолжала нормально обновляться?)

В следующий раз попробуйте отправить SIGABRT процессу, чтобы он распечатал состояния задач.

Когда у меня возникала проблема, он всегда что-то делал внутри libnetwork/ipvs/netlink.go , что заставляет меня подозревать, что системный вызов netlink по какой-то причине зависает.

Извините за мое отсутствие, но выходные, а затем пришлось сосредоточиться на возвращении к iptables для нашей установки.

Оглядываясь назад на запрошенные журналы для службы @lbernail , у нас их много:

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

Мы также видели это:

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

Как сообщали другие, это произошло только на некоторых узлах. К тому времени, когда я обнаружил проблему, у нас было 3 узла кластера, которые были сломаны для этой конкретной службы.

@lbernail Совершенно верно. Вот запрошенная часть журналов, я также включил часть запуска: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Дайте мне знать, если вам понадобится весь файл. Если да, то куда вы хотите, чтобы я его отправил или куда загрузил.

Чтобы ответить на ваши вопросы:

1. В кластере более 60 узлов, я проверил несколько других узлов, запись ipvs верна. Хотя не уверен насчет всех записей. Но на главном узле, через который мы направляем весь трафик службам, по крайней мере две службы не обновлялись должным образом. Могло быть и больше, но как только мы начали получать жалобы от клиентов, мы сразу узнали, что две услуги недоступны. Я собрал логи и перезапустил kube-proxy, чтобы минимизировать влияние. Я сравнил состояние записей ipvs на этом главном узле и на одном из рабочих узлов в рамках устранения неполадок и понял, что это другое. Есть вероятность, что другие узлы могут иметь другие записи, которые не обновляются должным образом, но, поскольку трафик не проходит через них, мы не заметили никакого влияния.

2. Нет, пострадали как минимум две службы. Возможно и больше, но я на это не проверял.

Две интересные вещи из логов:

• 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] никогда не обрабатывается IPVS, но без ошибок, потому что вы сохраняете два старых RS (мы не можем быть уверены, добавление RS не создает журнал)
• 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] не запускает вызов удаления для 10.148.192.14:8080 (там должны быть журналы)

@emptywee - IPVS работал на вас до корректного завершения, или вы использовали iptables?

@ m1093782566 / @ Lion-Wei есть идеи, что здесь может происходить?

@lbernail Мы подождали, пока мы

@emptywee : Я собираюсь добавить еще несколько журналов уровня Info, чтобы попытаться определить проблему. Не могли бы вы запустить более подробную версию на несколько часов? (Я полностью понимаю, если вы не хотите, но я еще не смог воспроизвести на своей стороне)

Мы используем IPVS с мая, и в 1.12.1 и 1.11.1 проблем не было.

Мы также видели, как это происходило на нескольких, но далеко не на всех узлах после обновления до 1.12.3. Затронутые узлы перестали обновлять IPVS через несколько часов после обновления, но не скоординированным образом, как я мог различить.

Следует отметить, что kube-proxy также полностью прекратил ведение журнала в то время, поэтому похоже, что он полностью завис.

Файл журнала, показывающий, что он застревает, и дамп горутины после SIGQUIT (слегка отредактирован)

Файл журнала

Вы можете возразить, что есть какая-то логическая ошибка, вызывающая слишком много взаимодействий с сокетом netlink. Но если связь с netlink не стабильна, ipvs в конце концов зависнет. Если логическая ошибка будет исправлена, достижение этого состояния может занять намного больше времени, но это не значит, что этого не может произойти при достаточном времени.

Вот почему я бы посоветовал иметь какой-то тайм-аут при взаимодействии с netlink; если время операции истекло, закройте сокет netlink и автоматически откройте новый в качестве механизма восстановления.

@matthiasr Хорошо, это хорошие новости (мы также использовали IPVS более 6 месяцев без каких-либо проблем, но еще не обновились до версий, использующих изящное завершение в наших самых загруженных кластерах)

Похоже, у нас где-то тупик

@lbernail, хотя переключить весь кластер на ipvs немного обременительно, но если это поможет решить эту проблему, я не могу. Скажите мне, какое имя изображения использовать, и я сделаю все, что в моих силах, чтобы помочь вам в этом.

Мы вернулись к IPVS 1.11.6, чтобы посмотреть, сможем ли мы воссоздать нашу проблему. Для ведения журнала установлено значение 5, и в последующие дни в кластере выполняются некоторые действия. Я не буду работать завтра, но я захожу в Интернет, чтобы посмотреть, есть ли изображение с усиленным ведением журнала, на которое мне следует изменить.

@matthiasr : 1.12.3 определенно имеет проблему (см. оставшуюся часть этой ветки). Частично это решается в 1.12.4 . Вы получите намного меньше ошибок в журналах. Все это должно исчезнуть: Failed to add destination: 10.zz.yy.xx, error: file exists

У нас все еще есть проблема, когда kube-proxy, кажется, зависает и больше не обновляет реальные серверы.
Я изучил это еще немного:

• от @emptywee кажется, что после того, как проблема началась, мы не видим никаких журналов ни от proxier.go, ни от ipset.go, ни от graceful_termination.go, что, похоже, указывает на то, что мы где-то застряли. @emptywee, можете ли вы проверить, есть ли у вас логи для этих файлов после 21:30?
• в дампе процедуры go есть два системных вызова, получаемых через сокет netlink. Так что у нас может быть проблема. Кроме того, для поддержки постепенного завершения была обновлена ​​библиотека libnetwork / ipvs, поэтому поведение могло измениться. Однако код libnetwork, похоже, устанавливает тайм-ауты send / rcv для сокета netlink (и если он завис, мы должны увидеть количество минут, в течение которых это было): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Интересно, что только в новой версии libnetwork есть таймауты netlink:

libnetwork была обновлена ​​во всех ветвях выпуска (1.11, 1.12 и 1.13), чтобы обеспечить плавное завершение. мы перешли от: ba46b928444931e6865d8618dc03622cac79aa6f к a9cd636e37898226332c439363e2ed0ea185ae92

В старой версии код был: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

Единственные различия в коде IPVS в libnetwork между этими двумя коммитами:

• введение тайм-аута
• добавление ActiveConnections и InactiveConnections к Destination (что требовалось для постепенного завершения)

Интересно, может ли это быть связано.

Высказав еще несколько мыслей по этому поводу, я думаю, что это связано с тем, что теперь у нас есть две горутины, использующие один и тот же сокет netlink (поскольку gracefulTerminationManager работает в своей собственной горутине и использует интерфейс utilipvs.Interface с прокси).

Мы могли бы, вероятно, добавить мьютекс во все вызовы в pkg/util/ipvs/ipvs_linux.go чтобы убедиться, что одна горутина использует сокет netlink в любой момент времени.

@ m1093782566 как ты думаешь?

@lbernail Нет, после 21:30 в этих файлах нет записей.
Вот последние записи для разных файлов:

Последние записи с сайта 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

Последние записи с 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

Последние записи с 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

Все они закончили регистрацию около 21:18 ... Есть какие-нибудь подсказки?

@emptywee Да, это подтверждает гипотезу о тупике между двумя горутинами, совместно использующими сокет netlink. Они оба застревают в ожидании получения сообщений и продолжают безуспешно повторять попытки (из-за тайм-аута получения 3 с).

Я попытаюсь проверить гипотезу и начну работать над исправлением, как только смогу

Я установил 1.12.4 на тестовый кластер и начал повторное развертывание приложения, которое воспроизводило проблему за 1,5 часа, поэтому я думаю, что смогу достаточно надежно протестировать потенциальное исправление.

На приеме netlink снова висят 2 горутины (1 и 107).

У меня есть возможное исправление ошибки, код доступен здесь: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
Идея состоит в том, чтобы защитить все вызовы netlink с помощью Mutex, чтобы избежать взаимоблокировки. Я не уверен, что это лучшее решение, но оно может решить проблему (и, если оно сработает, подтвердите, что мы обнаружили ошибку).

Если вы хотите / можете протестировать это, я создал два изображения с исправлением:

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

Если вы тестируете, дайте нам знать, работает ли это, а если нет, поделитесь интересными журналами и посмотрите горутины, чтобы увидеть, не застряли ли некоторые из них в вызовах netlink.

(Я провел некоторое тестирование на своей стороне, но ограничился небольшим кластером)

Я могу попробовать в понедельник, 24 декабря!

Давай попробуем сегодня. Сообщу о результатах, если таковые имеются.

Это ошибка. Я перешел в режим iptables.

Я также обновился до бета-версии и вскоре снова запустил наши нагрузочные тесты. Обычно ломаются быстро (меньше суток) и довольно стабильно ... скрестив пальцы.

@ li-sen определенно ошибка. Мы работаем над этим

@emptywee и @bjornryden большое спасибо за тестирование!

@lbernail, с удовольствием! Итак, прошло около двух дней с тех пор, как я запустил kube-proxy с образом 1.11.7-beta.1. Это еще не повлияло на нас. Я вижу, что proxier.go и другие горутины все еще живы и печатают в журналах. Я дам ему еще немного времени, так как последние пару дней были очень медленными и тихими, развертываний было не так много. В любом случае, я чувствую, что мьютексы, добавленные @lbernail , помогают :)

Я обновлю этот выпуск / тему к концу недели.

@lbernail

Не могли бы вы поднять PR для решения этой проблемы?

/ повторно открыть
(чтобы следить за отзывами о тестах и ​​перед тем, как делать выбор, если все работает нормально)

@lbernail : Вы не можете повторно открыть проблему / PR, если не являетесь автором или соавтором.

@ m1093782566 можете снова открыть проблему, пока мы не будем полностью уверены, что она решена?

У меня такая же проблема с Kube-proxy ipvs, версия 1.12.3.
Реальные серверы неправильные, и Kube-proxy не может обновить правила ipvs.

Вот последние журналы, и он застрял здесь, больше не печатал новые журналы.

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 : есть две проблемы:

• неудачные удаления: исправлено в 1.12.4
• kube-proxy застревает из-за тупика (проблема, которую вы описываете): надеюсь, исправлено с помощью вчерашнего PR. Мы ждем отзывов от @emptywee и @bjornryden , которые сейчас тестируют патч. Как только мы получим подтверждение, что проблема больше не существует, я создам Cherrypicks для 1.13, 1.12 и 1.11 (если патч сработает, он, вероятно, будет объединен во всех ветках в начале следующей недели и станет частью следующие выпуски патчей)

Я также повторно запускаю свой эксперимент https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 снова с обратным переносом патча на 1.12.4. Отчитаюсь!

У нас не было проблем с доступом к сервисам, пока kube-proxy работал (и работает) в режиме IPVS, и у нас было довольно много развертываний и изменений сервисов. Пока я бы сказал, что патч у нас работает хорошо.

@lbernail Отличная работа по исправлению! Очень признателен!

Хорошо, давайте подождем до понедельника, чтобы мы также получили отзывы от @matthiasr и @bjornryden (я хочу не торопиться с вишен и убедиться, что на этот раз у нас есть чистое исправление)

@lbernail Хорошие новости, спасибо за ответ.

Никаких проблем после 12+ часов 1.12.4 с https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f - без этого я получил блокировку через 1,5 часа, так что это выглядит очень хорошо!

@lbernail У меня еще вопрос, пожалуйста. Если следующий патч будет версия 1.12.5?
Если я просто обновлю kube-proxy до 1.12.5, другие модули (apiserver, kubelet, controller-manager, scheduler ...) сохранят 1.12.3, это нормально? Или мне нужно обновить все юниты?

@VincentFF Надеюсь, это дойдет до 1.12.5, да. Вы можете запустить kube-proxy 1.12.5 с другими модулями, работающими под управлением 1.12.3, без проблем

Обновление: через 24 часа, все еще нет проблем, я прекращаю свой эксперимент и считаю его полным успехом. С нетерпением жду 1.12.5!

Хорошо, это очень хорошие новости. Я собираюсь сделать выборку для всех веток, чтобы как можно скорее получить исправление в официальных выпусках.
Большое спасибо за ваше участие в решении проблемы и тестировании!

Вишня:
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

Могу присоединиться к хору счастливых испытателей. 4 дня без проблем.

Большое спасибо всем участникам, особенно @lbernail. С Новым Годом!

Я собираю его и развертываю для тестирования env, более 24 часов без проблем. С Новым Годом.

Привет, мой env
Ubuntu 16.04.4 LTS
Версия Kubernetes (используйте версию kubectl): v1.13.0
Облачный провайдер или конфигурация оборудования: голое железо, 64-разрядная версия Linux
Ядро 4.4.0-75-generic

та же ошибка:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Попытка удалить rs: 10.200.198.70:9090/TCP/172.200.101.32:9090
E0101 22: 20: 09.742975 267576 proxier.go: 1519] Не удалось получить службу IPVS, ошибка: ожидается, что получена только одна служба = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] Не удалось синхронизировать конечную точку для службы: 10.200.36.192:80/TCP, ошибка: ожидается, что получена только одна служба = 0

Мне нужно перезапустить kube-proxy, исправить

@daigong v1.13.1 исправили это. В моем случае проблем больше, чем через неделю.

@daigong : полное исправление на самом деле будет в 1.13.2 (это зависит от того, как быстро # 72426 будет объединен)

@lbernail @FrostyLeaf
спасибо, я использую # 72426, чтобы проверить эту ошибку

Все в порядке

PR был объединен во все ветки выпуска, поэтому он будет присутствовать в:

• 1.11.7
• 1.12.5
• 1.13.2

@annProg

та же проблема, как 1.12.2, так и 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Сколько стоит ваш почтовый ящик, узнайте это. .малолетний

одна и та же

есть ли шанс на новую сборку в v1.11.x?

Последние пару дней я обновлял страницы релизов почти каждый час в надежде, что появится версия 1.12.5, и я смогу исправить эту ошибку на нескольких кластерах. :-)

@verwilst, ха-ха, тоже самое, не могу дождаться выхода версии 1.11.7 для обновления текущих производственных кластеров. И v1.12.5 тоже, чтобы начать обновление в более низких envs.

Последние пару дней я обновлял страницы релизов почти каждый час в надежде, что появится версия 1.12.5, и я смогу исправить эту ошибку на нескольких кластерах. :-)

Его здесь :-P

Последние пару дней я обновлял страницы релизов почти каждый час в надежде, что появится версия 1.12.5, и я смогу исправить эту ошибку на нескольких кластерах. :-)

Его здесь :-P

Почему его нет в версии 1.11? :(

Была ли эта ошибка исправлена ​​в 1.11.7? Я не видел никаких примечаний к выпуску.

Да, это 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)

Да, я забыл добавить "IPVS" в примечании к выпуску в PR, извините за это
Дайте нам знать, если это работает сейчас! (на всякий случай оставим вопрос открытым на неделю)

С момента обновления до 1.12.5 у нас не было проблем 🎉

Отличные новости!

@ m1093782566 , @thockin Я думаю, мы можем закрыть эту проблему (новых отчетов не будет примерно через 2 месяца)

Для справки, ошибка влияет на начальные выпуски с постепенным завершением:

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

Исправление присутствует после:

• 1.11.7
• 1.12.5
• 1.13.2

/Закрыть

@ m1093782566 : закрытие этой проблемы.

Мы можем снова открыть? Мы видим эту проблему 1.12.7.

да, мы тоже наблюдаем проблемы в 1.12.9

Вы уверены, что это та же проблема?
Можете ли вы опубликовать логи экземпляра kube-proxy?

извините, возможно, это было ложное предупреждение ... Мы видим, что это журналы, а это не та же ошибка

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

по какой-то причине, когда кластер находится под нагрузкой, он не может выполнить маршрутизацию к некоторым IP-адресам службы кластера. Мы все еще не уверены, что это проблема IPVS.

Может быть, распространение конечной точки требует времени, если apiserver перегружен?

Это обычные сообщения информационного уровня:
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

Я могу подтвердить тот же лог в 1.14.4. Когда выходит этот лог?

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

Это просто информационные журналы:

• Trying to delete rs : серверный модуль из удален, пытается удалить его. Если у него есть существующие соединения, введите изящное завершение, в противном случае удалите идентификатор
• Deleting rs : сервер не имеет соединения, удаление его из IPVS

@andrewsykim Может быть, теперь мы могли бы уменьшить уровень этих журналов, чтобы они, например, отображались только выше v = 5?

В https://github.com/kubernetes/kubernetes/pull/78395 мы подняли уровень журнала с v = 0 до v = 2, я думаю, что v = 5 имеет смысл. https://github.com/kubernetes/kubernetes/pull/80100 для обновления