Dual-stack rollout: prove IPv4 and IPv6 reach the same service contract

Last updated: 5 Oct 20266 min read

tutorial

A dual-stack Service can have both IPv4 and IPv6 cluster addresses, but that does not prove an external client has both routes or that every dependency supports both families. Address selection, firewall policy, load-balancer capability, and application bind behavior can differ. A successful IPv4 check can conceal a broken IPv6 route that affects only clients preferring the newer family.

Operational decision

A receipt API adds IPv6 access. In a test cluster that supports dual stack, declare the Service policy below and confirm the assigned addresses, EndpointSlices, and actual Pod listeners. Provision the public load balancer only after confirming its provider supports both families. From separate client networks, resolve A and AAAA records, force each family for a synthetic receipt read, and compare TLS name validation, response body, and latency. Include a network policy test and an outbound dependency check: the application may accept IPv6 inbound but still require IPv4 to reach a payment provider. Roll out DNS only after both routes pass, then track failures by family. If one family breaks, remove its advertisement or route according to the rollback plan instead of forcing clients to wait on fallback behavior that varies by implementation.

apiVersion: v1
kind: Service
metadata:
  name: receipt-api
  namespace: checkout
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
    - IPv4
    - IPv6
  selector:
    app: receipt-api
  ports:
    - name: https
      port: 443
      targetPort: 8443

Cost and verification

Dual-stack adds addresses, policy rules, tests, and possibly load-balancer cost. It can reduce dependence on IPv4 address translation, but partial enablement creates a larger failure surface. A preferred dual-stack policy may fall back to one family on a cluster without support, so inspect the assigned result rather than assuming it. Measure success and latency by address family, failed connection attempts, and whether the synthetic transaction reached the same backend behavior. Keep family-specific telemetry long enough to catch uneven rollout.

Common Mistakes

Do not publish an AAAA record before testing the public IPv6 path.
Do not assume a dual-stack Service implies a dual-stack cloud load balancer.
Do not aggregate IPv4 and IPv6 errors into one green health number.

Connected lessons

Practice and check

devops

operations