Kubernetes: O modo kube-proxy ipvs trava após algumas horas, precisa ser reiniciado manualmente

rede / sig

o mesmo erro. atualização de 1.11.1. Tudo se torna bom, exceto o kube-proxy que se torna instável, às vezes o pod não consegue acessar o svc embora seus endpoints estejam ok .. E o mesmo que a resolução de nomes. então eu acho que pode haver um bug importante aqui.

/ área ipvs

@gjcarneiro você resolve esse problema?

Bem, eu mudei o cluster de volta para o modo padrão (iptables), parece estar bastante estável desde então ...

@ kubernetes / sig-network-bugs

@berlinsaint : Reiterando as menções para acionar uma notificação:
@ kubernetes / sig-network-bugs

mesmo problema, 1.12.2 e 1.13.0-beta1. @ m1093782566 @ Lion-Wei

@gjcarneiro quer dizer que no kernel 4.15, tem o mesmo problema?

@annProg

mesmo problema, 1.12.2 e 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Quanto custa sua caixa de correio, fique por dentro. .juvenil

@annProg

mesmo problema, 1.12.2 e 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Quanto custa sua caixa de correio, fique por dentro. .juvenil

Clique no meu avatar para ver

Também estou vendo isso repetidamente em meu sistema de registro centralizado:

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

Estou executando a v1.12.3 (instalação nova, não uma atualização).

Olá a todos. Obrigado pelo relato, vou fazer uma pesquisa e tentar descobrir o que aconteceu, qualquer progresso relatarei aqui.

Além do que aconteceu, o que é bom saber, não me sinto confiante quanto ao IPVS até que haja um código em vigor que detecte e reconfigure um soquete de netlink quebrado. Porque pelo que posso adivinhar a partir dos logs e rastreios, o soquete netlink entra em um estado quebrado e a tarefa que lê / grava dele vai travar para sempre. Acho que o kube-proxy precisa ter um código que detecte esse problema e, se isso acontecer, crie um novo soquete netlink do zero e talvez reinicie a tarefa que o trata. Mas, não, não sou voluntário, nem sei Go, desculpe.

Porque pelo que posso adivinhar a partir dos logs e rastreios, o soquete netlink entra em um estado quebrado e a tarefa que lê / grava dele vai travar para sempre.

Atualizamos a versão go netlink alguns dias atrás para oferecer suporte ao encerramento normal. A biblioteca netlink estava rodando bastante estável antes. Não tenho certeza se é a causa.

1.12.3 com o mesmo erro.
Depois de filtrar o log de INFO,
execute 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;
e todo o log do nó do proxy é

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

BTW. visto acima dos meus logs, parece que o kube-proxy ainda tem muitos problemas com o iptables-restore. todos os meus nodos são UBUNTU 16.04 que possuem a versão 1.6.0 do iptable.
@ m1093782566 @ Lion-Wei

Vemos isso acontecendo ao atualizar do 1.12.1. deve, portanto, estar no delta de 1.12.1 e 1.12.2.

O problema está relacionado ao encerramento normal e acho que corrigimos o bug na v1.13.1.

@ m1093782566 a correção será portada para a linha 1.12? no momento, isso está bloqueando a correção de segurança 1.12.3 para nós.

O mesmo aconteceu com a atualização de 1.11.2 para 1.11.5.

@ m1093782566 você pode fornecer mais informações sobre a correção? Eu estaria interessado em examinar o commit.

Isso é muito insano, fomos mordidos com muita força hoje cedo.

Vemos isso acontecendo ao atualizar do 1.12.1. deve, portanto, estar no delta de 1.12.1 e 1.12.2.

O mesmo aconteceu com a atualização de 1.11.2 para 1.11.5.

O bug foi escolhido por chery?

Parece o PR que corrige o problema: https://github.com/kubernetes/kubernetes/pull/71515

True @ Quentin-M

Sim, isso provavelmente vem da correção na função delete (não realmente relacionada ao título do PR).

@ m1093782566 posso criar a escolha

O bug foi escolhido por chery?

@ Quentin-M, parece que o bug foi introduzido por https://github.com/kubernetes/kubernetes/pull/66012 que foi escolhido a dedo para as versões 1.11.5 e 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

Acho que todo o # 71515 deve ser escolhido a dedo. A terminação elegante em geral só foi introduzida e escolhida a dedo com o # 66012, portanto, a mudança de comportamento já aconteceu.

