Day 1 - Introducing Kubernetes

Kubernetes is an open-source system for automating the deployment, scaling and management of containerized applications.
It groups containers that make up an application into logical units called pods, which can run on a cluster of nodes.
Kubernetes provides features such as service discovery, load balancing, storage orchestration, horizontal scaling, self-healing and more. Official doc for Kubernetes can be found on kubernetes_Doc

Why Kubernetes?

Kubernetes is a system that helps you manage containerized applications at scale. It solves some of the common problems that arise when you have to deploy, scale, and maintain many containers across multiple nodes or clusters. 

Some of the problems which are solved by Kubernetes are:

•  Application Availability: How to ensure that your applications and services are available 24/7, even if some containers or nodes fail or need to be updated.

•  High Availability: How to deploy code multiple times a day with no downtime, and with the ability to roll back if something goes wrong.

•  Efficiency of Resources: How to make more efficient use of cloud resources, by packing and scheduling containers according to the demand and availability of resources, and by scaling up or down as needed.

•  Automation of Configuration: How to simplify the configuration and automation of your operations, by allowing you to define your desired state through code, and by handling the tasks such as networking, service discovery, load balancing, security, and updates.

•  Traffic Distribution on Multiple Containers: In general terms for redundancy multiple containers are created to reduce traffic load on single container and these are managed by Kubernetes.

Terminology Used in Kubernetes

We can assume that Kubernetes configuration file is similar to Docker-Compose file and there are few different terminologies used in Kubernetes which are as below.

Pods: A pod in Kubernetes is the smallest deployable unit of computing that you can create and manage in Kubernetes. A pod consists of one or more containers that share the same network and storage resources and run in a shared context. A pod can also contain init containers that run before the main application containers, and ephemeral containers that can be injected for debugging purposes.

Pods are designed to run a single instance of an application or a tightly coupled group of applications. Pods are ephemeral, which means they can be terminated or deleted at any time. If a pod fails or is deleted, Kubernetes can automatically create a new replica of the pod on another node in the cluster.

Some of the benefits of using pods are:

•  They allow you to package your applications with their dependencies and configuration and run them in isolated environments.
•  They enable you to distribute your workloads across multiple nodes or clusters and improve the availability and performance of your applications.
•  They simplify the communication and coordination between your containers, by providing them with a shared network namespace and filesystem volumes.
•  They support various lifecycle events and probes that can help you monitor and manage the health and readiness of your containers.

Difference between a pod and a container?

A container is a standardized executable component that packages an application and its dependencies in a single unit. A container runs in an isolated environment on a host machine, and can use any container runtime, such as Docker. A container is designed to run a single process or application.

A pod is a collection of containers that share the same network and storage resources and run in a shared context. A pod is the smallest deployable unit of computing in Kubernetes and can contain one or more containers. A pod can also contain init containers and ephemeral containers for initialization and debugging purposes.

The main difference between a pod and a container is that a container resides inside of a pod. 

A pod is a higher-level abstraction that allows you to group and manage related containers as a single unit. 

A pod provides network and storage resources for its containers and handles the communication and coordination between them.

Worker Nodes:

Worker nodes in Kubernetes are the machines that run the containerized applications and workloads that are deployed on the cluster. It's simply like a virtual Box machine where we run our containers.

They have two main components: the kubelet and the kube-proxy.

The kubelet is an agent that runs on each worker node and communicates with the control plane. It ensures that the containers are running in a pod. The kubelet also handles the pod lifecycle events, such as creation, deletion, and health checks.

The kube-proxy is a network proxy that runs on each worker node and maintains the network rules on the node. It allows the pods to communicate with each other and with external services. The kube-proxy also performs load balancing for services with multiple pods.

Worker nodes are managed by the control plane, which consists of one or more master nodes. The control plane assigns work to the worker nodes, monitors their status, and coordinates cluster-wide operations. The control plane also exposes the Kubernetes API, which is used to interact with the cluster.

Some of the benefits of using worker nodes in Kubernetes are:

•  They allow you to scale your applications horizontally by adding or removing worker nodes as needed.

•  They enable you to distribute your workloads across multiple machines or regions and improve the availability and performance of your applications.

•  They simplify the operation and maintenance of your cluster, by abstracting away the details of the underlying infrastructure and platform.

Control Plane OR Master Node

The control plane in Kubernetes is the set of components that manages the cluster and its resources, such as worker nodes and pods. The control plane receives information about the cluster activity, internal and external requests, and the desired state of the cluster, and makes and executes decisions accordingly. The control plane also exposes the Kubernetes API, which is used to interact with the cluster.

The control plane consists of the following components:

•  The kube-apiserver, which is the interface that communicates with the other control plane components, the worker nodes, and the external systems. It exposes the Kubernetes API by sharing data via its REST endpoints.

•  The etcd, which is a distributed key-value store that stores the cluster configuration and state. It acts as the source of truth for the cluster.

•  The kube-scheduler, which is responsible for assigning pods to worker nodes based on resource availability and other constraints. It watches for new pods that have no node assigned, and selects the best node for them.

•  The kube-controller-manager, which is a collection of controllers that run control loops to maintain the desired state of the cluster. For example, it manages the replication, scaling, and updating of pods, services, endpoints, and nodes.

•  The cloud-controller-manager, which is an optional component that runs controllers that interact with the underlying cloud providers. For example, it manages the load balancers, storage volumes, and node lifecycle on the cloud platform.

