DevOps Dictionary

Kubernetes Service

A Kubernetes Service is a stable network endpoint that exposes one or more pods and routes traffic to them inside or outside a Kubernetes cluster. In practical terms, it gives your application a consistent DNS name and virtual IP address, even when the backing pods are created, deleted, rescheduled, or replaced during deployments.

Services solve a core Kubernetes networking problem: pods are temporary, and their IP addresses change. Instead of sending traffic directly to pod IPs, other workloads send traffic to a Service. Kubernetes then forwards that traffic to healthy matching pods.

What a Kubernetes Service does

• Provides stable access to pods: A Service keeps the same name and cluster IP while pods behind it change.
• Routes traffic: It forwards requests to pods selected by labels, such as app=api.
• Supports service discovery: Kubernetes DNS creates names such as api.default.svc.cluster.local.
• Balances traffic: It spreads requests across matching pod endpoints.
• Exposes workloads: Depending on the Service type, it can expose apps only inside the cluster or to external clients.

How it works

A Service usually uses a label selector to find the pods it should send traffic to. For example, if your backend pods have the label app=backend, the Service can select those pods and route traffic to them.

Kubernetes tracks the matching pods through EndpointSlices. These EndpointSlices store the pod IPs and ports that currently back the Service. When pods scale up, fail, or move to another node, Kubernetes updates the endpoints automatically.

Inside the cluster, kube-proxy or an equivalent networking component programs routing rules so traffic to the Service IP reaches one of the available pods. In many modern clusters, this behavior may be implemented with iptables, IPVS, or eBPF-based networking depending on the cluster setup.

Common Service types

• ClusterIP: The default type. It exposes the Service only inside the cluster. Use it for internal APIs, databases, queues, and backend services.
• NodePort: Exposes the Service on a static port on each Kubernetes node. It is useful for testing or simple external access, but less common for production internet-facing traffic.
• LoadBalancer: Creates an external load balancer through the cloud provider, such as AWS, Azure, or Google Cloud. This is common for public APIs and ingress controllers.
• ExternalName: Maps a Kubernetes Service name to an external DNS name. It does not proxy traffic. It returns a CNAME record.

Simple example

Assume you run an API with three pod replicas:

• api-7c9f9d5b6f-a1
• api-7c9f9d5b6f-b2
• api-7c9f9d5b6f-c3

Each pod has its own IP address, and those IPs can change during rolling updates. Instead of having a frontend call those pod IPs directly, you create a Service named api. The frontend sends requests to http://api:8080, and Kubernetes sends each request to one of the healthy API pods.

If you deploy a new version and Kubernetes replaces all three pods, the frontend does not need to change. The Service keeps the same name and IP, while the endpoints behind it update.

Key fields in a Service

• metadata.name: The Service name, used for DNS discovery inside the cluster.
• spec.type: Defines how the Service is exposed, such as ClusterIP or LoadBalancer.
• spec.selector: Matches pods by label.
• spec.ports.port: The port exposed by the Service.
• spec.ports.targetPort: The port on the pod that receives traffic.
• spec.ports.protocol: Usually TCP, but UDP and SCTP are also supported.

Example YAML

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP

In this example, other workloads can call the Service on port 80. Kubernetes forwards the traffic to port 8080 on pods labeled app=api.

Common use cases

• Internal service-to-service communication: A frontend calls an internal backend API through a ClusterIP Service.
• Database access inside the cluster: Applications connect to a database Service instead of individual database pod IPs.
• Ingress traffic routing: An Ingress controller often runs behind a LoadBalancer Service.
• Cloud load balancer integration: Managed Kubernetes platforms can create external load balancers for LoadBalancer Services.
• Stable endpoints for platform services: Monitoring, logging, CI runners, and internal developer platforms often use Services for predictable connectivity.

Kubernetes Service vs Ingress

A Kubernetes Service operates at the cluster networking level and exposes pods through a stable endpoint. An Ingress manages HTTP and HTTPS routing rules, usually for traffic entering the cluster from outside.

For example, you might use:

• A ClusterIP Service for your internal api workload.
• An Ingress rule for api.example.com that routes external HTTPS traffic to that Service.
• A LoadBalancer Service to expose the Ingress controller itself to the internet.

Kubernetes Service vs Deployment

A Deployment manages pods and updates them over time. A Service gives those pods a stable network identity.

In most application setups, you use both. The Deployment defines how many replicas should run and which container image to use. The Service defines how other workloads reach those replicas.

Benefits

• Stable networking: Clients do not need to track changing pod IPs.
• Built-in discovery: Workloads can use Kubernetes DNS instead of hardcoded addresses.
• Simple scaling support: When replicas increase or decrease, the Service updates its endpoints.
• Cloud integration: A LoadBalancer Service can request a cloud load balancer on managed platforms such as EKS, AKS, and GKE.
• Clear separation: Teams can update workloads without changing how other services connect to them.

Tradeoffs and limitations

• It is not a full application gateway: A Service does not provide path-based routing, TLS termination, or host-based routing by itself. Use Ingress or Gateway API for that.
• LoadBalancer behavior depends on the environment: In cloud clusters, it usually provisions a cloud load balancer. In local clusters, it may do nothing unless you install an implementation such as MetalLB.
• Selectors must match correctly: If the Service selector does not match pod labels, the Service will have no endpoints.
• Debugging can span several layers: Issues may come from DNS, NetworkPolicies, kube-proxy, CNI behavior, readiness probes, or cloud load balancer settings.

Where it fits in real infrastructure

In production Kubernetes environments, Services usually sit between application workloads, ingress controllers, service meshes, and cloud networking. For example, a data platform running Airflow on EKS may expose webserver and worker-related components with Services as part of the cluster design. You can see this pattern in a practical guide to deploying Apache Airflow on AWS EKS.

The same Service concepts apply across managed Kubernetes platforms. On Azure, for example, teams running Azure Kubernetes Service still use Service objects for internal endpoints and cloud-backed load balancers.

Services also work well with infrastructure automation patterns. If you manage cloud resources from Kubernetes, tools such as Crossplane can define related infrastructure while Kubernetes Services expose the workloads that consume it. For example, you can combine application manifests with cloud resource provisioning using Crossplane on Kubernetes.

How to think about it

Use a Kubernetes Service when pods need a stable way to receive traffic. If the caller is inside the cluster, start with ClusterIP. If you need external access, use LoadBalancer directly or place an Ingress or Gateway in front of a Service.

For most teams, the Service is one of the basic building blocks of Kubernetes application delivery. It keeps networking predictable while pods remain dynamic.