Kubernetes / Basic: objects and execution boundaries / Lesson 4

Services, endpoint selection, and DNS

Trace service discovery from a DNS name through a Service and ready endpoints to the intended application port.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of services, endpoint selection, and dns.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

Give replacement a stable discovery contract

Pod addresses and lifetimes change, so clients normally use a Service abstraction rather than hardcoding one Pod IP. A Service can select matching Pods and expose a stable port contract, with endpoint information represented through EndpointSlices. How traffic is implemented depends on the networking stack. A Service is not a process supervisor and cannot make an unready application serve requests. Distinguish discovery, endpoint selection, packet forwarding, and application behavior. A valid DNS answer establishes only that name resolution returned data, not that the selected peer is reachable or authorized.

Read selectors and port mapping together

The first manifest exposes Service port 80 and forwards to a named container port http on matching Pods. The Pod specification and process must actually provide that name and listener. A targetPort is not necessarily the same number as the Service port. Labels can match the wrong workload or no workload at all, and readiness can remove eligible endpoints. Inspect selector, namespace, EndpointSlice addresses and conditions, named-port resolution, and application binding as separate evidence. The object is illustrative YAML using v1 and is never created by this course.

yaml Illustrative Service port contract

apiVersion: v1
kind: Service
metadata:
  name: booking-api
  namespace: training
spec:
  selector: {app: booking, tier: api}
  ports:
    - name: web
      port: 80
      targetPort: http
  type: ClusterIP

A selected Pod must define the named port http and a real listener. This manifest alone contains no Pods and proves no endpoints or network access.

Resolve names in the caller’s context

Cluster DNS supports names whose interpretation depends on namespace and search configuration. A short name can resolve differently in another namespace; a fully qualified service name is clearer for diagnosis. The cluster domain is configurable and must not be assumed universal. The second record separates a synthetic caller, service namespace, and expected port without asserting a real DNS answer. Containers within one Pod share a network context, while localhost in another Pod refers to that other Pod. Avoid correcting the wrong layer by changing credentials when the client is resolving an unintended name.

yaml Synthetic discovery context

caller_namespace: reporting
service_namespace: training
service_name: booking-api
cluster_domain: installation-defined
service_port: 80
expected_target_port_name: http

The namespaces and port are explicit; the domain must come from the installation contract. These fields are a diagnostic record, not a Kubernetes object.

Choose exposure according to purpose

ClusterIP, NodePort, and LoadBalancer have different exposure and provider requirements. Headless Services use a different discovery pattern and do not provide the usual virtual-IP abstraction. Ingress or Gateway APIs add application routing boundaries with their own controller implementations, supported versions, and TLS policy. Do not select a public load balancer merely to bypass internal connectivity diagnosis. Define who should reach the service, through which protocol and identity checks, and at which boundary encryption terminates. Network reachability is not application authorization, and a namespace alone does not supply traffic isolation.

Verify the whole path with bounded evidence

Diagnose from the actual caller context using approved observations: name result, Service contract, endpoint eligibility, policy, transport, then application response. Distinguish connection refusal, timeout, TLS identity failure, and HTTP authorization failure rather than treating them as one DNS problem. A Service without ready endpoints needs workload or selector investigation before network tuning. Existing evidence and synthetic simulations are sufficient for this lesson; no packet, resolver query, kubectl request, port forward, or external endpoint is contacted. Record exact context and time so a later investigator can reproduce the reasoning safely.

Common errors and fixes

DNS succeeds but requests fail

Why it happens: Resolution was mistaken for endpoint and application health.
How to fix it: Inspect endpoints, policy, listener, and response separately.
Prevent it next time: Use a layered connectivity checklist.

A Service has no eligible endpoints

Why it happens: Selector, namespace, readiness, or named port does not match.
How to fix it: Compare selection and Pod evidence before routing changes.
Prevent it next time: Test selector inclusion and named-port contracts.

localhost targets the wrong Pod

Why it happens: The caller’s network context was ignored.
How to fix it: Use the documented service discovery contract.
Prevent it next time: Include caller and destination namespaces in evidence.

Check your understanding

1. Service port is 80 and targetPort is http. May the process listen on 8080?

Show worked solution

Yes, if the selected Pod declares a container port named http with number 8080 and the application binds correctly. Port declarations do not start a listener. Verify selection and readiness as well; matching numbers alone do not establish a usable endpoint.

2. A short service name works in one namespace and fails in another. What should be compared?