The control plane components usually run on a dedicated node called the master node or primary node. In a production-quality Kubernetes cluster, the control plane can be replicated across multiple nodes for high availability and fault tolerance.

Some of the benefits of using the control plane in Kubernetes are:

•  It allows you to deploy and manage your containerized applications at scale, by abstracting away the details of the underlying infrastructure and platform.

•  It enables you to monitor and troubleshoot your cluster health and performance, by providing various tools and metrics to inspect the cluster state and activity.

•  It supports various features and extensions that can enhance your cluster functionality and security, such as service discovery, load balancing, networking, storage, authentication, authorization, admission control, etc.

Services in Kubernetes

Services in Kubernetes are a method for exposing a network application that is running as one or more Pods in your cluster. Services enable a loose coupling between dependent Pods, such as the frontend and backend components in an application. Services also define a logical set of endpoints (usually these endpoints are Pods) along with a policy about how to make those pods accessible.

For example, you can use a Service to specify whether you want to load balance traffic across your Pods, or assign a static IP address to your Service, or use DNS names to refer to your Service.

Services are defined using YAML or JSON, like all Kubernetes object manifests. 

You can use a selector to determine which Pods are targeted by a Service, or you can use other ways to define Service endpoints, such as manually specifying them or using a headless Service. You can also use different types of Services, such as ClusterIP, NodePort, LoadBalancer, or ExternalName, depending on your needs.

Objects in Kubernetes

Objects in Kubernetes are persistent entities that represent the state of your cluster. By creating an object, you tell Kubernetes what you want your cluster's workload to look like; this is your cluster's desired state.

Some of the common objects in Kubernetes are:

•  Pods: The smallest unit of deployment in Kubernetes. They host one or more containers and provide them with storage and networking resources.

•  Services: A way to expose applications running in pods. They represent a set of pods that perform the same function and set the policy for accessing those pods.

•  Volumes: Objects that provide storage to pods. They can be either ephemeral (tied to the pod lifecycle) or persistent (independent of the pod lifecycle).

•  Deployments: Objects that manage the creation and update of pods. They ensure that a specified number of pod replicas are running at any given time.

•  ConfigMaps: Objects that store configuration data as key-value pairs. They allow you to decouple configuration from pod specifications.

•  Secrets: Objects that store sensitive data such as passwords, tokens, or keys. They allow you to avoid exposing secrets in pod specifications or images.

There are many other objects in Kubernetes, such as Namespaces, StatefulSets, Jobs, CronJobs, etc. You can see the complete list of available objects by typing kubectl api-resources in your terminal.

Where to practice Kubernetes

There are several ways to practice Kubernetes on your laptop, depending on your preferences and resources. Here are some of the options you can try:

•  Minikube: This is a single-node Kubernetes cluster inside a virtual machine. You will need a virtualization option, such as VirtualBox or Hyper-V, to be installed on your laptop. The official website of Kubernetes provides complete instructions on how to get started with Minikube. You will also need kubectl, the command-line tool to deploy and manage applications on Kubernetes.

•  KinD: This is a tool that lets you run Kubernetes clusters using Docker containers as nodes. You will need Docker installed on your laptop. KinD is designed for testing Kubernetes itself, but you can also use it for local development or learning.

•  K3d: This is another tool that runs Kubernetes clusters using Docker containers. It is based on k3s, a lightweight Kubernetes distribution that works well on low-resource devices. You will need Docker and k3s installed on your laptop. K3d is easy to install and use, and it supports multiple clusters and load balancers.

•  Play with Kubernetes: This is an online playground that lets you create and interact with Kubernetes clusters in your browser. You don't need to install anything on your laptop, but you will need an internet connection. You can use this platform to learn the basics of Kubernetes or try out different scenarios.

What exactly Kubernetes will NOT DO.

Kubernetes is a powerful platform for managing containerized applications, but it is not a magic bullet that can solve all your problems. There are some things that Kubernetes will not do, such as:

•  Kubernetes will not run your applications for you: You still need to write, package, and deploy your code to Kubernetes clusters. Kubernetes will not automatically fix bugs, optimize performance, or secure your applications. You are responsible for the quality and functionality of your code.

•  Kubernetes will not manage your infrastructure for you: You still need to provision, configure, and maintain the servers, networks, storage, and other resources that Kubernetes runs on. Kubernetes will not automatically scale up or down your infrastructure, patch vulnerabilities, or backup your data. You are responsible for the availability and reliability of your infrastructure.

•  Kubernetes will not support Docker as a container runtime: Starting from version 1.20, Kubernetes will no longer support Docker as a container runtime option. This means that you will not be able to use Docker commands or tools to interact with Kubernetes pods or containers. However, you can still use Docker to build and push container images, as long as they comply with the Open Container Initiative (OCI) standards. You will need to use a different container runtime, such as containerd or CRI-O, to run your containers on Kubernetes.

•  Kubernetes will not simplify complex applications: Kubernetes can help you orchestrate and scale your applications, but it can also introduce new layers of complexity and abstraction. You will need to learn how to use Kubernetes concepts and components, such as pods, services, deployments, ingress, configmaps, secrets, etc. You will also need to monitor and troubleshoot your applications across multiple nodes and clusters. Kubernetes can make simple applications more complicated than they need to be.