A Service is a stable name and address in front of a changing group of Pods, with built-in load balancing.

The two ideas inside one object

A Kubernetes Service does two jobs at once. First, it gives a group of Pods one steady identity: a fixed internal address and a fixed name that never change while the Service exists. Second, it spreads incoming requests across all the healthy Pods in that group, so no single Pod is overloaded and a failed Pod is skipped automatically. Callers only ever learn the Service’s name. They never need to know how many Pods stand behind it, where those Pods run, or whether they were replaced a minute ago.

A few words to know first

• Pod: the smallest unit Kubernetes runs, holding one or more containers that share a network address.
• Label: a small tag, like a colored sticker, attached to an object. A Pod might carry the label “app equals cart.”
• Selector: a rule that says “pick every Pod with this label.” A Service uses a selector to find its Pods.
• Load balancing: sharing work between several identical workers so that none is overwhelmed.
• Cluster: the group of machines that Kubernetes manages as one system.

flowchart LR
    C["Cart program - the caller"] -->|calls one steady name| S["Service: payments - stable name and address"]
    S --> P1["Payment Pod 1"]
    S --> P2["Payment Pod 2"]
    S --> P3["Payment Pod 3"]

To see why Services matter, look at what life is like without one.

Pods are mortal, and their addresses die with them

Every Pod in a cluster receives its own network address, called an IP address. Two Pods can talk directly using these addresses, and Kubernetes promises that this works even across different machines. That sounds convenient, but there is a catch. Kubernetes treats Pods as disposable. If a Pod crashes, a replacement is created with a new address. If you deploy a new version, the old Pods are removed and new ones appear. If the cluster adds machines or removes them, Pods move. An address that was correct in the morning may point to nothing by the afternoon.

Why not just write the address down?

Suppose the cart program stored the payment Pod’s address in a settings file. The first time that Pod restarted, every payment would fail. Suppose instead the cart program asked the cluster for the current list of payment Pods before each request. That would work, but now every program in your company would need special code to talk to Kubernetes, choose between Pods, and handle failures. It would be repetitive, error-prone, and impossible to share with programs that know nothing about Kubernetes.

The Service as the clean solution

A Service moves this whole problem into the platform. Programs use an ordinary name, the same way a website uses a domain name, and the cluster quietly keeps the list of Pods up to date behind the scenes. Your code needs no Kubernetes knowledge at all. It just calls a name.

Five gifts a Service gives you

Five small ideas explain how a Service is described and how it knows where to send traffic.

1. The selector: which Pods belong to me?

A Service does not create Pods and does not own them. It only points at them. The pointing is done with a selector, a label rule. If the Service says “select Pods labeled app equals payments,” then every Pod in the same namespace carrying that label becomes a member, and any Pod losing the label leaves the group. This loose connection is powerful: you can add, remove, or replace Pods freely, and the Service adapts without any edits.

2. Ports: the doors

A machine offers many numbered network doors called ports. A Service has a few port settings, and beginners often mix them up, so here they are in plain words:

3. The cluster IP: the virtual address

Most Services receive a cluster IP, an internal address taken from a range reserved for Services. It is called virtual because no machine or network card really owns it. It exists only as a rule inside the cluster’s networking, which redirects any traffic sent to it toward a real Pod. That is why it can stay fixed while the Pods behind it change.

4. Endpoints and EndpointSlices: the current member list

Somebody must keep track of which Pods currently match the selector and are ready. That list is stored in objects called EndpointSlices, which hold the addresses and ports of the healthy Pods. A controller in the cluster creates and updates them automatically. The older Endpoints object did the same job for all Pods at once, and it is being phased out because one huge list was slow to update in big clusters. Slices break the list into smaller pieces, roughly a hundred addresses each by default.

5. Readiness: only healthy Pods get traffic

Each Pod can define a readiness check, a small test that says “I am ready for customers.” While the test fails, for example because the app is still loading data, the Pod stays out of the member list. When it passes, the Pod is added. This is what makes rolling updates and restarts smooth.

Reading a Service definition in plain words

When you write a Service as a configuration file, it usually holds only a handful of facts, and you can read them like a short form. It has a name, which becomes the DNS name. It has a namespace, the room it lives in. It has a type, which decides who can reach it, and if you leave the type out it becomes ClusterIP. It has a selector, the label rule that finds its Pods. And it has a list of ports, each with the number callers use and the number the app listens on. That is nearly everything. A Service definition is one of the shortest and most readable objects in Kubernetes, which is one reason it is a good first object to learn.

A tip for choosing labels: use names that describe the role of the app, not its version. If a Service selects “version two,” it stops matching the moment you release “version three.” Labels for the role stay stable, while a separate label for the version can be added for other purposes, such as gradual rollouts.

A Service looks like a single object, but several cluster components cooperate to make it work.

flowchart TB
    USER["You create a Service"] --> API["API Server - stores the Service"]
    API --> ESC["EndpointSlice controller - watches Pods and Services"]
    ESC -->|writes member list| API
    API --> KP1["kube-proxy on Node 1 - programs traffic rules"]
    API --> KP2["kube-proxy on Node 2 - programs traffic rules"]
    API --> DNS["CoreDNS - adds the Service name to cluster DNS"]
    KP1 --> POD1["Pod on Node 1"]
    KP2 --> POD2["Pod on Node 2"]

The cast of characters

The virtual address is a clever illusion. Here is how the trick is done.

sequenceDiagram
    participant C as Cart Pod
    participant D as CoreDNS
    participant N as Node networking rules
    participant P as Payment Pod
    C->>D: What is the address of payments?
    D-->>C: The Service cluster IP
    C->>N: Send request to the cluster IP and port
    N->>N: Pick one ready Pod from the member list
    N->>P: Forward request to the chosen Pod address
    P-->>C: Reply travels back to the cart

Why the same connection keeps going to the same Pod

You might wonder what stops the next packet of the same conversation from being sent to a different Pod. The answer is the Linux connection tracking table. The first packet of a new connection triggers the choice of a Pod, and the kernel writes a note saying “this connection belongs to that Pod.” Every later packet in the same connection follows the note, and the replies are translated back using the same note. This is why the balancing decision happens once per connection, not once per request, and why a long-lived connection sticks to one Pod for its whole life. It also explains why a Pod that disappears in the middle of a connection can cause errors: the note still points at it until the connection ends or times out.

kube-proxy modes: three ways to write the rules

Replacing kube-proxy altogether

Some network plugins, most famously Cilium, use a Linux technology called eBPF to perform Service routing directly inside the kernel, without kube-proxy at all. This can be faster and gives better visibility. Google’s GKE Dataplane V2 is built on this idea, and other managed services offer similar options. From your point of view as an application developer, nothing changes: you still create a Service and call its name.

Every Service has a type that decides who can reach it. The first type, and the default, is ClusterIP.

What it does

A ClusterIP Service gets a virtual address that works only inside the cluster. Other Pods can call it, and so can programs running on the cluster’s own machines, but nobody outside can reach it directly. This is the right choice for most internal parts of an application: databases, payment engines, background workers, and internal APIs. It follows a good security habit: keep things private unless there is a reason to expose them.

A Service you already use without knowing

Every cluster contains a Service named kubernetes in the default namespace. It is the stable internal address of the API server itself. Programs running in Pods, such as controllers and monitoring tools, use it to find the cluster’s front door without knowing which control plane machine is currently active. This is a perfect example of the idea in action.

Where the virtual address comes from

When the cluster is created, the administrator reserves a block of private addresses just for Services, called the Service address range. The API server hands out one address from this block to every new Service and records it so that no two Services share one. The block is separate from the range used for Pod addresses, which is why Service addresses and Pod addresses never collide. You can ask for a particular address when you create a Service, but it is almost always better to let the cluster choose. If the range is too small, you can run out of addresses in a very large cluster, so platform teams choose it with growth in mind.

When to use ClusterIP

• Any component that is called only by other components in the cluster.
• Databases and caches that should never be public.
• Services placed behind an Ingress or Gateway, which handles the outside world.
• Anything you are unsure about, since private is the safe default.

When people outside the cluster must reach your app, two more Service types come into play. They build on each other like layers.

flowchart LR
    U["Customer on the internet"] --> LB["Cloud load balancer - public address"]
    LB --> NP1["NodePort door on Node 1"]
    LB --> NP2["NodePort door on Node 2"]
    NP1 --> CIP["ClusterIP - virtual address"]
    NP2 --> CIP
    CIP --> A["Pod A"]
    CIP --> B["Pod B"]
    CIP --> C["Pod C"]

