Object Names, UIDs, and DNS Rules
You create a Service named My_Service. The API server rejects it immediately. You rename it my_service. Still rejected. These are not arbitrary restrictions. The naming rules for Kubernetes objects are shaped by how Services are exposed inside the cluster, and breaking them has consequences that go beyond a failed kubectl apply.
Name vs UID
Every Kubernetes object has two identifiers, and they serve different purposes.
The name is the human-readable identifier you choose. It must be unique within a namespace for a given resource type. You can have a Pod named web and a Service named web in the same namespace, because they are different kinds. But you cannot have two Pods named web in the same namespace. After you delete an object, the name becomes available again and a new object can use it.
The uid is a globally unique identifier generated by Kubernetes at creation time. It is never reused, even if you delete an object and recreate it with the same name. The new object gets a new uid. You rarely see it in day-to-day operations, but it appears in kubectl get ... -o yaml under metadata.uid.
Why have a uid at all if you already have a name? Because the name is mutable in the sense that a new object can claim it after the previous one is deleted. The uid is immutable and unique across the entire history of the cluster. It is what Kubernetes uses internally to track ownership, garbage collection, and references between objects. When a ReplicaSet creates Pods, it records its own uid in each Pod’s ownerReferences field, not its name.
If you delete a Pod and immediately recreate it with the same name, does the new Pod have the same UID as the old one?
Reveal answer
No. Kubernetes generates a new uid for every object at creation time, regardless of the name. The name can be reused after deletion, but the uid is never reused. This is how Kubernetes distinguishes “this specific Pod instance” from “a Pod carrying this name at some point in time”.
Naming Rules for Standard Objects
Most Kubernetes objects follow the DNS subdomain naming convention defined in RFC 1123. The rules are:
- Lowercase letters and digits only
- Hyphens (
-) are allowed, underscores are not - Must start and end with a letter or digit
- Maximum 253 characters total
These rules apply to Pods, Deployments, ConfigMaps, and most other resources. Violating them causes an immediate API server rejection with a clear validation error.
Why Services Have Stricter Consequences
Services follow the same naming rules, but the stakes are higher. When you create a Service named web-frontend in the default namespace, Kubernetes registers a DNS record for it:
web-frontend.default.svc.cluster.localAny Pod inside the simulated cluster can reach that Service by name. The DNS record is built directly from the Service name. If the Service name is not a valid DNS label, the DNS record cannot exist, and any application trying to connect by name will fail with a name resolution error, not a connection refused error. That distinction is hard to debug.
This is why an underscore in a Service name is a real problem. It is not just a style violation. The DNS specification forbids underscores in hostnames, so CoreDNS cannot create a valid record for a Service named my_service. The Service might be accepted by the API server in some edge cases, but name resolution will silently fail.
Submitting a Service with an invalid name produces a clear rejection from the API server. Try it in the simulator:
kubectl create service clusterip my_service --tcp=80:80
The API server responds with a validation error: metadata.name: Invalid value: "my_service": a DNS-1035 label must consist of lower case alphanumeric characters or '-'. This error appears before the Service is ever created. Fix the name before applying.
Which of these names is valid for a Kubernetes Service?
My-Service(uppercase letters are not allowed)my-service-v2(correct)my_service(underscores are not allowed)
Reveal answer
my-service-v2. Uppercase letters violate the lowercase requirement, and underscores are invalid in DNS labels. Both would be rejected by the API server with a validation error on metadata.name.
Checking Names Before You Apply
A quick way to validate a name without creating the resource is to combine --dry-run=server with the creation command. The API server will evaluate the name against its admission rules and reject it if invalid, without persisting anything:
kubectl create service clusterip my-service-v2 --tcp=80:80 --dry-run=serverIf the output says service/my-service-v2 created (server dry run), the name passes validation. If it prints a validation error, you know before any real object is created.
Why do Service names in Kubernetes need to follow DNS naming rules specifically, when other objects like ConfigMaps have slightly more relaxed rules?
Reveal answer
Because a Service name becomes a DNS hostname. CoreDNS registers a record using the Service name directly. If the name is not a valid DNS label, the record cannot be created, and in-cluster name resolution breaks silently. Other objects like ConfigMaps are not exposed through DNS, so their names do not carry the same network-level constraint.
You now have a complete foundation in the Kubernetes object model: what objects are, how they are structured, how to generate them from the CLI, and how naming rules connect to network behavior. The next module goes deep on Pods, the smallest deployable unit in Kubernetes, and you will create, inspect, and manage them directly in the simulator.