✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Kubernetes Service Definition

A Kubernetes Service Definition is a resource that enables communication between pods by defining access points and routing rules within a cluster.

Kubernetes Service Definition is the precise characterization of a Service as an API object that defines a stable, virtual network identity for a dynamic, selector-matched set of Pods, formally decoupling the address at which a set of Pods is reached from the specific, changing set of Pod IP addresses that currently back it. A Service does not run anything itself; it is a declarative record that other components, principally kube-proxy and cluster DNS, use to implement the actual routing behavior it specifies.

Formal Structure

Selector and Port Mapping

A Service's spec formally consists of a label selector, identifying the Pods it targets, and one or more ports entries, each mapping a port exposed by the Service to a targetPort on the matched Pods, together defining both which Pods receive traffic and which port on those Pods it is delivered to.

apiVersion: v1
kind: Service
metadata:
  name: codartium-api
spec:
  selector:
    app: codartium-api
  ports:
    - port: 80
      targetPort: 8080
service = ( selector , ports , type , clusterIP )

Selector-to-Endpoints Derivation

A Service's set of backing addresses is not stored directly on the Service object; it is formally derived, and continuously re-derived by a controller, into a separate Endpoints or EndpointSlice object, computed as the set of Pods currently matching the Service's selector and reporting as ready.

endpoints = { p ∈ pods ∣ labels ( p ) ⊇ selector ∧ ready ( p ) }

Formal Types

ClusterIP

The default type: the Service is assigned a virtual IP address routable only within the cluster's internal network, formally not reachable from outside the cluster by any built-in mechanism.

NodePort

A superset of ClusterIP: in addition to the internal virtual IP, the Service is assigned a static port, reserved identically on every node in the cluster, formally making the Service reachable via any node's address on that port.

LoadBalancer

A superset of NodePort: the Service additionally triggers a request to the underlying cloud provider's API to provision an external load balancer configured to forward to the Service, formally requiring integration with a cloud-controller-manager capable of fulfilling that provisioning request.

ExternalName

A distinct type that formally does not proxy any traffic and defines no selector or ports in the usual sense; it maps the Service's DNS name to an external DNS name via a CNAME record, resolved entirely by the cluster's DNS layer rather than by kube-proxy.

spec:
  type: ExternalName
  externalName: payments.example-provider.com

The Special Case of clusterIP: None

Headless Services

Setting spec.clusterIP: None formally suppresses virtual IP allocation for the Service; DNS queries against a headless Service resolve directly to the IP addresses of its individual matching Pods rather than to a single virtual IP, a defined behavior specifically relied upon by StatefulSets to expose stable, individually addressable Pod identities.

spec:
  clusterIP: None
  selector:
    app: codartium-db

Formal Guarantees a Service Provides

Address Stability

A Service's name, and for ClusterIP and NodePort/LoadBalancer types its virtual IP, is formally guaranteed to remain constant for the Service object's lifetime, independent of any change to the set or identity of Pods matching its selector.

Continuous Reconciliation of Membership

The set of Pods considered part of a Service is formally re-evaluated continuously by the Endpoints/EndpointSlice controller as matching Pods are created, become ready, become unready, or are deleted, without requiring the Service object itself to be modified.

kubectl get service codartium-api -o jsonpath='{.spec.clusterIP}'
kubectl get endpointslices -l kubernetes.io/service-name=codartium-api

What a Service Formally Does Not Guarantee

A Service definition makes no guarantee about layer 7 behavior, host- or path-based routing, TLS termination, or request-level load balancing algorithms; those concerns are formally the responsibility of an Ingress or Gateway API resource layered on top of one or more Services, not the Service object itself, which operates strictly at the level of stable addressing and basic connection distribution.

Related content