Kubernetes: Auto-Healing and Container Management

• Kubernetes is an essential technology in DevOps, appearing in most job descriptions.
• It's considered the future of DevOps, especially with the rise of microservices.
• Prior container and Docker knowledge is often needed before learning Kubernetes.
• Docker is a container platform that simplifies container interaction using its engine and CLI.
• Kubernetes serves as a container orchestration platform.

Ephemeral Nature of Containers

• Containers can die and revive due to resource constraints.
• Running multiple containers on a single host can cause issues if one consumes excessive resources.
• A container using too much memory can lead to failures in other containers on the same host.
• Docker's single-host nature can create resource contention problems.

Auto-Healing

• Auto-healing is the automatic restart of failed containers without manual intervention.
• Standard Docker lacks built-in auto-healing.
• DevOps engineers need Auto-healing because manually monitoring all containers is not practical.

Auto-Scaling

• Auto-scaling automatically adjusts the number of container instances based on demand.
• Container resources are limited by the host's capacity (e.g., 4 CPU, 4 GB RAM).
• Unexpected user increases can overwhelm containers.
• Auto scaling is useful for use-cases such as during peak seasons like holidays.
• Auto scaling is useful for use-cases such as film viewing on Netflix.
• Auto scaling is a needed feature to handle increasing loads on applications.
• When the load increases, the number of containers needs to increase to manage it.
• The increase can be done manually or automatically.
• Docker doesn't inherently support auto scaling.
• Load balancing is crucial when scaling container counts by distributing the load equally across multiple containers.

Docker's Limitations

• Docker relies on a single host, such as one EC2 instance.
• Containers lack auto-healing capabilities, requiring manual tracking.
• Docker is a minimalistic platform missing enterprise-level application requirements by default, which is why it needs Kubernetes
• Docker doesn't provide enterprise-level support by default.

Enterprise-Level Standards

• Features essential for enterprise applications include load balancers, firewalls, auto-scaling, auto-healing, and API gateways.

Kubernetes Solutions to Docker Problems

• Kubernetes solves Docker's limitations related to single host, lack of auto-scaling and auto-healing, and absence of enterprise-level support.
• Kubernetes is a cluster, of nodes, and is generally installed in a master node architecture for production,
• Architecture allowing Kubernetes to move pods/applications to different nodes if one node is faulty.
• Kubernetes employs replica sets for auto-scaling and supports Horizontal Pod Autoscaler (HPA) for automatic scaling based on load thresholds.
• The number of replicas can be increased manually by editing a YAML file.
• HPA spins up more containers when the load reaches a specified threshold.

Kubernetes Auto Healing Feature

• Kubernetes has an auto-healing feature that controls and fixes damages.
• When a container goes down, Kubernetes starts a new container to control the damage.
• Kubernetes uses an API server that detects when a container is going down, rolling out a new container preemptively.
• Replacement of failing containers is thus made seamless to the end user by Kubernetes.

Kubernetes and Enterprise-Level Nature

• Kubernetes addresses Docker's lack of enterprise nature.
• Kubernetes originated from Google, where they used a tool called Borg, which is an enterprise-level container orchestration platform.
• Docker is just a container platform without all the enterprise support capabilities.
• Docker is suitable for personal laptops or EC2 instances.
• Kubernetes is aiming to solve the problem of Enterprise-level support.
• Kubernetes is evolving and has the support of the Cloud Native Computing Foundation (CNCF).
• CNCF has projects like podman, build packs, and Prometheus; the community focuses on developing tools around Kubernetes.
• Kubernetes is extensible to any level via custom resources and definitions.
• Custom resources and custom resource definitions introduced Ingress controllers.

Kubernetes Architecture Overview

• Kubernetes is easy to learn and focuses on using concepts like Pods, deployments, and services.
• Kubernetes offers advantages over Docker: cluster behavior, auto-healing, auto-scaling, and enterprise-level support with advanced load balancing, security, and networking.
• Kubernetes architecture includes a control plane (master node) and a data plane (worker nodes).
• A Pod is the smallest unit in Kubernetes, similar to a container in Docker.

