Kubernetes Overview and Key Benefits

Kubernetes as an Orchestration Tool

• Designed to manage complex applications composed of multiple containers

• Core capabilities:

  • High Availability

  • Scalability

  • Disaster Recovery

---

High Availability and Scalability

Core Infrastructure Setup

• Example cluster:

  • Two worker nodes (Server 1 and Server 2)

  • Each node hosts:

    • Replica of the application

    • Database instance

  • Ingress components on each node for handling incoming traffic

Request Handling Flow

• Incoming user request:

  • Received by Ingress (replicated on each node for load balancing)

  • Forwarded to a Service component

    • Service acts as a load balancer

    • Directs request to appropriate Pod (application replica)

• If database interaction is needed:

  • Application makes a request to Database Service

  • Database Service (also load balanced) routes to a database replica

Characteristics of the Setup

• End-to-end load balancing and replication:

  • Ingress → Service → Application Pods → Database Service → Database Pods

• No single point of failure:

  • Failure of one component doesn't halt request processing

• Example:

  • If Server 2 fails, replicas on Server 1 handle traffic

  • Controller Manager schedules new replicas on a third server (e.g., Server 3)

Requirements

• Application must be designed to support:

  • Stateless behavior

  • Horizontal scaling

  • Replication-aware data access

---

Kubernetes Self-Healing and Master Components

Controller Manager

• Continuously monitors cluster state

• Detects failed Pods

• Automatically restarts or reassigns them to other nodes

etcd Store

• Distributed key-value store that holds cluster state:

  • Pod status

  • Node resources

  • Configuration data

• Enables cluster awareness and recovery

• Example process:

  • Pod fails → etcd is updated → Controller Manager schedules a new Pod → etcd updates again

---

Disaster Recovery

etcd Snapshots

• Essential for restoring cluster state

• Stored as snapshots in remote storage

  • Can be outside the cluster (e.g., separate server or cloud)

• Not automatically managed by Kubernetes

  • Responsibility lies with the Kubernetes Administrator

Application Data Storage

• Application data not stored in etcd

• Stored in remote volumes or object storage

  • Accessed by Pods through persistent volumes

Cluster Recovery

• Possible to recreate the full cluster on new infrastructure using:

  • etcd snapshots

  • Application data backups

Backup Cluster Strategy

• To avoid downtime:

  • Maintain a "hot standby" cluster

  • Automatically take over if the primary cluster fails

---

Comparison with Alternative Setups (e.g., AWS-native)

Achievable Without Kubernetes

• Load balancing and replication can be configured manually:

  • AWS EC2 + Load Balancer

• Kubernetes advantages:

  • Easier replication:

    • Specify number of replicas in configuration

  • Built-in self-healing:

    • Detects and restarts failed Pods

  • Smart scheduling:

    • Automatically places new Pods on optimal nodes

    • Based on resource availability