Chuyển đến nội dung chính

LESSON 1: INTRODUCTION TO KUBERNETES AND CONTAINER ORCHESTRATION

The first lesson introduces Container Orchestration and Kubernetes - the foundation for understanding why K8s has become the industry standard. Learn the history, basic architecture, and comparisons with similar technologies.

🔒 DevSecOps — Lesson 1 LESSON 1: INTRODUCTION TO KUBERNETES AND CONTAINER ORCHESTRATION

KUBERNETES: FROM BASIC TO ADVANCED

Module 1: Introduction & Kubernetes Architecture

xdev.asia

🎯 LESSON OBJECTIVE_

After completing this lesson, you will:

  • ✅ Understand what Container Orchestration is and why it is needed_
  • ✅ Understand the role and The importance of Kubernetes
  • ✅ Compare Kubernetes with other tools
  • ✅ Understand the overall architecture of Kubernetes
  • ✅ Know about the Kubernetes ecosystem and its community co

PART 1: WHAT IS CONTAINER ORCHESTRATION?

1.1. Problem with Containers when Scale

Imagine you have a simple web application running in a Docker container:

docker run -d -p 8080:80 my-web-app

Everything worked fine... until when:

❌ Problem 1: Traffic suddenly increases

  • 1 container is not enough to handle__HTMLTAG_99___
  • Need to scale up 10, 20, 100 containers
  • How to distribute traffic?

❌ Problem 2: Container is broken crash

  • Who will detect and restart?
  • How to ensure 99.9% uptime?

❌ Problem 3: Multiple servers

  • How to deploy containers to multiple servers?
  • How to manage resources (CPU, RAM) effectively result?

❌ Problem 4: Update application

  • How to roll update downtime?
  • Rollback if there is an error?

❌ Issue 5: Service Discovery

  • Containers with dynamic IP
  • How do services find and call each other?

❌ Issue 6: Configuration Management

  • Managing secrets, configs for hundreds of containers_
  • Other dev, staging, production environments each

1.2. Container Orchestration is the solution

Container Orchestration is the automation of deployment, management, scaling, and networking of containers.

Orchestrator does What:

┌─────────────────────────────────────────────────────────┐
│         CONTAINER ORCHESTRATION PLATFORM                │
├─────────────────────────────────────────────────────────┤
│  ✓ Scheduling         - Chọn node phù hợp cho container│
│  ✓ Scaling            - Auto scale up/down              │
│  ✓ Self-healing       - Restart containers failed       │
│  ✓ Load Balancing     - Phân phối traffic đều          │
│  ✓ Service Discovery  - Tìm và kết nối services        │
│  ✓ Rolling Updates    - Update không downtime           │
│  ✓ Rollback           - Quay lại version cũ             │
│  ✓ Secret Management  - Quản lý credentials an toàn    │
│  ✓ Resource Management- Tối ưu CPU, RAM, Storage        │
└─────────────────────────────────────────────────────────┘

1.3. Real life example_

Before Orchestration:

# Trên server 1
ssh server1
docker run -d app:v1
docker run -d app:v1
docker run -d app:v1

Trên server 2

ssh server2 docker run -d app:v1 docker run -d app:v1

Manual monitoring

while true; do docker ps | grep app

Nếu container die -> manual restart

done

With Container Orchestration:

# Khai báo mong muốn
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5  # Muốn 5 containers
template:
spec:
containers:
- name: app
image: app:v1

AutomaticOrchestrator:

  • Deploy 5 containers to different servers_
  • Monitor and restart if crash
  • Load balance traffic
  • Scale when needed

PART 2: WHY NEED KUBERNETES?

2.1. Background

Google's Borg (2003-2015)

  • Google runs billions of containers every day week
  • Borg: internal system to manage containers
  • 15+ years of experience operating large-scale systems

Kubernetes was born (2014)

  • Google open-source Kubernetes (K8s)
  • Based on experience from Borg and Omega_
  • Designed for cloud-native applications
  • Donate for CNCF (Cloud Native Computing Foundation)

