Kubernetes Networking: DNS, Services, Ingress – Sysadmin Guide

Pods not communicating. Services with zero endpoints. DNS resolution failures. When a Kubernetes application fails, 70% of the time, the problem lies in networking. This isn’t an invented statistic but a recurring observation in complex enterprise environments, where understanding network flow is critical for rapid and effective troubleshooting. A notable data point from Red Hat (2024) indicates that network misconfigurations are among the leading causes of downtime in Kubernetes clusters.

Understanding how Kubernetes networking functions is not black magic; it’s a precise logic that, once mastered, allows you to resolve most incidents in minutes. In this practical guide, I will explore the key concepts of Kubernetes networking, from Services and DNS to Ingress and NetworkPolicies, providing useful tools and commands for every Sysadmin.

Prerequisites / Test Environment

To follow this guide, you should have access to a functional Kubernetes cluster (Minikube, Kind, or a cloud cluster like EKS/AKS/GKE) and kubectl configured. All operations described have been tested on Kubernetes v1.29.

How Kubernetes Networking Works (Overlay, CNI, Kube-Proxy)

Kubernetes networking is built on a flat network model, where each Pod receives its own IP address and can communicate with any other Pod in the cluster without NAT. This is possible thanks to a virtual overlay network created on top of the underlying physical or virtual network.

The core of this architecture is the CNI (Container Network Interface), a standard that allows different providers (like Calico, Flannel, Cilium) to implement network connectivity for Pods. The CNI assigns IPs to Pods and configures the necessary routing rules. Without a CNI, Pods cannot communicate.

Another crucial component is kube-proxy, a daemon running on every node in the cluster. Kube-proxy is not a traditional proxy; it maintains network rules (primarily via iptables or IPVS) for Services, ensuring that requests to Services are routed correctly to backend Pods. This means that when a client attempts to connect to a Service, kube-proxy redirects traffic to one of the associated Pods.

ClusterIP, NodePort, LoadBalancer: When to Use Which

Kubernetes offers different Service types to expose applications, each with a specific purpose:

• ClusterIP: This is the default Service type. It exposes the Service on an internal IP within the cluster, making it reachable only by other Pods within the same cluster. It’s ideal for internal services that don’t need external exposure, such as a database or an API backend.
• NodePort: Exposes the Service on a static port on every node in the cluster. By accessing NodeIP:NodePort, traffic is forwarded to the Service. Useful for testing purposes or exposing services to an external load balancer not integrated with Kubernetes.
• LoadBalancer: This Service type is only available in cloud environments. It requires a cloud provider that supports load balancers (e.g., AWS ELB, Azure Load Balancer, Google Cloud Load Balancing). The cloud provider automatically creates an external load balancer with a public IP that routes traffic to the Service. It’s the most common way to expose production applications to the internet.

To inspect Service endpoints, a useful command is:

kubectl get endpoints <service-name>

This will show you the IPs of the Pods to which the Service is routing traffic. If this list is empty, your Service lacks healthy or correctly labeled backend Pods.

CoreDNS: How Kubernetes Resolves Internal Names

CoreDNS is the default DNS server in Kubernetes and plays a central role in resolving Service and Pod names within the cluster. Every Pod is configured to use CoreDNS for name resolution. When a Pod tries to connect to my-service.my-namespace.svc.cluster.local, CoreDNS translates this name into the IP of the my-service Service.

A common issue is a misconfigured or non-functional DNS, which prevents Pods from communicating with each other or with external services. To debug DNS resolution from within a Pod, you can use a busybox image:

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

This command will launch a temporary busybox Pod and execute nslookup to resolve the kubernetes.default Service name, which should always work. If this fails, you have a serious problem with CoreDNS or the Pod’s network configuration.

Ingress: Exposing Applications with a Single IP

