DS - Terraform and Kubernetes

Imagine you're managing a smart city with two major aspects:

1. Building and setting up the city: Constructing buildings, setting up roads, and laying utilities.
   1. Terraform: The city planner and builder focuses on designing and building the infrastructure of the city (e.g., deploying houses, roads, parks, and utilities).
   2. Once built, its job is mostly done until you want to expand or modify the city.
2. Managing day-to-day operations: Deciding how residents (applications) move around, scaling services based on population, and ensuring things run smoothly.
   1. Kubernetes: The city manager and traffic controller focuses on managing the daily operations of the city. It ensures:
      1. People (applications) have the resources they need (e.g., water, electricity).
      2. Traffic (requests) is routed efficiently between locations.
      3. The city adapts dynamically (e.g., scaling services during peak hours or moving people if one area becomes overcrowded).

Terraform: The City Planner and Builder

Imagine you're building and managing a smart city (your cloud infrastructure). This city has buildings (servers), roads (networks), utilities (databases), and parks (other resources).

To manage this city efficiently:

• You don’t build each building or road by hand.
• Instead, you use blueprints that describe what needs to be built, where, and how it connects.

Terraform is the architect and planner that creates and applies these blueprints:

Blueprints (Code)

You write a blueprint using Terraform’s special language (HCL – HashiCorp Configuration Language) to describe your city’s infrastructure. For example:

• “Build 10 houses (servers).”
• “Create a road (network) to connect them.”
• “Add a park (database) for public use.”

Execution (Building)

Terraform takes the blueprint and talks to builders (cloud providers like AWS, Google Cloud, Azure) to construct the city as planned.

State Management

Terraform keeps a map of your city (state file). If you make changes to the blueprint, Terraform checks what’s already there and only updates the parts that need to change.

Example: If you add 2 more houses in the blueprint, Terraform builds just those without demolishing the existing ones.

Kubernetes: City Manager

Kubernetes is like the city’s management system that oversees the daily operations of your smart city. It ensures that every resident (application) gets what they need, resources are allocated efficiently, and the city scales dynamically based on the population.

Key Components

1. Containers: Residents in Apartments (contains application code)

• Containers are the individual residents living in the apartments (pods). They come with their furniture, and supplies (code and dependencies) packed and ready to use.
  • Containers are lightweight, portable, and self-contained.
  • Multiple residents (containers) can share an apartment (pod)
  • If a resident moves out or a new one moves in, the city manager (Kubernetes) handles it seamlessly.

2. Pods: Apartments in Buildings (contains containers)

• Pods are like apartments in your city’s buildings. Each pod houses one or more residents (containers) who live together and share resources like utilities (e.g., internet, electricity).
  • Apartments (pods) are the basic units of accommodation (deployment).
  • Each apartment has its own address (IP address).
  • It can house a single tenant (container) or a group of roommates (multiple containers working together).

3. Nodes: Buildings in the City (contains pods)

• Nodes are the physical or virtual buildings in your smart city. Each building provides space for apartments (pods).
  • The building (node) hosts multiple apartments (pods).
  • Buildings are managed by the city authority (Kubernetes).
  • If a building gets overcrowded or faces issues, the K9S ensures residents are relocated.

4. Clusters: The Entire City (contains nodes)

• A cluster is the whole city made up of multiple buildings (nodes). It’s managed by a central city authority (Kubernetes master node) that oversees everything.
  • The city (cluster) is made of several buildings (nodes).
  • Each building communicates with the central city authority using a messenger (kubelet).
  • The authority ensures everything in the city works efficiently, from assigning new apartments (pods) to managing city-wide resources.

5. Namespace: Districts in the City (contains clusters)

• A Namespace is like a district in your smart city. Each district organizes and isolates different parts of the city while sharing the same overall infrastructure.
  • Each district (namespace) has its own set of buildings (nodes), apartments (pods), and utilities (resources).
  • The city authority (Kubernetes) ensures that districts stay separate and operate efficiently within the larger city.

Why Use Namespaces?

• Organization: Separate different environments (e.g., development, testing, production) or teams within the same city (cluster).
• Resource Management: Control and allocate resources (CPU, memory, storage) per district to prevent one from overusing shared resources.

Imagine a city with three districts:

1. Development District: Where new building designs (apps) are tested.
2. Testing District: Where you simulate real-world conditions for buildings (apps).
3. Production District: Where finished buildings (apps) are fully operational for public use.

Each district has its own set of apartments (pods), residents (containers), and policies.

Other Components: Helm, Service Mesh, Vault

Helm Addon: The City’s Logistics Coordinator

In a smart city, organizing large deliveries to the city’s residents (applications) requires efficient logistics. Helm is the logistics coordinator who handles:

• Delivering packages (applications) to apartments (pods) i.e. how to fetch correct application artifacts and deploy them to a pod accurately.
  • Allowing you to easily plan complex deliveries with detailed manifests.
• Done via Helm Charts: they are like pre-packaged delivery plans with instructions on what packages to deliver, where, and how.

Service Mesh Addon: The City’s Transport Network

A Service Mesh is like having a city-wide transport control system that manages how buildings (microservices) talk to each other. Instead of each building figuring things out on its own, the service mesh handles:

• Traffic Routing 🚦 → Directs requests to the right service instance.
• Security (authentication) 🔒 → Ensures secure communication between services.
• Observability (rate limiting) → Tracks service-to-service interactions.
• Resilience 🏗️ → Retries failed requests and handles errors gracefully.

It does all this without requiring changes to the services themselves.

A service mesh works by using sidecar proxies 🚗.

• Each service has a "sidecar" proxy (like a personal driver for every building)
• These proxies handle all network communication on behalf of the service.
• The service itself only talks to its local proxy, and the proxies talk to each other.

Think of it as each building in the city having its own smart traffic assistant that follows the city's global rules.

Example: A popular service mesh tool is Istio, which uses Envoy as its sidecar proxy.

Vault Addon: The City’s Secure Vault

Every smart city needs a secure location to store valuable items like keys, documents, and credentials. The Vault addon is the city’s secure vault that:

• Stores sensitive information securely.
• Manages access to these secrets.
• Automatically rotates keys to ensure security.