2.2. Why does Kubernetes prevail?

1. Production-Proven

Google → 15+ năm kinh nghiệm
↓
Kubernetes → Battle-tested tại Google
↓
Cộng đồng → Hàng nghìn companies đóng góp

2. Vendor Agnostic

  • Runs everywhere: on-premise, cloud, hybrid_
  • Not locked-in with 1 cloud provider_
  • Portable between AWS, GCP, Azure, bare metal_

3. Extensible and Flexible

  • Plugin architecture_
  • Custom Resource Definitions (CRDs)
  • Operator pattern
  • Rich ecosystem

4. Large Community_

  • 100,000+ contributors
  • Millions of users
  • Mature tooling and documentation
  • Active development

5. Industry Standard

CNCF Graduated Project
↓
Được tích hợp bởi:

  • AWS (EKS)
  • Google (GKE)
  • Azure (AKS)
  • IBM (IKS)
  • DigitalOcean
  • và nhiều vendor khác

2.3. Impressive number

📊 Kubernetes Adoption (2024)

  • 96% of organizations are using or reviewing K8s
  • 5.6 million developers use K8s
  • Top 2 most wanted platform (Stack Overflow)
  • 89% of containers run on K8s

🚀 Use Cases

  • Microservices architecture
  • CI/CD pipelines
  • Machine Learning workloads
  • Big Data processing_
  • Hybrid/Multi-cloud deployments_

PART 3: COMPARING KUBERNETES WITH OTHER TOOLS_

3.1. Kubernetes vs Docker Swarm

Criteria__HTMLTAG_310___ Kubernetes Docker Swarm
Complexity High, many concepts__HTMLTAG_324___ Simple, easy to learn
Setup More complex Very simple__HTMLTAG_336___
Scalability Very good (1000+ nodes) Good (100+ nodes)
Ecosystem Very wide Restrictions
Auto-scaling Native HPA, VPA Limited
Load Balancing_ Advanced (Ingress) Basic
Community Huge Much smaller
Enterprise Support All cloud providers Limited
Learning Curve Steep Gentle
Production Ready Yes Yes (but rarely used)

Conclusion: Docker Swarm is easier but K8s is more powerful and is the industry standard.

3.2. Kubernetes vs Apache Mesos

Criteria Kubernetes Apache Mesos
Focus Container orchestration__HTMLTAG_446___ General purpose cluster manager
Architecture Monolithic Two-level (Mesos + Marathon)
Adoption Very high Average
Use Cases Containers,microservices Containers, Big Data, analytics
Complexity High Very high
Container Support Native Via Marathon/DC/OS

Conclusion: Mesos is more flexible but more complex. K8s focuses on containers.

3.3. Kubernetes vs Nomad

Criteria Kubernetes HashiCorp Nomad
Simplicity Complex Simple
Workload Types Containers Containers, VMs, binaries
Ecosystem Huge Growing
Multi-cloud Excellent Excellent
Adoption Very high Moderate
HashiCorp Integration Limited Native (Vault, Consul)

Conclusion:Nomad is simpler and has more diverse workloads, but the ecosystem is smaller.

3.4. When to use what?

Choose Kubernetes when:

  • ✅ Important production workloads_
  • ✅ Need to scale large (100+ services)
  • ✅ Team with DevOps experience
  • ✅ Need rich ecosystem
  • ✅ Multi-cloud strategy

Choose Docker Swarm when:

  • ✅ Small team, single project simple
  • ✅ Need to deploy quickly
  • ✅ Familiar with Docker CLI
  • ✅ No need to scale too much large

Choose Nomad when:

  • ✅ Diverse Workloads (not just containers)
  • ✅ Used HashiCorp stack
  • ✅ Need simplicity
  • ✅ Edge computing_

PART 4: KUBERNETES ARCHITECTURE OVERVIEW_

4.1. Kubernetes Cluster

