Kubernetes Networking

Kubernetes defines a network model that helps provide simplicity and consistency across a range of networking environments and network implementations. The Kubernetes network model provides the foundation for understanding how containers, pods, and services within Kubernetes communicate with each other. This guide explains the key concepts and how they fit together.

Editor’s note: Updated the article to reflect Kubernetes networking features in 2026, added troubleshooting for common issues and best practices.

This is part of an extensive series of guides about Kubernetes.

In this guide, you will learn:

The fundamental network behaviors the Kubernetes network model defines
How Kubernetes works with a variety of different network implementations
What Kubernetes services are
Kubernetes network policies
How DNS works within Kubernetes
What “NAT outgoing” is and when you would want to use it
What “dual stack” is
Common Kubernetes networking issues and how to resolve them
Kubernetes networking best practices

The Kubernetes network model

The Kubernetes network model specifies:

Every pod gets its own IP address
Containers within a pod share the pod IP address and can communicate freely with each other
Pods can communicate with all other pods in the cluster using pod IP addresses (without NAT)
Isolation (restricting what each pod can communicate with) is defined using network policies

As a result, pods can be treated much like VMs or hosts (they all have unique IP addresses), and the containers within pods can be treated like processes running within a VM or host (they run in the same network namespace and share an IP address). This model makes it easier for applications to be migrated from VMs and hosts to pods managed by Kubernetes. In addition, because isolation is defined using network policies rather than the structure of the network, the network remains simple to understand. This style of network is sometimes referred to as a “flat network.”

Because isolation is enforced at the policy layer rather than the network topology, Kubernetes network security is typically implemented by defining and enforcing network policies between pods.

Note that, although very rarely needed, Kubernetes does also support the ability to map host ports through to pods, or to run pods directly within the host network namespace sharing the host’s IP address.

Kubernetes network implementations

Kubernetes’s built-in network support, kubenet, can provide some basic network connectivity. However, it is more common to use third-party network implementations that plug into Kubernetes using the CNI (Container Network Interface) API.

There are lots of different kinds of CNI plugins, but the two main ones are:

Network plugins, which are responsible for connecting pods to the network
IPAM (IP Address Management) plugins, which are responsible for allocating pod IP addresses

Calico provides both network and IPAM plugins, but can also integrate and work seamlessly with some other CNI plugins, including AWS, Azure, and Google network CNI plugins, in addition to the host local IPAM plugin. This flexibility allows you to choose the best networking options for your specific needs and deployment environment.

These same networking choices extend when you connect workloads across several clusters; see our guide to Kubernetes multi-cluster networking.

For background on how pod-level connectivity is built up from lower layers, see our primer on container networking.

Learn more in our guide to determining the best networking option

Kubernetes services

Kubernetes services provide a way of abstracting access to a group of pods as a network service. The group of pods is usually defined using a label selector. Within the cluster, the network service is usually represented as a virtual IP address, and kube-proxy load balances connections to the virtual IP across the group of pods backing the service.

The virtual IP is discoverable through Kubernetes DNS. The DNS name and virtual IP address remain constant for the lifetime of the service, even though the pods backing the service may be created or destroyed, and the number of pods backing the service may change over time.

This stable service abstraction over ephemeral pods is what underpins container as a service platforms built on Kubernetes.

Kubernetes services can also define how a service is accessed from outside of the cluster, using one of the following:

A node port, where the service can be accessed via a specific port on every node
A load balancer, where a network load balancer provides a virtual IP address that the service can be accessed via from outside the cluster
In addition to node ports and load balancers, Kubernetes Ingress provides HTTP and HTTPS routing rules that expose services to clients outside the cluster.

Note that when using Calico in on-premises deployments, you can also advertise service IP addresses, allowing services to be conveniently accessed without going via a node port or load balancer.

Kubernetes network policies

Kubernetes network policies define how pods are allowed to communicate with each other and with other network endpoints. They are configured using the Kubernetes Network Policies API and act as rules that control traffic flow at the pod level.

A policy targets a set of pods using a pod selector, which matches pods based on labels. It then defines rules for ingress (incoming traffic) and egress (outgoing traffic). These rules specify which sources or destinations are allowed, effectively controlling communication paths.

Network policies are primarily used to enforce isolation. By default, pods can often communicate freely, but policies restrict this behavior so that only approved connections are allowed. This reduces the risk of unauthorized access and limits the impact of compromised workloads.

They are especially important in multi-tenant clusters, where different teams or applications share the same infrastructure. Policies ensure that workloads only interact with explicitly permitted peers. They also help organizations meet compliance requirements by enforcing clear network access controls.

Kubernetes DNS

Each Kubernetes cluster provides a DNS service. Every pod and every service is discoverable through the Kubernetes DNS service.

For example:

Service: my-svc.my-namespace.svc.cluster-domain.example
Pod: pod-ip-address.my-namespace.pod.cluster-domain.example
Pod created by a deployment exposed as a service:pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example

The DNS service is implemented as a Kubernetes service that maps to one or more DNS server pods (usually CoreDNS), which are scheduled just like any other pod. Pods in the cluster are configured to use the DNS service, with a DNS search list that includes the pod’s own namespace and the cluster’s default domain.

This means that if there is a service named foo in Kubernetes namespace bar, then pods in the same namespace can access the service as foo, and pods in other namespaces can access the service as foo.bar.

Kubernetes supports a rich set of options for controlling DNS in different scenarios. You can read more about these in the Kubernetes guide DNS for services and pods.

