← Kubernetes Course4 / 16

Services & Networking

Pods come and go with their own changing IPs. Services give them a stable address and load-balance across them — from internal-only ClusterIP to externally reachable NodePort and LoadBalancer.

Ad 728×90

Why pods need a Service

Why: pods are disposable — every replacement gets a new IP, so you can never hardwire a pod's address. A Service is a stable name and IP in front of a set of pods. It finds its pods by label selector and load-balances traffic across whichever ones are currently healthy. This is how one part of your app reliably reaches another.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web                  # send traffic to pods labelled app=web
  ports:
    - port: 80                # the Service's port
      targetPort: 80          # the container's port

ClusterIP and service discovery

ClusterIP is the default Service type: a virtual IP reachable only inside the cluster. Its real power is DNS — every Service gets a name, so other pods reach it as http://web or web.<namespace>.svc.cluster.local. You connect by NAME, never by IP, and Kubernetes handles the rest.

Create the Service and see its cluster-internal IP

kubectl apply -f service.yaml

kubectl get service web

From another pod, reach it by NAME (DNS resolves it)

kubectl run tmp --rm -it --image=busybox -- wget -qO- http://web

Expose externally with NodePort

Why: NodePort opens the same high-numbered port (30000–32767) on every node, forwarding it to your Service. It is the simplest way to reach an app from outside in a local or bare-metal cluster. Note: it is rarely used directly in production — a LoadBalancer or Ingress sits in front — but it is the building block they rest on.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080         # reach the app at <node-ip>:30080

LoadBalancer for cloud traffic

Why: on a cloud provider, type: LoadBalancer asks the platform to provision a real external load balancer with a public IP that routes to your Service. It is the standard way to put a single service on the internet. Note: on a local cluster there is no cloud to fulfill it, so the external IP stays <pending> — that is expected.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer          # cloud provisions a real external LB
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80