Skip to main content

Services: Networking & Discovery

Key Takeaways for AI & Readers
  • Purpose: Provides a stable IP and DNS name for a dynamic set of Pods.
  • Service Types: ClusterIP (internal), NodePort (external), LoadBalancer (cloud), ExternalName (alias).
  • Matching: Uses Labels and Selectors to route traffic.

2. Service Types: Choosing Your Exposure​

3. Cheat Sheet: Understanding Ports​

The most common mistake in Kubernetes is mixing up the three types of ports.

Port TypeLocationPurpose
portThe ServiceThe port other Pods use to talk to this service internally.
targetPortThe PodThe port your application is actually listening on (e.g. 8080).
nodePortThe NodeA port (30000-32767) opened on every physical machine for external access.

Analogy: nodePort is the front gate of the park, port is the information desk inside, and targetPort is the specific seat at the cafe.

4. Under the Hood: How it Works​

When you create a Service, what actually happens? It's not a magic process listening on a port. It's a set of routing rules.

The Role of kube-proxy​

Every Node runs a daemon called kube-proxy. This component watches the API Server for changes to Services and Endpoints.

  1. Userspace Mode (Legacy): kube-proxy actually proxies traffic. Slow and rare now.
  2. iptables Mode (Standard): kube-proxy writes huge lists of iptables rules. When a packet creates traffic to the Service IP, Linux kernel logic (NAT) intercepts it and redirects it to one of the Pod IPs randomly.
  3. IPVS Mode (High Performance): Uses the Linux IPVS kernel module for load balancing. Much faster for clusters with thousands of Services.

Key Takeaway: The "Service IP" is virtual. It doesn't exist on any network interface. It's just a key in an iptables rule!

EndpointSlices (The Scalable Future)​

In older Kubernetes, a Service mapped to a single Endpoints object containing ALL pod IPs. If you had 5,000 pods, this object became massive (MBs in size), clogging the API server every time one pod changed.

EndpointSlices break this list into chunks (slices) of 100 IPs. kube-proxy now consumes these slices, making large clusters much faster.

4. Service Discovery: DNS vs Env Vars​

How does frontend find backend?

Kubernetes runs a DNS server (CoreDNS). Every Service gets a DNS entry: my-service.my-namespace.svc.cluster.local

If you are in the same namespace, you can just call http://my-service.

Option B: Environment Variables​

When a Pod starts, K8s injects env vars for all currently running services.

  • MY_SERVICE_SERVICE_HOST=10.0.0.5
  • MY_SERVICE_SERVICE_PORT=80

Pitfall: This only works if the Service was created before the Pod. Avoid using this; stick to DNS.

5. Troubleshooting Guide​

Problem: "I can't connect to my Service!"

  1. Check Endpoints: Run kubectl get endpoints my-service.

    • Result is Empty? Your selector doesn't match any Pods. Check labels!
    • Result has IPs? Good, the Service knows where to send traffic.

  2. Check Pod Health: Are the target Pods actually Running and passing their Readiness Probes? A Service won't send traffic to an unready Pod.

  3. Check Container Port: Does the targetPort in your Service YAML match the containerPort your app is listening on? (e.g., App listens on 3000, Service sends to 80).