lhotari commented on PR #25520: URL: https://github.com/apache/pulsar/pull/25520#issuecomment-4247605683
Some additional details from Claude: > Cilium's Socket-LB, when used as a kube-proxy replacement, mitigates many of the stale connection and conntrack problems that affect kube-proxy in both iptables and IPVS modes. Because Socket-LB performs service-to-backend translation at the socket layer (at connect() time for TCP) rather than per-packet NAT, it avoids creating conntrack entries for service translation entirely. This eliminates the class of problems where stale conntrack entries cause connections to be black-holed or forwarded to dead backends after node reboots, pod restarts, or endpoint changes. Additionally, because Cilium tracks which sockets are connected to which backends in BPF maps, it can proactively destroy sockets connected to removed backends — using either the kernel's SOCK_DESTROY API (via netlink, requiring CONFIG_INET_DIAG_DESTROY) or the newer bpf_sock_destroy() kfunc (kernel 6.5+, being adopted in Cilium 1.17+). This is something neither kube-proxy iptables mode nor IPVS mode can do, since they operate at the packet level and have no visibility into application sockets. That said, Socket-LB doesn't cover all traffic paths — north-south traffic (external to cluster) and some scenarios like hostNamespaceOnly mode still use eBPF-based per-packet NAT at the tc/XDP layer, which is closer to what kube-proxy does (though still using BPF maps rather than iptables/IPVS). The conntrack-related issues are most effectively mitigated for east-west pod-to-service traffic where Socket-LB is fully in play. It seems that there's a recommendation to replace kube-proxy with Cilium. This option seems to be available also on all major cloud provider managed k8s services (EKS, GKE and AKS). The default option is kube-proxy in most cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
