IT 3300 : Virtualization

Kubernetes — Services & Networking

The networking rules

  • Every pod gets its own IP
  • Any pod can reach any other pod without NAT
  • But pods are disposable — their IPs change
  • So never target a pod IP directly

The problem a Service solves

  • A Deployment's pods come and go with changing IPs
  • Clients need one stable address for the group
  • A Service provides that stable endpoint + load balancing

How a Service finds pods

  • A Service selects pods by label (same idea as Deployments)
  • Any pod matching the selector is a backend
  • k8s load-balances across them and updates automatically as pods change

Service types

  • ClusterIP — internal-only stable IP (default)
  • NodePort — opens a fixed port on every node
  • LoadBalancer — external IP (cloud, or MetalLB on-prem)
  • ExternalName — maps to an external DNS name

A Service manifest

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Service DNS

  • Every Service gets a DNS name inside the cluster
  • Reach it as web (same namespace) or
    web.<namespace>.svc.cluster.local
  • Apps talk to services by name — never hardcode pod IPs

Inspecting services

  • kubectl get services
  • kubectl describe service web — see its endpoints (the pod IPs)
  • kubectl get endpoints web — the live backend list

But how do users outside get in?

  • ClusterIP is internal; NodePort is clunky; LoadBalancer needs a cloud
  • For HTTP(S), the clean answer is Ingress — next deck

Lab goals

  • Expose your Deployment with a ClusterIP service
  • Reach it from another pod by its DNS name
  • Switch it to NodePort and hit it from your laptop