CodeWithAbdessamad

Cluster Networking

Cluster Networking

Kubernetes clusters require robust networking infrastructure to enable seamless communication between components. This section dives deep into the foundational networking concepts that power your cluster, starting with how pods interact internally and progressing to the critical layer that defines your cluster’s network architecture: CNI plugins.

Pod-to-Pod Communication

In Kubernetes, pod-to-pod communication is the lifeblood of application interactions within your cluster. Unlike traditional distributed systems, Kubernetes abstracts network configuration so that pods can communicate using service names rather than IP addresses—this abstraction is what makes cloud-native applications so resilient and scalable.

How It Works Under the Hood

When two pods need to communicate:

  1. Kubernetes creates a DNS entry for each pod in the cluster’s DNS service (default: coredns).
  2. Pods resolve each other’s DNS names using the format pod-name.namespace.svc.cluster.local.
  3. The underlying CNI plugin (e.g., Calico) handles the actual network routing to connect pods via a network policy or overlay network.

This approach eliminates manual IP configuration and enables dynamic scaling without network reconfiguration.

Real-World Example: Testing Pod-to-Pod Communication

Let’s create two pods that communicate over HTTP to demonstrate this flow:

<code class="language-bash"># Create a simple HTTP server pod
<p>kubectl run http-server --image=nginx --port=80</p>

<h1>Create a client pod that connects to the server</h1>
<p>kubectl run http-client --image=alpine --command -- sleep 3600 \</p>
<p>  --env="HTTP<em>SERVER</em>POD=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')"</code>

Now, test communication from the client pod:

<code class="language-bash">kubectl exec -it http-client -- curl http://http-server.http-server.svc.cluster.local</code>

✅ Output: HTTP/1.1 200 OK (if the CNI plugin is properly configured)

Key Nuances

  • Namespace Isolation: Pods in different namespaces communicate via service.namespaces.svc.cluster.local (e.g., http-server.default.svc.cluster.local).
  • Network Policies: While DNS resolution works by default, network policies (via NetworkPolicy resources) control which pods can communicate (e.g., allowing only specific ports or labels).
  • Service Discovery: Kubernetes uses DNS-based service discovery (not static IPs) so pods can self-heal if a service restarts.

💡 Pro Tip: Always use kubectl get svc to verify service DNS names before testing communication. For example, http-server.default.svc.cluster.local resolves to the pod’s IP via the CNI plugin.

CNI Plugins

CNI (Container Network Interface) is Kubernetes’ standard for defining how containers connect to the network. Without a CNI plugin, your cluster would have no way to route traffic between pods. Think of CNI plugins as the “network drivers” that make Kubernetes networking work.

Why CNI Plugins Matter

Kubernetes does not include network configuration in its core API. Instead, it relies on CNI plugins to:

  • Assign IP addresses to pods
  • Route traffic between pods
  • Enforce network policies
  • Handle load balancing

This modular approach lets you choose the best networking solution for your use case—whether you need high security (Calico), low latency (Cilium), or simple scalability (Flannel).

Common CNI Plugins Compared

Plugin Use Case Key Strengths Complexity
Calico Production clusters, security Built-in network policies, BGP support Medium
Cilium High-performance, observability Unified networking, auto-traffic management High
Flannel Simple clusters, fast deployment Lightweight, easy to set up Low
Weave Net Hybrid cloud environments Good for multi-cluster networking Medium

Hands-On: Installing Calico (Production-Grade CNI)

Let’s configure a cluster with Calico for secure pod communication:

Step 1: Deploy Calico via Helm

<code class="language-bash"># Add Calico Helm repository
<p>helm repo add calico https://github.com/calico-project/helm-charts</p>

<h1>Install Calico</h1>
<p>helm install calico-calico calico/calico --namespace=kube-system \</p>
<p>  --set cniConfig.podCidr=192.168.0.0/16</code>

Step 2: Verify pod networking

<code class="language-bash"># Check Calico pods
<p>kubectl get pods -n kube-system -l k8s-app=calico-node</p>

<h1>Test pod-to-pod communication (same as earlier example)</h1>
<p>kubectl run http-client --image=alpine --command -- sleep 3600 \</p>
<p>  --env="HTTP<em>SERVER</em>POD=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')"</p>
<p>kubectl exec -it http-client -- curl http://http-server.http-server.svc.cluster.local</code>

✅ Output: HTTP/1.1 200 OK (with Calico’s routing)

Critical Implementation Notes

  1. Network Policies: Calico enforces policies by default. To allow traffic between pods:
<code class="language-yaml">   apiVersion: networking.k8s.io/v1</p>
<p>   kind: NetworkPolicy</p>
<p>   metadata:</p>
<p>     name: allow-http</p>
<p>     namespace: default</p>
<p>   spec:</p>
<p>     podSelector:</p>
<p>       matchLabels:</p>
<p>         app: nginx</p>
<p>     ingress:</p>
<p>     - from:</p>
<p>       - namespace: default</p>
<p>         podSelector:</p>
<p>           matchLabels:</p>
<p>             app: http-client</p>
<p>       ports:</p>
<p>         - protocol: TCP</p>
<p>           port: 80</code>

  1. IP Addressing: Calico uses BGP for multi-cluster networking and IPVS for load balancing—ideal for large-scale deployments.
  2. Troubleshooting: If pods fail to communicate, check:

– kubectl get pods -n kube-system -l k8s-app=calico-node (Calico pods running)

– kubectl describe networkpolicy -n default allow-http (policy rules)

🌟 Key Insight: The best CNI plugin for you depends on your cluster size, security needs, and observability requirements. Start with Calico for most production workloads—it balances security and simplicity.

Summary

Pod-to-pod communication in Kubernetes relies on DNS-based service discovery and CNI plugins to route traffic—enabling applications to interact without manual IP management. CNI plugins are the critical layer that transforms your cluster from a collection of containers into a cohesive network. By understanding how DNS resolves pod names and how plugins like Calico handle routing, you gain control over your cluster’s networking behavior. Start with Calico for production clusters, implement network policies for security, and always test communication using curl or kubectl exec to ensure your network is working as expected. 🚀