Container Networking Docker Kubernetes

Category: Advanced Networking Concepts
Type: Network Concepts
Generated on: 2025-07-10 09:11:42
For: Network Engineering, Administration & Technical Interviews

Container Networking Cheatsheet (Docker & Kubernetes)

What is Container Networking?

Container networking allows containers to communicate with each other and the external world. It enables applications running inside containers to interact with other services, databases, and users, regardless of where they are deployed.

Why is it important?

Microservices Architecture: Crucial for connecting independent microservices.
Scalability & Portability: Enables containers to move between hosts and clouds without breaking connectivity.
Isolation: Provides network isolation between containers for security and stability.
Resource Management: Enables efficient resource utilization and network policy enforcement.

Concept	Definition
Container Network Interface (CNI)	A specification and plugin system for configuring network interfaces for Linux containers. Allows for flexibility in networking solutions.
Container Runtime Interface (CRI)	An API between Kubernetes and container runtimes (Docker, containerd, CRI-O). Handles container lifecycle.
Docker Bridge Network	The default network in Docker, typically `docker0`. Provides NAT and IP masquerading for containers to access the external network.
User-Defined Networks (Docker)	Custom networks created using `docker network create`. Provide better isolation and DNS resolution between containers.
Overlay Network	A virtual network that runs on top of an existing network infrastructure. Used in Docker Swarm and Kubernetes for cross-host container communication.
Service (Kubernetes)	An abstraction that defines a logical set of Pods and a policy by which to access them. Provides stable IP address and DNS name.
Pod (Kubernetes)	The smallest deployable unit in Kubernetes. A group of one or more containers that share network namespace, volumes, and other resources.
Ingress (Kubernetes)	An API object that manages external access to the Services in a cluster, typically via HTTP/HTTPS. Acts as a reverse proxy and load balancer.
NetworkPolicy (Kubernetes)	Specifies how groups of Pods are allowed to communicate with each other and other network endpoints. Provides network segmentation and security.
CNI Plugins	Specific implementations that configure the network for containers (e.g., Calico, Flannel, Weave Net). Each provides different features and performance characteristics.
kube-proxy (Kubernetes)	A network proxy that runs on each node in the cluster and implements Kubernetes Service concepts. Maintains network rules for service routing.
IP Address Management (IPAM)	The process of assigning and managing IP addresses within the container network.
CIDR (Classless Inter-Domain Routing)	A method for allocating IP addresses and routing Internet traffic. Used to define network address blocks.

Docker Networking (Simplified)

docker run: When you run a container, Docker assigns it an IP address within a default bridge network (usually docker0).

+-------------+    +-------------+
| Host OS       |    | Container 1 |  172.17.0.2
|  eth0: 192.168.1.100|--->| eth0        |
| docker0: 172.17.0.1|    +-------------+
+-------------+    +-------------+
     |
     | NAT/Masquerading
     V
+-------------+
| Internet      |
+-------------+

Communication Between Containers (Same Host): Containers on the same bridge network can communicate directly via their IP addresses.
Communication with the Internet: Docker uses NAT (Network Address Translation) and IP masquerading to allow containers to access the internet through the host’s IP address.
User-Defined Networks: Creating custom networks using docker network create provides better isolation and enables containers to communicate using container names as hostnames (DNS resolution).

Kubernetes Networking (Simplified)

Pod Creation: When a Pod is created, Kubernetes assigns it an IP address from a defined network range (CIDR).

+-------------+    +-------------+
| Node 1        |    | Pod 1       | 10.244.1.2
|  eth0: 192.168.1.101|--->| eth0        |
+-------------+    +-------------+

+-------------+    +-------------+
| Node 2        |    | Pod 2       | 10.244.2.3
|  eth0: 192.168.1.102|--->| eth0        |
+-------------+    +-------------+

Communication Between Pods: Pods can communicate with each other directly using their IP addresses, regardless of which node they are running on. This is typically facilitated by a CNI plugin like Calico or Flannel.
Services: Services provide a stable IP address and DNS name for a set of Pods. kube-proxy manages the routing of traffic to the appropriate Pods.
Ingress: Ingress provides external access to Services, acting as a reverse proxy and load balancer.

While there isn’t a specific container networking protocol, understanding common protocols is crucial:

