Kubernetes: Le mode ipvs de kube-proxy se bloque après quelques heures, nécessite un redémarrage manuel

/ sig network

la même erreur. mise à niveau de 1.11.1. Tout devient bon sauf que kube-proxy devient instable, certains pods temporels ne peuvent pas accéder à svc bien que leurs points de terminaison soient ok .. Et la même chose que la résolution de nom. donc je pense qu'il peut exister un bug important ici.

/ zone ipvs

@gjcarneiro résolvez -vous ce problème?

Eh bien, j'ai basculé le cluster en mode par défaut (iptables), semble être assez stable depuis lors ...

@ kubernetes / sig-network-bugs

@berlinsaint :
@ kubernetes / sig-network-bugs

même problème, à la fois 1.12.2 et 1.13.0-beta1. @ m1093782566 @ Lion-Wei

@gjcarneiro voulez-vous dire que dans le noyau 4.15, il a le même problème?

@annProg

même problème, à la fois 1.12.2 et 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Combien coûte votre boîte aux lettres, apprenez à la connaître. .juvénile

@annProg

même problème, à la fois 1.12.2 et 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Combien coûte votre boîte aux lettres, apprenez à la connaître. .juvénile

Cliquez sur mon avatar pour voir

Je vois également cela à plusieurs reprises dans mon système de journalisation centralisé:

  | 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

J'exécute la v1.12.3 (nouvelle installation, pas une mise à niveau).

Salut à tous. Merci pour le rapport, je vais faire une recherche et essayer de comprendre ce qui s'est passé, tout progrès que je rapporterai ici.

Outre ce qui s'est passé, ce qui est bon à découvrir, je ne me sens pas confiant quant à IPVS tant qu'il n'y a pas de code en place qui détecte et réinitialise un socket netlink cassé. Parce que d'après ce que je peux deviner à partir des journaux et des traces, c'est que la socket netlink entre dans un état cassé et que la tâche qui lit / écrit de / vers elle se bloque pour toujours. Je pense que kube-proxy doit avoir un code qui détecte ce problème, et si cela se produit, créez un nouveau socket netlink à partir de zéro et redémarrez peut-être la tâche qui le gère. Mais non, je ne fais pas de bénévolat, je ne connais même pas Go, désolé.

Parce que d'après ce que je peux deviner à partir des journaux et des traces, c'est que la socket netlink entre dans un état cassé et que la tâche qui lit / écrit de / vers elle se bloque pour toujours.

Nous avons mis à jour la version go netlink il y a quelques jours pour prendre en charge la terminaison gracieuse. La bibliothèque netlink fonctionnait assez stable avant. Je ne sais pas si c'est la cause.

1.12.3 avec la même erreur.
Après avoir filtré le journal INFO,
exécuter 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;
et tout le journal du nœud proxy est

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

BTW. au-dessus de mes journaux, kube-proxy semble avoir encore de nombreux problèmes avec iptables-restore. tous mes nœuds sont UBUNTU 16.04 qui ont la version 1.6.0 d'iptable.
@ m1093782566 @ Lion-Wei

Nous voyons cela se produire lors de la mise à jour de la 1.12.1. il doit donc être dans le delta de 1.12.1 et 1.12.2.

Le problème est lié à la résiliation gracieuse et je pense que nous avons corrigé le bogue dans la v1.13.1.

@ m1093782566 le correctif sera-t-il rétroporté sur la ligne 1.12? pour le moment, cela bloque le correctif de sécurité 1.12.3 pour nous.

Obtenu la même chose avec la mise à niveau de 1.11.2 à 1.11.5.

@ m1093782566 pouvez-vous fournir plus d'informations sur le correctif? Je serais intéressé de regarder le commit.

C'est assez fou, nous avons été mordus très fort plus tôt dans la journée.

Nous voyons cela se produire lors de la mise à jour de la 1.12.1. il doit donc être dans le delta de 1.12.1 et 1.12.2.

Obtenu la même chose avec la mise à niveau de 1.11.2 à 1.11.5.

Le bogue a-t-il été cueilli par des chery?

Cela ressemble au PR qui résout le problème: https://github.com/kubernetes/kubernetes/pull/71515

Vrai @ Quentin-M

Oui, cela vient probablement du correctif de la fonction delete (pas vraiment lié au titre du PR).

@ m1093782566 Je peux créer le choix de la cerise pour 1.12. Voulons-nous rétroporter le PR complet ou uniquement le correctif dans la fonction de suppression? (pour éviter de changer de comportement avec les flux UDP en 1.12)

Le bogue a-t-il été cueilli par des chery?

@ Quentin-M, il semble que le bogue ait été introduit par https://github.com/kubernetes/kubernetes/pull/66012 qui a été sélectionné avec soin pour les versions 1.11.5 et 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

Je pense que tous les # 71515 devraient être choisis avec soin. La terminaison gracieuse dans son ensemble n'a été introduite et sélectionnée qu'avec # 66012, donc le changement de comportement s'est déjà produit.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 toujours périmé sur nos clusters. 60% d'entre eux sont restés bloqués en moins de 24 heures. Essayer 1.12.1 maintenant.

@ Quentin-M: Pouvez-vous vérifier les journaux sur kube-proxy et confirmer que ces types de messages ont disparu:

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

Les deux sont liés à la fonction de suppression fixée dans le PR. Si ceux-ci ont disparu et que vous voyez toujours le problème, ce correctif n'est pas suffisant

De plus, si tout fonctionne avec 1.12.1 , il y a une forte probabilité que le problème vienne d'une terminaison gracieuse (# 66012)

Je pense que j'ai une idée: je me demande ce qui se passe si nous essayons d'ajouter un serveur réel qui est toujours en fin de ligne gracieuse. Dans ce cas, nous devrions simplement augmenter le poids à 1 et le supprimer de la liste des terminaisons gracieuses.

J'essaierai de tester ce scénario dès que possible (mais ce sera délicat car je suis à Kubecon la semaine prochaine)

@ Lion-Wei qu'en pensez-vous?

Ok scratch ça, je viens de tester et ça marche bien. Le code responsable est ici: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

Dans ce cas, le RS est supprimé de la liste gracefulDelete et d'IPVS RS. Je me demande si remettre le poids à 1 à la place ne serait pas mieux

J'essaierai d'autres choses basées sur cette partie des journaux, ce qui semble indiquer d'essayer de synchroniser les points de terminaison pour un service supprimé

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

Ok après une vérification rapide, le commit qui corrige le problème de suppression n'est pas dans v1.13.1-beta.0 ni dans v1.14.0-alpha.0 qui a été coupé le 7 novembre
Je pense que ce sera dans la prochaine version alpha 1.14 qui sera basée sur master

Je vais aussi créer le choix de la cerise pour 1.13

Vous avez un problème avec la mise à niveau de la 1.12.0 à la 1.13.0, semble être lié à celui-ci, mais pas le même.

Nous ne pouvons pas le résoudre en revenant à iptables. Aidez-moi, s'il vous plaît.

Je l'ai posté sur stackoverflow

J'ai obtenu la même chose sur 1.11.5. Passage temporaire d'ipvs à iptables.

Idem au 1.11.5. Impossible de revenir à la version 1.11.4 en raison de la vulnérabilité présente. J'ai dû passer à iptables. Le correctif pour cela va-t-il être publié pour la 1.11.x?

Vous pouvez restaurer kube-proxy très spécifiquement, sans être affecté par la vulnérabilité.

@ Quentin-M Oui, cette pensée a frappé mon esprit, mais d'autre part, si je le faisais, je n'aurais pas une résiliation gracieuse, qui a toujours été là avec iptables. Pas sûr que nos clients aimeraient le changement.

@ Quentin-M signifie-t-il qu'il n'y aura pas de correctif pour 1.11.x pour résoudre ce bogue?

@emptywee J'ai créé un choix de cerises pour 1.11: https://github.com/kubernetes/kubernetes/pull/71848
Espérons qu'il sera fusionné très bientôt et sera en 1.11.6

Il a déjà été fusionné en 1.12 (sera en 1.12.4 ) et 1.13 (sera en 1.13.1 )

Le cherry-pick vient d'être fusionné dans 1.11 aussi
Nous avons juste besoin d'attendre les prochaines versions de correctifs dans les 3 branches (mais si vous voulez le tester avant de pouvoir créer facilement une version personnalisée de kube-proxy (ou, encore plus simple, une image de docker hyperkube avec le correctif)

Merci beaucoup @lbernail ! Une image de docker accessible au public serait bien d'avoir! J'adorerais le tester!

Le correctif est déjà sélectionné pour les v1.11, v1.12 et v1.13.

Voudriez-vous les tester afin que nous puissions résoudre ce problème.

@ m1093782566 Je teste ça. btw, quand la communauté publiera-t-elle la petite version pour cela?

Merci @berlinsaint , laissez-moi le résultat du test.

quand la communauté publiera-t-elle la petite version pour cela?

La nouvelle petite version avec le correctif sera publiée dans moins de 2 semaines.

@emptywee : c'est lbernail/hyperkube:v1.12.4-beta.1
Faites-nous savoir comment cela fonctionne pour vous!

@lbernail est-il correct de l'utiliser avec tout le reste de la v1.11.5? Ou devrais-je d'abord déplacer mon cluster Kubernetes vers la v1.12.4? Bref, merci beaucoup!

@emptywee oui cela devrait fonctionner sans aucun problème (j'utilise kube-proxy 1.11 sur des clusters 1.10 depuis des mois)

Je peux aussi faire une version 1.11 plus tard aujourd'hui

@lbernail ouais, ce serait bien d'avoir une image de la même version.

@emptywee, c'est parti : lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail Après une nuit d'observation, le journal des erreurs de synchronisation ipvs ne s'affiche plus, tandis que
il se produit au moins une fois la veille. Mais j'ai encore besoin de plus de temps pour le vérifier, merci beaucoup, cela m'a ennuyé longtemps.

Je vais commencer à tester demain sur 1.11 et je vais lui donner quelques jours aussi.

@lbernail je t'ai essayé lbernail/hyperkube:v1.11.6-beta.1 (Merci pour ça!)
Nous avons immédiatement pensé que les choses avaient été corrigées, car nous avons arrêté de voir les messages de journal can't find the real server . Cependant, après un jour et demi, nous constatons des problèmes avec les entrées ipvs périmées sur 3/6 nœuds de cluster.
Il s'agit des entrées ipvs pour un service sur un nœud de cluster cassé.
Avant de redémarrer 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

Après avoir redémarré 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 C'est la raison pour laquelle je suis entré dans ce fil lorsque je suis passé à IPVS sur 1.11.5. Le jour suivant, j'ai trouvé des services inaccessibles, alors j'ai pensé que kube-proxy s'était bloqué et ne mettrait pas à jour les entrées pour les services.
C'est juste pour vous faire savoir que j'ai eu un problème similaire (mauvaises adresses IP dans la table ipvs) avec la v1.11.5 de kube-proxy.

@bjornryden Bonne nouvelle pour les erreurs de suppression (c'était ce à quoi le patch s'adressait)

Le fait que les backends ne soient pas correctement mis à jour est étrange car une terminaison gracieuse ne devrait pas affecter les nouveaux points de terminaison (si certains points de terminaison obsolètes étaient toujours là, par exemple, je serais moins surpris)

Pourriez-vous partager les logs de kube-proxy liés au service 10.230.65.211:9494 ?

En outre, un comportement particulier avec ce service / déploiement? (par exemple, les pods sont-ils mis à jour très fréquemment, ou derrière un HPA?)

Il fonctionne donc depuis 2 jours dans mon cluster de laboratoire avec l'image 1.11.6-beta.1 de @lbernail en mode ipvs.
Jusqu'ici tout va bien, il ne s'est pas bloqué et continue de mettre à jour les entrées ipvs.

Une étrange observation cependant:

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         

Le premier appel à ipvsadm montre l'état initial avant de supprimer l'un des pods du service. Peu de personnes montrent ensuite qu'une entrée a disparu, car le pod a été supprimé. Cependant, je ne sais pas si c'est censé être, mais cela a créé une deuxième entrée avec la même adresse IP que le pod qui était parti. Et puis il l'a mis à jour avec la bonne adresse IP du nouveau pod qui est venu remplacer celui supprimé.

A part ça, ça va. Mais le cluster de laboratoires n'est pas aussi occupé que les autres. Le commentaire de @bjornryden m'a un peu inquiété d'essayer l'image dans des clusters plus occupés, où cela peut avoir un impact sur nos clients.

@emptywee Je suppose que le pod supprimé était 10.158.130.24 . Je ne comprends pas ça:

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 

Avoir deux fois le même serveur réel n'a pas de sens. Pouvez-vous le reproduire?

Le comportement normal lors de la suppression de pod doit être:

• s'il n'y a pas de connexion à ce pod, retirez le RS
• s'il y a des connexions, définissez le poids sur 0 (les connexions établies continuent, pas de nouvelles connexions)
• toutes les minutes, vérifiez tous les RS de poids 0 (c'est à cela que sert la liste de terminaison gracieuse) et supprimez ceux qui n'ont plus de connexions

@lbernail correct. Le pod supprimé avait cette adresse IP. Et oui, cela me paraissait aussi étrange. J'essaierai de reproduire quand j'en aurai l'occasion. Souhaitez-vous que j'augmente la verbosité du journal si je suis capable de reproduire le même comportement? Si oui, à quel niveau?

@emptywee : ce serait super merci, --v=5 devrait nous donner plein d'informations
L'essentiel est que je ne pense même pas qu'un RS puisse apparaître deux fois dans un VS en IPVS (je n'ai jamais vu cela). Quel noyau utilisez-vous?

@lbernail le mettra à --v = 5 et essaiera de se reproduire, probablement pendant le week-end.

Je suis sur CoreOS stable:

4.14 est très récent, je serais donc surpris s'il y avait un problème IPVS
Je vais essayer de stresser un cluster avec la version corrigée pour voir si je peux reproduire le problème de @bjornryden

@lbernail Malheureusement, je n'ai pas pu reproduire ce comportement de duplication d'entrée ipvs que je n'ai vu qu'une seule fois. Essayé plusieurs fois, avec différents services. Cependant, je n'ai vu aucune entrée avec un poids 0, mais cela pourrait s'expliquer par le fait que les pods que je supprime sortent très rapidement. De plus, kube-proxy a été réactif après avoir fonctionné pendant plus de 5 jours. Je pourrais essayer à nouveau de la manière dont le cluster est plus occupé ici.

@emptywee C'est une "bonne" nouvelle (même si je préfère que nous puissions la reproduire et la comprendre, c'était peut-être un problème d'affichage dans ipvsadm?)

Le poids n'est défini sur 0 que s'il s'agit de certains ActiveConn ou InActiveConn. Pour le voir, ouvrez simplement une connexion longue durée à un service avant de supprimer le pod associé (par exemple en utilisant telnet)

5 jours de stabilité, c'est une bonne nouvelle! Faites-nous savoir comment cela se passe lorsque / si vous essayez sur un cluster plus occupé

J'ai quelques petites améliorations en cours:

• https://github.com/kubernetes/kubernetes/pull/71834 : faites fonctionner la résiliation gracieuse avec les services utilisant sessionAffinity (déjà dans master, choix de cerises créés pour 1.13, 1.12 et 1.11)
• https://github.com/kubernetes/kubernetes/pull/71895 et https://github.com/kubernetes/kubernetes/pull/72106 : supporte la résiliation gracieuse lors de la suppression d'un service (le premier est déjà dans master, je suis en attendant que le second choisisse les deux dans toutes les branches)

De plus, 1.11.6 , 1.12.4 et 1.13.1 ont été publiés et contiennent le correctif dans la fonction de suppression

J'ai écrit un court article sur la question ce week-end /. Je vais m'assurer de le mettre à jour avec la version corrigée!

@lbernail Bien sûr, fera l'affaire! Votre image d'Hyperkube est-elle la même que celle qui a été publiée en 1.11.6? J'ai installé votre image pour kube-proxy uniquement dans le cluster le plus occupé et je suis à nouveau passé à ipvs pour les tests. Voudriez-vous que j'utilise la version officielle?

@emptywee Mon image et la 1.11.6 sont fondamentalement les mêmes: je l'ai construite à partir de la tête de la branche release-1.11 quelques jours avant la sortie officielle donc la différence est au plus quelques commits, aucun n'impliquant IPVS. Je ne pense donc pas que cela vaille la peine de mettre à jour à nouveau votre cluster

Mauvaise nouvelle: (Je viens de recevoir mon kube-proxy n'a pas réussi à mettre à jour les backends ipvs. Revenir à iptables et collecter les journaux. Kube-proxy fonctionnait avec l'indicateur --v=5 .

@lbernail Donc,

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

Mais quand je l'ai vérifié avec ipvsadm, il affichait toujours les deux premiers: 10.148.191.69:8080 10.148.192.14:8080

Alors que kubectl -n c-qa4 describe svc ycsdtleuk disait que les points de terminaison sont 10.148.183.70:8080 10.148.184.67:8080 , et sur d'autres boîtes, les entrées ipvs pour le même service étaient mises à jour correctement.

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

Je regardais essentiellement ce qui suit sur deux boîtes en même temps:

(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

Il n'y a aucun message d'erreur évident ou quoi que ce soit qui crie qui indiquerait des signes d'un problème n'importe où. Je peux vous envoyer directement le fichier journal complet (18M non compressé), si vous le souhaitez.

En bref: on a l'impression que la partie qui écoute les changements de services fonctionne correctement, mais que la partie qui interagit avec le module ipvs ne l'est pas. Je ne vois même pas qu'il essayait de supprimer les deux adresses IP initiales une fois qu'il les a ajoutées. Quelque chose se bloque quelque part.

@emptywee Merci pour le rapport détaillé. Rien de bizarre dans ces journaux.

Ce qui est surprenant, c'est que syncProxyRules est exécuté au moins toutes les 30 secondes (par défaut) et devrait réconcilier les serveurs réels IPVS avec les points de terminaison. Il appelle syncEndpoints ce qui déclenche AddRealServer et ipvsHandle.NewDestination

Tout cela se produit avant la suppression des anciens points de terminaison et ne devrait donc pas être affecté par une résiliation progressive

Pourriez-vous m'envoyer les journaux complets afin que je puisse voir exactement ce qui se passe entre 21:26 et 21:29 ?

Deux questions supplémentaires:

• un seul proxy kube a été touché, non?
• Un seul service a-t-il été affecté (l'autre a-t-il continué à se mettre à jour normalement?)

La prochaine fois, essayez d'envoyer SIGABRT au processus, afin qu'il imprime les états des tâches.

Quand j'ai eu le problème, il faisait toujours quelque chose à l'intérieur de libnetwork/ipvs/netlink.go , ce qui m'amène à soupçonner que l'appel système netlink est bloqué pour une raison quelconque.

Désolé pour mon absence, mais le week-end et j'ai ensuite dû se concentrer sur le retour à iptables pour notre configuration.

En regardant les journaux demandés pour le service, @lbernail , nous en avons beaucoup:

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

Nous avons également vu ceux-ci:

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

Tout comme d'autres l'ont signalé, cela ne s'est produit que sur certains nœuds. Au moment où j'ai trouvé le problème, nous avions 3 nœuds de cluster qui étaient cassés pour ce service spécifique.

@lbernail Absolument. Voici le morceau demandé des journaux, j'ai également inclus le morceau de démarrage: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Faites-moi savoir si vous avez besoin du fichier complet. Si oui, où vous souhaitez que je l'envoie ou que je la télécharge.

Pour répondre à tes questions:

1. Le cluster a plus de 60 nœuds, j'ai vérifié sur quelques autres nœuds, l'entrée ipvs était correcte. Pas sûr de toutes les entrées. Mais sur le nœud maître, à travers lequel nous acheminons tout le trafic vers les services, au moins deux services n'étaient pas mis à jour correctement. Il pourrait y en avoir plus, mais une fois que nous avons commencé à recevoir des plaintes de clients, nous avons immédiatement entendu dire que deux services n'étaient pas accessibles. J'ai collecté des journaux et redémarré kube-proxy pour minimiser l'impact. J'ai comparé l'état des entrées ipvs sur ce nœud maître et sur l'un des nœuds de travail dans le cadre du dépannage et j'ai réalisé que c'était différent. Il est possible que d'autres nœuds aient des entrées différentes qui ne soient pas mises à jour correctement, mais comme le trafic ne passe pas par eux, nous n'avons remarqué aucun impact.

2. Non, au moins deux services ont été touchés. Peut-être plus, mais je n'ai pas vérifié.

Deux choses intéressantes dans les journaux:

• 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] n'est jamais traité par IPVS mais pas d'erreur car vous gardez les deux anciens RS (on ne peut pas être sûr, l'ajout d'un RS ne génère pas de log)
• I1217 21:28:21.517538 1 endpoints.go:234] Setting endpoints for "c-qa4/ycsdtleuk:http" to [10.148.183.68:8080 10.148.187.41:8080 10.148.191.69:8080] ne déclenche pas l'appel de suppression pour 10.148.192.14:8080 (nous devrions y avoir des journaux)

@emptywee était-ce normale ou utilisiez-vous iptables?

@ m1093782566 / @ Lion-Wei une idée de ce qui pourrait se passer ici?

@lbernail Nous avons attendu la mise à niveau vers la 1.11 pour passer à ipvs (je crois que c'est à ce moment-là que la version GA est arrivée pour cette fonctionnalité) et nous sommes passés directement à la 1.11.5 et c'était notre première tentative de commencer à utiliser ipvs.

@emptywee : Je vais ajouter d'autres journaux de niveau Info pour essayer de localiser le problème. Seriez-vous d'accord pour exécuter une version plus détaillée pendant quelques heures? (Je comprends tout à fait si vous préférez ne pas le faire, mais je n'ai pas encore pu reproduire de mon côté)

Nous utilisons IPVS depuis mai et n'avons eu aucun problème avec les versions 1.12.1 et 1.11.1.

Nous avons également vu cela se produire sur plusieurs nœuds, mais de loin pas sur tous, après la mise à niveau vers la 1.12.3. Les nœuds affectés ont cessé de mettre à jour IPVS quelques heures après la mise à niveau, mais pas d'une manière coordonnée que je pourrais discerner.

Une chose à noter est que kube-proxy a également arrêté complètement la journalisation à ce moment-là, il semble donc qu'il soit complètement bloqué.

Fichier journal montrant qu'il est bloqué et un vidage de goroutine après SIGQUIT (légèrement expurgé)

fichier journal de @matthiasr montre à nouveau un goroutine bloqué la lecture de socket netlink. Comme moi.

Vous pourriez affirmer qu'il y a une erreur logique causant trop d'interactions avec le socket netlink. Mais si la communication avec netlink n'est pas solide, ipvs finira par se bloquer. Si l'erreur logique est corrigée, cela peut prendre beaucoup plus de temps pour atteindre cet état, mais cela ne signifie pas que cela ne peut pas se produire avec suffisamment de temps.

C'est pourquoi je conseillerais d'avoir une sorte de délai d'expiration dans les interactions netlink; si l'opération expire, fermez le socket netlink et ouvrez-en un nouveau automatiquement, comme mécanisme de récupération.

@matthiasr OK, c'est une bonne nouvelle (nous utilisons également IPVS depuis plus de 6 mois sans aucun problème, mais nous n'avons pas encore mis à jour les versions utilisant une terminaison gracieuse sur nos clusters les plus occupés)

On dirait que nous pouvons avoir une impasse quelque part

@lbernail bien qu'il soit un peu fastidieux de basculer l'ensemble du cluster sur ipvs, si cela peut aider à résoudre ce problème, je suis en panne. Dites-moi le nom de l'image à utiliser et je ferai tout ce qui est en mon pouvoir pour vous aider.

Nous sommes revenus à IPVS sur 1.11.6 pour voir si nous pouvons recréer notre problème. Journalisation définie sur 5 et exécution d'une activité dans le cluster au cours des prochains jours. Je ne travaillerai pas demain, mais je vais apparaître en ligne pour voir s'il y a une image avec une journalisation accrue vers laquelle je devrais changer.

@matthiasr : 1.12.3 définitivement un problème (voir le reste de ce fil). Une partie est résolue en 1.12.4 . Vous obtiendrez beaucoup moins d'erreurs dans les journaux. Tout cela devrait disparaître: Failed to add destination: 10.zz.yy.xx, error: file exists

Nous avons toujours le problème où kube-proxy semble se bloquer et ne met plus à jour les serveurs réels.
Je l'ai examiné un peu plus:

• de @emptywee, il semble qu'après le début du problème, nous ne voyons aucun journal de proxier.go, ipset.go ou graceful_termination.go, ce qui semble indiquer que nous sommes bloqués quelque part. @emptywee pouvez-vous vérifier si vous avez des journaux pour ces fichiers après 21h30?
• dans le vidage de la routine go, il y a deux appels système reçus sur un socket netlink. On pourrait donc avoir un problème là-bas. De plus, pour prendre en charge une terminaison gracieuse, libnetwork / ipvs a été mis à niveau afin que le comportement ait changé. Cependant, le code libnetwork semble définir les délais d'envoi / rcv sur le socket netlink (et s'il était bloqué, nous devrions voir le nombre de minutes qu'il a été): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Fait intéressant, seule la nouvelle version de libnetwork a des délais d'expiration de lien réseau:

libnetwork a été mis à niveau dans toutes les branches de version (1.11, 1.12 et 1.13) pour permettre une terminaison gracieuse. nous sommes passés de: ba46b928444931e6865d8618dc03622cac79aa6f à a9cd636e37898226332c439363e2ed0ea185ae92

Dans l'ancienne version, le code était: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

Les seules différences dans le code IPVS dans libnetwork entre ces 2 commits sont:

• introduction du timeout
• ajout de ActiveConnections et InactiveConnections à Destination (qui était requis pour une résiliation gracieuse)

Je me demande si cela pourrait être lié.

Après avoir réfléchi à la question, je pense que cela vient du fait que nous avons maintenant deux goroutines utilisant le même socket netlink (car le gracefulTerminationManager fonctionne dans sa propre goroutine et partage l'interface utilipvs.Interface avec le proxy).

Nous pourrions probablement ajouter un mutex dans tous les appels dans pkg/util/ipvs/ipvs_linux.go pour nous assurer qu'un seul goroutine utilise la socket netlink à un moment donné.

@ m1093782566 qu'en pensez-vous?

@lbernail Non, il n'y a aucune entrée de ces fichiers après 21h30.
Voici les dernières entrées pour divers fichiers:

Dernières entrées 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

Dernières entrées 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

Dernières entrées 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

Ils ont tous terminé la journalisation vers 21h18 ... Cela donne-t-il des indices?

@emptywee Oui cela confirme l'hypothèse que nous avons un blocage entre les deux goroutines partageant la socket netlink. Ils sont tous deux bloqués en attente de recevoir des messages et continuent de réessayer sans succès (en raison du délai de réception de 3 secondes).

J'essaierai de valider l'hypothèse et je commencerai à travailler sur un correctif dès que possible

J'ai mis 1.12.4 sur un cluster de test et j'ai commencé à redéployer une application, qui reproduisait le problème en 1,5 heure, donc je pense que je serai en mesure de tester un correctif potentiel de manière assez fiable.

Il y a à nouveau 2 goroutines (1 et 107) accrochées à un Netlink Receive.

J'ai un correctif potentiel pour le bogue, le code est disponible ici: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
L'idée est de protéger tous les appels netlink avec un Mutex pour éviter l'impasse. Je ne suis pas sûr que ce soit la meilleure solution, mais cela pourrait résoudre le problème (et si cela fonctionne, confirmez que nous avons identifié le bogue).

Si vous voulez / pouvez le tester, j'ai créé deux images avec le correctif:

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

Si vous testez, faites-nous savoir si cela fonctionne et si ce n'est pas le cas, partagez des journaux intéressants et regardez les goroutines pour voir si certains semblent bloqués dans les appels netlink.

(J'ai fait quelques tests de mon côté mais limité à un petit cluster)

Je vais peut-être essayer le lundi 24 décembre!

Essayez-le aujourd'hui. Rapportera les résultats, le cas échéant.

C'est un bug. Je suis passé en mode iptables.

J'ai également mis à niveau vers la version bêta et redémarré sous peu nos tests de charge. Nous cassons généralement rapidement (moins d'une journée) et assez régulièrement ... croiser les doigts.

@ li-sen définitivement un bug. Nous y travaillons

@emptywee et @bjornryden merci beaucoup pour les tests!

@lbernail mon plaisir! Cela fait donc environ deux jours que j'ai lancé kube-proxy avec l'image 1.11.7-beta.1. Cela ne nous a pas encore pendu. Je peux voir que proxier.go et d'autres goroutines sont toujours en vie et impriment dans les journaux. Je vais lui donner un peu plus de temps car les deux derniers jours ont été très lents et calmes, il n'y a pas beaucoup de déploiements en cours. Quoi qu'il en soit, j'ai le sentiment que les mutex ajoutés par @lbernail aident :)

Je mettrai à jour ce problème / fil de discussion d'ici la fin de la semaine.

@lbernail

Souhaitez-vous s'il vous plaît soulever un PR pour résoudre ce problème?

/rouvrir
(pour garder un œil sur les commentaires des tests et avant de créer des sélections si tout fonctionne bien)

@lbernail : Vous ne pouvez pas rouvrir un problème / PR à moins que vous ne l'ayez créé ou que vous ne soyez un collaborateur.

@ m1093782566 pouvez-vous rouvrir le problème jusqu'à ce que nous soyons complètement sûrs qu'il est résolu?

J'ai le même problème d'ipvs Kube-proxy, version 1.12.3.
Les vrais serveurs sont erronés et Kube-proxy ne peut pas actualiser les règles ipvs.

Voici les derniers journaux et il est resté ici, n'a plus imprimé de nouveaux journaux.

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 : il y a deux problèmes:

• suppressions échouées: corrigé dans 1.12.4
• kube-proxy est bloqué en raison d'une impasse (qui est le problème que vous décrivez): avec un peu de chance résolu avec le PR d'hier. Nous attendons les commentaires de @emptywee et @bjornryden qui testent actuellement le correctif. Dès que nous aurons confirmation que le problème n'est plus présent, je créerai les cherrypicks pour 1.13, 1.12 et 1.11 (si le correctif fonctionne, il sera probablement fusionné dans toutes les branches au début de la semaine prochaine et fera partie de les prochaines versions de patch)

Je relance également mon expérience https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 à nouveau, avec le correctif rétroporté sur 1.12.4. Fera rapport!

Nous n'avons eu aucun problème d'accès aux services pendant que kube-proxy fonctionnait (et est) en mode IPVS et nous avons eu plusieurs déploiements et modifications des services. Jusqu'à présent, je dirais que le correctif fonctionne bien pour nous.

@lbernail Excellent travail pour le réparer! Très appréciée!

Ok, attendons jusqu'à lundi pour que nous obtenions également les commentaires de @matthiasr et @bjornryden (je veux éviter de précipiter les choix de cerises et m'assurer que nous avons une solution propre cette fois)

@lbernail Bonne nouvelle, grâce à votre réponse.

Aucun problème après plus de 12 heures sur 1.12.4 avec https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f - sans cela, j'ai eu un blocage en 1,5 heure, donc ça a l'air très bien!

@lbernail J'ai une autre question, s'il vous plaît. Si le prochain patch est la version 1.12.5?
Si je mets simplement à jour kube-proxy vers la 1.12.5, les autres unités (apiserver, kubelet, controller-manager, scheduler ...) conservent la 1.12.3, est-ce que ça va? Ou je dois améliorer toutes les unités?

@VincentFF J'espère qu'il arrivera à 1.12.5 oui. Vous pouvez exécuter kube-proxy 1.12.5 avec d'autres unités exécutant 1.12.3, pas de problème

Mise à jour: après 24 heures, toujours pas de problèmes, j'arrête mon expérience maintenant et considère cela comme un succès complet. Dans l'attente de la 1.12.5!

Ok, c'est une très bonne nouvelle. Je vais créer le choix pour toutes les branches afin d'obtenir le correctif dans les versions officielles dès que possible.
Merci beaucoup pour votre implication dans la résolution du problème et les tests!

Choix de cerises:
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

Je peux rejoindre la chorale des testeurs heureux. 4 jours sans problème.

Merci beaucoup à toutes les personnes impliquées, en particulier @lbernail. Bonne année!

Je le construis et le déploie pour tester env, plus de 24 heures n'ont aucun problème. Bonne année.

Bonjour, mon env est
Ubuntu 16.04.4 LTS
Version Kubernetes (utilisez la version kubectl): v1.13.0
Fournisseur de cloud ou configuration matérielle: bare metal, Linux 64 bits
Kernel 4.4.0-75-générique

même bug:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Tentative de suppression de rs: 10.200.198.70:9090/TCP/172.200.101.32:9090
E0101 22: 20: 09.742975 267576 proxier.go: 1519] Impossible d'obtenir le service IPVS, erreur: un seul service attendu = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] Échec de la synchronisation du point de terminaison pour le service: 10.200.36.192:80/TCP, err: un seul service attendu = 0

J'ai besoin de redémarrer kube-proxy pour le réparer

@daigong v1.13.1 a corrigé ce problème. Dans mon cas, pas de problèmes après plus d'une semaine.

@daigong : le correctif complet sera en fait dans 1.13.2 (cela dépend de la rapidité avec laquelle # 72426 est fusionné)

@lbernail @FrostyLeaf
merci, j'utilise # 72426 pour tester ce bug

Tout va bien maintenant

Le PR a été fusionné dans toutes les branches de publication, il sera donc présent dans:

• 1.11.7
• 1.12.5
• 1.13.2

@annProg

même problème, à la fois 1.12.2 et 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Combien coûte votre boîte aux lettres, apprenez à la connaître. .juvénile

même

une chance pour une nouvelle version en v1.11.x?

J'ai actualisé les pages de versions à peu près toutes les heures ces derniers jours dans l'espoir que la version 1.12.5 apparaisse afin que je puisse corriger ce bogue sur plusieurs clusters. :-)

@verwilst haha, pareil, j'ai hâte que la v1.11.7 soit publiée pour mettre à niveau les clusters de production actuels. Et v1.12.5 aussi pour commencer la mise à niveau dans les environnements inférieurs.

J'ai actualisé les pages de versions à peu près toutes les heures ces derniers jours dans l'espoir que la version 1.12.5 apparaisse afin que je puisse corriger ce bogue sur plusieurs clusters. :-)

C'est ici :-P

J'ai actualisé les pages de versions à peu près toutes les heures ces derniers jours dans l'espoir que la version 1.12.5 apparaisse afin que je puisse corriger ce bogue sur plusieurs clusters. :-)

C'est ici :-P

Pourquoi n'est-il pas là pour 1.11? :(

Ce bogue a-t-il été corrigé dans la version 1.11.7? Je n'ai vu aucune note de publication.

Oui, c'est 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)

Oui, j'ai oublié d'ajouter "IPVS" dans la note de publication dans le PR, désolé pour cela
Faites-nous savoir si cela fonctionne bien maintenant! (nous laisserons le problème ouvert pendant une semaine au cas où)

Nous n'avons eu aucun problème depuis la mise à niveau vers la 1.12.5 🎉

Bonne nouvelle!

@ m1093782566 , @thockin Je pense que nous pouvons fermer ce problème (pas de nouveau rapport dans environ 2 mois)

Pour référence, le bogue a un impact sur les versions initiales avec une terminaison gracieuse:

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

Le correctif est présent après:

• 1.11.7
• 1.12.5
• 1.13.2

/Fermer

@ m1093782566 :

Pouvons-nous rouvrir? Nous voyons ce problème sur 1.12.7.

oui, nous constatons également les problèmes de la version 1.12.9

Êtes-vous sûr que c'est le même problème?
Pouvez-vous publier les journaux d'une instance de kube-proxy?

désolé, il peut s'agir d'une fausse alerte ... Nous voyons que ce sont les journaux et ce n'est pas la même erreur

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

pour une raison quelconque, lorsque le cluster est sous charge, il ne peut pas acheminer vers certaines des adresses IP du service de cluster. Nous ne savons toujours pas s'il s'agit d'un problème IPVS.

Peut-être que la propagation du point final prend du temps si l'apiserver est surchargé?

Les messages sont des messages de niveau Info normaux:
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

Je peux confirmer le même journal dans 1.14.4. Quand ce journal sort-il?

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

Ce ne sont que des journaux d'informations:

• Trying to delete rs : un pod backend de supprimé, en essayant de le supprimer. S'il a des connexions existantes, faites-lui entrer une terminaison gracieuse, sinon supprimez l'id
• Deleting rs : le backend n'a pas de connexion, le supprimant d'IPVS

@andrewsykim Peut-être

Dans https://github.com/kubernetes/kubernetes/pull/78395, nous avons fait passer le niveau de journalisation de v = 0 à v = 2, je pense que v = 5 a du sens. https://github.com/kubernetes/kubernetes/pull/80100 pour la mise à jour