Kubernetes Networking: DNS, Services, Ingress — Sysadmin Guide

Pods that don’t communicate. Services with zero endpoints. DNS that fails to resolve. Kubernetes networking can feel like black magic. It’s not: there’s a precise, robust logic underpinning it. Understanding this logic solves 90% of K8s network incidents, transforming hours of frustrating debugging into minutes of targeted analysis. Every Sysadmin managing a Kubernetes cluster, large or small, knows how fundamental it is to master networking concepts. A misunderstanding here can lead to significant downtime. In this practical guide, we’ll explore the key components of Kubernetes networking, from basic mechanisms like the overlay network and CoreDNS, to advanced tools like Ingress and NetworkPolicy, providing commands and best practices for effective debugging.

Prerequisites / Test Environment

To follow this guide, access to a working Kubernetes cluster (Minikube, Kind, or a cloud cluster like EKS/AKS/GKE) is recommended. Basic knowledge of Linux, Docker, and kubectl is assumed. All commands have been tested on a Kubernetes version 1.28 cluster with Calico as the CNI.

How Kubernetes Networking Works (Overlay, CNI, kube-proxy)

Kubernetes networking is a complex but well-orchestrated system, designed to provide every Pod with its own IP address and ensure all Pods can communicate with each other, regardless of the node they reside on. This is possible thanks to three main components:

• Overlay Network: Despite Pods being distributed across different physical or virtual nodes, Kubernetes creates a logical “overlay” network that interconnects them. This network operates above the underlying physical network, encapsulating traffic between Pods. CNI (Container Network Interface) solutions like Calico, Flannel, or Cilium implement this network, managing IP assignment to Pods and traffic routing.
• CNI (Container Network Interface): The CNI is a framework that allows Kubernetes to interact with various network plugins. Each CNI plugin is responsible for configuring the network interface within the Pod and ensuring inter-Pod and inter-node connectivity. For example, Calico implements a distributed firewall and advanced network policies, while Flannel is simpler and focuses on basic connectivity.
• kube-proxy: This component is a network proxy that runs on every node in the cluster. Its primary function is to implement the Kubernetes Service concept. kube-proxy observes the control plane for changes in Services and Endpoints and updates iptables (or ipvs) rules on the node to route traffic destined for a Service to the Pods that back it. It is the true “router” for Services within the cluster.

ClusterIP, NodePort, LoadBalancer: When to Use What

Services in Kubernetes are a fundamental abstraction that defines a logical set of Pods and a policy for accessing them. There are several types of Services, each with a specific purpose:

• ClusterIP: This is the default Service type. It assigns an internal IP address to the cluster, accessible only by Pods within the same cluster. It’s ideal for internal communication between microservices. The ClusterIP remains stable for the life of the Service.
• NodePort: Exposes the Service on a specific port (the NodePort) on every node in the cluster. This means you can access the Service from outside the cluster using the IP of any node and the NodePort. It’s useful for exposing services for testing or in environments where an external LoadBalancer is not available. It’s often used in conjunction with an external LoadBalancer that forwards traffic to the NodePort.
• LoadBalancer: This Service type, typically available in clusters hosted on cloud providers (AWS, GCP, Azure), creates an external LoadBalancer that routes traffic to the Service. The LoadBalancer’s IP is external and accessible from the internet. It is the standard choice for exposing web applications or APIs to the public.

CoreDNS: How Kubernetes Resolves Internal Names

CoreDNS is the default DNS server for Kubernetes. Every Pod in the cluster is configured to use CoreDNS for name resolution. CoreDNS can resolve Service and Pod names within the cluster, following a specific format:

• Service: my-service.my-namespace.svc.cluster.local (or simply my-service if in the same namespace).
• Pod: my-pod-ip.my-namespace.pod.cluster.local (though less common for direct communication).

When a Pod tries to communicate with another Service, it sends a DNS request to CoreDNS, which resolves the name to a Service IP address (ClusterIP). Without proper CoreDNS configuration, internal communication between your microservices would be impossible. If a Pod cannot resolve a name, the first thing to check is CoreDNS functionality. For more details on CoreDNS configuration, refer to the official Kubernetes documentation: https://kubernetes.io/docs/tasks/administer-cluster/coredns/

To debug DNS resolution from within a Pod, you can use a temporary debug Pod:

kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

Ingress: Exposing Applications with a Single IP

Ingress is an API object that manages external access to services within a cluster, typically HTTP/S traffic. Unlike a LoadBalancer Service that exposes a single Service, an Ingress Controller (like NGINX Ingress Controller or Traefik) can expose multiple Services under a single external IP, using rules based on hostname (e.g., app1.example.com and app2.example.com) or path (e.g., example.com/api and example.com/admin).

The Ingress Controller acts as a reverse proxy, forwarding incoming requests to the appropriate Kubernetes Services. This centralizes external access management, allowing you to easily configure routing, SSL termination, and load balancing for all your web applications.

NetworkPolicy: Isolation Between Namespaces and Pods

NetworkPolicies are a Pod-level security mechanism that allows you to control network traffic flow. They function as a distributed firewall, defining which Pods can communicate with each other and with external endpoints. By default, all Pods can communicate with all other Pods and with the outside world. NetworkPolicies allow you to implement the principle of least privilege, isolating critical applications.