TCP/IP: The foundation of container networking.
HTTP/HTTPS: Used for application-level communication.
DNS: Essential for service discovery.
VXLAN/Geneve: Encapsulation protocols used by some overlay networks to tunnel traffic between nodes. Headers will contain information about the virtual network.

Example: VXLAN Header (Simplified)

+-----------------------------------------------------------------+
| Outer Ethernet Header (Destination MAC, Source MAC, EtherType=0x0800) |
+-----------------------------------------------------------------+
| Outer IP Header (Destination IP, Source IP, Protocol=UDP)       |
+-----------------------------------------------------------------+
| UDP Header (Source Port, Destination Port=4789)                  |
+-----------------------------------------------------------------+
| VXLAN Header (VNI - Virtual Network Identifier)                   |
+-----------------------------------------------------------------+
| Inner Ethernet Header (Original Packet)                           |
+-----------------------------------------------------------------+
| Inner IP Header (Original Packet)                                |
+-----------------------------------------------------------------+
| TCP/UDP Header (Original Packet)                                 |
+-----------------------------------------------------------------+
| Application Data (Original Packet)                               |
+-----------------------------------------------------------------+

Microservices Deployment: Connecting various microservices (e.g., authentication, order processing, payment) running in separate containers and pods.
Load Balancing: Distributing traffic across multiple container instances of a service.
Database Access: Allowing containers to access databases (e.g., MySQL, PostgreSQL) running in separate containers or on external servers.
CI/CD Pipelines: Building and deploying containerized applications using automated pipelines.
Multi-Tier Applications: Deploying web servers, application servers, and databases in separate containers and connecting them through container networking.

Issue	Troubleshooting	Solution
Container Cannot Connect to Internet	Check if the host machine has internet access. Verify that the container has a valid IP address and default gateway. Inspect the `iptables` rules on the host machine. Check DNS resolution within the container.	Ensure that NAT/masquerading is enabled on the host. Configure DNS settings in the container. Use `--dns` flag with `docker run`. Verify that firewall rules allow outbound traffic.
Containers Cannot Communicate (Docker)	Check if the containers are on the same network. Use `docker inspect <container_id>` to check the network configuration. Verify that there are no firewall rules blocking communication between containers.	Connect the containers to the same user-defined network. Use container names as hostnames for communication. Expose ports if needed. Check firewall rules.
Service Discovery Issues (Kubernetes)	Verify that the Service is correctly defined. Check the status of the Pods associated with the Service. Inspect the `kube-proxy` logs. Check DNS resolution within the cluster.	Ensure that the Service selector matches the Pod labels. Verify that the Pods are healthy and running. Restart `kube-proxy`. Check CoreDNS or kube-dns configuration.
NetworkPolicy Blocking Traffic (Kubernetes)	Inspect the NetworkPolicy definitions. Use `kubectl describe networkpolicy <policy_name>` to understand the policy rules. Check the labels on the Pods to ensure they match the NetworkPolicy selectors. Review audit logs for denied connections.	Adjust the NetworkPolicy rules to allow the required traffic. Correct the labels on the Pods. Use `kubectl apply -f <networkpolicy.yaml>` to update the policy. Ensure you have a default deny policy to prevent unintended access.
CNI Plugin Issues (Kubernetes)	Check the logs of the CNI plugin (e.g., Calico, Flannel). Verify that the CNI plugin is correctly configured. Inspect the network interfaces on the nodes. Check the Kubernetes events for network-related errors.	Restart the CNI plugin. Reconfigure the CNI plugin. Verify that the kernel modules required by the CNI plugin are loaded. Check for compatibility issues between the CNI plugin and the Kubernetes version. Consider upgrading or downgrading the CNI plugin.
DNS Resolution Problems	`dig <hostname>` or `nslookup <hostname>` inside the container/pod. Check `/etc/resolv.conf` inside the container. Verify DNS server configuration. Check CoreDNS or kube-dns logs.	Configure the correct DNS server in Docker/Kubernetes. Ensure proper DNS records are configured. Restart DNS services.
MTU Mismatch	Capture packets to observe fragmentation. Use `ping -s <size> -M do <destination>` to test MTU without fragmentation.	Adjust MTU settings on container interfaces or overlay networks. Ensure consistent MTU across the network.

Docker

Creating a User-Defined Network:
Terminal window
```
docker network create my-network
```

Running a Container on a Specific Network:

docker run --network my-network --name my-container my-image

