Gotcha: Kubernetes service DNS resolution timing

Pod fails to resolve other service DNS names during startup because services aren't ready yet.

K8s DNS resolution timing issues:

# Problem: Pod A starts before Service B is ready
# Pod A tries to connect to 'service-b' -> DNS resolution fails

# Solution 1: Init container that waits for dependency
apiVersion: v1
kind: Pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c',
        'until nslookup postgres-service; do echo waiting for DB; sleep 2; done']
  containers:
    - name: app
      image: myapp

# Solution 2: Application-level retry
# Don't fail immediately on DNS failure at startup
# Retry with exponential backoff

# Solution 3: Use fully qualified DNS names
# Instead of: postgres
# Use: postgres.default.svc.cluster.local
# More reliable and explicit

# Solution 4: readinessProbe on the dependency
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  template:
    spec:
      containers:
        - name: postgres
          readinessProbe:
            tcpSocket:
              port: 5432
            initialDelaySeconds: 5
            periodSeconds: 10

DNS debugging in K8s:

# Test DNS from inside a pod
kubectl run dns-test --rm -it --image=busybox -- sh
  nslookup kubernetes
  nslookup my-service
  nslookup my-service.my-namespace.svc.cluster.local
  cat /etc/resolv.conf

# Check CoreDNS status
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

Kubernetes services are eventually consistent. DNS records appear after the service and its endpoints are created. Pods that start faster than their dependencies need retry logic.

Kubernetes application startup ordering