TCP (Transmission Control Protocol) is connection-oriented and reliable. Before sending data, it establishes a connection via 3-way handshake. Every packet is acknowledged. If a packet is lost, TCP retransmits it. Packets arrive in order. Slower due to this overhead. Use TCP for: HTTP/HTTPS (web), SSH (terminal), database connections, any application where data correctness matters more than speed. UDP (User Datagram Protocol) is connectionless and fast. No handshake, no acknowledgment, no ordering guarantee. Packets can arrive out of order or be lost — the application handles this. Much lower latency. Use UDP for: DNS queries (fast single request-response, loss just means retry), video streaming (slightly corrupted frame better than paused video), VoIP (voice calls — slight audio glitch acceptable, delay is not), online gaming (old position data is useless, better to drop than wait for retransmit). In Kubernetes: most service traffic uses TCP. DNS queries use UDP port 53. QUIC (HTTP/3) uses UDP but builds its own reliability layer on top for better performance than TCP.

Layered investigation. Step 1: verify the service exists and has endpoints. kubectl get service my-service -n production, then kubectl get endpoints my-service -n production. If endpoints is empty, no pods match the service selector. Check that pod labels match service selector exactly. Step 2: test DNS resolution. kubectl exec -it debug-pod -- nslookup my-service.production.svc.cluster.local. If DNS fails, CoreDNS might be down: kubectl get pods -n kube-system shows coredns pods. Step 3: test connectivity directly to pod IP. kubectl exec -it debug-pod -- curl http://pod-ip:8080/health. Bypass the service to isolate if issue is service routing or pod itself. Step 4: check NetworkPolicy. If a NetworkPolicy exists in that namespace, it might be blocking traffic. kubectl get networkpolicy -n production and describe each one. NetworkPolicy is default-deny when any policy exists — you must explicitly allow traffic. Step 5: check if the target pod is actually listening. kubectl exec -it target-pod -- ss -tlnp should show your port. Step 6: run a debug container with network tools in the same namespace: kubectl run netshoot --image=nicolaka/netshoot --rm -it -- bash then curl from inside.

All three are server-side errors but mean different things, important for diagnosing production issues. 502 Bad Gateway: the load balancer or reverse proxy received an invalid response from the upstream server. The upstream is responding but with garbage. Causes: application crashed mid-response, application returning malformed HTTP, upstream service sending errors. 503 Service Unavailable: the server cannot handle the request right now. Usually: server overloaded (too many requests, CPU at 100%), application in maintenance mode, health check failing so load balancer removed all backends. In Kubernetes: all pods in the service are in Pending or CrashLoopBackOff state so no backends available. 504 Gateway Timeout: the load balancer sent the request to the upstream but the upstream did not respond within the timeout period. The upstream is alive but too slow. Causes: slow database query, external API call timing out, application blocked on a resource, or simply the operation takes longer than the configured timeout. Debugging: 502 = check upstream application logs. 503 = check pod/server health, check load balancer backends. 504 = check for slow operations, increase timeout, check database/external dependency performance.