┌────────────────────────────────────────────────────────────┐
│                    KUBERNETES CLUSTER                      │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  ┌──────────────────────┐      ┌────────────────────────┐│
│  │   CONTROL PLANE      │      │      WORKER NODES      ││
│  │   (Master Nodes)     │      │                        ││
│  │                      │      │  ┌──────────────────┐  ││
│  │  ┌────────────────┐ │      │  │  Node 1          │  ││
│  │  │  API Server    │ │◄────►│  │  - kubelet       │  ││
│  │  └────────────────┘ │      │  │  - kube-proxy    │  ││
│  │                      │      │  │  - Container     │  ││
│  │  ┌────────────────┐ │      │  │    Runtime       │  ││
│  │  │  etcd          │ │      │  │  - Pods          │  ││
│  │  │  (Database)    │ │      │  └──────────────────┘  ││
│  │  └────────────────┘ │      │                        ││
│  │                      │      │  ┌──────────────────┐  ││
│  │  ┌────────────────┐ │      │  │  Node 2          │  ││
│  │  │  Scheduler     │ │      │  │  - kubelet       │  ││
│  │  └────────────────┘ │      │  │  - kube-proxy    │  ││
│  │                      │      │  │  - Container     │  ││
│  │  ┌────────────────┐ │      │  │    Runtime       │  ││
│  │  │  Controller    │ │      │  │  - Pods          │  ││
│  │  │  Manager       │ │      │  └──────────────────┘  ││
│  │  └────────────────┘ │      │                        ││
│  └──────────────────────┘      │  ┌──────────────────┐  ││
│                                 │  │  Node N          │  ││
│                                 │  │  ...             │  ││
│                                 │  └──────────────────┘  ││
│                                 └────────────────────────┘│
└────────────────────────────────────────────────────────────┘

4.2. Control Plane Components (Master)

1. API Server 🚪

  • Kubernetes' "Gateway"_
  • Handle all REST requests_
  • Authentication & Authorization_
  • Validate and process requests
  • Frontend for etcd_
kubectl → API Server → etcd
  ↑          ↓
  └──── Response

2. etcd 💾

  • Key-value database
  • Storing the entire cluster state_
  • Source of truth
  • Highly available (HA setup)
  • Only API Server talks to etcd_

3. Scheduler 📅

  • Decide which Node the Pod runs on
  • Consider: resources, constraints, affinity_
  • Do not deploy (kubelet) do)
Flow:
1. User tạo Pod
2. Scheduler xem Pods chưa assign
3. Chọn Node tốt nhất
4. Update Pod spec với nodeName

4. Controller Manager 🎮

  • Run multiple controllers_
  • _Monitor cluster state_
  • Make changes to achieve desired state

Important controllers:

  • Node Controller: Monitor nodes health
  • Replication Controller: Make sure Pods number is correct
  • Endpoints Controller: Populate Endpoints objects
  • ServiceAccount Controller: Create default ServiceAccounts_

4.3. Worker Node Components

1. kubelet 👷_

  • Agent runs on each node_
  • Get Pod specs from API Server_
  • Ensure containers are running run_
  • Report node/pod status to API Server
  • _Execute liveness/readiness probes_

2. kube-proxy_ 🔀_

  • Network proxy per node_
  • Maintain network rules_
  • Implement Kubernetes Service abstraction
  • Load balancing for Services
  • Modes: iptables, IPVS, userspace_

3. Container Runtime 🐳

  • Software running containers
  • _Implement Kubernetes CRI (Container Runtime Interface)
  • Popular:
    • containerd (recommended)
    • CRI-O
    • Docker (deprecated in K8s 1.24+)

4.4. Add-ons (Optional but Important)

DNS (CoreDNS)

  • Service discovery
  • Resolve service names to IPs
  • Each Service has a DNS name

Dashboard

  • Web UI to cluster management_
  • Visualize resources

Monitoring_ (Metrics Server)_

  • Collect resource metrics
  • CPU, Memory usage_
  • Enable HPA (Horizontal Pod Autoscaler)

Logging

  • EFK Stack (Elasticsearch, Fluentd, Kibana)
  • Centralized logging

PART 5: KUBERNETES ECOSYSTEM

