Services and Networking
Service wiring, DNS, NetworkPolicy, and Ingress.
Services and endpoints
A Service routes to Pods matching its selector on targetPort. port is what the Service exposes, targetPort is the container port, nodePort (30000–32767) is only for NodePort/LoadBalancer. Trap: a selector typo produces a Service with zero endpoints - clients hang or get connection refused while every Pod looks healthy. Verify with kubectl get endpointslice or kubectl describe svc. ExternalName returns a CNAME and creates no proxy. clusterIP: None is headless, giving per-Pod DNS for StatefulSets.
DNS
From inside the cluster the forms are <svc>, <svc>.<namespace>, and <svc>.<namespace>.svc.cluster.local. Trap: a short name only resolves within the same namespace; cross-namespace calls need at least <svc>.<namespace>.
NetworkPolicy
Policies are additive allow-lists - there is no deny rule. Omitting policyTypes means it applies to Ingress only (or Egress if egress rules are present). podSelector: {} selects everything, so an empty policy with Ingress gives default-deny. The classic trap is combining selectors: separate from items are OR'd, while namespaceSelector and podSelector in the same item are AND'd. Once a Pod is selected for egress, do not forget a DNS rule (UDP/TCP 53) or name resolution breaks. The CNI must actually implement policies.
Ingress
Ingress needs ingressClassName (or an annotation) and a running controller. pathType is Prefix, Exact, or ImplementationSpecific; TLS references a Secret of type tls.
Worked example: test reachability with kubectl run tmp --rm -it --restart=Never --image=busybox -- wget -qO- http://web.dev.svc.cluster.local:8080.
Rule of thumb: when a Service fails, check endpoints first, then port names, then policy.