Docker Container Creation

• Running a container in Docker requires a container runtime component called Docker shim.

Kubernetes Pod Deployment

• Kubernetes deployments consist of a master node (control plane) and worker nodes (data plane).
• User requests go through the master node or control plane.
• The smallest deployment unit is a Pod, a wrapper over a container.
• Within a worker node, the kubelet runs and maintains the Pod.

Kubernetes Components in Worker Node

• Along with the kubelet, a container runtime is necessary, supporting Docker shim, containerd, and CRI-O.
• These container runtimes must implement the Kubernetes Container Runtime Interface (CRI) standard.
• Kubelet keeps the Pod running and informs the control plane of issues.
• Kube-proxy provides networking, including IP address allocation and load balancing.
• When a Pod scales to multiple replicas, kube-proxy manages traffic distribution.

Worker Node Components Recap

• kube-proxy: Networking, IP addresses, and load balancing (using IP tables).
• kubelet: Pod creation and maintenance, ensuring the Pod is in a running state.
• Container Runtime: Executes the containers within the Pod.

Kubernetes Control Plane

• The control plane or master components are necessary for enterprise-level features and instructions.
• Kubernetes provides cluster behavior, including pod placement decisions.
• The API server is the core component, handling incoming requests and acting as the entrypoint of Kubernetes.
• The scheduler schedules Pods or resources on the Kubernetes cluster.

Kubernetes Components

• etcd is a key-value store that serves as a backup by storing all cluster information as key-value pairs.
• Without etcd, cluster information will disappear.

Controller Managers

• Kubernetes supports auto-scaling using controllers.
• Replica sets maintain the state of Kubernetes pods, ensuring the specified number of pods are running.
• Example: a replica set controller ensures that two pods are always running if specified in the Kubernetes YAML file.
• The controller manager ensures that controllers like replica sets are always running.

Cloud Controller Manager (CCM)

• Kubernetes can be run on cloud platforms like EKS, AKS, or GKE.
• Cloud controller manager translates user requests for creating resources like load balancers or storage into API requests that the cloud provider understands.
• Cloud controller manager bridges the gap between Kubernetes and the underlying cloud provider.
• The logic for new cloud provider can implement its cloud provider inside the Cloud controller manager and contribute to the open-source repository.
• Cloud controller manager is not required when running Kubernetes on-premise.

Kubernetes Architecture

• Kubernetes has two main parts: the control plane and the data plane.
• Worker nodes contain the Kubernetes data plane components: kubelet, kube-proxy, and container runtime.
• Container runtime may not always be explicitly mentioned in documentation but is essential.
• The Kubernetes master (control plane) includes:
  • API server: The heart of Kubernetes that receives every request.
  • Scheduler: Schedules resources onto worker nodes.
  • etcd: The key-value store that stores all cluster information.
  • Controller manager: Manages the built-in Kubernetes controllers.
  • Cloud controller manager.

Practical Kubernetes: MiniKube Installation

• MiniKube, k3s is a lightweight kubernetes cluster for local development.
• Minicube documentation can be found at minicube.sigs.k8s.io
• Prerequisites for MiniKube:
  • 2 CPUs.
  • 2GB of free RAM.
  • 20GB of free hard disk space.
  • Internet connection.
  • Hypervisor.
• Steps to use mini kube:
  • Go to the official documentation page to download mini kube
  • Download kubectl
  • Execute the mini kube start command to start the cluster for you
• CubeCTL (Kubernetes command line tool) interacts with the Kubernetes cluster.
• CubeCTL can be installed from kubernetes.io
• There are other instructions for how you can operate with your mini kube cluster like pause, unpause, create multiple clusters, etc
• Mini Cube supports add-ons like Ingress controller operator lifecycle manager
• Use the command minicube to see all available options