k8s.gcr.io/kube-proxy:v1.13.1-beta.0 ainda está obsoleto em nossos clusters. 60% deles travaram em menos de 24 horas. Tentando 1.12.1 agora.

@ Quentin-M: Você pode verificar os logs no kube-proxy e confirmar se esses tipos de mensagens sumiram:

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

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

Ambos estão relacionados à função de exclusão fixada no PR. Se eles sumiram e você ainda vê o problema, essa correção não é suficiente

Além disso, se tudo funcionar com 1.12.1 , há uma grande probabilidade de que o problema venha do encerramento normal (# 66012)

Acho que tenho uma ideia: o que acontecerá se tentarmos adicionar um servidor real que ainda esteja em encerramento normal. Nesse caso, devemos apenas aumentar o peso para 1 e removê-lo da lista de término normal.

Tentarei testar esse cenário assim que puder (mas será complicado porque estou na Kubecon na próxima semana)

@ Lion-Wei o que você acha?

Ok, risque isso, acabei de testar e funciona bem. O código responsável por isso está aqui: https://github.com/kubernetes/kubernetes/blob/456c351e31517543e0686b2cadf21615d30a738f/pkg/proxy/ipvs/proxier.go#L1538 -L1542

Nesse caso, o RS é removido da lista gracefulDelete e do IPVS RS. Eu me pergunto se definir o peso de volta para 1 em vez disso não seria melhor

Vou tentar outras coisas com base nesta parte dos logs, que parece apontar para a tentativa de sincronizar endpoints para um serviço excluído

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, após uma verificação rápida, o commit que corrige o problema de exclusão não está em v1.13.1-beta.0 nem em v1.14.0-alpha.0 que foi cortado em 7 de novembro
Eu acho que será na próxima versão alfa 1.14 que será baseada no mestre

Vou criar a escolha certa para 1.13 também

Tive um problema com a atualização de 1.12.0 para 1.13.0, parece estar relacionado a este, mas não é o mesmo.

Não podemos corrigir isso revertendo para o iptables. Por favor me ajude.

Eu postei no stackoverflow

Obteve o mesmo em 1.11.5. Temporário revertido de ipvs para iptables.

O mesmo em 1.11.5. Não é possível reverter para 1.11.4 devido à vulnerabilidade presente nele. Tive que mudar para iptables. A correção para isso será lançada para 1.11.x?

Você pode reverter o kube-proxy muito especificamente, sem ser afetado pela vulnerabilidade.

@ Quentin-M Sim, esse pensamento me atingiu, mas por outro lado, se o fizesse, não teria um encerramento normal, que sempre esteve lá com o iptables. Não tenho certeza se nossos clientes gostariam da mudança.

@ Quentin-M significa que não haverá correção para 1.11.x para resolver esse bug?

@emptywee Eu criei uma escolha https://github.com/kubernetes/kubernetes/pull/71848
Esperançosamente, será mesclado em breve e estará em 1.11.6

Já foi mesclado em 1.12 (estará em 1.12.4 ) e 1.13 (estará em 1.13.1 )

A escolha certa acabou de ser fundida no 1.11 também
Precisamos apenas esperar pelos próximos lançamentos de patch nos 3 branches (mas se você quiser testá-lo antes, posso criar facilmente uma compilação de proxy kube personalizada (ou, ainda mais fácil, uma imagem docker hyperkube com o patch)

Muito obrigado @lbernail ! Seria bom ter uma imagem docker disponível publicamente! Eu adoraria testar!

A correção já foi escolhida a dedo para v1.11, v1.12 e v1.13.

Você poderia testá-los para que possamos resolver este problema.

@ m1093782566 estou testando isso. A propósito, quando a comunidade publicará o pequeno lançamento para isso?

Obrigado @berlinsaint , por favor deixe-me o resultado do teste.

quando a comunidade publicará o pequeno lançamento para isso?

O novo pequeno lançamento com a correção será publicado em menos de 2 semanas.

@emptywee : aqui está: lbernail/hyperkube:v1.12.4-beta.1
Conte-nos como isto funciona para você!

@lbernail, há problema em usá-lo com tudo o mais na v1.11.5? Ou devo aumentar meu cluster do Kubernetes para v1.12.4 primeiro? De qualquer forma, muito obrigado!

@emptywee sim, deve funcionar sem problemas (estou executando kube-proxy 1.11 em clusters 1.10 há meses)

Também posso fazer uma compilação 1.11 mais tarde hoje

@lbernail sim, seria bom ter uma imagem da mesma versão de lançamento.

@emptywee aqui está: lbernail/hyperkube:v1.11.6-beta.1

@ m1093782566 @lbernail Depois de uma observação noturna, o log de erros de sincronização do ipvs não foi mais visto, enquanto
ocorre pelo menos uma vez na noite anterior. Mas ainda preciso de mais tempo para verificar isso, muito obrigado, isso me incomodou muito tempo.

Começarei os testes amanhã em 1.11 e darei alguns dias também.

@lbernail Eu tentei lbernail/hyperkube:v1.11.6-beta.1 (Obrigado por isso!)
Imediatamente pensamos que as coisas estavam consertadas, pois paramos de ver as can't find the real server mensagens de log. No entanto, depois de um dia e meio, estamos vendo problemas com entradas ipvs obsoletas em 3/6 nós do cluster.
Estas são as entradas ipvs para um serviço em um nó de cluster quebrado.
Antes de reiniciar o 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

Depois de reiniciar o 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 Esse foi o motivo pelo qual entrei neste tópico quando mudei para IPVS no 1.11.5. No dia seguinte, descobri que os serviços não estavam acessíveis, então pensei que o kube-proxy havia travado e não atualizaria as entradas dos serviços.
Isso é só para avisar que tive um problema semelhante (IPs errados na tabela ipvs) com a v1.11.5 do kube-proxy.

@bjornryden Boas notícias para os erros de exclusão (era isso que o patch estava tratando)

O fato de os back-ends não serem atualizados corretamente é estranho porque o encerramento normal não deve afetar os novos endpoints (se alguns endpoints obsoletos ainda estivessem lá, eu ficaria menos surpreso)

Você poderia compartilhar os logs do kube-proxy relacionados ao serviço 10.230.65.211:9494 ?

Além disso, algum comportamento especial com este serviço / implantação? (por exemplo, os pods são atualizados com muita frequência ou por trás de um HPA?)

Portanto, está em execução há 2 dias no cluster do meu laboratório com a imagem 1.11.6-beta.1 de @lbernail no modo ipvs.
Até agora tudo bem, ele não travou e continua atualizando as entradas do ipvs.

Porém, uma observação estranha:

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         

A primeira chamada para ipvsadm mostra o estado inicial antes de eu excluir um dos pods do serviço. Poucos mostram que uma entrada foi removida, pois o pod foi excluído. No entanto, não sei se é como deveria ser, mas criou uma segunda entrada com o mesmo endereço IP do pod que saiu. E então ele foi atualizado para o IP correto do novo pod que veio para substituir o excluído.

Fora isso, está tudo bem. Mas o cluster do laboratório não está tão ocupado quanto os outros. O comentário de @bjornryden me deixou um pouco preocupado em experimentar a imagem em clusters mais ocupados, onde pode impactar nossos clientes.

@emptywee Presumo que o pod excluído era 10.158.130.24 . Eu não entendo isso:

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 

Ter o mesmo servidor real duas vezes não faz sentido. Você pode reproduzi-lo?

O comportamento normal na exclusão do pod deve ser:

• se não houver conexões com este pod, remova o RS
• se houver conexões, defina o peso para 0 (as conexões estabelecidas continuam, sem novas conexões)
• a cada minuto verifique todos os RS com peso 0 (é para isso que serve a lista de terminação normal) e remova aqueles que não têm mais conexões

@lbernail correto. O pod excluído tinha esse endereço IP. E sim, também parecia estranho para mim. Vou tentar reproduzir quando tiver chance. Você gostaria que eu aumentasse a verbosidade do log se eu conseguir reproduzir o mesmo comportamento? Se sim, em que nível?

@emptywee : seria ótimo, obrigado, --v=5 deve nos fornecer muitas informações
O principal é que eu nem acho que um RS pode aparecer duas vezes em um VS no IPVS (nunca vi isso). Qual kernel você está executando?

@lbernail o definirá como --v = 5 e tentará reproduzir, provavelmente em algum momento do fim de semana.

Estou no CoreOS estável:

4.14 é muito recente, então eu ficaria surpreso se houvesse um problema de IPVS
Vou tentar estressar um cluster com a versão corrigida para ver se consigo reproduzir o problema de @bjornryden

@lbernail Infelizmente, não consegui reproduzir aquele comportamento de duplicação de entrada do ipvs que vi apenas uma vez. Tentei várias vezes, com serviços diferentes. No entanto, não vi nenhuma entrada com peso 0, mas isso pode ser explicado pelo fato de que os pods que excluo saem muito rapidamente. Além disso, o kube-proxy tem respondido após ser executado por mais de 5 dias. Eu poderia tentar novamente no modo como o cluster mais ocupado aqui.

@emptywee Esta é uma "boa" notícia (mesmo se eu preferisse que pudéssemos reproduzi-la e entendê-la, talvez fosse uma falha de exibição no ipvsadm?)

O peso só é definido como 0 se forem ActiveConn ou InActiveConn. Para vê-lo, basta abrir uma conexão de longa duração com um serviço antes de excluir o pod associado (por exemplo, usando telnet)

5 dias de estabilidade são boas notícias! Deixe-nos saber como vai quando / se você tentar em um cluster mais ocupado

Tenho algumas pequenas melhorias a caminho:

• https://github.com/kubernetes/kubernetes/pull/71834 : faça com que a terminação normal funcione com serviços usando sessionAffinity (já no mestre, escolhas aleatórias criadas para 1.13, 1.12 e 1.11)
• https://github.com/kubernetes/kubernetes/pull/71895 e https://github.com/kubernetes/kubernetes/pull/72106 : suporte ao encerramento normal ao excluir um serviço (o primeiro já está no mestre, estou esperando o segundo escolher ambos em todos os ramos)

Além disso, 1.11.6 , 1.12.4 e 1.13.1 foram lançados e contêm a correção na função de exclusão

Escrevi um pequeno artigo sobre o assunto no fim de semana /. Vou me certificar de atualizá-lo com a versão corrigida!

@lbernail Claro, basta! A sua imagem do hyperkube é a mesma que foi lançada como 1.11.6? Instalei sua imagem para kube-proxy apenas no cluster mais ocupado e mudei para ipvs novamente para teste. Você gostaria que eu usasse o oficial?

@emptywee Minha imagem e a 1.11.6 são basicamente as mesmas: eu a construí do cabeçalho do branch release-1.11 alguns dias antes do lançamento oficial, então a diferença são alguns commits no máximo, nenhum envolvendo IPVS. Portanto, não acho que vale a pena o esforço de atualizar seu cluster novamente

Más notícias :( acabei de receber o meu kube-proxy e não conseguiu atualizar os back-ends do ipvs. Voltando para iptables e coletando logs. O kube-proxy estava em execução com a bandeira --v=5 .

@lbernail Então, não

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

Mas quando verifiquei com ipvsadm, ainda estava mostrando os dois primeiros: 10.148.191.69:8080 10.148.192.14:8080

Enquanto kubectl -n c-qa4 describe svc ycsdtleuk estava dizendo que os endpoints são 10.148.183.70:8080 10.148.184.67:8080 , e em outras caixas as entradas de ipvs para o mesmo serviço estavam sendo atualizadas corretamente.

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

Basicamente, estava olhando para o seguinte em duas caixas ao mesmo tempo:

(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

Não há mensagem de erro óbvia ou qualquer coisa gritando que indique qualquer sinal de um problema em qualquer lugar. Posso enviar o arquivo de log completo (18M descompactado) diretamente para você, se desejar.

Resumindo: parece que enquanto a parte que escuta as mudanças de serviços está funcionando bem, mas a parte que está interagindo com o módulo ipvs não está. Não estou nem vendo que ele estava tentando excluir os dois endereços IP iniciais depois de adicioná-los. Algo está travando em algum lugar.

@emptywee Obrigado pelo relatório detalhado. Nada de estranho nesses logs.

O que é surpreendente é que syncProxyRules é executado pelo menos a cada 30s (padrão) e deve reconciliar servidores IPVS reais com endpoints. Ele chama syncEndpoints que aciona AddRealServer e ipvsHandle.NewDestination

Tudo isso acontece antes da exclusão de endpoints antigos, portanto, não deve ser afetado pelo encerramento normal

Você poderia me enviar os logs completos para que eu possa ver exatamente o que acontece entre 21:26 e 21:29 ?

Duas perguntas adicionais:

• um único Kube-proxy foi afetado, certo?
• Um único serviço foi afetado (o outro continuou a atualizar normalmente?)

Da próxima vez, tente enviar SIGABRT ao processo, para que ele imprima os estados das tarefas.

Quando eu tinha o problema, ele estava sempre fazendo algo dentro de libnetwork/ipvs/netlink.go , o que me leva a suspeitar que a chamada de sistema do netlink travou por algum motivo.

Desculpe pela minha ausência, mas fim de semana e depois tive que me concentrar em reverter para o iptables para nossa configuração.

Analisando os registros solicitados para o serviço, @lbernail , temos muitos destes:

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

Também vimos estes:

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

Assim como outros relataram, isso só aconteceu em alguns nós. Quando encontrei o problema, tínhamos 3 nós de cluster que estavam quebrados para este serviço específico.

@lbernail Absolutamente. Aqui está a parte solicitada dos logs, incluí a parte de inicialização também: https://gist.github.com/emptywee/6f7e9c9e43f10288950d1d8420c038f0

Avise-me se precisar de todo o arquivo. Em caso afirmativo, para onde você gostaria que eu enviasse ou carregasse.

Para responder às suas perguntas:

1. O cluster tem mais de 60 nós, verifiquei em alguns outros nós, a entrada ipvs estava correta. Não tenho certeza sobre todas as entradas embora. Mas no nó mestre, por meio do qual roteamos todo o tráfego para os serviços, pelo menos dois serviços não estavam sendo atualizados corretamente. Poderia haver mais, mas assim que começamos a receber reclamações dos clientes, ouvimos imediatamente que dois serviços não estavam acessíveis. Eu coletei os logs e reiniciei o kube-proxy para minimizar o impacto. Eu comparei o estado das entradas ipvs nesse nó mestre e um dos nós de trabalho como parte da solução de problemas e percebi que era diferente. Existe a possibilidade de que outros nós possam ter entradas diferentes não atualizadas corretamente, mas como o tráfego não passa por eles, não notamos nenhum impacto.

2. Não, pelo menos dois serviços foram impactados. Possivelmente mais, mas não verifiquei isso.

Duas coisas interessantes dos registros:

• 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] nunca é processado por IPVS, mas sem erro porque você mantém os dois RS antigos (não podemos ter certeza, adicionar um RS não gera 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] não aciona a chamada de exclusão para 10.148.192.14:8080 (devemos ter logs lá)

@emptywee estava trabalhando com IPVS antes do encerramento

@ m1093782566 / @ Lion-Wei tem ideia do que pode estar acontecendo aqui?

@lbernail Esperamos até fazer o upgrade para 1.11 para mudar para ipvs (acredito que foi quando o lançamento do GA para esse recurso aconteceu) e atualizamos direto para 1.11.5 e foi nossa primeira tentativa de começar a usar ipvs.

@emptywee : Vou adicionar mais alguns registros de nível de informações para tentar localizar o problema. Você poderia executar uma versão mais detalhada por algumas horas? (Se você preferir, eu entendo perfeitamente, mas ainda não consegui reproduzir do meu lado)

Estamos usando o IPVS desde maio e não tivemos problemas em 1.12.1 e 1.11.1.

Também vimos isso acontecer em vários, mas nem em todos os nós, após a atualização para 1.12.3. Os nós afetados pararam de atualizar o IPVS algumas horas após a atualização, mas não de uma forma coordenada que eu pudesse discernir.

Uma coisa a ser observada é que o kube-proxy também parou de registrar completamente naquele momento, então parece que travou completamente.

Arquivo de log mostrando que ele travou e um despejo de goroutine após SIGQUIT (ligeiramente redigido)

@matthiasr 's arquivo de log novamente mostra uma goroutine preso leitura da tomada netlink. O mesmo que eu.

Você pode argumentar que há algum erro lógico causando muitas interações com o soquete netlink. Mas se a comunicação com o netlink não for sólida, o ipvs eventualmente travará. Se o erro lógico for corrigido, pode levar muito mais tempo para atingir esse estado, mas isso não significa que não possa acontecer com tempo suficiente.

É por isso que eu aconselharia ter algum tipo de tempo limite nas interações do netlink; se a operação expirar, feche o soquete netlink e abra um novo automaticamente, como mecanismo de recuperação.

@matthiasr OK, são boas notícias (também estamos usando IPVS há mais de 6 meses sem nenhum problema, mas ainda não atualizamos para as versões que usam terminação normal em nossos clusters mais ocupados)

Parece que podemos ter um impasse em algum lugar

@lbernail embora seja um pouco complicado mudar todo o cluster para ipvs, se isso vai ajudar a resolver esse problema, estou fora do ar. Diga-me o nome da imagem a ser usado e farei o que estiver ao meu alcance para ajudá-lo com isso.

Revertemos para o IPVS em 1.11.6 para ver se podemos recriar nosso problema. Registro definido como 5 e execução de alguma atividade no cluster nos próximos dias. Não estarei trabalhando amanhã, mas estarei online para ver se há uma imagem com maior registro para a qual devo mudar.

@matthiasr : 1.12.3 definitivamente tem um problema (veja o resto deste tópico). Parte disso é resolvido em 1.12.4 . Você obterá muito menos erros nos logs. Todos estes devem desaparecer: Failed to add destination: 10.zz.yy.xx, error: file exists

Ainda temos o problema em que o kube-proxy parece travar e não atualiza mais os servidores reais.
Eu examinei um pouco mais:

• de @emptywee , parece que, após o início do problema, não vemos nenhum registro de proxier.go, ipset.go ou graceful_termination.go, o que parece indicar que estamos presos em algum lugar. @emptywee você pode verificar se possui logs para esses arquivos após as 21:30?
• no despejo de rotina go, há dois syscall recebendo em um soquete netlink. Então, podemos ter um problema aí. Além disso, para suportar o encerramento normal, libnetwork / ipvs foi atualizado, portanto, o comportamento pode ter mudado. No entanto, o código libnetwork parece definir o tempo limite de envio / rcv no soquete netlink (e se estiver travado, veremos quantos minutos esteve): https://github.com/docker/libnetwork/blob/a9cd636e37898226332c439363e2ed0ea185ae92/ipvs /ipvs.go#L77 -L105

Curiosamente, apenas a nova versão da libnetwork tem tempos limite de netlink:

libnetwork foi atualizado em todos os ramos de lançamento (1.11, 1.12 e 1.13) para permitir o encerramento normal. passamos de: ba46b928444931e6865d8618dc03622cac79aa6f para a9cd636e37898226332c439363e2ed0ea185ae92

Na versão anterior, o código era: https://github.com/docker/libnetwork/blob/ba46b928444931e6865d8618dc03622cac79aa6f/ipvs/ipvs.go#L65 -L87

As únicas diferenças no código IPVS em libnetwork entre esses 2 commits são:

• introdução do tempo limite
• adição de ActiveConnections e InactiveConnections a Destination (que era necessário para a rescisão normal)

Eu me pergunto se isso pode estar relacionado.

Depois de colocar mais algumas reflexões sobre o problema, acho que isso vem do fato de que agora temos duas goroutines usando o mesmo soquete netlink (porque o gracefulTerminationManager é executado em sua própria goroutine e compartilha utilipvs.Interface com o proxy).

Provavelmente poderíamos adicionar um mutex em todas as chamadas em pkg/util/ipvs/ipvs_linux.go para ter certeza de que uma única goroutine está usando o soquete netlink a qualquer momento.

@ m1093782566 o que você acha?

@lbernail Não, não há entradas desses arquivos depois das 21:30.
Estas são as últimas entradas para vários arquivos:

Últimas entradas de graceful_termination.go

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

Últimas entradas de proxier.go:

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

Últimas entradas de ipset.go:

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

Todos eles terminaram de registrar por volta das 21:18 ... Isso dá alguma pista?

@emptywee Sim, confirma a hipótese de que temos um impasse entre os dois goroutines que compartilham o soquete netlink. Ambos estão presos à espera de receber mensagens e continuam tentando novamente sem sucesso (devido ao tempo limite de recebimento 3s).

Vou tentar validar a hipótese e começar a trabalhar em uma correção assim que puder

Eu coloquei 1.12.4 em um cluster de teste e comecei a reimplantar um aplicativo, que reproduziu o problema em 1,5 horas, então acho que poderei testar uma possível correção de forma bastante confiável.

Existem novamente 2 goroutines (1 e 107) pendurados em um Netlink Receive.

Tenho uma possível correção para o bug, o código está disponível aqui: https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f
A ideia é proteger todas as chamadas de netlink com um Mutex para evitar o deadlock. Não tenho certeza se essa é a melhor solução, mas pode resolver o problema (e se funcionar, confirme que identificamos o bug).

Se você quiser / pode testar, criei duas imagens com a correção:

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

Se você testar, deixe-nos saber se funciona e se não funcionar, compartilhe logs interessantes e veja as goroutines para ver se algumas parecem travadas em chamadas de netlink.

(Fiz alguns testes do meu lado, mas limitado a um pequeno cluster)

Posso tentar na segunda-feira, 24 de dezembro!

Dando uma chance hoje. Irá relatar os resultados, se houver.

Este é um bug. Eu mudei para o modo iptables.

Eu também atualizei para a versão beta e iniciei nossos testes de carga novamente em breve. Costumamos quebrar rapidamente (menos de um dia) e de forma bastante consistente ... dedos cruzados.

@ li-sen definitivamente é um bug. Estamos trabalhando nisso

@emptywee e @bjornryden muito obrigado pelo teste!

@lbernail o prazer é meu! Então, já se passaram cerca de dois dias desde que lancei o kube-proxy com a imagem 1.11.7-beta.1. Ainda não está pendurado em nós. Posso ver que proxier.go e outras goroutines ainda estão vivas e imprimindo nos logs. Vou dar mais um tempo, já que os últimos dias foram muito lentos e silenciosos, sem muitas implantações acontecendo. De qualquer forma, tenho a sensação de que as mutexes adicionadas por @lbernail estão ajudando :)

Vou atualizar este problema / tópico até o final da semana.

@lbernail

Você poderia levantar um PR para corrigir este problema?

/reabrir
(para ficar de olho no feedback dos testes e antes de criar escolhas se tudo funcionar bem)

@lbernail : Você não pode reabrir uma edição / RP a menos que seja o autor ou um colaborador.

@ m1093782566 você pode reabrir o problema até que tenhamos certeza de que foi corrigido?

Eu tenho o mesmo problema do Kube-proxy ipvs, versão 1.12.3.
Os servidores reais estão errados e o Kube-proxy não pode atualizar as regras de ipvs.

Aqui estão os últimos logs e ficou preso aqui, não imprime mais novos logs.

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 : existem dois problemas:

• exclusões com falha: corrigidas em 1.12.4
• O kube-proxy está travando devido a um impasse (que é o problema que você está descrevendo): esperançosamente corrigido com o PR de ontem. Estamos aguardando feedback de @emptywee e @bjornryden que estão testando o patch. Assim que tivermos a confirmação de que o problema não está mais presente, criarei as opções para 1.13, 1.12 e 1.11 (se o patch funcionar, provavelmente será mesclado em todos os ramos no início da próxima semana e fará parte do os próximos lançamentos de patch)

Também estou executando novamente meu experimento https://github.com/kubernetes/kubernetes/issues/71071#issuecomment -449402484 novamente, com o patch portado para 1.12.4. Apresentarei um relatório de volta!

Não tivemos problemas com o acesso a serviços enquanto o kube-proxy estava (e está) em execução no modo IPVS e tivemos algumas implantações e mudanças nos serviços. Até agora, eu diria que o patch está funcionando bem para nós.

@lbernail Bom trabalho ao consertá-lo! Muito apreciado!

Ok, vamos esperar até segunda-feira para que também recebamos feedback de @bjornryden (quero evitar apressar as escolhas certas e ter certeza de que temos uma solução limpa desta vez)

@lbernail Boas notícias, obrigado pela sua resposta.

Sem problemas após 12+ horas em 1.12.4 com https://github.com/DataDog/kubernetes/commit/9121f0122d805f55f85f42d26c294898fe29a92f - sem isso, obtive um bloqueio em 1,5 horas, então parece muito bom!

@lbernail Tenho outra pergunta, por favor. Se o próximo patch for a versão 1.12.5?
Se eu apenas atualizar o kube-proxy para 1.12.5, outras unidades (apiserver, kubelet, gerenciador de controlador, planejador ...) manter 1.12.3, está tudo bem? Ou eu tenho que atualizar todas as unidades?

@VincentFF Espero que

Atualização: depois de 24 horas, ainda sem problemas, estou interrompendo minha experiência agora e considero isso um sucesso total. Ansioso por 1.12.5!

Ok, esta é uma notícia muito boa. Vou criar a escolha certa para todos os branches para obter a correção nos lançamentos oficiais o mais rápido possível.
Muito obrigado por seu envolvimento em ajudar a resolver o problema e testar!

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

Posso me juntar ao coro de testadores felizes. 4 dias sem problemas.

Muito obrigado a todos os envolvidos, especialmente @lbernail. Feliz Ano Novo!

Eu construo e implanto para testar env, mais de 24 horas não tenho problemas. Feliz Ano Novo.

Olá, meu env é
Ubuntu 16.04.4 LTS
Versão do Kubernetes (use a versão do kubectl): v1.13.0
Provedor de nuvem ou configuração de hardware: bare metal, linux de 64 bits
Kernel 4.4.0-75-genérico

mesmo bug:

I0101 22: 20: 09.742898 267576 graceful_termination.go: 160] Tentando excluir rs: 10.200.198.70:9090/TCP/172.200.101.32:9090
E0101 22: 20: 09.742975 267576 proxier.go: 1519] Falha ao obter serviço IPVS, erro: Esperado apenas um serviço obtido = 0
E0101 22: 20: 09.743036 267576 proxier.go: 843] Falha ao sincronizar endpoint para serviço: 10.200.36.192:80/TCP, erro: Esperado apenas um serviço obtido = 0

