Services and Networking
External exposure and in-cluster network isolation are central to both reachability and security on Kubernetes. This section covers Service, Ingress, NetworkPolicy and the next-generation Gateway API.
Quick Navigation
| Section | Content | When to Read |
|---|---|---|
| Service / Ingress | Service types and Ingress layer-7 routing | Expose applications and front them with a load balancer |
| NetworkPolicy | Pod- and Namespace-level ingress/egress policy | Network isolation between microservices |
| Gateway API | GatewayClass, Gateway, HTTPRoute and other next-generation APIs | Complex routing, cross-namespace and multi-protocol gateways |
Recommended Reading Order
- Expose first, tighten second — when shipping a service, start with Service / Ingress to make it reachable;
- Layer on security — use NetworkPolicy to restrict Pod-to-Pod traffic at the namespace or service level;
- Move to Gateway API last — when you outgrow Ingress (many rules, cross-namespace sharing, or advanced TCP / TLS needs), migrate to Gateway API.
Picking the right backend
- If the cluster already has the Gateway API CRDs (
gateway.networking.k8s.io), go straight to Gateway API; - If the cluster only has Ingress-NGINX or another classic Ingress, keep using Service / Ingress.
