Bird
Raised Fist0
Kubernetesdevops~5 mins

Pod-to-Pod communication in Kubernetes - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is Pod-to-Pod communication in Kubernetes?
It is the ability of one Pod to send network traffic directly to another Pod within the same Kubernetes cluster.
Click to reveal answer
beginner
How do Pods communicate with each other by default in Kubernetes?
By default, all Pods in a Kubernetes cluster can communicate with each other using their IP addresses without any extra configuration.
Click to reveal answer
intermediate
What role does the Kubernetes Service play in Pod-to-Pod communication?
A Service provides a stable IP and DNS name to a set of Pods, enabling reliable communication even if Pods change or restart.
Click to reveal answer
intermediate
What is a NetworkPolicy in Kubernetes?
A NetworkPolicy is a set of rules that control how Pods are allowed to communicate with each other and other network endpoints.
Click to reveal answer
advanced
Why might Pod-to-Pod communication fail even though Pods are running?
Possible reasons include NetworkPolicy restrictions, misconfigured network plugins, or firewall rules blocking traffic.
Click to reveal answer
What is the default behavior of Pod-to-Pod communication in Kubernetes?
AAll Pods can communicate with each other by default
BPods cannot communicate unless a Service is created
CPods communicate only within the same Node
DPods require manual IP configuration to communicate
Which Kubernetes object provides a stable IP address for a group of Pods?
AService
BPod
CNetworkPolicy
DConfigMap
What does a NetworkPolicy control in Kubernetes?
APod scheduling
BNetwork traffic between Pods
CPod resource limits
DPod storage volumes
If Pod-to-Pod communication is blocked, what is a common cause?
APods have different labels
BPods are on different Nodes
CNetworkPolicy is restricting traffic
DPods are in different namespaces
How do Pods identify each other for communication?
AUsing hostnames only
BUsing external DNS names
CUsing MAC addresses
DUsing IP addresses assigned by Kubernetes
Explain how Pod-to-Pod communication works in Kubernetes and the role of Services.
Think about how Pods find each other and stay connected even if they restart.
You got /4 concepts.
    Describe what a NetworkPolicy is and how it affects Pod-to-Pod communication.
    Consider how you might restrict who can talk to whom inside the cluster.
    You got /4 concepts.

      Practice

      (1/5)
      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
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard