CKA — kube-proxy Modes

5 minute read

CKA Exam Domain

Domain Weight
Services & Networking 20%

Understanding kube-proxy is important for the CKA exam. You should know the different modes, how to check the current mode, and how session affinity works.

What Is kube-proxy?

kube-proxy is a network component that runs on every node in the cluster as a DaemonSet. Its job is to implement the Service abstraction — it makes the virtual IP (ClusterIP) of a Service actually work by setting up networking rules to route traffic to backend Pods.

When you hit a Service’s ClusterIP, kube-proxy is the component that intercepts the traffic and forwards it to one of the healthy Pods behind the Service.

# kube-proxy runs as a DaemonSet
kubectl get daemonset kube-proxy -n kube-system

# Check kube-proxy Pods
kubectl get pods -n kube-system -l k8s-app=kube-proxy

kube-proxy watches the Kubernetes API for changes to Services and Endpoints, and updates its routing rules accordingly.

iptables Mode

iptables is the default kube-proxy mode. In this mode, kube-proxy creates iptables rules on each node to capture traffic destined for Service ClusterIPs and redirect it to one of the backend Pod IPs.

How it works:

  1. kube-proxy watches for Service and Endpoint changes
  2. For each Service, it creates iptables rules in the nat table
  3. When a packet arrives for a Service’s ClusterIP, iptables randomly selects a backend Pod
  4. The packet is DNAT’d (destination NAT) to the selected Pod’s IP

Pros:

  • Reliable and well-tested
  • Good performance for small to medium clusters

Cons:

  • Uses random selection — no smart load balancing
  • Performance degrades with many Services (thousands of iptables rules)
  • Rule updates are not incremental — the entire chain is rewritten

IPVS Mode

IPVS (IP Virtual Server) mode uses the Linux kernel’s IPVS subsystem for packet routing. It’s designed for high-performance load balancing.

How it works:

  1. kube-proxy creates IPVS virtual servers for each Service
  2. Backend Pods are added as real servers
  3. The kernel’s IPVS module handles traffic routing with real load balancing algorithms

Supported load balancing algorithms:

  • rr — Round Robin (default)
  • lc — Least Connections
  • dh — Destination Hashing
  • sh — Source Hashing
  • sed — Shortest Expected Delay
  • nq — Never Queue

Pros:

  • Better performance at scale (hash table lookups vs linear iptables traversal)
  • Real load balancing algorithms
  • Incremental updates (no full rule rewrite)

Cons:

  • Requires IPVS kernel modules to be loaded
  • Slightly more complex to debug

iptables vs IPVS

Feature iptables IPVS
Performance Good for small clusters Better at scale
Load Balancing Random selection Multiple algorithms (RR, LC, etc.)
Scalability Degrades with many Services Handles large numbers well
Default? Yes (default mode) No (must be configured)
Rule updates Full chain rewrite Incremental
Kernel modules Built-in Requires ip_vs modules
Debugging iptables -L ipvsadm -L

For most CKA exam scenarios, you’ll encounter the default iptables mode. But you should know that IPVS exists and understand the trade-offs.

kube-proxy Configuration

kube-proxy is configured via a ConfigMap in the kube-system namespace:

# View kube-proxy configuration
kubectl get configmap kube-proxy -n kube-system -o yaml

# Look for the mode field:
# mode: ""       (empty string = iptables, the default)
# mode: "ipvs"   (IPVS mode)

# Check the DaemonSet
kubectl get daemonset kube-proxy -n kube-system

# View kube-proxy logs
kubectl logs -n kube-system -l k8s-app=kube-proxy | head -20

To check the current mode from the node:

# Check iptables rules (if iptables mode)
iptables -t nat -L KUBE-SERVICES | head -20

# Check IPVS rules (if IPVS mode)
ipvsadm -L -n

Session Affinity

By default, Services distribute traffic randomly (iptables mode) or via the configured algorithm (IPVS mode). Session Affinity lets you route all requests from the same client to the same Pod.

Set service.spec.sessionAffinity to ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: ClusterIP
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800    # 3 hours (default)
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

With ClientIP session affinity, kube-proxy ensures that all requests from the same source IP are directed to the same backend Pod (for the duration of timeoutSeconds).

Possible values for sessionAffinity:

  • None (default) — no session affinity
  • ClientIP — route by client IP

Note: Kubernetes doesn’t support cookie-based session affinity at the Service level. For that, you’d need an Ingress controller.

Debugging kube-proxy

When Services aren’t routing traffic correctly, check kube-proxy:

# Check kube-proxy Pods are running
kubectl get pods -n kube-system -l k8s-app=kube-proxy

# Check kube-proxy logs for errors
kubectl logs -n kube-system -l k8s-app=kube-proxy

# View kube-proxy mode from logs
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep "Using"

# On the node — check iptables rules
iptables -t nat -L KUBE-SERVICES | head -20

# On the node — check KUBE-SVC rules for a specific service
iptables -t nat -L | grep <service-clusterip>

Common issues:

  • kube-proxy Pod crashing — check logs
  • Wrong mode configured — check ConfigMap
  • iptables rules missing — restart kube-proxy Pods

Practice Questions

Q1. What is the default kube-proxy mode in Kubernetes?

Show Answer

iptables is the default kube-proxy mode. If the mode field in the kube-proxy ConfigMap is empty or set to "", iptables mode is used.

Q2. How do you check the current kube-proxy mode in a cluster?

Show Answer 
# Check the ConfigMap
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode

# Or check the logs
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i "using"

Q3. Create a Service with ClientIP session affinity for a Deployment named app on port 80.

Show Answer 
apiVersion: v1
kind: Service
metadata:
  name: app-svc
spec:
  type: ClusterIP
  sessionAffinity: ClientIP
  selector:
    app: app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

kubectl apply -f app-svc.yaml

Or imperatively, then patch:

kubectl expose deployment app --port=80 --name=app-svc
kubectl patch svc app-svc -p '{"spec":{"sessionAffinity":"ClientIP"}}'

Q4. Name two load balancing algorithms that IPVS mode supports but iptables mode does not.

Show Answer

IPVS supports:

  • Round Robin (rr) — distributes requests evenly
  • Least Connections (lc) — sends to the backend with fewest active connections

iptables mode only supports random selection — it doesn’t implement any real load balancing algorithm.

Q5. kube-proxy is not running on a node. What command do you use to check its DaemonSet status?

Show Answer 
kubectl get daemonset kube-proxy -n kube-system

# Check if Desired, Current, and Ready counts match
# If not, describe the DaemonSet for events:
kubectl describe daemonset kube-proxy -n kube-system

# Check individual Pod status:
kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide

Updated:

You may also enjoy