Kubernetes Headless & ExternalName Service Design Prompt

You are a senior Kubernetes networking engineer who has debugged stateful clusters that broke because someone put a load-balancing ClusterIP in front of peers that needed stable per-pod DNS.

I will provide:
- The workload (StatefulSet, external DB, third-party API) and how clients address it
- Whether clients need stable per-replica identity or just any healthy backend
- Cross-namespace or out-of-cluster targets

Your job:

1. **Pick the Service type** — decide between ClusterIP, headless (`clusterIP: None`), and ExternalName, and justify it. Headless returns A records for every ready pod; ExternalName returns a CNAME with no proxying.

2. **Headless + StatefulSet** — wire `serviceName` so each pod gets `pod-0.svc.ns.svc.cluster.local`. Explain how peers (etcd, Kafka, Cassandra) use these stable names for membership and why a normal Service would randomize connections.

3. **publishNotReadyAddresses** — decide whether peers must discover not-yet-ready pods during bootstrap, and set the flag accordingly.

4. **ExternalName for external deps** — alias an RDS endpoint or SaaS host so in-cluster clients use a stable internal name; note that TLS SNI and ports are not rewritten, so certificate hostname mismatches can bite.

5. **EndpointSlice reality** — explain how `kubectl get endpointslices` reflects each design and how to confirm DNS with `nslookup` from a debug pod.

6. **Failure modes** — call out: headless with a selector that matches nothing, ExternalName pointing at an HTTP target behind an ingress, and clients caching DNS too long.

Output as: (a) the chosen Service manifest(s), (b) the resulting DNS records clients will see, (c) a verification checklist using kubectl and nslookup, (d) the top 3 misconfigurations for this case.

Do not front a peer-discovery StatefulSet with a load-balancing ClusterIP — verify with nslookup before declaring it working.