我正在使用kubeadm构建一个Kubernetes集群,并且在单个节点上遇到了问题。
工作者节点与子接口和基于策略的路由一起运行,其按预期工作;然而,在4个工作者节点中,如果Pod被移动到其中一个,则它们通过HTTP的活跃性和就绪性检查失败。
我使用的是Kubernetes版本1.26.1,calico 3.25.0,metallb 0.13.9和ingress-nginx 4.5.0。集群运行起来没有什么问题;除了在节点上制定基于策略的路由之外。Calico和MetalLB也站起来工作了。现在的问题是当我站起来ingress-nginx控制器并强制pod到特定的工作节点上时。站起来并在其他节点上运行它们是可行的,我可以 curl LoadBalancer IP;然而,在测试过程中,当ingress-nginx pod被移动到特定节点时,liveness和readiness检查失败。将pod移回任何其他工作节点,它们都会正常运行。我一直在验证所有节点上的路由和iptables;以及通过tcpdump查看接口,但我还没有缩小问题的范围。
对于简单的事情:
- 节点之间的内核参数和加载模块相同
- 消息中无日志/crio显示启动pod时出现问题
- calico和metallb pod正在处理问题节点
- 自从注意到这个问题后,我已经重新构建了集群,之前的构建cert-manager在节点上遇到了问题,我还尝试了其他一些随机测试部署
从与豆荚,而他们正在运行,我可以击中外部网络通过 curl (dns工作和出站流量工作)在问题节点的'any'接口上使用tcpdump,我可以看到pod和kubernetes内部API IP通信我打不到pod的IP,service IP,或来自问题节点或其他成员节点的任何内容除了活动性和就绪性探测失败外,未显示任何问题服务的端点在问题节点上未被填充(尽管这并不令人惊讶)。通过vxlan.calico接口观察流量并不只显示单向流量-对通过的流量有响应。
我不知道该从哪里寻找根本问题。这已经持续了一个多星期了,我需要一些帮助。
1条答案
按热度按时间ioekq8ef1#
我首先发现了我所做的导致问题的原因,所以将记录它,以防有人遇到相同的情况。
关于这一点的更多背景,因为它非常小众。但是我们面临的一些限制,工作节点有1个物理接口,它被分成2个额外的子接口,以允许VLAN标记的流量。在这种情况下,我编写了iproute策略规则来引导逻辑接口之间的流量。所以总而言之,eth 2(实际上已连接电缆的那个)具有逻辑接口eth 2、eth2.3和eth2.4,它们都在不同的子网上。
我导致的问题是为主接口编写规则,eth 2.这导致liveness和readiness探测器的kubelet流量被错误路由,实际上没有遵循kube-proxy iptables规则和calico的felix路由规则。一旦主接口的策略规则被删除,pods重新启动(这最后一点更多的是我的不耐烦)交通流动,因为它应该和吊舱来了,探测器完成令人满意。