Memory hook: Pod IPs change; Services give a stable destination; DNS gives a name; policy controls the path.
Must remember
- Each Pod has a network identity. Containers inside one Pod share its network namespace and port space, so they can communicate through
localhostbut cannot both bind the same address and port. - A network implementation provides Pod connectivity, commonly through CNI plugins. CoreDNS commonly provides cluster DNS. The mechanism routing Service traffic may be kube-proxy or another implementation.
- A Service describes a stable way to reach a changing set of backends. Label selectors usually identify its Pods, and EndpointSlices record backend addresses and readiness information. A Service does not create those application Pods.
| Service type | Recognition cue |
|---|---|
| ClusterIP | Stable address inside the cluster; the default type |
| NodePort | A port exposed on nodes, subject to network reachability and firewalls |
| LoadBalancer | An external load balancer supplied by an available integration |
| ExternalName | DNS alias to another name; no ordinary Pod proxying |
- A headless Service uses
clusterIP: Noneand allows discovery of endpoint addresses rather than providing the normal virtual ClusterIP. It is useful when clients need individual backend identities. service.namespace.svc.<cluster-domain>is the normal fully qualified Service name pattern. The cluster domain is oftencluster.local, but it is configurable.portis the Service-facing port;targetPortis the backend application port.- Ingress expresses HTTP/HTTPS routing such as host and path rules. It requires a controller. Gateway API provides more expressive, role-oriented networking APIs and also needs an implementation. Neither an API manifest nor a Service type guarantees external infrastructure exists.
- A NetworkPolicy selects Pods and permits particular ingress or egress traffic. Enforcement requires a supporting network plugin. Policies are additive allow rules: when both ends are isolated, the source egress and destination ingress rules must permit the connection.
- Without applicable isolation policies, standard Kubernetes network policy behaviour is permissive. Namespace separation alone does not block packets. A default-deny policy often needs explicit allowances for DNS and application dependencies.
- A service mesh adds application traffic features such as identity-based mutual TLS, traffic management and telemetry. It can use proxies such as Envoy. It complements basic networking; it does not make RBAC or application authorisation unnecessary.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reach a backend despite replacement Pod IPs | Service and cluster DNS |
Route shop.example and /api to different applications |
Ingress or an appropriate Gateway API implementation |
| Block arbitrary Pod-to-Pod access | NetworkPolicy plus an enforcing plugin |
| Discover each stateful backend directly | A headless Service and suitable DNS discovery |
| Encrypt and authenticate service-to-service connections | Mutual TLS, often provided through a service mesh |
Traps
- A ClusterIP Service is not automatically reachable from the public internet.
- A Service with the wrong selector can exist while having no usable application endpoints.
- NetworkPolicy controls connectivity; it does not by itself encrypt packets or decide Kubernetes API permissions.
- A NetworkPolicy object has no useful enforcement effect if the installed network implementation does not support it.
Active recall
1. A web Pod is replaced and gets a new IP. What should clients use instead of remembering that Pod IP?
A Service name or its appropriate stable address. The Service's endpoint information can follow the replacement Pods, while clients keep the same destination.
2. An Ingress resource exists, but nothing accepts external requests. What prerequisite might be missing?
An Ingress controller and its required network exposure. The resource describes routing intent; an implementation must realise it.
3. A default-deny egress rule makes database access by hostname fail. What dependency should you check before changing the database?
DNS access. The workload may need an explicit allowance to the cluster DNS service as well as permission to reach the database itself. Inspect the actual permitted path.
4. Both client and server Pods are isolated by NetworkPolicies. Is server ingress permission alone sufficient?
No. The connection must also be allowed by the client Pod's egress policies. Allow rules from applicable policies combine, but both directions of isolation must permit the path.
5. Does choosing ExternalName create a proxy to selected Pods?
No. ExternalName returns a DNS alias to the configured external name. It does not use the usual selector-backed Service proxying model.