Kubernetes networking feels complex because several abstractions participate in one request. A client reaches an entry point, traffic is routed to a Service, the Service selects ready Pods, and the network plugin carries packets to changing Pod addresses.

The reliable way to understand this system is layer by layer. This guide connects the Pod network, cluster DNS, Services, EndpointSlices, NetworkPolicy and north-south routing. It also explains why new platforms should evaluate Gateway API while still understanding Ingress.

What you will learn

  • Pods receive cluster-network addresses, but applications should discover backends through Services and DNS.
  • A Service selector must match Pod labels, and ready backends appear in EndpointSlices.
  • NetworkPolicy is allow-list policy whose enforcement depends on a compatible network plugin.
  • Ingress remains stable but frozen; Kubernetes recommends Gateway API for new routing capabilities.

The Kubernetes network model

Each Pod receives an IP from the cluster network implementation. Pod IPs are ephemeral, so replacing a Pod can replace its address. Hard-coding Pod IPs therefore creates fragile applications.

A CNI plugin implements connectivity and may add policy enforcement, encryption or advanced routing. Validate address capacity, dual-stack requirements, maximum Pod density and policy support before choosing a production implementation.

Services, selectors and EndpointSlices

A Service provides a stable virtual endpoint for a changing set of backends. Most Services select Pods using labels. Kubernetes records matching backends in EndpointSlices and updates them as Pods become ready, terminate or are replaced.

Use ClusterIP for internal access, NodePort only when its trade-offs are understood, and LoadBalancer when a provider-integrated external endpoint is required. Expose the narrowest surface that satisfies the requirement.

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app.kubernetes.io/name: api
  ports:
    - name: http
      port: 80
      targetPort: 8080

DNS-based service discovery

Cluster DNS creates records for Services. A workload in the same namespace can usually reach api, while cross-namespace clients can use api.production or the full cluster domain.

When DNS fails, test resolution inside the affected Pod, then inspect the Service, EndpointSlices and DNS Pods. A DNS answer does not prove that selectors, target ports, readiness or the application listener are correct.

Default-deny NetworkPolicy

Namespaces do not automatically isolate network traffic. Start sensitive namespaces with default-deny ingress and egress, then allow only documented flows such as ingress to frontend, frontend to API, API to database and workloads to DNS.

NetworkPolicies are additive. Applicable source egress and destination ingress rules must both permit a connection. Test in staging and confirm that the installed CNI actually enforces NetworkPolicy.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Ingress and Gateway API

Ingress maps HTTP and HTTPS requests to Services and requires an ingress controller. The resource alone does not move traffic. Controller-specific annotations, TLS behavior and supported features must be documented.

The official documentation states that Ingress is stable but frozen and recommends Gateway. Gateway API separates infrastructure ownership from application routes using resources such as GatewayClass, Gateway and HTTPRoute.

A repeatable troubleshooting path

Follow the request from client to backend: resolve DNS, inspect the external address, check Gateway or Ingress status, verify the Service port, list EndpointSlices, test a Pod IP and confirm the process listens on targetPort.

Labels and ports cause many failures. A Service can exist with zero endpoints when selectors do not match. Pods can exist but remain absent from normal traffic when readiness fails.

Production checklist

  • Plan non-overlapping Pod, Service, node and connected-network ranges.
  • Use Services and DNS instead of storing Pod IPs.
  • Verify selectors and EndpointSlices during incidents.
  • Adopt default-deny policies and explicitly allow DNS plus required flows.
  • Document TLS lifecycle and controller-specific routing behavior.
  • Evaluate Gateway API for new platform designs.

Frequently asked questions

What is the difference between Service and Ingress?

A Service exposes a stable endpoint for backends. Ingress adds HTTP and HTTPS routing from outside the cluster to Services and needs a controller.

Does every NetworkPolicy plugin behave the same?

The API is standardized, but implementation support and advanced capabilities vary. Verify the selected CNI.

Should every Ingress be replaced now?

No. Ingress remains stable. Evaluate Gateway API for new designs and migrate when the operational value justifies it.

Continue learning Kubernetes

Official Kubernetes references