Pod-to-Pod communication in Kubernetes - Commands & Configuration

Introduction

Pods in Kubernetes are groups of containers that share network and storage. Pod-to-Pod communication means letting these pods talk to each other inside the cluster. This helps apps work together smoothly.

When you want a frontend pod to get data from a backend pod inside the cluster

When multiple pods need to share information or coordinate tasks

When you want to test if two pods can connect before deploying a full app

When you want to expose a pod's service to other pods without external access

When you want to debug network issues between pods

Config File - pod-communication.yaml

pod-communication.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-a
  labels:
    app: pod-a
spec:
  containers:
  - name: container-a
    image: busybox
    command: ["sleep", "3600"]
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-b
  labels:
    app: pod-b
spec:
  containers:
  - name: container-b
    image: busybox
    command: ["sleep", "3600"]
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: pod-b-service
spec:
  selector:
    app: pod-b
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

This file creates two pods named pod-a and pod-b, each running a simple container that sleeps to stay alive. It also creates a Service named pod-b-service that selects pod-b by its label. This service gives pod-b a stable network name and IP inside the cluster, so pod-a can reach it easily.

Commands

This command creates the two pods and the service in the Kubernetes cluster. It sets up the environment for pod-to-pod communication.

Terminal

kubectl apply -f pod-communication.yaml

Expected Output

pod/pod-a created

pod/pod-b created

service/pod-b-service created

This command checks that both pods are running and ready to communicate.

Terminal

kubectl get pods

Expected Output

NAME    READY   STATUS    RESTARTS   AGE

pod-a   1/1     Running   0          10s

pod-b   1/1     Running   0          10s

This command runs a simple HTTP request from pod-a to pod-b using the service name. It tests if pod-a can reach pod-b inside the cluster.

Terminal

kubectl exec pod-a -- wget -qO- http://pod-b-service

Expected Output

No output (command runs silently)

→

-- - Separates kubectl exec options from the command to run inside the pod

This command shows details about the service that connects to pod-b, including its cluster IP and ports.

Terminal

kubectl describe service pod-b-service

Expected Output

Name:              pod-b-service

Namespace:         default

Labels:            <none>

Annotations:       <none>

Selector:          app=pod-b

Type:              ClusterIP

IP:                10.96.0.1

Port:              80/TCP

TargetPort:        80/TCP

Endpoints:         10.244.1.5:80

Session Affinity:  None

Events:            <none>

Key Concept

Pods can communicate inside a Kubernetes cluster using Services that provide stable network names and IPs.

Common Mistakes

Trying to connect to a pod directly by its IP address

Pod IPs can change when pods restart, so connections break.

Use a Service to give pods a stable network name and IP.

Not labeling pods correctly to match the Service selector

The Service won't find the pods to route traffic to, so communication fails.

Make sure pod labels match the Service selector exactly.

Running commands without the '--' flag in kubectl exec

kubectl treats the command as its own option, causing errors.

Always use '--' before the command to run inside the pod.

Summary

Create pods and a Service to enable stable network communication between pods.

Use kubectl exec with the '--' flag to run commands inside pods for testing connectivity.

Verify pods are running and the Service is correctly routing traffic.

Practice

1.

How do pods inside a Kubernetes cluster typically communicate with each other?

easy

A. Using external DNS names only

B. Using pod IP addresses or service names

C. Through direct access to the host machine's network

D. By sharing the same storage volume

Solution

1. Step 1: Understand pod networking basics

   Pods have their own IP addresses inside the cluster and can communicate directly using these IPs.

2. Step 2: Recognize the role of services

   Services provide stable DNS names to reach pods even if pod IPs change.

3. Final Answer:

   Using pod IP addresses or service names -> Option B

4. Quick Check:

   Pod communication = IP or service name [OK]

Hint: Pods use IPs or services to talk inside cluster [OK]

Common Mistakes:

• Thinking pods use external DNS only
• Assuming pods share host network by default
• Believing storage volumes enable communication

2.

Which of the following is the correct way to define a Kubernetes Service to expose pods for pod-to-pod communication?

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

easy

A. The service exposes port 8080 externally but does not select pods

B. The selector matches pods with label app: myapp but ports are reversed

C. The selector matches pods with label app: myapp and forwards port 80 to 8080

D. The service definition is missing the type field, so it won't work

Solution

1. Step 1: Check the selector field

   The selector app: myapp correctly matches pods with that label.

2. Step 2: Verify ports mapping

   Port 80 on the service forwards traffic to port 8080 on the pods, which is correct.

3. Final Answer:

   The selector matches pods with label app: myapp and forwards port 80 to 8080 -> Option C

4. Quick Check:

   Selector and ports correct = The selector matches pods with label app: myapp and forwards port 80 to 8080 [OK]

Hint: Selector matches pod labels; ports map service to pod [OK]

Common Mistakes:

• Confusing port and targetPort roles
• Thinking 'type' is mandatory for basic service
• Ignoring selector means no pods matched

3.

Given two pods in the same namespace, pod-a and pod-b, where pod-b runs a web server on port 80, what is the expected output of this command run inside pod-a?

curl http://pod-b:80

Assuming pod-b is reachable by its pod IP but not by name.

medium

A. Connection refused or host not found error

B. Successful HTTP response from pod-b's web server

C. Timeout error because pods cannot communicate

D. DNS resolution error for pod-b

Solution

1. Step 1: Understand pod DNS naming

   Pods do not have DNS names by default; only services have stable DNS names.

2. Step 2: Analyze the command

   Trying to curl pod-b by name will fail DNS resolution because pod names are not DNS entries.

3. Final Answer:

   DNS resolution error for pod-b -> Option D

4. Quick Check:

   Pod names not DNS = DNS resolution error [OK]

Hint: Pod names are not DNS names; use service names [OK]

Common Mistakes:

• Assuming pod names resolve in DNS
• Expecting direct pod name communication
• Ignoring need for service abstraction

4.

You have a service named backend exposing pods on port 8080. A pod tries to connect using curl http://backend:80 but gets a connection refused error. What is the likely cause?

medium

A. The service port is 8080, but curl uses port 80

B. The service selector does not match any pods

C. The pod network is not enabled

D. The service type is NodePort instead of ClusterIP

Solution

1. Step 1: Check service port configuration

   The service exposes port 8080, but the curl command targets port 80, causing connection refusal.

2. Step 2: Understand port mapping importance

   Clients must use the service port, not the pod's internal port, to connect successfully.

3. Final Answer:

   The service port is 8080, but curl uses port 80 -> Option A

4. Quick Check:

   Port mismatch causes connection refused [OK]

Hint: Match curl port to service port exactly [OK]

Common Mistakes:

• Ignoring port mismatch between service and client
• Assuming network is disabled without checking
• Confusing service types with connectivity issues

5.

You want to ensure stable pod-to-pod communication in a Kubernetes cluster where pods restart frequently and get new IPs. Which approach best solves this problem?

hard

A. Use a Kubernetes Service to provide a stable DNS name and load balancing

B. Use pod IP addresses directly in application configuration

C. Configure pods to share the same static IP address

D. Use host networking mode for all pods

Solution

1. Step 1: Identify the problem with pod IPs

   Pods get new IPs on restart, so direct IP communication is unstable.

2. Step 2: Use Kubernetes Service for stability

   Services provide a stable DNS name and load balancing to reach pods regardless of IP changes.

3. Step 3: Evaluate other options

   Static IPs for pods are not practical; host networking breaks isolation; direct IP use is unreliable.

4. Final Answer:

   Use a Kubernetes Service to provide a stable DNS name and load balancing -> Option A

5. Quick Check:

   Service = stable pod communication [OK]

Hint: Use services for stable pod communication despite IP changes [OK]

Common Mistakes:

• Hardcoding pod IPs in configs
• Trying to assign static IPs to pods
• Using host networking unnecessarily