Pod-to-Pod communication in Kubernetes - Cheat Sheet & Quick Revision
Practice
How do pods inside a Kubernetes cluster typically communicate with each other?
Solution
Step 1: Understand pod networking basics
Pods have their own IP addresses inside the cluster and can communicate directly using these IPs.Step 2: Recognize the role of services
Services provide stable DNS names to reach pods even if pod IPs change.Final Answer:
Using pod IP addresses or service names -> Option BQuick Check:
Pod communication = IP or service name [OK]
- Thinking pods use external DNS only
- Assuming pods share host network by default
- Believing storage volumes enable communication
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: 8080Solution
Step 1: Check the selector field
The selectorapp: myappcorrectly matches pods with that label.Step 2: Verify ports mapping
Port 80 on the service forwards traffic to port 8080 on the pods, which is correct.Final Answer:
The selector matches pods with labelapp: myappand forwards port 80 to 8080 -> Option CQuick Check:
Selector and ports correct = The selector matches pods with labelapp: myappand forwards port 80 to 8080 [OK]
- Confusing port and targetPort roles
- Thinking 'type' is mandatory for basic service
- Ignoring selector means no pods matched
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.
Solution
Step 1: Understand pod DNS naming
Pods do not have DNS names by default; only services have stable DNS names.Step 2: Analyze the command
Trying to curlpod-bby name will fail DNS resolution because pod names are not DNS entries.Final Answer:
DNS resolution error for pod-b -> Option DQuick Check:
Pod names not DNS = DNS resolution error [OK]
- Assuming pod names resolve in DNS
- Expecting direct pod name communication
- Ignoring need for service abstraction
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?
Solution
Step 1: Check service port configuration
The service exposes port 8080, but the curl command targets port 80, causing connection refusal.Step 2: Understand port mapping importance
Clients must use the service port, not the pod's internal port, to connect successfully.Final Answer:
The service port is 8080, but curl uses port 80 -> Option AQuick Check:
Port mismatch causes connection refused [OK]
- Ignoring port mismatch between service and client
- Assuming network is disabled without checking
- Confusing service types with connectivity issues
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?
Solution
Step 1: Identify the problem with pod IPs
Pods get new IPs on restart, so direct IP communication is unstable.Step 2: Use Kubernetes Service for stability
Services provide a stable DNS name and load balancing to reach pods regardless of IP changes.Step 3: Evaluate other options
Static IPs for pods are not practical; host networking breaks isolation; direct IP use is unreliable.Final Answer:
Use a Kubernetes Service to provide a stable DNS name and load balancing -> Option AQuick Check:
Service = stable pod communication [OK]
- Hardcoding pod IPs in configs
- Trying to assign static IPs to pods
- Using host networking unnecessarily
Ready to prove it?
Pass the test and this pattern moves unknown