Preciso reiniciar o kube-proxy para corrigir

@daigong v1.13.1 corrigiu isso. No meu caso, sem problemas depois de mais de uma semana.

@daigong : a correção completa estará realmente em 1.13.2 (depende de quão rápido # 72426 é mesclado)

@lbernail @FrostyLeaf
obrigado, eu uso o # 72426 para testar este bug

Tudo está bem agora

O PR foi mesclado em todos os ramos de lançamento, portanto, estará presente em:

• 1.11.7
• 1.12.5
• 1.13.2

@annProg

mesmo problema, 1.12.2 e 1.13.0-beta1. @ m1093782566 @ Lion-Wei

Quanto custa sua caixa de correio, fique por dentro. .juvenil

mesmo

alguma chance de uma nova compilação na v1.11.x?

Estive atualizando as páginas de lançamentos praticamente a cada hora nos últimos dias, na esperança de que 1.12.5 apareça para que eu possa corrigir esse bug em vários clusters. :-)

@verwilst haha, mesmo, não pode esperar a v1.11.7 ser lançada para atualizar os clusters de produção atuais. E v1.12.5 também para iniciar a atualização em ambientes inferiores.

Estive atualizando as páginas de lançamentos praticamente a cada hora nos últimos dias, na esperança de que 1.12.5 apareça para que eu possa corrigir esse bug em vários clusters. :-)