When name resolution or connectivity between pods and services misbehaves, our guide to Kubernetes debugging walks through how to isolate the problem.

Per-pod DNS behavior is governed by the Kubernetes DNS policy, which determines how a pod’s DNS resolver is configured.

NAT outgoing

The Kubernetes network model specifies that pods must be able to communicate with each other directly using pod IP addresses. But it does not mandate that pod IP addresses are routable beyond the boundaries of the cluster. Many Kubernetes network implementations use overlay networks. Typically for these deployments, when a pod initiates a connection to an IP address outside of the cluster, the node hosting the pod will use SNAT (Source Network Address Translation) to map the source address of the packet from the pod IP to the node IP. This enables the connection to be routed across the rest of the network to the destination (because the node IP is routable). Return packets on the connection are automatically mapped back by the node, replacing the node IP with the pod IP before forwarding the packet to the pod.

For a deeper look at how outbound pod traffic is handled, see our overview of Kubernetes egress.

When using Calico, depending on your environment, you can generally choose whether you prefer to run an overlay network or have fully routable pod IPs. You can read more about this in the Calico determine best networking option guide. Calico also allows you to configure outgoing NAT for specific IP address ranges if more granularity is desired.

For deployments that need a stable, identifiable source address for outbound traffic, an egress gateway can route pod egress through dedicated gateway pods.

Dual stack

If you want to use a mix of IPv4 and IPv6, you can enable Kubernetes dual-stack mode. When enabled, all pods will be assigned both an IPv4 and IPv6 address, and Kubernetes services can specify whether they should be exposed as IPv4 or IPv6 addresses.

Common Kubernetes networking issues and how to resolve them

DNS resolution failures

DNS resolution issues in Kubernetes often result from misconfigured CoreDNS deployments or incorrect service definitions. If pods are unable to resolve service names, check the status of CoreDNS pods and ensure they are running and not restarting due to errors.

Misconfigured resolv.conf files inside pods, especially when using custom DNS settings or host networking, can also lead to failures. Additionally, verify that the DNS service IP is correctly set in the kubelet and kube-dns configuration.

When troubleshooting, use tools like nslookup or dig from within a pod to test DNS lookups. Also check for NetworkPolicies that might be blocking traffic to the DNS service.

Pod connectivity problems

Pod-to-pod connectivity issues typically stem from one of three sources: incorrect CNI plugin configuration, network segmentation, or restrictive NetworkPolicies.

Begin by confirming that the CNI plugin is properly installed and functioning. Check the logs of the CNI plugin and kubelet for errors related to networking. Next, ensure that nodes can route traffic to each other and that overlay networks (if used) are functioning.

NetworkPolicies should also be reviewed. Even a single overly restrictive policy can prevent pods from communicating, especially in namespaces where policies are enforced by default. Tools like kubectl describe and network policy visualizers can help audit policy effects.

Service not reachable

When a service is unreachable, the first step is to verify that the backing pods are healthy and that the label selector used by the service matches the intended pods. If no endpoints are available, the service cannot route traffic.

Next, confirm that kube-proxy is running correctly on all nodes and that it is setting up the appropriate iptables or IPVS rules. Problems here can prevent traffic from reaching service endpoints.

For externally accessible services, also check that the service type (NodePort, LoadBalancer, etc.) is correctly configured and that any required cloud-provider integration is working. Use kubectl get endpoints, kubectl get svc, and kubectl logs on kube-proxy to gather diagnostics.

Kubernetes networking best practices

Choose the right CNI plugin

Select a CNI plugin that aligns with your networking and operational requirements. For simple setups, basic plugins like Flannel may suffice. For advanced features like network policy enforcement, BGP routing, or dual-stack support, consider Calico.

Evaluate whether your environment benefits from overlay networks or whether you need direct routing with BGP or VXLAN. Factor in support for IP address management, scalability limits, and integration with your infrastructure (e.g., cloud vs. on-prem).

Use NetworkPolicies for security

Enforcing network security with Kubernetes NetworkPolicies limits the blast radius of compromised pods and controls which services can talk to each other.

Start with a default deny-all policy and explicitly allow required traffic. Define ingress and egress rules based on labels to limit communication to approved sources and destinations.

Apply policies per namespace for fine-grained control and audit them regularly to ensure they reflect current application architecture.

Monitor and observe network traffic

Observability is key to maintaining healthy networking in Kubernetes. Use tools like Calico’s felix, Cilium’s Hubble, or Istio’s telemetry stack to inspect flows and detect anomalies.

Export metrics and logs to centralized observability platforms like Prometheus, Grafana, or ELK for long-term trend analysis and alerting. Packet captures with tcpdump or tools like netshoot can help in debugging transient or low-level issues.

Understanding flow data and tracking dropped or delayed packets can uncover hidden misconfigurations or bottlenecks.

Optimize for scalability and performance

As clusters scale, networking can become a bottleneck. Choose CNI plugins known for performance and tune settings like MTU size to match your infrastructure. Prefer direct routing when possible to reduce latency and overhead.

Avoid relying on kube-proxy in iptables mode at scale; consider switching to IPVS mode for better performance. For DNS, increase the number of CoreDNS replicas and configure caching to reduce load.

Regularly benchmark network throughput and latency between pods to detect regressions as the cluster grows.

Next steps:

See Additional Guides on Key Kubernetes Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Kubernetes.