Introduction: The Standard of Container Orchestration

So far, we've learned how to create and manage containers with Docker. However, in real production environments, you need to operate dozens or hundreds of containers across multiple servers. Manually managing each container is virtually impossible in such scenarios.

In this Part 6, we'll explore the fundamental concepts and architecture of Kubernetes (K8s), which has become the de facto standard for container orchestration. Understanding what Kubernetes is, why it's needed, and how it's structured will give you a complete picture of application operations in cloud-native environments.

1. What is Kubernetes?

1.1 Definition of Kubernetes

Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. The name comes from the Greek word meaning "helmsman" or "pilot," representing its role in properly transporting and managing container "cargo."

The abbreviation "K8s" comes from the 8 letters (ubernete) between K and s.

1.2 History of Kubernetes

  • 2014: Google released Kubernetes as open source based on their internal Borg system experience
  • 2015: Version 1.0 released, donated to Cloud Native Computing Foundation (CNCF)
  • 2018: Became CNCF's first "graduated" project
  • Present: Established as the de facto standard for container orchestration

1.3 Features Provided by Kubernetes

  • Service Discovery and Load Balancing: Exposes containers via DNS names or IP addresses and distributes traffic
  • Storage Orchestration: Automatically mounts local storage, cloud storage, etc.
  • Automated Rollouts and Rollbacks: Gradually deploys application changes and rolls back when issues occur
  • Automatic Bin Packing: Optimally places containers on nodes based on resource requirements
  • Self-healing: Restarts failed containers and replaces unresponsive ones
  • Secret and Configuration Management: Securely stores and manages sensitive information

2. Why is Kubernetes Needed?

2.1 Why Docker Alone is Not Enough

Docker alone is sufficient when running a few containers on a single server. However, real production environments have the following requirements:

  • Distribute hundreds of containers across multiple servers
  • Automatically scale container count when traffic increases
  • Auto-recover from container failures
  • Zero-downtime deployments (Rolling Update, Blue-Green, Canary)
  • Manage networking and storage between containers
  • Resource monitoring and logging

2.2 The Need for Container Orchestration

Container orchestration refers to automating the deployment, management, scaling, and networking of containers. Just as an orchestra conductor coordinates various instruments, a container orchestrator coordinates numerous containers.

Manual Management Problems Orchestration Solutions
Manual recovery required on server failure Automatic failure detection and recovery
Manual scaling on traffic increase Auto scaling (HPA, VPA)
Downtime during deployment Zero-downtime rolling updates
Difficulty optimizing container placement Automatic scheduling and bin packing
Complex inter-service communication Service discovery and load balancing

2.3 Kubernetes vs Other Orchestration Tools

  • Docker Swarm: Docker-native orchestration, simple but limited features
  • Apache Mesos: General-purpose cluster management tool with steep learning curve
  • Nomad: HashiCorp's lightweight orchestration tool
  • Kubernetes: Most features, largest ecosystem, de facto standard

3. Kubernetes Architecture

A Kubernetes cluster consists mainly of the Control Plane and Worker Nodes.

3.1 Control Plane (Master Node)

The Control Plane acts as the "brain" of the cluster. It manages the cluster state and schedules workloads to run on worker nodes.

3.1.1 API Server (kube-apiserver)

The center of all Kubernetes communication. kubectl commands, other components, and external clients all interact with the cluster through the API Server.

  • Provides RESTful API
  • Handles authentication and authorization
  • Validates requests
  • The only communication channel with etcd

3.1.2 etcd

A distributed key-value store that stores all cluster state data.

  • Stores cluster configuration, state, and metadata
  • Usually configured with 3 or 5 instances for high availability
  • Uses Raft consensus algorithm
  • Cluster backup = etcd backup

3.1.3 Scheduler (kube-scheduler)

Decides which node newly created Pods should be placed on.

  • Considers resource requirements (CPU, memory)
  • Checks available node resources
  • Applies affinity/anti-affinity rules
  • Handles taints and tolerations

3.1.4 Controller Manager (kube-controller-manager)

Runs various controllers that maintain the cluster's desired state.

  • Node Controller: Monitors node status
  • Replication Controller: Maintains Pod count
  • Endpoints Controller: Connects services and Pods
  • Service Account Controller: Creates accounts and tokens

3.1.5 Cloud Controller Manager (Optional)

Manages cloud-specific features by integrating with cloud provider APIs.

  • Load balancer provisioning
  • Storage volume management
  • Node management (cloud instances)

3.2 Worker Node

Worker Nodes are servers where actual application containers run.

3.2.1 kubelet

An agent running on each node that manages Pod lifecycle.

  • Receives Pod specifications (PodSpec) from API Server
  • Requests container creation/deletion from container runtime
  • Monitors and reports container status
  • Reports node status to API Server

3.2.2 kube-proxy

Performs network proxy functions on each node.

  • Maps Service virtual IPs to actual Pod IPs
  • Manages iptables or IPVS rules
  • Routes internal and external cluster traffic
  • Load balancing (round-robin)

3.2.3 Container Runtime

