Service: Stable Access

Pod IPs change, but a Service provides a stable entry point and routes traffic to Pods through label selectors.

Common types

ClusterIP: internal access
NodePort: expose on node ports
LoadBalancer: cloud LB integration
Headless: no load balancing

Example Service

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

Troubleshooting

Ensure selector matches Pod labels
Check kubectl get endpoints api

Practical notes

Start with a quick inventory: kubectl get nodes, kubectl get pods -A, and kubectl get events -A.
Compare desired vs. observed state; kubectl describe usually explains drift or failed controllers.
Keep names, labels, and selectors consistent so Services and controllers can find Pods.

Quick checklist

The resource matches the intent you described in YAML.
Namespaces, RBAC, and images are correct for the target environment.
Health checks and logs are in place before promotion.

Network identity and discovery

Kubernetes networking is built around stable names rather than stable IPs. Services provide a stable virtual IP and DNS name, while endpoints track the Pods behind them. This lets you roll or scale workloads without changing client configuration. Services builds on this idea and helps you control how traffic is routed and discovered.

Service types and routing choices

ClusterIP is the default and is the right choice for most internal traffic. NodePort and LoadBalancer expose services externally, while Ingress provides HTTP routing with hostnames and paths. Choosing the right type depends on your environment and traffic pattern. Document which entry points are for users, which are for internal calls, and which are only for debugging.

Headless and direct endpoints

A headless Service skips the virtual IP and publishes the Pod IPs directly. This is useful for stateful systems that need stable identities or direct peer discovery. When you use headless services, be mindful that client logic is now responsible for connection balancing and failure handling. The benefit is predictable addressing for each Pod.

Port forward for debugging

Port forwarding is a fast way to reach a Pod or Service from your laptop without changing cluster networking. It is ideal for ad hoc troubleshooting, but it is not a production access method. Keep port forwarding sessions short, and avoid relying on them for automation. If you need regular access, build a proper Service or Ingress instead.

DNS naming conventions

Kubernetes DNS supports short names and fully qualified names. Use service.namespace when you want clarity across namespaces. For stateful or headless services, plan naming conventions so operators can reason about peer addresses without guessing.

External traffic paths

External traffic often passes through a load balancer, a NodePort, and then kube proxy to reach Pods. Each hop adds potential failure points and timeouts. When debugging, trace the path end to end to identify where traffic is dropped or rewritten.

Security and policy

NetworkPolicy can block traffic even when DNS resolves. If you use mTLS or service mesh policies, ensure they align with your Service selectors. Always document which namespaces are allowed to talk to each other to avoid accidental outages during policy changes.

Operational tips

Use consistent Service naming to make DNS names predictable. Watch endpoints to confirm that rollout changes are reflected. For large clusters, EndpointSlices reduce load, but you should still monitor for stale endpoints. If you use external traffic, ensure you set health checks and timeouts at the load balancer layer.

kubectl get svc -n demo
kubectl get endpoints -n demo
kubectl get endpointslices -n demo
kubectl port-forward svc/demo-api 8080:80 -n demo

Wrap-up: Service issues are usually endpoints issues

If traffic cant reach your app, dont start with kube-proxy or DNS.

Start with:

is the Pod Ready?
does the Service selector match Pod labels?
do endpoints exist?