Kubernetes Networking Vocabulary: CNI, Services, Ingress, and Policies

Kubernetes networking is notoriously complex — and the English vocabulary that describes it can be just as intimidating. Engineers who cannot precisely name what they mean (ClusterIP vs headless service, ingress rule vs egress rule, iptables mode vs eBPF) slow down every architecture discussion they participate in. This guide gives you the vocabulary to contribute confidently.

The CNI Layer

CNI (Container Network Interface) is the standard interface that Kubernetes uses to configure pod networking. A CNI plugin is the implementation — Calico, Cilium, Flannel, and Weave Net are the most common. The CNI plugin is responsible for assigning IP addresses to pods and setting up the network routes that allow pods to communicate.

Pod networking in Kubernetes follows a flat network model: every pod gets its own IP address, and pods can communicate with each other directly across nodes — without NAT. This is called the pod CIDR (the IP address range reserved for pods). The cluster also has a service CIDR — the IP range used for virtual service IPs.

Engineers discuss CNI plugins when troubleshooting connectivity issues: “The new nodes aren’t joining the network properly — check whether the CNI plugin daemonset is running on those nodes.”

Service Types

A Kubernetes Service is a stable network endpoint that load-balances traffic to a set of pods. There are four main service types:

• ClusterIP — the default; the service is accessible only within the cluster, on a virtual IP. “The database service is ClusterIP — it’s not exposed outside the cluster.”
• NodePort — exposes the service on a static port on every node’s IP. Useful for development but rarely used in production.
• LoadBalancer — provisions an external load balancer (typically a cloud provider load balancer) and assigns a public IP to the service.
• ExternalName — maps the service to an external DNS name, allowing pods to use the Kubernetes service DNS name to reach external services.

A headless service is a ClusterIP service with clusterIP: None. It does not create a virtual IP; instead, DNS returns the individual pod IPs directly. This is used for stateful workloads (like databases) where clients need to connect to specific instances.

Ingress and Traffic Management

An Ingress is a Kubernetes resource that defines HTTP routing rules — mapping domain names and URL paths to backend services. An Ingress controller is the software that implements those rules — NGINX Ingress Controller, Traefik, and the AWS Load Balancer Controller are popular choices. An IngressClass specifies which Ingress controller should handle a given Ingress resource (useful when multiple controllers are installed).

Engineers say: “The new Ingress rule isn’t routing correctly — check whether the IngressClass annotation matches the deployed controller.”

Network Policies and DNS

NetworkPolicy is a Kubernetes resource that controls which pods can communicate with which other pods and endpoints. It defines ingress rules (who can send traffic to the pod) and egress rules (where the pod is allowed to send traffic). Without NetworkPolicies, all pods in a cluster can communicate with all other pods — a significant security risk.

“We’re enforcing a zero-trust network model — every namespace has a default-deny NetworkPolicy, and services must explicitly allow the traffic they need.”

CoreDNS is the DNS server that runs in Kubernetes. It resolves service names to their cluster IP addresses. The Kubernetes DNS convention is <service-name>.<namespace>.svc.cluster.local. Cross-namespace communication requires using the full DNS name: “The frontend service in the web namespace cannot reach the auth service in the platform namespace using a short hostname — use the fully qualified name.”

kube-proxy is the component that implements service load balancing on each node. It runs in either iptables mode (the traditional approach, using kernel firewall rules) or eBPF mode (using Cilium’s eBPF-based data plane, which is faster and more observable). Teams migrating to Cilium discuss: “Switching from iptables to eBPF mode cut our connection setup latency by 40%.”

Service Mesh

A service mesh adds a layer of infrastructure for service-to-service communication — handling mTLS, traffic shaping, retries, and observability. A sidecar injection is the mechanism by which the service mesh automatically adds a proxy container (the sidecar) to every pod. In Istio, this is the Envoy proxy; the injection is typically controlled by a namespace label.

“Enable sidecar injection on the payments namespace before deploying the new service — it needs to be part of the mesh for mTLS to work.”

Next Steps

Pick one networking concept from this article that you find least intuitive and deploy a small test in a local cluster (minikube or kind). Create two pods in different namespaces, write a NetworkPolicy, and verify the connectivity change using kubectl exec and curl. Then describe what you built in English — using the vocabulary from this article — to a colleague or in a written note.