Kubernetes Prep

⚙️ kubectl apply: A Visual Walkthrough

Overview

kubectl apply is the primary command for deploying and updating Kubernetes resources. It follows a declarative approach where you define the desired state in YAML files, and Kubernetes ensures the cluster matches that state.

The kubectl apply Process Flow

Step 1: Local Workstation

• Create or modify Pod.yaml file with desired configuration
• Run kubectl apply -f Pod.yaml command
• YAML is sent to the Kubernetes cluster

Step 2: Cluster Communication

• YAML is transmitted to the Kubernetes API Server
• API Server is located in the Control Plane
• Request includes authentication credentials

Step 3: API Server Processing

• Validates the YAML syntax and schema
• Checks authorization and RBAC policies
• Stores the configuration in etcd (distributed key-value store)
• Watches for any changes to the resource

Step 4: Scheduler Assignment

• Scheduler picks up unscheduled pods from the API Server
• Evaluates node resources (CPU, memory, disk)
• Assigns pods to appropriate worker nodes based on requirements
• Updates the pod's node assignment in etcd

Step 5: Worker Node Execution

• Kubelet (node agent) receives the pod assignment
• Pulls the container image from the registry
• Starts the container on the node
• Kube-proxy handles networking and service routing
• Running app pod is deployed and ready to serve traffic

Key Components Involved

Example YAML Configuration

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: app-container
    image: my-app:latest
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

🌐 Kubernetes DNS

What is Kubernetes DNS?

Kubernetes uses DNS to provide service discovery. Because Pods are dynamic—they restart, scale, and their IPs keep changing—DNS is essential for reliable communication between services.

CoreDNS: The Internal DNS Server

CoreDNS is a flexible, extensible DNS server that serves as Kubernetes' cluster DNS. It automatically discovers services and resolves their names to IP addresses.

How Kubernetes DNS Works

1. Pod sends a DNS query (e.g., my-service.default.svc.cluster.local)
2. Request goes to CoreDNS - The CoreDNS service intercepts the query
3. CoreDNS checks Kubernetes API - Looks up the Service IP
4. Returns the Cluster IP - CoreDNS returns the Service's Cluster IP
5. Traffic is routed to the correct Pod - Kube-proxy handles the routing

DNS Format

<service-name>.<namespace>.svc.cluster.local

Example DNS Names

• backend.default.svc.cluster.local - Service in default namespace
• database.production.svc.cluster.local - Service in production namespace
• cache.monitoring.svc.cluster.local - Service in monitoring namespace

Why This Matters

• Dynamic Discovery: Pods are dynamic and their IPs keep changing
• Service Discovery: Applications can reference services by name instead of IP
• Load Balancing: Requests are automatically distributed across all pod replicas
• Namespace Isolation: Services can be scoped to specific namespaces
• Reliability: Service names remain constant even if pods restart

CoreDNS Configuration

CoreDNS runs as a Deployment in the kube-system namespace and is configured via a ConfigMap. You can view the current configuration with:

kubectl get configmap coredns -n kube-system -o yaml

🏗️ Kubernetes Architecture

High-Level Overview

Kubernetes is a containerization platform that provides automated deployment, scaling, and management of containerized applications. It abstracts away the underlying infrastructure and provides a unified interface for managing containers across a cluster of machines.

The Two-Layer Architecture

Kubernetes follows a master-worker (or control plane-worker node) architecture:

Control Plane Components

The Control Plane is the brain of Kubernetes and consists of several critical components:

1. API Server

• Entry point for all requests (REST API)
• Validates and processes all requests
• Communicates with etcd for state management
• Enforces authorization and authentication

2. etcd

• Distributed key-value store
• Stores all cluster state and configuration
• Single source of truth for cluster data
• Highly available and consistent

3. Scheduler

• Watches for unscheduled pods
• Assigns pods to appropriate worker nodes
• Considers resource requirements and constraints
• Makes intelligent placement decisions

4. Controller Manager

• Runs multiple controllers in a single process
• Maintains desired state of resources
• Handles node failures and pod replicas
• Examples: ReplicaSet Controller, Deployment Controller, Service Controller

Worker Node Components

Worker Nodes run the actual application containers and consist of:

1. Kubelet

• Node agent that ensures containers run in pods
• Communicates with the API Server
• Manages pod lifecycle
• Reports node and pod status

2. Kube-proxy

• Handles networking and service routing
• Maintains network rules on nodes
• Enables service discovery
• Implements load balancing

3. Container Runtime

• Runs the containers (Docker, containerd, CRI-O)
• Manages container lifecycle
• Pulls images and starts containers

Architecture Flow

kubectl → API Server → etcd → Scheduler → Node → Pod runs

Why This Architecture Matters

🌍 Kubernetes Ingress

What is Ingress?

Ingress is a Kubernetes API object that manages external access to services within a cluster. It provides HTTP and HTTPS routing to services based on hostnames and URL paths.

Why Do We Need Ingress?

Without Ingress, you would need to:

• Use NodePort services (expose ports on every node)
• Use LoadBalancer services (expensive, one per service)
• Manually manage external load balancers

Ingress solves this by providing a single entry point with intelligent routing.

How Ingress Works

Ingress Components

1. Ingress Resource

Defines routing rules (YAML configuration)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 3000

2. Ingress Controller

Implements the Ingress rules (e.g., NGINX, HAProxy, Istio)

• Watches Ingress resources
• Configures the load balancer
• Routes traffic based on rules

Routing Patterns

Host-Based Routing

api.example.com → api-service
web.example.com → web-service
admin.example.com → admin-service

Path-Based Routing

example.com/api → api-service
example.com/web → web-service
example.com/admin → admin-service

Combination Routing

api.example.com/v1 → api-v1-service
api.example.com/v2 → api-v2-service

Common Ingress Controllers

🔍 Kubernetes Probes

What Are Probes?

Probes are diagnostic checks that Kubernetes uses to determine the health and readiness of containers. They help Kubernetes make intelligent decisions about pod lifecycle management.

Types of Probes

1. Liveness Probe

Use Cases:

• Detect deadlocks
• Recover from hung processes
• Restart unhealthy containers

Example:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

2. Readiness Probe

Use Cases:

• Wait for dependencies to be ready
• Prevent traffic during startup
• Graceful shutdown

Example:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

3. Startup Probe

Example:

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Liveness vs Readiness Comparison

Probe Types

HTTP Probe

httpGet:
  path: /health
  port: 8080
  scheme: HTTP
  httpHeaders:
  - name: Custom-Header
    value: Awesome

TCP Probe

tcpSocket:
  port: 8080

Exec Probe

exec:
  command:
  - /bin/sh
  - -c
  - curl localhost:8080/health

Probe Configuration Parameters

⚡ How Kubernetes Works (End-to-End)

The Complete Journey: From kubectl to Running Pod

Step 1: User Issues kubectl Command

$ kubectl apply -f deployment.yaml

Step 2: kubectl Communicates with API Server

• kubectl reads the YAML file
• Sends HTTP POST request to API Server
• Includes authentication credentials

Step 3: API Server Validates Request

• Authenticates the user
• Authorizes the action (RBAC)
• Validates YAML schema
• Performs admission control checks

Step 4: API Server Stores in etcd

• Creates the resource object
• Stores it in etcd
• Returns success response to kubectl

Step 5: Controllers Watch for Changes

• Deployment Controller detects new Deployment
• Creates ReplicaSet
• ReplicaSet Controller creates Pods

Step 6: Scheduler Assigns Pods to Nodes

• Scheduler watches for unscheduled pods
• Evaluates node resources and constraints
• Assigns pod to best-fit node
• Updates pod's nodeName field in etcd

Step 7: Kubelet Receives Pod Assignment

• Kubelet on assigned node watches API Server
• Detects pod assignment
• Begins pod startup process

Step 8: Container Runtime Creates Container

• Kubelet instructs container runtime
• Container runtime pulls image
• Creates and starts container
• Sets up networking

Step 9: Pod Becomes Ready

• Container starts successfully
• Readiness probe passes
• Pod is added to Service endpoints
• Traffic can now be routed to pod

Step 10: Application Serves Traffic

• Pod is fully operational
• Receives requests through Service
• Processes requests and returns responses

Complete Flow Diagram

User (kubectl apply)
    ↓
API Server (validate & store)
    ↓
etcd (persistent storage)
    ↓
Controllers (create resources)
    ↓
Scheduler (assign to node)
    ↓
Kubelet (create container)
    ↓
Container Runtime (run container)
    ↓
Running Pod (serving traffic)

📱 Kubernetes in 6 Swipes

A Quick Overview of Core Kubernetes Objects

1. Pod

What: Smallest deployable unit in Kubernetes

Contains: One or more containers

Lifetime: Ephemeral (can be created and destroyed)

Use: Never create Pods directly; use Deployments

2. Service

What: Stable endpoint for accessing pods

Purpose: Provides service discovery and load balancing

Types: ClusterIP, NodePort, LoadBalancer, ExternalName

Benefit: Pods can change, but Service IP remains stable

3. Deployment

What: Declarative way to manage pods

Features: Scaling, rolling updates, rollbacks

Manages: ReplicaSets and Pods

Use: Primary way to deploy stateless applications

4. ConfigMap

What: Store configuration data

Format: Key-value pairs

Use Cases: Environment variables, config files

Benefit: Separate configuration from application code

5. Secret

What: Store sensitive data

Types: Opaque, TLS, ServiceAccount, Docker registry

Encoding: Base64 encoded (not encrypted by default)

Use: Passwords, API keys, certificates

6. Namespace

What: Virtual cluster within a cluster

Purpose: Isolate resources and teams

Default: default, kube-system, kube-public

Benefit: Multi-tenancy and resource organization

Quick Reference Table

📦 Your First Kubernetes Object: Pod

What is a Pod?

A Pod is the smallest deployable unit in Kubernetes. It's a wrapper around one or more containers (usually one) that runs together on the same node and shares network namespace.

Pod Characteristics

• Ephemeral: Pods are temporary and can be created/destroyed
• Shared Network: All containers in a pod share the same IP address
• Shared Storage: Containers can share volumes
• Atomic: Pod is the smallest unit you can schedule

Pod Lifecycle

Pod Phases

Creating Your First Pod

Simple Pod YAML

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
  labels:
    app: hello-world
spec:
  containers:
  - name: hello-container
    image: nginx:latest
    ports:
    - containerPort: 80

Apply the Pod

$ kubectl apply -f pod.yaml
pod/my-first-pod created

View the Pod

$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
my-first-pod    1/1     Running   0          10s

Get Pod Details

$ kubectl describe pod my-first-pod

View Pod Logs

$ kubectl logs my-first-pod

Execute Commands in Pod

$ kubectl exec -it my-first-pod -- /bin/bash

Pod with Multiple Containers

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: web-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: app-container
    image: my-app:latest
    ports:
    - containerPort: 8080

Pod with Resource Requests and Limits

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
  - name: app
    image: my-app:latest
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Pod with Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: env-pod
spec:
  containers:
  - name: app
    image: my-app:latest
    env:
    - name: ENVIRONMENT
      value: "production"
    - name: DEBUG
      value: "false"
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

Common kubectl Commands for Pods

Important Notes About Pods