Services, DNS, and Ingress
Services, DNS, and Ingress
Service types: ClusterIP (internal), NodePort (exposes 30000–32767 on every node), LoadBalancer (cloud LB), ExternalName (CNAME). A Service selects pods by label into EndpointSlices — mismatched labels mean kubectl get endpoints svc shows <none>, the single most common service failure.
DNS names follow <service>.<namespace>.svc.cluster.local; cross-namespace calls must include the namespace. Ingress needs a controller (ingress-nginx) and usually ingressClassName — a manifest alone routes nothing.
Connectivity triage order: endpoints populated? → DNS from a debug pod (kubectl run tmp --rm -it --image=busybox -- nslookup svc.ns) → NetworkPolicy → kube-proxy programming (kubectl get ds -n kube-system kube-proxy, iptables rules).
Persistent Storage
Persistent Storage
Binding chain: PVC requests storage → matches a PV (static) or triggers a StorageClass provisioner (dynamic) → Pod mounts the claim.
volumes:
- name: data
persistentVolumeClaim: { claimName: app-data }
containers:
- name: app
volumeMounts: [{ name: data, mountPath: /var/lib/app }]
PVC essentials: access modes ReadWriteOnce (single node), ReadWriteMany (NFS/CSI supporting it), ReadOnlyMany; storageClassName: fast selects the class (kubectl get sc — note the default marked (default)); expansion requires allowVolumeExpansion: true on the class, then edit the PVC size. volumeBindingMode: WaitForFirstConsumer delays binding until scheduling so zonal constraints resolve correctly.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
PVC stuck Pending: no StorageClass matching the request, no free PV for static binding, zone mismatch (immediate binding chose the wrong zone), or the access mode nobody can satisfy. kubectl describe pvc states the reason.
PVC Terminating/Released: reclaimPolicy: Retain leaves PVs Released after claim deletion — data preserved, but manual reclaim (inspect, delete PV, rebind) is required.
RWO conflicts: a volume attached to node A cannot mount on node B — StatefulSet rescheduling to another node waits on detach.
Ingress 404 everywhere: missing/wrong ingressClassName or no controller running — check kubectl get ingressclass.
Interview angle: diagnose "connection refused from pod A to service B" stepwise (endpoints → selector/targetPort → DNS → policy), and walk PVC Pending from claim to class to provisioner.
Quiz
1. kubectl get endpoints shows <none> for a Service. Most likely cause?
2. What does volumeBindingMode: WaitForFirstConsumer do?
3. A PVC remains Pending after creating a StorageClass. What should you check first?
Flashcards
Question
Service endpoint check
Click to reveal answer
Answer
kubectl get endpoints/<svc>: empty means selector/pod mismatch or pods not ready — fix before touching DNS.
Question
DNS name shape
Click to reveal answer
Answer
<svc>.<ns>.svc.cluster.local — cross-namespace calls must qualify the namespace.
Question
PV/PVC/StorageClass chain
Click to reveal answer
Answer
PVC claims, StorageClass provisioner creates PV (dynamic), pod mounts PVC; class default marked in kubectl get sc.
Question
Access modes
Click to reveal answer
Answer
RWO single node, RWX multi-node (needs capable backend), ROX read-only multi-node.
Revision Notes
Key Takeaways
- 1. Service failures start with endpoints, then DNS, then policy — in that order
- 2. Storage flows PVC → class/provisioner → PV → mount; Pending always has a stated reason
- 3. Ingress needs a controller and class; a YAML file alone routes nothing
Interview Tips
- • Diagnose a service connectivity report as a fixed checklist, naming commands per step
- • Explain PVC Pending causes from memory and how WaitForFirstConsumer changes binding
Cheat Sheet
Service no-traffic: endpoints → DNS (nslookup) → NetworkPolicy → kube-proxy. DNS: