IPSet Fundamentals

Does Kubernetes use ipset? If yes, how is it different from iptables and IPVS, and when is it utilized?

Yes, Kubernetes heavily incorporates ipset, but it is important to understand its precise architectural role: ipset is not a standalone networking mode that you choose instead of iptables or IPVS.

Rather, ipset is a high-performance companion extension that works alongside iptables. It is heavily utilized by specific Container Network Interface (CNI) plugins and by kube-proxy when configured in ipvs mode.

To understand how these primitives relate to one another and when they are used, we must look at the Linux networking stack from an architectural perspective.

The Differences: iptables, ipset, and IPVS

iptables (The Sequential Filter)

iptables is the standard Linux kernel packet filtering framework. When kube-proxy is set to iptables mode, it creates a sequential chain of rules to evaluate and route traffic for Services.

• The Limitation: iptables evaluates rules linearly from top to bottom. If you have 5,000 Services, it must traverse thousands of rules to find a match. This O(N) algorithmic complexity leads to severe performance degradation at scale.

ipset (The Hash Table Extension)

ipset is a distinct extension to iptables. Instead of generating 1,000 sequential iptables rules to match 1,000 different remote IP addresses, you can place all 1,000 IP addresses into a single ipset (which is stored in host memory as a highly optimized kernel hash table). You then write a single iptables rule that simply states: "match any IP found within this specific ipset."

• The Advantage: Because the lookup utilizes hash tables rather than linear processing, IP lookups happen in O(1) constant time. This drastically shrinks the sheer volume of the iptables rule chains and completely eliminates the linear processing bottleneck.

IPVS (The Dedicated Load Balancer)

IP Virtual Server (IPVS) is a completely separate L4 load-balancing facility built directly into the Linux kernel. Rather than relying on firewall rules for routing, IPVS directly maps virtual servers (Service IPs) to real servers (Pod IPs) using its own highly optimized hash tables.

How Kubernetes Uses ipset in Practice

Kubernetes utilizes ipset behind the scenes to optimize network routing and security in two primary areas:

Network Policy Enforcement (via CNI Plugins)

NetworkPolicies declare exactly what traffic is allowed to flow between Pods. A single policy label selector might allow traffic from hundreds of source Pods.

Instead of generating hundreds of individual iptables rules for every allowed Pod IP on the node firewall, advanced CNI plugins leverage ipset. For example, the Kube-router CNI addon utilizes a Network Policy Controller that configures iptables rules and ipsets to allow or block traffic as directed by the policies. By pushing the allowed Pod IPs into a fast-lookup ipset, the CNI can enforce highly complex Zero-Trust security rules with minimal processing overhead.

kube-proxy in ipvs Mode

When you configure kube-proxy to leverage ipvs mode, IPVS executes the actual load balancing to the backend Pods. However, IPVS does not execute packet filtering or port masquerading (Source NAT).

Therefore, kube-proxy still requires the iptables framework to perform these fundamental firewall operations. To prevent iptables from becoming a linear bottleneck once again, kube-proxy automatically constructs ipsets holding all of the cluster's valid Service IPs and active NodePorts. It then uses a handful of basic iptables rules pointing to those constant-time ipsets to securely allow the traffic straight into the IPVS load balancer.

---

When to Choose Which?

As a cluster architect, you do not explicitly choose ipset vs iptables. Instead, you choose your proxy mode (iptables vs ipvs) and your CNI plugin, which dictates how these kernel primitives are utilized.

• When to stick with iptables mode: For smaller clusters (under 1,000 Services), the default iptables mode is perfectly sufficient. It is mature, heavily tested, and the linear traversal overhead is negligible at this scale.
• When to choose IPVS mode (which leverages ipset): If you are building a massive multi-tenant cluster and anticipate creating thousands of Services, you must switch kube-proxy to ipvs mode. This ensures that Service resolution remains instantaneous (O(1)) regardless of cluster growth, and relies on ipset to keep the necessary firewall rules optimized.
• When evaluating CNIs: If you plan to implement strict "default deny" NetworkPolicies across hundreds of namespaces, you should evaluate CNI plugins (like Calico, Cilium, or Kube-router) that are specifically architected to use ipset (or eBPF) rather than native iptables rules. This ensures your security posture does not unintentionally degrade node network performance.