Está aqui :-P

Estive atualizando as páginas de lançamentos praticamente a cada hora nos últimos dias, na esperança de que 1.12.5 apareça para que eu possa corrigir esse bug em vários clusters. :-)

Está aqui :-P

Por que não está lá para 1.11? :(

Este bug foi corrigido no 1.11.7? Eu não vi nenhuma nota de lançamento.

Sim, é 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)

Sim, esqueci de adicionar "IPVS" na nota de lançamento no PR, desculpe por isso
Deixe-nos saber se funciona bem agora! (vamos deixar o problema aberto por algumas semanas, apenas no caso)

Não tivemos problemas desde a atualização para 1.12.5 🎉

Boas notícias!

@ m1093782566 , @thockin acho que podemos resolver este problema (sem novos relatórios em cerca de 2 meses)

Para referência, o bug afeta as versões iniciais com encerramento normal:

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

A correção está presente após:

• 1,11.7
• 1,12,5
• 1.13.2

/Fechar

@ m1093782566 : Fechando este problema.

Podemos reabrir? Estamos vendo esse problema no 1.12.7.

sim, estamos vendo os problemas no 1.12.9 também

Tem certeza de que é o mesmo problema?
Você pode postar os logs de uma instância do kube-proxy?

desculpe, pode ter sido um alerta falso ... Vemos que são os logs e não é o mesmo erro

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

por algum motivo, quando o cluster está sob carga, ele não pode rotear para alguns dos IPs de serviço do cluster. Ainda não temos certeza se é um problema de IPVS.

Talvez a propagação do endpoint esteja demorando se o apiserver estiver sobrecarregado?

As mensagens são mensagens normais de nível de informação:
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

Posso confirmar o mesmo log em 1.14.4. Quando esse log sai?

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

Estes são apenas registros de informações:

• Trying to delete rs : um pod de back-end removido, tentando excluí-lo. Se ele tiver conexões existentes, faça-o entrar no encerramento normal, caso contrário, exclua o id
• Deleting rs : o back-end não tem conexão, removendo-o do IPVS

@andrewsykim Talvez agora possamos diminuir o nível desses logs para que eles apareçam acima de v = 5, por exemplo?

Em https://github.com/kubernetes/kubernetes/pull/78395 aumentamos o nível de log de v = 0 para v = 2, acho que v = 5 faz sentido. https://github.com/kubernetes/kubernetes/pull/80100 para atualização