Kubernetes Service Continuity Basics

Kubernetes Service Continuity Basics is the set of reliability considerations at the networking layer that determine whether traffic actually reaches a healthy pod once it is ready and included in a Service's endpoints, covering traffic policy trade-offs between source IP preservation and even load distribution, session affinity, and the client-side DNS behavior that can itself become a source of unreliability.

externalTrafficPolicy: Cluster vs. Local

The Extra-Hop vs. Source-IP Trade-off

apiVersion: v1
kind: Service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster

Cluster (the default) load-balances external traffic across every node regardless of whether that node hosts a matching pod, potentially forwarding through an extra network hop to reach a pod on a different node, but evenly distributing load and tolerating any single node's pod absence gracefully.

spec:
  externalTrafficPolicy: Local

Local preserves the original client source IP and avoids the extra hop by only routing to pods on the same node the traffic arrived at, but a node with no matching pod scheduled on it simply drops that traffic entirely, meaning uneven pod distribution across nodes under Local policy can produce uneven, sometimes zero, capacity on specific nodes despite the Service overall having healthy endpoints elsewhere.

Combining Local Policy With Topology Spread

Because Local policy's reliability depends on every node that could receive external traffic actually hosting a healthy pod, it should be paired with topology spread constraints ensuring pods are distributed broadly enough across nodes that the external load balancer's traffic distribution assumption (every node has capacity) actually holds.

internalTrafficPolicy for Cluster-Internal Traffic

The Same Trade-off Applied Internally

spec:
  internalTrafficPolicy: Local

internalTrafficPolicy applies the identical Local-vs-Cluster trade-off to traffic originating from within the cluster rather than from an external load balancer, useful specifically for node-local optimization patterns (a client pod preferring a same-node backend to avoid cross-node network latency) but carrying the identical risk of dropped traffic if a node lacks a local backend pod.

Session Affinity Reliability Implications

ClientIP Affinity and Its Failure Interaction

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

Session affinity routes a given client consistently to the same backend pod for the affinity duration, which is useful for stateful client interactions but means that specific pod's failure disproportionately affects the subset of clients pinned to it, since those clients do not automatically and immediately redistribute to other healthy pods the way they would under pure round-robin balancing, until affinity is re-established after the failure is detected.

kube-proxy Mode and Its Reliability Characteristics

iptables vs. IPVS

kube-proxy --proxy-mode=ipvs

The iptables proxy mode implements load balancing through sequentially evaluated rules whose lookup cost grows with the number of services and endpoints, which can introduce latency at very large scale; IPVS mode uses a purpose-built kernel load-balancing hash table with better performance characteristics at scale, a relevant reliability consideration specifically for very large clusters where iptables rule evaluation latency itself becomes a bottleneck.

Load Balancer Health Checks

The healthCheckNodePort for Local Policy

spec:
  externalTrafficPolicy: Local
  healthCheckNodePort: 32000

With Local traffic policy, an external cloud load balancer needs its own mechanism to determine which nodes currently have a healthy local pod, provided by a dedicated healthCheckNodePort that the load balancer polls directly, distinct from and in addition to the pods' own readiness probes, since the load balancer operates entirely outside the cluster's own endpoint-tracking mechanism.

Client-Side DNS Reliability

ndots and Search Domain Overhead

dnsConfig:
  options:
    - name: ndots
      value: "2"

The default ndots:5 configuration causes every DNS lookup for a name with fewer than five dots to be tried against each configured search domain before falling back to the fully qualified name, multiplying DNS query volume and latency for common short-name lookups; tuning ndots or using fully qualified domain names directly reduces this overhead, which can otherwise manifest as intermittent, hard-to-diagnose connection delays that look like service unreliability but originate entirely from client-side DNS resolution behavior.

Relationship to Readiness Availability and the Availability Model

Service continuity basics sit directly downstream of the readiness mechanism covered under readiness availability, addressing what happens to traffic once endpoints are correctly populated: traffic policy choices, session affinity, proxy mode, and DNS configuration all determine whether that correctly-computed endpoint list actually translates into reliably delivered requests, directly operationalizing the availability model's client-perspective definition of availability at the point where traffic actually meets a serving pod.