Stage 5 · Platform
Networking & Service Mesh
Service Traffic Flow
ClusterIP, EndpointSlice, kube-proxy IPVS, session affinity, and topology-aware routing.
Service Traffic Flow
When a pod connects to a Service ClusterIP, the request flows through several layers: DNS resolution to get the ClusterIP, kube-proxy rules (iptables or IPVS) to select an endpoint, and finally delivery to a pod. Understanding this flow is critical for debugging connectivity issues.
Pod A -> DNS (CoreDNS)
-> ClusterIP (virtual IP)
-> kube-proxy rules (iptables/IPVS)
-> Endpoint selection
-> Pod B (actual target)
Return traffic:
Pod B -> Pod A (direct, no proxy)The return traffic goes directly from Pod B to Pod A — kube-proxy only handles the initial connection routing. This is why Services work with any protocol, not just HTTP. The connection is tracked in conntrack for subsequent packets.
EndpointSlice
EndpointSlices replace Endpoints as the scalable way to track Service backends. Each EndpointSlice contains up to 100 endpoints. Services with many backends create multiple EndpointSlices. This reduces API server load and improves watch performance.
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: api-service-abc12
namespace: production
labels:
kubernetes.io/service-name: api-service
addressType: IPv4
ports:
- name: http
port: 8080
protocol: TCP
appProtocol: http
endpoints:
- addresses:
- 10.244.1.5
conditions:
ready: true
serving: true
terminating: false
nodeName: worker-1
zone: us-east-1a
hints:
forZones:
- name: us-east-1aEndpointSlice tracks pod readiness, zone, and node. The hints field enables topology-aware routing — traffic is routed to endpoints in the same zone when possible. appProtocol allows protocol-specific behavior.
IPVS Mode
IPVS (IP Virtual Server) provides better load balancing than iptables for large clusters. It uses consistent hashing (Maglev, ring hash) instead of round-robin iptables. IPVS handles thousands of Services without performance degradation.
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-proxy
namespace: kube-system
data:
config.conf: |
mode: "ipvs"
ipvs:
scheduler: "maglev" # Consistent hashing
syncPeriod: "30s"
minSyncPeriod: "2s"
strictARP: true # Required for MetalLB
conntrack:
maxPerCore: 131072
tcpEstablishedTimeout: "86400s"
tcpCloseWaitTimeout: "1h"maglev provides consistent hashing — when endpoints change, only a small fraction of connections are redistributed. strictARP enables ARP suppression for MetalLB. minSyncPeriod batches updates to reduce churn.
IPVS supports: rr (round-robin), lc (least connections), dh (destination hashing), sh (source hashing), sed (shortest expected delay), nq (never queue), and maglev. maglev is preferred for Kubernetes because it provides consistent hashing with minimal disruption on endpoint changes.
Session Affinity
Session affinity ensures requests from the same client go to the same pod. Kubernetes supports ClientIP-based affinity (source IP) and None (no affinity). IPVS provides more sophisticated affinity options: source IP, destination IP, and both.
apiVersion: v1
kind: Service
metadata:
name: sticky-service
spec:
type: ClusterIP
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800 # 3 hours
selector:
app: sticky-app
ports:
- port: 80
targetPort: 8080ClientIP affinity uses a hash of the source IP to select the endpoint. Multiple clients behind the same NAT (same IP) share the same endpoint. timeoutSeconds controls how long affinity is maintained. Use None for stateless applications.
Topology-Aware Routing
Topology-aware routing directs traffic to endpoints in the same zone or region. This reduces latency and cross-zone data transfer costs. Kubernetes uses EndpointSlice hints to implement topology-aware routing.
apiVersion: v1
kind: Service
metadata:
name: api-service
annotations:
service.kubernetes.io/topology-mode: Auto
spec:
type: ClusterIP
selector:
app: api
ports:
- port: 80
targetPort: 8080The service.kubernetes.io/topology-mode: Auto annotation enables topology-aware routing. Kubernetes automatically distributes traffic proportionally across zones. If a zone has 30% of endpoints, it receives 30% of traffic.
Internal Traffic Policy
InternalTrafficPolicy controls how traffic from the same node is routed. Local routes traffic only to endpoints on the same node (reducing latency). Cluster (default) routes to any endpoint, preferring local.
apiVersion: v1
kind: Service
metadata:
name: node-agent
spec:
type: ClusterIP
internalTrafficPolicy: Local
selector:
app: node-agent
ports:
- port: 9090
targetPort: 9090internalTrafficPolicy: Local routes traffic only to endpoints on the same node. If no local endpoint exists, traffic is dropped (not forwarded to another node). This is useful for node-local agents like log collectors or monitoring exporters.
Check EndpointSlice to see which endpoints are ready. Use kubectl exec to test connectivity: kubectl exec -it test-pod -- curl api-service:80. Check conntrack entries with conntrack -L -p tcp --dport 8080.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.