Operations 20 min read

Master Container Networking: From Basics to Advanced Kubernetes Practices

This comprehensive guide explores container networking fundamentals, Docker network modes, Kubernetes CNI plugins, network security policies, monitoring, troubleshooting, and performance optimization, providing practical commands and configuration examples for operations engineers.

Raymond Ops
Raymond Ops
Raymond Ops
Master Container Networking: From Basics to Advanced Kubernetes Practices

Container network management is a critical component of modern cloud‑native architectures, connecting distributed services across hosts. The article begins by outlining core concepts such as container‑to‑container communication, cross‑host connectivity, external service access, and network isolation.

Linux Network Namespaces

Each container runs in its own network namespace, which includes its own network interfaces, routing tables, firewall rules, and statistics.

Virtual Network Devices

veth pair : connects a container to the host network.

bridge : virtual bridge for intra‑host container communication.

tun/tap : used for VPN and overlay networks.

macvlan/ipvlan : enables containers to access the physical network directly.

Docker Network Modes

Bridge Mode

Bridge is Docker’s default mode, providing NAT connectivity.

# Create a custom bridge network
docker network create --driver bridge my-bridge-network
# Run a container on the custom network
docker run -d --name web --network my-bridge-network nginx
# Inspect the network
docker network inspect my-bridge-network

Docker daemon creates the default docker0 bridge.

Each container gets a veth pair.

One end attaches to the container, the other to docker0.

iptables rules perform NAT forwarding.

Host Mode

Containers share the host’s network stack, offering the best performance but minimal isolation.

# Run a container with host networking
docker run -d --name web-host --network host nginx
# Verify the container uses the host interface
docker exec web-host ip addr show

Typical use cases include high‑performance applications, services that must bind specific host ports, and network diagnostics.

Container Mode

Allows a container to share another container’s network namespace.

# Create a network container
docker run -d --name network-container alpine sleep 3600
# Share its network namespace
docker run -d --name app --network container:network-container nginx

None Mode

Provides complete network isolation, suitable for highly secure environments.

# Create an isolated container
docker run -d --name isolated --network none alpine sleep 3600
# Manually configure networking if needed
docker exec isolated ip link set lo up

Kubernetes Networking

Kubernetes Network Model

Each Pod receives a unique IP address.

Pods can communicate directly without NAT.

Nodes can communicate directly with Pods.

The IP seen by a Pod is the same as that seen by other Pods.

CNI (Container Network Interface)

CNI defines the standard API between container runtimes and network plugins.

{
  "cniVersion": "0.3.1",
  "name": "mynet",
  "type": "bridge",
  "bridge": "mynet0",
  "isDefaultGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.22.0.0/16",
    "routes": [{"dst": "0.0.0.0/0"}]
  }
}

Service Types

# ClusterIP Service
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP
---
# NodePort Service
apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30000
  type: NodePort
---
# LoadBalancer Service
apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

Ingress

Provides HTTP/HTTPS routing from hostnames to services.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: web.example.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Popular CNI Plugins Comparison

Flannel

Simple configuration, supports VXLAN, host‑gw, UDP backends.

Moderate performance, basic feature set.

# Flannel ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [{"type": "flannel","delegate": {"hairpinMode": true,"isDefaultGateway": true}}]
    }
  net-conf.json: |
    {"Network": "10.244.0.0/16","Backend": {"Type": "vxlan"}}

Calico

Uses BGP routing for high performance.

Built‑in network policy support.

Supports Linux kernel, eBPF, and VPP data planes.

# Calico NetworkPolicy example
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  selector: all()
  types:
  - Ingress
  - Egress
  egress:
  - action: Allow
    destination:
      selector: app == "database"
    protocol: TCP
    destination:
      ports: [5432]

Weave Net

Automatic node discovery and connection.

Built‑in DNS service discovery.

Supports network encryption.

# Deploy Weave Net
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '
')"
# Check status
kubectl exec -n kube-system weave-net-xxx -- /home/weave/weave --local status

Cilium

eBPF‑based, high‑performance data plane.

Provides L7 network policies.

Integrates with service mesh features.

# Cilium NetworkPolicy example
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l3-l4-policy"
spec:
  endpointSelector:
    matchLabels:
      app: web
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

Container Network Security

Network Policies

# Basic NetworkPolicy example
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-netpol
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 3306

Namespace Isolation

# Deny all ingress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Allow specific namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-namespace
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

Encryption (IPSec/WireGuard)

# Calico IPSec/WireGuard configuration
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  wireguardEnabled: true
  wireguardInterfaceName: wg0

Service Discovery & Load Balancing

CoreDNS

# CoreDNS ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
      errors
      health { lameduck 5s }
      ready
      kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
      }
      prometheus :9153
      forward . /etc/resolv.conf
      cache 30
      loop
      reload
      loadbalance
    }

Istio Service Mesh

# Istio VirtualService example
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productpage
spec:
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

IPVS Load Balancing

# kube-proxy ConfigMap for IPVS
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy
  namespace: kube-system
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "ipvs"
    ipvs:
      scheduler: "rr"
      syncPeriod: 30s
      minSyncPeriod: 5s

Monitoring & Troubleshooting

Network Performance Monitoring

# ServiceMonitor for Prometheus
apiVersion: v1
kind: ServiceMonitor
metadata:
  name: container-network-monitor
spec:
  selector:
    matchLabels:
      app: network-exporter
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

eBPF Traffic Analysis

# bpftrace script to measure TCP send latency
bpftrace -e '
 kprobe:tcp_sendmsg { @send_start[tid] = nsecs; }
 kretprobe:tcp_sendmsg /@send_start[tid]/ { @send_latency = hist(nsecs - @send_start[tid]); delete(@send_start[tid]); }'

Alerting Example

# PrometheusRule for high network latency
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: network-monitoring
spec:
  groups:
  - name: network.rules
    rules:
    - alert: HighNetworkLatency
      expr: histogram_quantile(0.99, rate(container_network_receive_bytes_total[5m])) > 1000
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "High network latency detected"
        description: "Network latency is above 1000ms for {{ $labels.instance }}"

Common Diagnosis Commands

# Check pod connectivity
kubectl exec -it pod-name -- ping target-ip
# DNS lookup
kubectl exec -it pod-name -- nslookup service-name
# Port check
kubectl exec -it pod-name -- telnet service-name port
# Review network policies
kubectl describe networkpolicy policy-name

Kernel Tuning for Performance

# Increase network buffers
echo 'net.core.rmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_rmem = 4096 87380 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_wmem = 4096 65536 134217728' >> /etc/sysctl.conf
# Expand conntrack limits
echo 'net.netfilter.nf_conntrack_max = 1000000' >> /etc/sysctl.conf
echo 'net.netfilter.nf_conntrack_buckets = 250000' >> /etc/sysctl.conf
sysctl -p

Calico Performance Settings

# Enable eBPF in Calico
apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  bpfEnabled: true
  bpfLogLevel: "info"
  bpfDataIfacePattern: "^(en|eth|ens|eno|enp|enx|em|wlan|wlp|wlx|ww|sl|bond|team|br|docker|veth|lo|tunl|vxlan|cilium|lxc|cni|flannel|kube|dummy|virbr|vnet|ptp|ipvlan|macvlan|tap|p2p|erspan|gre|sit|ip6gre|ip6tnl|ip6gretap|isatap|vti|nlmon|ipip|ip_vti|ip6_vti)"

Automation Scripts

#!/bin/bash
check_network_health() {
  echo "Checking network connectivity..."
  kubectl get pods --all-namespaces -o wide | grep -v Running | grep -v Completed
  kubectl get svc --all-namespaces
  kubectl exec -n kube-system -it $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o name | head -1) -- nslookup kubernetes.default.svc.cluster.local
  kubectl get networkpolicies --all-namespaces
}
network_performance_test() {
  echo "Running network performance test..."
  kubectl run netperf-server --image=networkstatic/netperf --restart=Never -- netserver
  kubectl run netperf-client --image=networkstatic/netperf --restart=Never -- netperf -H netperf-server
  kubectl delete pod netperf-server netperf-client
}
check_network_health
network_performance_test

Future Trends

eBPF will become the core of container networking, delivering higher performance and observability.

Deep integration of service mesh with container networking for advanced service governance.

Support for edge‑computing topologies and more complex network layouts.

Zero‑trust networking models to strengthen security in container environments.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

monitoringDockerPerformance OptimizationKubernetesCNIcontainer networkingnetwork policies
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.