Module 5 Exercises: Cluster Networking

Module 5 Exercises: Cluster Networking

Master the data plane. Connect services with Ingress, secure them with Network Policies, and debug internal DNS.

Module 5 Exercises: Cluster Networking

In Module 5, we moved from basic services to the complex, vascular system of the cluster. These exercises will help you practice the transition from "internal discovery" to "secured external access."


Exercise 1: The Path-Based Ingress

Create an Ingress resource to route traffic to two different services.

  • Domain: ai.example.com
  • Service A: frontend-svc (Target path: /)
  • Service B: api-svc (Target path: /api)
  • Verification: If you were using Nginx, which annotation would you use to ensure /api/test correctly reaches the API service even if it expects traffic at /test? (Hint: See Lesson 3).

Exercise 2: Implementing "Zero Trust"

  1. Preparation: Create two namespaces: safe-zone and danger-zone.
  2. The Goal: Create a Network Policy in the safe-zone that allows incoming traffic ONLY from other pods in the same namespace.
  3. The Test: A pod in danger-zone tries to ping a pod in safe-zone. What should happen?
  4. Verification: Write the YAML for a "Default Deny Ingress" policy for the safe-zone namespace.

Exercise 3: Cross-Namespace DNS Lookup

  1. Setup: Create a Service named database-svc in the backend namespace.
  2. Task: From a pod in the frontend namespace, use nslookup or curl to reach that service.
  3. Question: What is the Fully Qualified Domain Name (FQDN) you must use? Why won't http://database-svc work?

Exercise 4: Debugging the CoreDNS Phonebook

  1. Symptoms: Your pod is failing to resolve any names, even google.com.
  2. Commands:
    • How do you check the logs of the CoreDNS pods?
    • How do you check the /etc/resolv.conf of your failing pod without deleting it?
    • What is the service name and namespace for the internal DNS server?

Solutions (Self-Check)

Exercise 1 Answer:

You would use the rewrite-target annotation: nginx.ingress.kubernetes.io/rewrite-target: /$2

Exercise 2 Hint:

Your policy should use a namespaceSelector that matches the current namespace's labels, or a podSelector: {} combined with the default namespace behavior. A pod in the danger-zone will be timed out. It won't get a "Permission Denied" error; the packets will just be dropped by the kernel.

Exercise 3 Solution:

The FQDN is database-svc.backend.svc.cluster.local. http://database-svc won't work because the default search path inside a pod only looks in the current namespace (frontend.svc.cluster.local).

Exercise 4 Commands:

  • kubectl logs -n kube-system -l k8s-app=kube-dns
  • kubectl exec -it <pod-name> -- cat /etc/resolv.conf
  • Service: kube-dns, Namespace: kube-system.

Summary of Module 5

You have mastered the most complex part of Kubernetes.

  • You understand Pod-to-Pod communication across nodes.
  • You can look inside the iptables and kube-proxy logic.
  • You can build sophisticated Ingress gateways for users.
  • You can secure your apps with Network Policies.
  • You can navigate the cluster using CoreDNS.

In Module 6: Storage and Volumes, we will look at how we manage the "Memory" of these networked applications using advanced storage patterns.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn