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

• provides stable networking for pods
• provides ip, port, and dns name
• is a REST object in the API - defined in a manifest file and posted to the API server
• load balances traffic to pods with labels that match selector
• have a static front end and a dynamic back end

Labels and Selectors

• are used to define (select) the pods in the same group
• for a pod to be selected, it must match (contain) all the labels specified in the Service’s selector
• a pod can have more labels that what the serive is looking for, just not less

Services and EndpointSlices

• EndpointSlice objects are used by the Service
• created automatically and are up-to-date lists of pods that belong to a Service

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

• this circumvents (skips) the DNS lookup
• Endpoints objects have been replaced with EndpointSlices

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

• this IP and the name of the Service is registered with the internal DNS service
• All Pods in the cluster know and can use the cluster’s DNS service
• All Pods in the cluster send service discovery requests to internal DNS
• All Pods are able to convert (resolve) these Service names to ClusterIPs
• only works inside the cluster, since cluster DNS service is required
• this does not work for any clients outside of the cluster

Accessing Services Outside of the Cluster

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

NodePort

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
metadata:
  name: exampleService
spec:
  type: NodePort
  ports:
  - port: 8888
    nodePort: 30333
  selector:
    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

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.