Inspecting a Container’s Network Configuration:
Terminal window
```
docker inspect my-container | grep NetworkSettings -A 20
```

Kubernetes

Creating a Service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Creating a NetworkPolicy (Example: Allow traffic from pods with label role=frontend to pods with label role=backend):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend

Applying a NetworkPolicy:
Terminal window
```
kubectl apply -f networkpolicy.yaml
```
Inspecting a Service:
Terminal window
```
kubectl describe service my-service
```

Q: What is CNI, and why is it important?

A: CNI (Container Network Interface) is a specification and plugin system for configuring network interfaces for Linux containers. It’s important because it provides a standardized way for container runtimes (like Docker and Kubernetes) to integrate with different networking solutions (CNI plugins like Calico, Flannel, Weave Net), allowing for flexibility and portability.

Q: Explain the difference between a Docker bridge network and a user-defined network.

A: A Docker bridge network (usually docker0) is the default network in Docker, providing NAT and IP masquerading for containers to access the external network. It’s simple but lacks isolation and DNS resolution between containers. User-defined networks, created using docker network create, offer better isolation, DNS resolution using container names as hostnames, and better control over network configuration.

Q: How does Kubernetes networking work? How do Pods communicate with each other?

A: Kubernetes networking relies on a flat network model where all Pods can communicate with each other directly, regardless of which node they are running on. Each Pod is assigned an IP address. This connectivity is typically managed by a CNI plugin that configures the network interfaces and routing rules on each node.

Q: What is a Kubernetes Service, and why is it needed?

A: A Kubernetes Service is an abstraction that defines a logical set of Pods and a policy by which to access them. It provides a stable IP address and DNS name for the Pods, allowing clients to access the service without needing to know the individual Pod IPs. It’s needed for load balancing, service discovery, and ensuring that applications remain accessible even as Pods are created, deleted, or moved.

Q: Explain the purpose of Kubernetes NetworkPolicies.

A: Kubernetes NetworkPolicies provide network segmentation and security by specifying how groups of Pods are allowed to communicate with each other and other network endpoints. They use selectors to define which Pods the policy applies to and rules to define which traffic is allowed or denied.

Q: What is an Ingress controller in Kubernetes and how does it work?

A: An Ingress controller manages external access to services in a Kubernetes cluster, typically via HTTP/HTTPS. It acts as a reverse proxy and load balancer, routing traffic from outside the cluster to the appropriate services based on rules defined in Ingress resources. It typically requires an Ingress controller implementation like Nginx Ingress Controller or Traefik.

Q: How do you troubleshoot network connectivity issues in Docker/Kubernetes?

A: (See Section 6. Common Issues for detailed troubleshooting steps). Common techniques include:

Checking container IP addresses and routing tables.
Verifying DNS resolution.
Inspecting firewall rules and NetworkPolicies.
Checking logs of network components (e.g., CNI plugin, kube-proxy).
Using network tools like ping, traceroute, tcpdump, and nslookup inside containers/pods.
Software-Defined Networking (SDN): A networking architecture that allows network behavior to be dynamically configured and controlled programmatically.
Network Functions Virtualization (NFV): A network architecture that virtualizes network functions (e.g., firewalls, load balancers) and runs them as software on commodity hardware.
Service Mesh (e.g., Istio, Linkerd): A dedicated infrastructure layer for handling service-to-service communication in microservices architectures. Provides features like traffic management, security, and observability.
Cloud-Native Computing Foundation (CNCF): A foundation that fosters the adoption of cloud-native technologies, including containerization, microservices, and service meshes.
eBPF (Extended Berkeley Packet Filter): A technology that allows sandboxed programs to run in the Linux kernel without modifying kernel source code. Used by some CNI plugins for advanced networking and security features.
Istio: A popular service mesh implementation that provides advanced traffic management, security, and observability for microservices.
Cilium: A CNI plugin that uses eBPF to provide advanced networking, security, and observability features for Kubernetes.

Further Reading:

Docker Networking Documentation: https://docs.docker.com/network/
Kubernetes Networking Documentation: https://kubernetes.io/docs/concepts/services-networking/
CNI Specification: https://github.com/containernetworking/cni
Calico Documentation: https://www.tigera.io/project-calico/
Flannel Documentation: https://github.com/flannel-io/flannel
Weave Net Documentation: https://www.weave.works/oss/net/
Istio Documentation: https://istio.io/