NodePort: a side entrance on every machine

A NodePort Service does everything a ClusterIP Service does, and additionally opens the same port number on every worker machine. By default this number comes from the range 30000 to 32767. Anyone who can reach any machine’s address on that port is forwarded to the Service, and from there to a Pod, even if that Pod runs on a different machine. It is a quick way to test an app from outside, and it is the building block that other types use.

In real production use, NodePort has drawbacks. The port numbers are unfamiliar and high. You must know the addresses of your machines, and those may change. Firewalls must be opened for the whole range. And there is no health-checking front layer that stops sending traffic to a machine that has failed. For these reasons, it is mainly used for learning, small tests, or as a hidden layer beneath a load balancer.

LoadBalancer: a proper public front door

A LoadBalancer Service goes one step further. It does all the work of NodePort and then asks the cloud provider, through the cloud controller, to create a real external load balancer with its own public address. The provider’s load balancer checks the health of the machines and spreads traffic across them. When the address is ready, Kubernetes writes it into the Service, and you can point your website name at it.

Internal load balancers

A LoadBalancer Service does not have to face the internet. Most clouds let you ask for an internal load balancer, which receives an address only on your private network. This is useful when a Service must be reachable from other clusters, from virtual machines outside Kubernetes, or from your company network over a private link, but never from the public internet. Requesting it usually means adding a provider-specific annotation to the Service, which is one more reason to review annotations carefully when you move between clouds.

What you need to know about LoadBalancer

• It costs money. Each Service of this type usually creates its own cloud load balancer, and you pay for each one every hour, plus data transfer.
• It depends on the cloud. On AWS, Google Cloud, and Azure, it works out of the box. In a private data center, or on a laptop, there is no cloud to answer, so the address stays “pending” unless you install a helper such as MetalLB.
• Settings live in annotations. Details such as internal versus public, or which kind of load balancer to build, are usually chosen with provider-specific annotations, so they are not fully portable.
• It works at the network level. A LoadBalancer Service moves raw connections and does not understand website addresses or paths. For that, use Ingress or Gateway (Chapter 11).

Not every Service points at ordinary Pods. Three special forms handle unusual needs.

ExternalName: a nickname for something outside

An ExternalName Service does not select Pods at all. Instead, it makes a name inside the cluster point to a name outside it. When a Pod asks for the Service, cluster DNS answers with an alias to the outside name, such as the address of a managed database run by a cloud provider. No proxying or load balancing happens; it is only a nickname. Its advantage is that your applications use a stable in-cluster name, and if you later move the database, you change one Service instead of every application.

Headless Services: the phone book without a receptionist

Sometimes load balancing is exactly what you do not want. A database cluster needs each member to find the others by name, and a client may need to connect to a particular member. A headless Service is created by setting the cluster IP to “None.” It gets no virtual address and no load balancing. Instead, DNS returns the individual addresses of all the ready Pods, and the caller decides which to use.

Headless Services are the partner of StatefulSets, the Kubernetes tool for running stateful programs such as databases. Together they give each Pod a stable, predictable name, like database-0, database-1, and database-2, which survives restarts.

Services without selectors: pointing at anything

If you create a Service without a selector, Kubernetes does not create a member list for you. You supply the addresses yourself. This lets you give a friendly in-cluster name to something that is not a Pod, for example an old database server in your data center, or an application in another cluster. Applications inside the cluster call the Service name, and you control where it points.

A Service is only useful if others can find it. Kubernetes gives you two mechanisms, and one of them is far better.

DNS: the recommended way

The cluster runs its own name server, CoreDNS. Whenever you create a Service, it automatically gains a name of the form service-name.namespace.svc.cluster.local. So a Service called payments in the namespace shop is known as payments.shop.svc.cluster.local. Every Pod is configured to search sensible shortcuts, so the ways you can call it depend on where you are:

DNS also supports named ports, which lets callers look up not only the address but also which port carries a particular protocol. For headless Services, DNS returns the list of Pod addresses instead of a single virtual address.

A hidden cost: the search list

The convenience of short names comes with a small price. Each Pod is configured with a list of suffixes to try, such as its own namespace, the general Service suffix, and the cluster suffix. It also has a setting that treats any name with fewer than five dots as “probably local,” so it tries the suffixes first. When your program looks up a real outside website like a payment provider, the Pod may first ask DNS several wrong questions, such as the outside name with the cluster suffix added, before it gets to the correct one. In a busy application this can multiply the load on CoreDNS and add small delays. Teams that notice this often add a trailing dot to outside names, which marks them as complete, or adjust the setting for their Pods, or run a local DNS cache on every machine.

Environment variables: the older way

When a Pod starts, Kubernetes also places details of the Services that already exist into its environment variables, for example the host and port of a Service named payments. This works, but it has a trap: only Services created before the Pod starts appear. Creating things in the wrong order leads to confusing behavior. For this reason, teams rely on DNS.

The most important behavior of a Service happens during change: updates, crashes, and scaling.

Life of a Service

What happens during a rolling update

sequenceDiagram
    participant D as Deployment
    participant NP as New Pod
    participant OP as Old Pod
    participant E as EndpointSlice
    participant K as kube-proxy
    D->>NP: Start a new version Pod
    NP->>E: Becomes ready, so its address is added
    E->>K: Member list changed
    K->>K: Add new Pod to traffic rules
    D->>OP: Begin shutting down an old Pod
    OP->>E: Marked as terminating, so removed from new traffic
    E->>K: Member list changed
    K->>K: Remove old Pod from traffic rules
    OP->>OP: Finish in-flight requests and exit

Watch the order. A new Pod receives traffic only after its readiness check passes. An old Pod is taken out of the member list when it starts terminating, and only then is it stopped. In an ideal update, no customer request is sent to a Pod that is not ready or that has already gone.

Scaling up and down behind a Service

The Service makes scaling almost invisible. When traffic grows, an autoscaler raises the number of Pods in the Deployment. Each new Pod starts, passes its readiness check, and only then joins the member list. From that moment the Service shares traffic with it, and the caller sees nothing but faster answers. When traffic falls, the autoscaler removes Pods, and each leaving Pod is taken out of the member list before it stops. Because callers only know the Service name, they never have to be told that the number of workers changed. This separation, where callers depend on a name and the platform manages the workers, is the central idea of the Service, and it is why a small team can run an application that grows a hundred times bigger without rewriting how its parts find each other.

One practical point: a new Pod that takes a long time to become ready will not help during a sudden spike, because it receives no traffic until it passes its check. Applications that start quickly, or that keep a few spare Pods warm, cope with spikes better than ones that need a minute to load data.

The race that catches beginners

There is a small timing gap. The signal to shut down a Pod and the update of network rules on every machine happen at the same time, not one after the other. A few machines may still send a request to the old Pod for a fraction of a second after the Pod has started closing. If the app exits instantly, those requests fail. The fix is to give the app a graceful shutdown: keep serving for a short while after the shutdown signal, finish work already in progress, and then exit. Many teams add a short pause in a “pre-stop” step to cover the gap.

A common beginner puzzle is how these three fit together. They are layers, not competitors.

flowchart LR
    U["Customer browser"] --> DNSX["DNS for the website name"]
    DNSX --> CLB["Cloud load balancer"]
    CLB --> IC["Ingress controller or Gateway - reads host and path"]
    IC -->|shop.example.com| S1["Service: storefront"]
    IC -->|shop.example.com/api| S2["Service: catalog"]
    IC -->|pay.example.com| S3["Service: payments"]
    S1 --> P1["Storefront Pods"]
    S2 --> P2["Catalog Pods"]
    S3 --> P3["Payment Pods"]

How to choose

• For internal calls between programs, use a ClusterIP Service.
• For web applications reached by website names and paths, use Ingress or Gateway in front of ClusterIP Services.
• For non-web protocols such as a database port, a game server, or a message broker that must be public, use a LoadBalancer Service directly.
• For a quick test, use NodePort or a temporary port-forward to one Pod.

Once the basics feel comfortable, a few extra settings let you fine-tune how a Service treats traffic.

Choosing the right balance

Each of these switches trades simplicity for efficiency or control. Start with defaults. Turn on a special setting only when you have a measured reason, such as a legal need to see real client addresses, or a bill showing large cross-zone transfer costs. Then test, because a setting that fits one workload can quietly harm another.

Services solve a big problem elegantly, but they have limits worth knowing.

When you might not need a Service

Not every Pod needs a Service. A batch job that reads from a queue and writes to a database receives no incoming calls, so no Service is required. A program that only sends requests out never needs an address of its own. Creating Services for things that do not receive traffic adds clutter and, in very large clusters, extra rules for the machines to maintain. A helpful question is “does anyone need to call this by name?” If the answer is no, leave the Service out.

Key trade-offs at a glance

A useful rule of thumb: start with plain ClusterIP Services and one shared entry point. Add complexity, such as a service mesh or special policies, only when a real need appears. Simple designs are easier to understand at two in the morning when something breaks.

A Service decides who can reach your application, which makes it one of the most security-sensitive objects you create.

Layers of protection

Common ways Services are exposed by accident

• A LoadBalancer Service created “temporarily” for a test and never removed, exposing an admin page or database to the internet.
• A database exposed as a public LoadBalancer for convenience during a migration.
• Selectors that are too broad, so a Service accidentally forwards traffic to Pods that were never meant to receive it.
• Cloud firewall rules opened wide to make NodePort work.
• A monitoring or dashboard Service exposed publicly without sign-in.

Segmenting with namespaces and policies

Use namespaces to group related Services, and combine them with network policies so that traffic between groups must be explicitly allowed. A good starting rule is “deny everything, then allow what each app needs.” It takes an afternoon to set up and pays back the first time something goes wrong.

Because a Service is a set of rules and lists, not a running program, you watch it indirectly, through the parts that make it work.

What to watch

Logs and events

Services themselves do not write logs, but the components around them do. CoreDNS logs show name lookups. Ingress controllers log every web request, which is often the best record of customer traffic. Cloud load balancers can write access logs. Kubernetes events, for example about a load balancer that could not be created, appear on the Service object and are the first place to look when something is stuck in a pending state.

A calm way to troubleshoot

When “the Service does not work,” walk down the path from the caller to the Pod, one step at a time. Most problems are found in the first three questions.

flowchart TD
    START["Requests to the Service fail"] --> Q1{"Does the name resolve in DNS?"}
    Q1 -->|No| F1["Check spelling, namespace and CoreDNS health"]
    Q1 -->|Yes| Q2{"Does the Service list ready endpoints?"}
    Q2 -->|No| F2["Check selector labels, Pod readiness and Pod status"]
    Q2 -->|Yes| Q3{"Does targetPort match the app port?"}
    Q3 -->|No| F3["Correct the port numbers"]
    Q3 -->|Yes| Q4{"Do network policies allow the traffic?"}
    Q4 -->|No| F4["Add or fix the allow rule"]
    Q4 -->|Yes| F5["Check app logs, kube-proxy and network plugin health"]

The usual suspects

• Selector mismatch: a typo means zero Pods match, so the Service has no endpoints and every call fails.
• Wrong target port: the app listens on one number and the Service forwards to another.
• Pods not ready: the readiness check fails, so Pods are silently left out.
• Wrong namespace: the caller uses a short name that resolves in its own namespace, where no such Service exists.
• Pending load balancer: no cloud controller, no quota, or a permission problem.
• Blocked by policy: a network policy or a cloud firewall quietly drops the traffic.

Patterns are habits shared by teams that run Services well. Anti-patterns are shortcuts that look harmless until they break.

Patterns that work

Anti-patterns to avoid

A short checklist that saves a lot of late-night debugging.

Best practices

• Use clear, consistent labels. A shared labeling scheme makes selectors simple and reduces accidental matches.
• Name ports. Named ports let you change a port number in the Pod without editing every Service.
• Always define readiness checks and, for slow starters, startup checks.
• Handle shutdown gracefully so old Pods finish current work while the member list updates.
• Prefer DNS over environment variables for discovery.
• Run more than one Pod behind every important Service, spread across machines and zones.
• Restrict traffic with network policies and start from “deny by default.”
• Limit LoadBalancer Services and review them regularly for forgotten ones.
• Keep Services in the same namespace as their Pods and use clear namespace boundaries.
• Test failure. Delete a Pod under load and confirm that customers notice nothing.

Common mistakes

These examples come from what projects and companies have said publicly. Details may have changed since.