Hands-on Lab·Certified Kubernetes Administrator
Headless and ExternalName Services
The two Service types that are not proxies. A headless Service hands back Pod IPs so a client can choose a member; an ExternalName is a DNS alias with no endpoints, no port mapping and no kube-proxy rules at all.
Services and Networking Guide 51 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 16 min
Pod and cluster IPs are this lab's. The shape of each answer - one address, several addresses, a CNAME - is what to learn.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when you need DNS without a proxy in the way - every Pod address, or a name pointing somewhere outside the cluster. This matters because headless and ExternalName are the two Service types that do no load balancing at all, and each fails in its own characteristic way.
- putting three Service types over the same two Pods, so nothing else can explain the difference
- resolving each of them from the same Pod and comparing what comes back
- seeing which Services have Endpoints objects behind them and which have none
- meeting the failure ExternalName is known for, and why it happened not to bite here
Before you start
-
Three Services over the same two Pods
-
What each one resolves to
-
What has endpoints, and what does not
-
The failure it is known for