Module 12 Exercises: The Extensible Cluster

Module 12 Exercises: The Extensible Cluster

Become a cluster architect. Practice building custom resources, exploring the power of operators, and experimenting with service mesh security.

Module 12 Exercises: The Extensible Cluster

In Module 12, we looked "Under the Hood" of Kubernetes. You learned about CRDs, Operators, Service Meshes, and Webhooks. These exercises will help you understand how these complex pieces fit together to create a powerful, customized platform.


Exercise 1: The "Digital Twin" CRD

  1. Task: Write the YAML for a Custom Resource Definition (CRD) named GPUWorker.
    • Group: research.ai.org.
    • Properties: It should have nodeGroup (string) and minGpus (integer).
  2. Creation: Use kubectl apply to register the CRD.
  3. Instantiation: Create an actual resource of kind: GPUWorker named high-perf-cluster.
  4. Verification: Use kubectl get gpuworker to verify it's stored in the cluster.
  5. Bonus: If you update the minGpus to -5, will Kubernetes accept it? If not, why? (Hint: See Lesson 1 schemas).

Exercise 2: Operator Observation

  1. Exploration: Run kubectl get pods -A | grep operator.
  2. Task: Identify one operator running in your cluster (e.g., the Prometheus Operator, the Cert-Manager Operator, or the ArgoCD Operator).
  3. Deep Dive: Pick one operator and run kubectl get crds | grep <operator-name>. How many new "Types" did this operator add to your cluster?
  4. Analysis: What human task does this specific operator automate? (e.g., "It automatically rotates SSL certificates before they expire").

Exercise 3: Sidecar Magic

  1. Scenario: You have Istio installed in the cluster.
  2. Task: Label the default namespace with istio-injection=enabled.
  3. Action: Deploy a simple nginx pod.
  4. Observation: Run kubectl describe pod <nginx-pod>. How many containers are running inside the pod?
  5. Analysis: Where did the second container come from? Which component (from Lesson 4) was responsible for injecting it?

Exercise 4: Governance Design

  1. Thinking Task: You are the Lead Architect. You want to ensure that NO POD can be created if it requests more than 4 GPUs.
  2. Design: Which tool from this module would you use to enforce this? (Webhook, CRD, or Service Mesh?)
  3. Logic: Describe the steps the API Server takes when a developer tries to create a pod with 8 GPUs. At which stage is the request blocked?

Solutions (Self-Check)

Exercise 1 Answer:

  • If you followed Lesson 1 and added a minimum: 0 to your schema, Kubernetes will Reject the -5 value with a validation error. This ensures your custom data is always high-quality.

Exercise 2 Hint:

The Cert-Manager Operator usually adds CRDs like Certificate, Issuer, and Order. It automates the "Human" task of talking to Let's Encrypt and updating K8s Secrets.

Exercise 3 Solution:

  • You will see 2 containers.
  • The second one is the istio-proxy.
  • It was injected by a Mutating Admission Webhook.

Exercise 4 Logic:

  • Tool: A Validating Admission Webhook (using OPA Gatekeeper or Kyverno).
  • Stage: The request is blocked at the Admission Control stage, before it is ever saved to etcd. The developer receives a 403 Forbidden error immediately.

Summary of Module 12

Congratulations! You have mastered the most advanced parts of Kubernetes.

  • You can extend the API using CRDs.
  • You understand the "Brain" of the cluster: the Operator Pattern.
  • You can manage billions of requests with a Service Mesh.
  • You can enforce enterprise rules with Admission Webhooks.

In Module 13: Kubernetes on Cloud Platforms, we will move from "How it works" to "Where it runs," exploring the power of EKS, GKE, and AKS.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn