Skip to content

Cluster Networking Types

Estimated time to read: 4 minutes

Kubernetes networking can be a bit complex, but once you understand its basic components and behavior, it becomes easier to manage. Here are the key concepts

Container-to-container communication

When multiple containers are part of the same Pod, they share the following:

  • Network Namespace: This means all containers in the same pod share the same IP address. Containers within a pod can communicate with each other using localhost or 127.0.0.1 (loopback interface), and they can access each other’s ports directly.
  • Shared Volumes: Besides network sharing, containers in the same pod can also share storage volumes. This can be useful for sharing files or logs between containers.

Use case

Let’s say you have two containers in a pod:

  • Container A runs an application on port 80.

  • Container B can communicate with Container A by making a request to localhost:80.

    No special configuration is needed to enable this communication, as containers in the same pod are designed to tightly collaborate.

    A common use case is the sidecar pattern, where one container is responsible for the main application logic, and another container (sidecar) provides auxiliary functions such as logging, monitoring, or proxying.

    ofl-c2c.yml
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
    apiVersion: v1
kind: Pod
metadata:
  name: multicontainerpod
  labels:
    name: multi-container-pod
    environment: production
    tier: front-end
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80
  - name: sidecar
    image: curlimages/curl:latest
    command: ["sh", "-c", "while true; do curl localhost:80; sleep 300; done"]

Pod-to-Pod Communication

Kubernetes ensures that all pods within the cluster can communicate with each other directly, regardless of which node they are running on. Each pod is assigned its own unique IP address, and the network allows communication between these IPs.

Let’s say there are two pods:

  • Pod A has IP 10.244.1.5 and is running a service on port 8080.

  • Pod B can directly communicate with Pod A by sending a request to http://10.244.1.5:8080.

    ofl-p2p.yml
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
    apiVersion: v1
kind: Pod
metadata: 
  name: webserver
  labels:
    name: webserver
    environment: production
    tier: front-end
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

  • Creating the temporary pod that calls the the IP address of the another POD 

    kubectl run busybox --image=busybox --rm  -it --restart=Never -- wget <podIp>

Pod-to-Service communication

A Service in Kubernetes is an abstraction that defines a logical set of pods and provides a stable endpoint (IP address and/or DNS) for accessing those pods. Services help solve issues related to the dynamic nature of pods, such as changing IP addresses or the need to load balance traffic across multiple replicas.

There are different types of services, depending on how and where you want to expose your service:

  • ClusterIP (default): Exposes the service only inside the cluster, making it accessible to other pods. This is the most common type used for internal communication.
  • NodePort: Exposes the service on a static port on each node in the cluster. This allows external traffic to access the service from outside the cluster.
  • LoadBalancer: Creates an external load balancer (typically used with cloud providers) that routes traffic to the service.
  • ExternalName: Maps the service to an external DNS name. This type of service doesn’t expose any pods; it simply acts as an alias for an external service.

For pod-to-service communication within the cluster, the most common and default service type is ClusterIP.