5.1. CNCF Landscape

Kubernetes is part of the CNCF ecosystem:

┌─────────────────────────────────────────────┐
│         CNCF CLOUD NATIVE LANDSCAPE         │
├─────────────────────────────────────────────┤
│  Container Orchestration                    │
│  └─ Kubernetes ⭐                           │
│                                             │
│  Container Runtime                          │
│  └─ containerd, CRI-O                      │
│                                             │
│  Service Mesh                               │
│  └─ Istio, Linkerd, Consul                 │
│                                             │
│  Monitoring                                 │
│  └─ Prometheus, Grafana                    │
│                                             │
│  Logging                                    │
│  └─ Fluentd, Loki                          │
│                                             │
│  CI/CD                                      │
│  └─ Argo, Flux, Tekton                     │
│                                             │
│  Security                                   │
│  └─ Falco, OPA, Trivy                      │
└─────────────────────────────────────────────┘

5.2. Core Tools

Package Management

  • Helm: Package manager for K8s
  • Kustomize: Configuration management

GitOps

  • ArgoCD_: Declarative GitOps CD
  • Flux: GitOps toolkit_

Service Mesh

  • Istio: Complete service mesh_
  • _Linkerd: Simple, lightweight

Monitoring & Observability_

  • Prometheus_: Metrics collection
  • Grafana: Visualization
  • Jaeger: Distributed tracing

Security

  • Falco_: Runtime security
  • OPA: Policy engine
  • Trivy: Vulnerability scanner

5.3. Managed Kubernetes Services

Major Cloud Providers:

  • _AWS: EKS (Elastic Kubernetes Service)
  • Google Cloud: GKE (Google Kubernetes Engine)
  • Azure: AKS (Azure Kubernetes Service)
  • IBM Cloud: IKS
  • DigitalOcean: DOKS
  • Linode: LKE

Loi Useful:_

  • Control plane managed
  • Automatic upgrades_
  • Integrated with cloud services
  • Easy setup_
  • Cost: only paid worker nodes_

PART 6: KUBERNETES CONCEPTS OFFICER REPORT

6.1. Declarative vs Imperative

Imperative (Old way):

# Nói K8s phải làm GÌ và NHƯ THẾ NÀO
kubectl run nginx --image=nginx
kubectl expose deployment nginx --port=80
kubectl scale deployment nginx --replicas=3

Declarative (How K8s):

# Nói K8s muốn KẾT QUẢ gì
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
kubectl apply -f nginx.yaml

Why Declarative is better:

  • ✅ Infrastructure as Code
  • ✅ Version control friendly
  • ✅ Idempotent (run multiple times = same result)
  • ✅ Self-healing
  • ✅ Easy rollback

6.2. Desired State vs Current State

┌──────────────────────────────────────────────┐
│  KUBERNETES RECONCILIATION LOOP              │
├──────────────────────────────────────────────┤
│                                              │
│  ┌────────────────┐      ┌────────────────┐│
│  │ DESIRED STATE  │      │ CURRENT STATE  ││
│  │                │      │                ││
│  │ replicas: 3    │  VS  │ replicas: 2    ││
│  │ image: v2      │      │ image: v1      ││
│  └────────────────┘      └────────────────┘│
│          │                       │          │
│          └───────────┬───────────┘          │
│                      ↓                      │
│            ┌──────────────────┐             │
│            │   CONTROLLER     │             │
│            │   Takes Action   │             │
│            └──────────────────┘             │
│                      ↓                      │
│            ┌──────────────────┐             │
│            │  Start 1 Pod     │             │
│            │  Update 2 Pods   │             │
│            └──────────────────┘             │
└──────────────────────────────────────────────┘

Controllers persistent:

  1. Watch current state
  2. Compare with desired state
  3. Take actions to match
  4. Repeat (reconciliation loop)

6.3. Labels and Selectors

Labels = Key-value pairs to organize objects_

metadata:
  labels:
    app: nginx
    tier: frontend
    environment: production
    version: v1.0

Selectors_ = Query to find objects_

