Post content
调试 Calico 的一些方法 最近一直在死磕 Calico, 因为领导层已经拍板了要让 Kubernetes 的 Pod 暴露给集群外访问, 也就是说什么 Ingress / Service / NodePort 全都不用, 而是依赖 operator + DNS 做 failover 和 automation, 原因居然是认为 Nginx(Ingress) 和 iptables(Service) 影响性能, 匪夷所思... 经典场景: node1 上 ping 不通 node2 上的容器 IP. 1. 确认 wep, 看对应的容器是否创建了对应的 Calico WorkloadEndpoint, 如果不存在那么是 network plugin 的问题, 查看 libnetwork (CNM) 或者 kubelet (CNI) 的日志. 2. 确认 node2 上的路由, 在 node2 上 ping 容器 IP, 如果失败, 那么是 calico-felix 监听 datastore (etcd / kubernetes) 失败或者修改路由失败, 查看 felix 日志. 3. 确认 node1 上的路由, 如果路由正常, 那么几乎可以确认是 iptables 的问题, 进一步通过在 node1 和 node2 上抓包确认 node1 到容器的包已经发到 node2 4. 如果第三步路由正常, 排查 iptables 4.a. 先检查 Calico profile, 是否 allow ingress / egress, 是否设置了 selector 4.b. 如果 profile 正常, 手动检查 iptables, 不用死记硬背表链, 只要 iptables-save 后的顺序检查表就行了; 需要在 node1 上检查 OUTPUT -> POSTROUTING, 在 node2 上检查 PREROUTING -> INPUT 4.c 如果实在没精力/时间/不熟悉 iptables, 不妨 systemctl stop iptables 会 drop 所有规则, 不过 Calico 会立刻把它的 profile 修改到 iptables 中, 这么做只能清理掉非 Calico 的规则 5. 如果第三步路由不正常, 排查 BGP 5.a. 进入 calico-node 容器, 进入 bird 命令行, 查看 protocol 和 route, node1 需要查看 node2 的 protocol, node2 需要查看 kernel1 的 protocol 5.b. 一般来说是 node2 的 kernel1 protocol 显示有所需的路由, 但是 node1 的 node2 protocol 缺失了该路由, 那么在两个节点上抓 BGP 包, 在 bird cli 里执行 restart node2 protocol, 期望看到两个节点分别发送 OPEN 和 UPDATE message 5.c. 若 OPEN 失败, 查看 bird 日志, 可能的原因是 recursive cidr, 这种情况发生在 calico in calico 5.d. 若 UPDATE 发送成功但是依然没有路由, 依然查看 bird 日志, 可能的原因是 interface unreachable, 这意味着 node1 和 node2 L2 不通, 需要建立 ipip 隧道 5.e 若压根没看到 node1 收到有正确的 NLRI 和 NEXT_HOP 的 UDPATE message, 那么一定是 BGPPeer 没有正确交换路由信息; 如果 peer 是我们能控制的 RR 节点, 上去撸; 如果是 ToR 交换机, 找 infra. 大致就是如此.