Software that actually runs containers.

  • containerd: Industry-standard runtime separated from Docker
  • CRI-O: Lightweight Kubernetes-dedicated runtime
  • Docker Engine: Direct support discontinued from Kubernetes 1.24 (dockershim removed)

3.3 Architecture Diagram

+------------------------------------------------------------------+
|                       CONTROL PLANE                               |
|  +-------------+  +-------------+  +-------------+               |
|  | API Server  |  |  Scheduler  |  | Controller  |               |
|  |             |  |             |  |  Manager    |               |
|  +------+------+  +-------------+  +-------------+               |
|         |                                                         |
|  +------+------+                                                 |
|  |    etcd     |                                                 |
|  | (Key-Value) |                                                 |
|  +-------------+                                                 |
+------------------------------------------------------------------+
                              |
                              | (API Communication)
                              |
+------------------------------------------------------------------+
|                       WORKER NODE 1                               |
|  +-------------+  +-------------+  +-------------+               |
|  |   kubelet   |  |  kube-proxy |  |  Container  |               |
|  |             |  |             |  |   Runtime   |               |
|  +-------------+  +-------------+  +-------------+               |
|  +---------+ +---------+ +---------+                             |
|  |  Pod 1  | |  Pod 2  | |  Pod 3  |                             |
|  +---------+ +---------+ +---------+                             |
+------------------------------------------------------------------+

4. Kubernetes Core Objects

4.1 Pod

A Pod is the smallest deployable unit that can be created and managed in Kubernetes.

Pod Characteristics:

  • Contains one or more containers
  • Containers in the same Pod share network and storage
  • Containers in the same Pod communicate via localhost
  • Typically one main container + auxiliary containers (Sidecar)
  • Pods are ephemeral - can be deleted and recreated at any time
# pod-example.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.24
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

4.2 Service

A Service provides a stable network endpoint for a set of Pods. Pod IPs can change, but the Service IP (ClusterIP) remains fixed.

Service Types:

  • ClusterIP (default): Accessible only within the cluster
  • NodePort: Allows external access through specific ports on each node
  • LoadBalancer: External access through cloud load balancer
  • ExternalName: Maps external DNS names to cluster internal
# service-example.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx    # Route traffic to Pods with this label
  ports:
  - protocol: TCP
    port: 80        # Service port
    targetPort: 80  # Pod container port
  type: ClusterIP

4.3 Deployment

A Deployment provides declarative updates for Pods. Define the desired state, and the Deployment Controller makes the actual state match it.

Deployment Features:

  • Manages Pod count (replicas)
  • Rolling updates and rollbacks
  • Scaling (manual/automatic)
  • Pod template management
# deployment-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3    # Maintain 3 Pods
  selector:
    matchLabels:
      app: nginx
  template:      # Pod template
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Additional Pods to create during rolling update
      maxUnavailable: 0  # Unavailable Pod count during rolling update

4.4 Namespace

A Namespace is a virtual cluster that logically separates the cluster.

Default Namespaces:

  • default: Default namespace for resources created without specification
  • kube-system: For Kubernetes system components
  • kube-public: Public resources readable by all users
  • kube-node-lease: Stores node heartbeat information
# namespace-example.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: dev
---
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: prod

Namespace Use Cases:

  • Environment separation (dev, staging, production)
  • Team-based resource separation
  • Apply ResourceQuota
  • Apply NetworkPolicy

5. kubectl Basics

kubectl is the command-line tool for interacting with Kubernetes clusters.

5.1 Installing kubectl

# macOS (Homebrew)
brew install kubectl

# Windows (Chocolatey)
choco install kubernetes-cli

# Linux (curl)
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

5.2 Basic Command Structure

kubectl [command] [TYPE] [NAME] [flags]

# Examples
kubectl get pods                    # List all Pods
kubectl get pod nginx-pod           # Get specific Pod
kubectl get pods -n kube-system     # List Pods in kube-system namespace
kubectl get pods -o wide            # Detailed information
kubectl get pods -o yaml            # Output in YAML format

5.3 Frequently Used Commands

Resource Listing (get)

# List Pods
kubectl get pods
kubectl get pods -A                 # All namespaces

# List Services
kubectl get services
kubectl get svc                     # Abbreviation

# List Deployments
kubectl get deployments
kubectl get deploy                  # Abbreviation

# List multiple resources
kubectl get pods,services,deployments

# Filter by label
kubectl get pods -l app=nginx

# List all resources
kubectl get all

Resource Details (describe)

# Pod details
kubectl describe pod nginx-pod

# Node details
kubectl describe node node-1

# Service details
kubectl describe service nginx-service

Resource Creation (create, apply)

# Create resource from YAML file
kubectl apply -f deployment.yaml

# Apply all YAML files in directory
kubectl apply -f ./manifests/

# Create resource imperatively
kubectl create deployment nginx --image=nginx:1.24
kubectl create namespace my-namespace

# Dry-run (test without actual creation)
kubectl apply -f deployment.yaml --dry-run=client

Resource Modification (edit, patch, scale)

