Services: ClusterIP, NodePort, LoadBalancer and endpoints

How a Service gives changing Pods one stable address, what each Service type adds, and how to read EndpointSlices.

Pods come and go, and each new Pod gets a new IP. A Service gives a group of Pods one address that does not change. Your frontend calls http://api, and the Service passes each request to one of the api Pods. The exam topic is Use ClusterIP, NodePort, LoadBalancer service types and endpoints.

Expect one task that says "expose", and one where a Service exists but nothing answers. Both are quick if you know three things:

• The selector decides which Pods get the traffic.
• targetPort must be the port the container listens on.
• The EndpointSlice shows which of those two is wrong.

What a Service is

A Service is a stable address in front of a group of Pods. It has three parts:

• A ClusterIP: a virtual IP address from the Service range (10.96.0.0/16 in this lab).
• A DNS name, such as api, so clients never need to know the IP.
• A selector, such as app=api. Every Pod in the same namespace with those labels gets the traffic.

Three things happen behind the scenes to make that work:

1. 1.The EndpointSlice controller watches the Pods. It writes the IPs of the matching Pods, and whether each one is ready, into an EndpointSlice.
2. 2.kube-proxy on every node reads those EndpointSlices. It turns them into network rules on the node (iptables rules in this lab).
3. 3.A client connects to ClusterIP:port. The rules on the client's node change the destination to one ready PodIP:targetPort.

No program listens on the ClusterIP itself, which is why you cannot ping a Service. kube-proxy runs as a DaemonSet in kube-system, one Pod per node. Its mode is in the kube-proxy ConfigMap: iptables here, with nftables as the newer choice.

Here is a Service in YAML, with the fields you set most often:

apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: nw-svc
spec:
  type: ClusterIP            # default; NodePort and LoadBalancer build on it
  selector:
    app: api                 # must match the Pod template labels, not the Deployment's own labels
  ports:
    - name: http             # required once a Service has more than one port
      protocol: TCP
      port: 80               # what clients connect to on the ClusterIP
      targetPort: 8080       # container port; a number or a named containerPort such as "http"

port, targetPort and nodePort: three ports, three jobs

These names look alike, but each one is a different port:

targetPort can also be a name, such as http. It then means the container port with that name. That lets you change the container's port number without editing the Service. If you leave targetPort out, it is the same as port. That is a common cause of "connection refused".

The Service types

Each type adds one more way in, on top of the type before it.

A LoadBalancer Service needs a helper outside Kubernetes, because Kubernetes only records the request. A cloud provider's controller (AWS, GCP, Azure) or an add-on such as MetalLB creates the load balancer and fills in its address. Without one, the Service still works as a NodePort. You can see this on ingress-nginx-controller in this lab.

Quick commands: expose and create service

Two commands create a Service in one line. The difference is the selector:

• kubectl expose copies the selector from the Deployment, so the Service finds the right Pods.
• kubectl create service always sets the selector to app=<service-name>. If your Pods have other labels, fix the selector afterwards.

# expose reads the Deployment's selector, so the endpoints are right by construction
kubectl -n nw-svc expose deploy api --name=api-svc --port=80 --target-port=8080
kubectl -n nw-svc expose deploy api --name=api-np --type=NodePort --port=80 --target-port=8080
#   there is no --node-port flag on expose; set it afterwards:
kubectl -n nw-svc patch svc api-np --type=json -p='[{"op":"replace","path":"/spec/ports/0/nodePort","value":30080}]'

# create service sets the selector to app=<service-name>; correct it if your Pods differ
kubectl -n nw-svc create service clusterip api --tcp=80:8080
kubectl -n nw-svc create service nodeport api --tcp=80:8080 --node-port=30080
kubectl -n nw-svc create service externalname docs --external-name=kubernetes.io
kubectl -n nw-svc create service clusterip db --clusterip=None --tcp=5432:5432   # headless

# A Pod can be exposed too (it uses the Pod's labels as the selector)
kubectl -n nw-svc expose pod web --port=80 --target-port=8080 --name=web

Endpoints and EndpointSlices

An EndpointSlice is the list of Pod IPs behind a Service. When a Service does not answer, look here first.

• Each slice has the label kubernetes.io/service-name=<service>, so you find it by label, not by name.
• Each address has conditions, such as ready. Only ready Pods get traffic.
• The older Endpoints object still exists, but reading it prints a deprecation warning. Use slices in scripts; either is fine for a quick look.

kubectl -n nw-svc get endpointslices -l kubernetes.io/service-name=api-svc
# NAME            ADDRESSTYPE   PORTS   ENDPOINTS                       AGE
# api-svc-x7k2p   IPv4          8080    10.244.157.130,10.244.89.67   10s

kubectl -n nw-svc describe svc api-svc | grep -E 'Selector|TargetPort|Endpoints'
kubectl -n nw-svc get endpoints api-svc       # works, with "v1 Endpoints is deprecated" warning

A Service whose selector matches no Pod still looks fine in kubectl get svc. The signs are elsewhere:

• kubectl describe svc shows an empty Endpoints: line.
• The EndpointSlice shows <unset> for its ports and endpoints.
• Clients get connection refused at once, because kube-proxy rejects traffic to a Service with no backends.
• Pods that match but are not Ready appear with ready=false, and get no traffic.

kubectl -n nw-svc get svc orders -o jsonpath='{.spec.selector}{"\n"}'
kubectl -n nw-svc get pods --show-labels
kubectl -n nw-svc get pods -l app=orders,tier=backend      # paste the selector here; empty means mismatch
kubectl -n nw-svc get endpointslices -l kubernetes.io/service-name=orders

# Fix the Service, not the Pods, unless the question says otherwise
kubectl -n nw-svc set selector svc orders app=orders,tier=backend
# or: kubectl -n nw-svc patch svc orders -p '{"spec":{"selector":{"app":"orders"}}}'