我们在使用腾讯云容器服务(tke)的过程中，遇到"no route to host"问题，这里记录为运维日志。 环境 tke 1.12.4(1.14.3) 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 排查过程 请详见tke团队roc的文章Kubernetes 疑难杂症排查分享: 诡异的 No route to host 其它找到的一些有用的文章 https://engineering.dollarshaveclub.com/kubernetes-fixing-delayed-service-endpoint-updates-fd4d0a31852c https://fuckcloudnative.io/posts/kubernetes-fixing-delayed-service-endpoint-updates/ 中文版本 五元组：源IP地址，源端口，目的IP地址，目的端口，和传输层协议这五个量组成的一个集合 终局 kube-proxy ipvs conn_reuse_mode setting causes errors with high load from single client #81775 该issue说明了最终的解决方案，是通过操作系统来解决的。2020年7月，我们将所有TKE集群的节点更换为“CentOS 7.6 64bit TKE-Optimized”后，没有再出现过问题。关于如何判定自己的内核有没有应用这个修订，issue中有说明。

我们在使用腾讯云容器服务(tke)的过程中，遭遇了kube-proxy的ipvs模式udp转发规则过期问题，过程记录。 环境 tke 1.12.4 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 操作和现象 目标节点：172.21.128.109, 该节点有coredns, coredns的svc ClusterIP: 172.23.127.235。执行封锁后，执行drain操作。操作后的现象：业务大量报错“getaddrinfo failed: Name or service not known (10.010s)”,持续约8分钟. 和腾讯云的伙伴复盘时关注dns的变化.操作后会看到新的pod在172.21.128.111节点生成，在集群的任意节点上查看ipvs规则,发现tcp规则已更新成新podip，但udp规则还是老的podip。 # kubectl drain 172.21.128.109 # kubectl get pod -n kube-system -o wide|grep dns coredns-568cfc555b-4vdgk 1/1 Running 0 66s 172.23.3.41 172.21.128.111 <none> coredns-568cfc555b-7zkfz 1/1 Running 0 77d 172.23.0.144 172.21.128.10 <none> # ipvsadm -Ln|grep -A2 172.