# Edit resource directly (opens editor)
kubectl edit deployment nginx-deployment

# Partial modification with patch
kubectl patch deployment nginx-deployment -p '{"spec":{"replicas":5}}'

# Scale adjustment
kubectl scale deployment nginx-deployment --replicas=5

Resource Deletion (delete)

# Delete specific resource
kubectl delete pod nginx-pod
kubectl delete deployment nginx-deployment

# Delete resources defined in YAML file
kubectl delete -f deployment.yaml

# Delete by label
kubectl delete pods -l app=nginx

# Delete namespace and all its resources
kubectl delete namespace development

Logs and Debugging

# View Pod logs
kubectl logs nginx-pod
kubectl logs nginx-pod -f           # Real-time log streaming
kubectl logs nginx-pod --previous   # Previous container logs

# View specific container logs in multi-container Pod
kubectl logs nginx-pod -c sidecar

# Execute command inside Pod
kubectl exec nginx-pod -- ls /usr/share/nginx/html
kubectl exec -it nginx-pod -- /bin/bash  # Interactive shell

# Port forwarding (access Pod locally)
kubectl port-forward pod/nginx-pod 8080:80
kubectl port-forward service/nginx-service 8080:80

5.4 Context and Namespace Management

# Check current context
kubectl config current-context

# List available contexts
kubectl config get-contexts

# Switch context
kubectl config use-context my-cluster

# Change default namespace
kubectl config set-context --current --namespace=development

5.5 Useful kubectl Plugins and Tools

# kubectx - Quick context switching
brew install kubectx
kubectx                  # List and switch contexts
kubens                   # List and switch namespaces

# k9s - Terminal UI
brew install k9s
k9s

# kubectl auto-completion (bash)
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

# kubectl alias setup
alias k='kubectl'
alias kgp='kubectl get pods'
alias kgs='kubectl get services'

6. Hands-on: Deploying Your First Application

6.1 Setting Up Local Kubernetes Environment

# Enable Kubernetes in Docker Desktop
# Settings > Kubernetes > Enable Kubernetes

# Or use Minikube
brew install minikube
minikube start

# Check cluster status
kubectl cluster-info
kubectl get nodes

6.2 Deploying Nginx

# 1. Create Deployment
kubectl create deployment nginx-demo --image=nginx:1.24

# 2. Verify Deployment
kubectl get deployments
kubectl get pods

# 3. Create Service (NodePort type)
kubectl expose deployment nginx-demo --type=NodePort --port=80

# 4. Verify Service
kubectl get services

# 5. Test access (Minikube)
minikube service nginx-demo

# 6. Or port forwarding
kubectl port-forward service/nginx-demo 8080:80
# Access http://localhost:8080 in browser

6.3 Scaling Test

# Scale up Pod count
kubectl scale deployment nginx-demo --replicas=5

# Verify Pods
kubectl get pods -o wide

# Scale down Pod count
kubectl scale deployment nginx-demo --replicas=2

6.4 Rolling Update

# Update image
kubectl set image deployment/nginx-demo nginx=nginx:1.25

# Check rollout status
kubectl rollout status deployment/nginx-demo

# View rollout history
kubectl rollout history deployment/nginx-demo

# Rollback
kubectl rollout undo deployment/nginx-demo

6.5 Cleanup

# Delete resources
kubectl delete deployment nginx-demo
kubectl delete service nginx-demo

# Or all at once
kubectl delete deployment,service nginx-demo

7. Kubernetes Learning Resources

7.1 Official Documentation

  • Kubernetes Official Docs: https://kubernetes.io/docs/
  • Kubernetes Tutorials: https://kubernetes.io/docs/tutorials/
  • kubectl Cheat Sheet: https://kubernetes.io/docs/reference/kubectl/cheatsheet/

7.2 Local Learning Environments

  • Minikube: Local Kubernetes cluster
  • Kind (Kubernetes in Docker): Run cluster in Docker containers
  • Docker Desktop: Built-in Kubernetes support
  • k3s: Lightweight Kubernetes distribution

7.3 Online Practice Environments

  • Katacoda: Browser-based Kubernetes practice
  • Play with Kubernetes: Free online Kubernetes environment

Conclusion

In this Part 6, we explored the fundamental concepts and architecture of Kubernetes. Key takeaways include:

  • What is Kubernetes: The de facto standard platform for container orchestration
  • Architecture: Composed of Control Plane (API Server, etcd, Scheduler, Controller Manager) and Worker Nodes (kubelet, kube-proxy, Container Runtime)
  • Core Objects: Pod (smallest deployment unit), Service (network endpoint), Deployment (declarative Pod management), Namespace (logical separation)
  • kubectl: CLI tool for interacting with Kubernetes clusters

Kubernetes may seem complex at first, but understanding its design philosophy of "declarative configuration" and "desired state" reveals it to be a very powerful and flexible tool.

In the next part, we'll cover Kubernetes Installation and Cluster Configuration. We'll explore setup methods from Minikube and Kind for local development to cloud-managed services like EKS, GKE, and AKS, as well as cluster bootstrapping with kubeadm.