☰

k8s 节点上的 Pod 无法访问，kube-proxy 或 CNI 失败

tag-icon • tag-icon networking proxy kubernetes calico containerd
k8s 节点上的 Pod 无法访问，kube-proxy 或 CNI 失败

我已向我的 k8s 集群添加了一个新节点，但我发现分配给该节点的一些节点无法显示如下日志：

$ kubectl logs -n xxxx xxxxx-6d5bdd7d6f-5ps6k

Unable to connect to the server: EOF

使用 Lens 会出现如下错误日志：

Failed to load logs: request to http://127.0.0.1:49271/api-kube/api/v1/namespaces/xxxxxxx/pods/xxxx34-27736483--1-hxjpv/log?tailLines=500&timestamps=true&container=xxxxxx&previous=false failed, reason: socket hang up
Reason: undefined (ECONNRESET)

当我使用端口转发时，我相信这个节点存在一些问题：

$ kubectl port-forward -n argocd svc/argocd-notifications-controller-metrics 9001:9001
error: error upgrading connection: error dialing backend: dial tcp 10.0.6.20:10250: i/o timeout

我认为内部IP 10.0.6.20是错误的。

所有 kube-proxy pods 显示从 kubectl 运行

-> % kgp -o wide -n kube-system | grep kube-proxy
kube-proxy-7pg9d                                  1/1     Running     1 (2d20h ago)   29d     10.0.6.20        worker4     
kube-proxy-cqh2c                                  1/1     Running     1 (15d ago)     29d     10.0.6.3         worker3           
kube-proxy-lp4cd                                  1/1     Running     0               29d     10.0.6.1         worker1           
kube-proxy-r6bgw                                  1/1     Running     0               29d     10.0.6.2         worker2

但crictl pods在每个节点上使用寻找这些 pod

# crictl pods | grep kube-proxy
ceef94b060e56       2 days ago          Ready               kube-proxy-7pg9d                                   kube-system         1                   (default)
418bd5b46c2b9       4 weeks ago         NotReady            kube-proxy-7pg9d                                   kube-system         0                   (default)

显示 Ready 或 NotReady 我正在使用 Calico 进行 CNI，处于 ip_vs 模式。我该如何修复此问题？

答案1

我按照以下步骤解决了这个问题：

工人4

确保 kubelet 正在监听默认端口：

# lsof -i:10250
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kubelet 819 root   26u  IPv4  13966      0t0  TCP worker4.cluster.local:10250 (LISTEN)

工人1 curl https://10.0.6.20:10250超时但发现curl https://10.0.6.1:10250 # worker1worker4响应很快。

所以这可能是 worker4 内部丢弃的数据包，

这在 worker4 中记录数据包： https://www.thegeekstuff.com/2012/08/iptables-log-packets/

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

将保存日志至/var/log/syslog

使用命令从日志中过滤：

tail -200 /var/log/syslog | grep IPTables-Dropped | grep 10.0.6.1
Oct 10 13:49:37 compute kernel: [637626.880648] IPTables-Dropped: IN=eth1 OUT= MAC=00:16:ce:d4:b7:01:00:16:b2:77:89:01:08:00 SRC=10.0.6.1 DST=10.0.6.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29087 DF PROTO=TCP SPT=58838 DPT=10250 WINDOW=64240 RES=0x00 SYN URGP=0

所以我确信数据包已被丢弃。

添加规则：

iptables -I INPUT -s 10.0.0.0/8 -p tcp --dport 10250 -j ACCEPT

然后我可以附加 shell 或从节点上的 pod 获取日志。我很感谢与 @SYN 的讨论

相关内容