Kubernetes Services

19 Sep 2023 - rich

Pods fail… they get replaced Scaling up results in more, new, many pods Scaling down causes a decrease in the number of pods Rolling updates delete existing pods and create new pods This is why you should never try to connect directly to any pod

Services provide a stable and reliable network endpoint for groups of unreliable pods.

Every Service gets its own stable IP address and its own stable DNS name and its own stable port

Services use labels and selectors to dynamically select the Pods to which they send traffic.

The Service Object

Labels and Selectors

Services and EndpointSlices

Cluster internal DNS resolves the Service name to an IP address Traffic is directed to this stable IP address which is then sent to one of the active pods

The EndpointSlices can be directly queried

Accessing Services

Default: ClusterIP

This Service provides a stable IP address that is accessible only from inside the cluster.

Every Service you create is assigned a ClusterIP

Accessing Services Outside of the Cluster

There are two types of Services that can be used for access from outside of the cluster…


NodePort Services use the default ClusterIP type to allow external clients to access a dedicated port on every cluster node in order to reach the Service.

The NodePort Service adds an externally accessible port that is available on any node in the cluster

For example:

apiVersion: v1
kind: Service
  name: exampleService
  type: NodePort
  - port: 8888
    nodePort: 30333
    app: exampleApp

Internally, Pods can access this service by its name (e.g. exampleService) using port 8888. To connect from outside of the cluster, traffic is directed to any node in the cluster on port 30333

The request is forwarded from the cluster node to the service inside of the cluster which is then forwarded to an active pod somewhere in the cluster (that could be on any node inside the cluster)

The ‘problem’ with doing this is that the external client be able to access individual clusternode IP addresses (it only needs one, but should have at least two for redundancy and failover). The way to work around this would be to use a LoadBalancer Service


LoadBalancer Services make external access even easier by integrating with an internet- facing load-balancer on your cloud platform. You get a high-performance highly- available public IP or DNS name that external clients can use to access the Service. You can even register friendly DNS names to make access even simpler – you don’t need to know cluster node names or IPs.