selector:
  matchLabels:
    app: nginx
    tier: frontend

Use cases:

  • Services find Pods
  • Deployments manage Pods_
  • NetworkPolicies apply rules
  • Queries and filtering

PART 7: KUBERNETES IN ACTION - REAL EXAMPLES TE

Scenario: E-commerce Website

Requirements:

  • Frontend: React app (3 replicas)
  • Backend API: Node.js (5 replicas, auto-scale)
  • Database: PostgreSQL (1 instance, persistent)
  • Cache: Redis (3 replicas)
  • High availability
  • Zero-downtime updates
  • Auto-scaling based on traffic_

Kubernetes solves this Which:

# Frontend Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: react-app
        image: myapp/frontend:v1.0
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"

Backend API with Auto-scaling

apiVersion: apps/v1 kind: Deployment metadata: name: backend spec: replicas: 5 selector: matchLabels: app: backend template: metadata: labels: app: backend spec: containers: - name: api image: myapp/backend:v1.0 ports: - containerPort: 8080


Auto-scaler

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: backend-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: backend minReplicas: 5 maxReplicas: 20 metrics:

  • type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

Database with Persistent Storage

apiVersion: apps/v1 kind: StatefulSet metadata: name: postgres spec: serviceName: postgres replicas: 1 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:14 ports: - containerPort: 5432 volumeMounts: - name: postgres-storage mountPath: /var/lib/postgresql/data volumeClaimTemplates:

  • metadata: name: postgres-storage spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 20Gi

Load Balancer Service

apiVersion: v1 kind: Service metadata: name: frontend-lb spec: type: LoadBalancer selector: app: frontend ports:

  • port: 80 targetPort: 3000

Kubernetes automatic:

  • ✅ Deploy 3 frontend + 5 backend + 1 DB
  • ✅ Distribute across nodes
  • ✅ Restart if crash
  • ✅ Scale backend from 5→20 when traffic increase
  • ✅ Load balance requests
  • ✅ Persistent data for database
  • ✅ Rolling update no downtime_

💡 KEY TAKEAWAYS_

Important points to take remember:

  1. Container Orchestration solves the problem of scaling and managing containers_
    • Auto-scaling, self-healing, load balancing
    • Service discovery, rolling updates
  2. Kubernetes is industry standard
    • Production-proven from Google
    • Largest community
    • Vendor agnostic
  3. K8s Architecture has 2 main parts:
    • Control Plane: API Server, etcd, Scheduler, Controllers
    • Worker Nodes: kubelet, kube-proxy, Container Runtime
  4. Declarative > Imperative
    • Declares desired state
    • K8s automatically reconcile
  5. Rich Ecosystem
    • CNCF landscape
    • Tools for every need
    • Managed services available


🎯 EXERCISE

Exercise 1: Research and Compare compare

Learn and write a detailed comparison (200-300 words) between:

  • Kubernetes
  • Docker Swarm
  • Amazon ECS

Focus on: ease of use, scalability, ecosystem, cost.

Exercise 2: Mindmap

Draw a mindmap (can use tool or hand) about:

  • Kubernetes Architecture
  • Includes all components
  • Describe the role of each component

Exercise 3: Use Case Analysis

Choose an application you are working on or know:

  • Describe current architecture
  • Draw a diagram if deployed to K8s
  • List of benefits and challenge

Exercise 4: Video Learning

Watch the videos "Kubernetes in 100 seconds" and "Kubernetes Explained in 15 minutes"

  • Summary of 5 main points
  • Note points you don't understand to learn more more

📖 REFERENCES_

Articles write_

Videos_

Interactive_


⏭️ POST NEXT_

Lesson 2: Installing and Configuring Kubernetes

In the next lesson, we will:

  • Install Minikube and kubectl
  • Start the first cluster_
  • Explore Kubernetes dashboard_
  • Run basic kubectl commands_
  • Understanding kubeconfig_

Standard device:

  • Computer with at least 4GB RAM_
  • Install Docker_
  • Install VirtualBox or VMware