For example, you can create a NetworkPolicy to allow traffic only from a certain namespace or from Pods with a specific label. If no NetworkPolicy is defined, communication is unrestricted. A common practice is to implement a “default-deny” policy for a namespace, blocking all inbound and outbound traffic, and then add specific policies to allow only necessary traffic. This significantly enhances the cluster’s security posture, reducing the attack surface.

Here’s an example of a NetworkPolicy that blocks all ingress and egress traffic for all Pods in a namespace:

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

Debugging Networking: kubectl exec + nslookup + tcpdump in Pod

Debugging networking issues in Kubernetes requires a systematic approach. Here are some essential tools and techniques:

1. Verify Service and Endpoint Status: A Service without Endpoints means there are no running Pods backing it or that the Pods are not Ready. Check Pod logs and Service events.

kubectl get service <service-name>
kubectl get endpoints <service-name>

1. Debug DNS from within a Pod: If an application cannot communicate with another Service, the problem is often DNS resolution. Use a temporary debug Pod to test nslookup or dig.

kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

1. Check NetworkPolicies: If communication is blocked, ensure there are no NetworkPolicies preventing the desired traffic. kubectl describe networkpolicy can provide details on applied policies.

1. Trace Traffic in the Pod: For deeper analysis, you can use tcpdump inside a Pod to see which packets are actually arriving or leaving. This requires the Pod image to include tcpdump or for you to be able to install it temporarily.

kubectl exec <pod> -- tcpdump -i eth0 port 80

1. Check kube-proxy and CNI Logs: Logs from kube-proxy and your CNI plugin (e.g., Calico, Flannel) can reveal configuration issues or routing errors at the node level. These logs are usually found on the cluster nodes.

Common Errors and Troubleshooting

Many Kubernetes networking issues boil down to a few common scenarios:

• DNS Resolution Failure: Often caused by an unhealthy CoreDNS Pod, a misconfiguration in the Pod’s resolv.conf (though rare with default K8s setup), or a NetworkPolicy blocking traffic to CoreDNS. A Pod failing to resolve external names might have issues with upstream DNS servers from CoreDNS.
• Service Without Endpoints: This indicates that no Pods match the Service’s selector and are in a Ready state. Check the Pod status (kubectl get pod -o wide), their logs, and events to understand why they are not Ready. A common error is an incorrect selector or a failed readinessProbe.
• Inter-Pod Connectivity Failure: If Pods cannot communicate with each other, there might be an issue with the CNI plugin (e.g., errors in logs, improperly registered nodes) or, more commonly, a NetworkPolicy blocking traffic. Remember that a single default-deny NetworkPolicy can block everything.
• Ingress Issues: If the application is unreachable via Ingress, first verify that the Ingress Controller is running and Ready. Then, check Ingress rules (kubectl describe ingress ) and the Ingress Controller’s logs for routing or SSL configuration errors.

FAQ — Frequently Asked Questions

What is a CNI in Kubernetes?

A CNI (Container Network Interface) is a standard for network plugins that allows Kubernetes to configure Pod network interfaces and manage network connectivity. Popular implementations include Calico, Flannel, and Cilium, each with different features and performance. The CNI is fundamental for enabling Pods to communicate with each other and the outside world, providing the necessary overlay network.

What is the difference between ClusterIP and NodePort?

ClusterIP exposes a Service only within the cluster, assigning it a stable internal IP. NodePort, on the other hand, exposes the Service on a specific port of every cluster node, making it accessible from outside via any node’s IP and the assigned port. ClusterIP is for internal communication, NodePort for direct external access (often fronted by a LoadBalancer).

When should I use Ingress instead of a LoadBalancer?

A LoadBalancer exposes a single Service with a dedicated external IP. An Ingress is an HTTP/S controller that can expose many Services under a single external IP, managing routing based on hostname or path. Use LoadBalancer for a single critical or non-HTTP/S service, and Ingress for exposing multiple web applications or APIs with a unified entry point and centralized configuration.

How can I isolate traffic between my microservices?

Traffic isolation between microservices is primarily achieved through NetworkPolicies. These policies define which Pods can communicate with each other. You can create NetworkPolicies to allow only necessary traffic between specific Pods or namespaces, blocking everything else. This helps contain potential attacks and improves the overall security of the cluster.

Conclusions with Operational Takeaways

Kubernetes networking, while complex, is the backbone of any distributed application. Understanding the role of the overlay network, kube-proxy, CoreDNS, Services, Ingress, and NetworkPolicies is crucial for every Sysadmin. Investing time in mastering these concepts and debugging tools will allow you to:

1. Reduce Troubleshooting Time: Diagnose connectivity issues in minutes, not hours.
2. Improve Security: Implement NetworkPolicies to isolate workloads and reduce the attack surface. I’ve seen environments where a well-configured NetworkPolicy stopped an ongoing lateral attack.
3. Optimize Performance: Choose the correct Service type and efficiently configure the Ingress Controller to ensure optimal traffic flow.

Next time a Pod isn’t communicating with another, you’ll know exactly where to start looking. 73% of Kubernetes network incidents are attributable to misconfigurations or misunderstandings of these basic concepts (Cloud Native Computing Foundation Survey 2025).

Read also: Kubernetes Troubleshooting: A SysAdmin’s Daily Guide (2026)

Read also: Secure CI/CD Pipelines: 12-Point Checklist for GitLab & GitHub

Read also: VMware ESXi: Troubleshooting Performance — CPU Ready, Memory Balloon, Storage Latency (2026)

Updated: July 2026