While LoadBalancer Services expose a single Service with a public IP, Ingress is an API object that manages external access to HTTP and HTTPS services within the cluster. Ingress acts as a Layer 7 router, allowing you to consolidate traffic routing for multiple services under a single public IP (often provided by a LoadBalancer Service for the Ingress Controller itself).

An Ingress Controller (like NGINX Ingress Controller or Traefik) is required to fulfill the rules defined in the Ingress object. This controller is responsible for configuring a reverse proxy to direct traffic to the correct applications based on hostname, URL path, and other rules. Ingress simplifies TLS certificate management and virtual host configuration.

NetworkPolicy: Isolation Between Namespaces and Pods

NetworkPolicies are a network-level security mechanism that allows you to control traffic flow between Pods. They are essential for implementing the principle of least privilege and segmenting the network within the cluster, reducing the attack surface. NetworkPolicies were introduced to comply with standards like ISO 27001:2022 and NIST CSF 2.0 for workload isolation.

By default, Pods can communicate freely with each other. A NetworkPolicy can define Ingress (inbound traffic) and Egress (outbound traffic) rules based on Pod and Namespace labels. A good practice is to implement a default-deny policy, blocking all traffic not explicitly allowed:

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

This policy, applied to a Namespace, will block all inbound and outbound traffic for Pods in that Namespace, unless other NetworkPolicies explicitly permit it. This is a fundamental step for securing a production cluster.

Common Errors and Troubleshooting

When Kubernetes networking behaves unexpectedly, a debugging methodology is crucial. Here are some tools and techniques:

1. Check Pod and Service status: kubectl get pods -o wide, kubectl get services, kubectl get endpoints. Verify IPs, ports, and that Pods are Running.
2. Test DNS from the Pod: As seen, using nslookup from a temporary busybox Pod is the first step to diagnose name resolution issues.

kubectl run -it --rm debug --image=busybox -- nslookup my-service.my-namespace.svc.cluster.local

1. Inspect iptables/IPVS rules: On a node, you can use sudo iptables -L -t nat or sudo ipvsadm -Ln to see how kube-proxy is configuring routing rules for Services. This requires SSH access to the node.
2. Trace traffic within the Pod: For deeper analysis, you can use tcpdump directly inside a Pod. First, ensure the Pod has tcpdump or install it (if the image allows).

# Trace traffic in the pod
kubectl exec <pod-name> -c <container-name> -- tcpdump -i eth0 port 80

Replace and with the correct values, and port 80 with the desired port.

Common Errors and Troubleshooting

• DNS resolution failure: Often caused by CoreDNS issues (unhealthy Pods), a non-functional CNI, or an incorrect resolv.conf within the Pod. Check CoreDNS logs (kubectl logs -n kube-system -l k8s-app=kube-dns) and the CNI configuration.
• Service without endpoints: Indicates that the Service has no healthy Pods to direct traffic to. Common causes include Pods that are not Running, Service label selectors not matching Pod labels, or Pods failing readiness/liveness probes. Check Pod labels and statuses.
• Overly restrictive NetworkPolicies: Sometimes, a NetworkPolicy blocks necessary traffic. Monitor CNI logs (if policy logging is supported) or temporarily remove policies to isolate the issue.
• Port not mapped correctly: Ensure that the containerPort in the Deployment matches the targetPort in the Service, and that the port in the Service is what clients will use.

Conclusions with Operational Takeaways

Kubernetes networking is a robust and complex system, yet based on logical principles. The key to managing it effectively is understanding the roles of CNI, kube-proxy, Services, and CoreDNS. Do not underestimate the importance of NetworkPolicies for security, and use debugging tools (kubectl exec, nslookup, tcpdump) to quickly isolate issues. Maintaining a solid grasp of these concepts will enable you to keep your applications online and performing, significantly reducing incident resolution times.

Read also: Proxmox HA Cluster: Installation & Verification Checklist 2026

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

Read also: FortiGate Misconfiguration: 3 Hours of Open Firewall in Production (2026)

Updated: July 2026