Ravindra BagaleCourses & study guides

Chapter 15: Kubernetes Introduction

15.13 Lab — kind cluster, deploy, curl

By Last updated:

Lab

Stick to kind for this lab.

  1. Install kind + kubectl (per current official docs); verify Docker works.
  2. kind create cluster --name badge-api and confirm node Ready.
  3. Create namespace badge-api.
  4. Apply a Deployment + ClusterIP Service for your badge API API image (build/push or kind load a local image).
  5. Wait for Pods Ready; kubectl logs on one Pod.
  6. kubectl port-forward Service to localhost; curl /health.
  7. Change to a second image tag (or a deliberate bad tag, then fix); practise rollout status / rollout undo.
  8. kind delete cluster --name badge-api when finished; confirm Docker resources freed.
  9. Write five bullets: Pod vs Deployment vs Service vs Namespace vs why not only Compose.

Practice task

Draw labels on paper: two Pods with app=badge-api and a Service selector. Then draw the bug where Service selector is app=badge-api (typo) — what does kubectl get endpoints show conceptually?

Thodkyaat sangaycha tar

  • Compose is great on one host; Kubernetes orchestrates desired replicas and healing across a cluster.
  • Core objects: Pod, Deployment, Service, Namespace — labels connect Services to Pods.
  • Lab tool: kind — stick to it; k3d/minikube exist but we do not hop.
  • Everyday kubectl: get, describe, logs, apply; port-forward for kind access.
  • Prefer immutable image tags; practise rollout undo; delete kind clusters after labs.
  • Ports are logical published ports; link AWS/managed K8s depth elsewhere — no invented cloud prices.

Samajla ka? Nasel tar lab (15.13) kind create → apply → port-forward curl → delete cluster paryant sodu naka. Aata pudhe jaauya badge API capstone kade.