Introduction to Kubernetes

What is an orchestration system?

Kubernetes, in its most common usage, is a container orchestration system. Of course, we need to define what that means! Look no further:

An orchestration system provides automated configuration, coordination and management of complex computing networks, systems and services.

So these systems are designed to reduce the time and manual effort/manipulation required to align a business’s applications, data, and infrastructure. In a software-defined networking (SDN) context, orchestration systems decouple the "orchestration layer" from the "service layer" to increase the agility of the applications being rolled out on the network.

Still puzzled? Let's dive deeper to get a visual!

The need for an orchestration system

OK-- why do we even need an orchestration system?

Modern software applications are based on many different services working together as a larger system. If containerized, these services would be wrapped by many different containers that need maintenance, resources, deployments, monitoring, and so on.

In order to efficiently manage a system like this, manpower is not enough. This effort requires a lot of manual work and monitoring, and could potentially result in human errors and misconfigurations.

Hence arrives the need of having a system that could compose all of these containers, one that would take care of their resources (such as disk space, memory, network), and would automatically manage them. This kind of system would easily take care of continuous deployment and integration, as well as managing the applications' configurations.

Hello, Kubernetes!

Kubernetes is an open-source orchestration system for automating deployment, scaling, and overall management of containerized applications. It gives developers the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure-- allowing effortless movement of workloads wherever necessary.

Some of the main functionalities of Kubernetes include:

• Automated rollouts and rollbacks
• Storage orchestration
• Automatic bin packing
• Service discovery and load balancing
• Secret and configuration management
• Batch execution
• Horizontal scaling
• Self-healing

Kubernetes operates at the container level rather than at the hardware level. It provides some generally applicable features common to PaaS (Platform as a Service), such as deployment, scaling, and load balancing. It also lets users integrate their logging, monitoring, and alerting solutions into the same dashboard.

However, the main difference between PaaSs and Kubernetes is that K8 (short for Kubernetes) is not monolithic, and these default solutions are optional and pluggable.

Think of Kubernetes as the layer that turns many container chores into a managed system.

In the visual, notice the shift from manual container-by-container work to declaring a desired state: how many copies should run, what resources they need, and how traffic should reach them. Kubernetes continuously works to make the real system match that desired state.

Which of the following processes can be automated using Kubernetes?

Kubernetes architecture

Before explaining the Kubernetes architecture, we are going to define a few of the main terms used in Kubernetes:

• Container - a program packaged with its necessary OS resources, frameworks, and packages
  • Node - the smallest unit of computing hardware (a single machine)
  • Pod - one or more containers wrapped together. They are placed on a node
  • Cluster - nodes put together to form a powerful computing unit

See below for a visual representation of a Kubernetes cluster:

A Kubernetes architecture consists of two parts: the control plane and the nodes. Each node can be either a physical or virtual machine and has its own environment. Every node runs the pods, which are composed of containers.

1. The control plane is the "nerve center" that houses Kubernetes components that control the cluster. It also maintains a data record of the configuration and state of all of the cluster’s objects. It consists of several different components:

- The **API Server** supports updates, scaling, and other kinds of lifecycle orchestration by providing APIs for various types of applications, which can be accessed by clients from outside the cluster, since it also serves as a gateway.

- The **scheduler** keeps the resource usage data for each node, determines whether a cluster is healthy, and determines whether new containers should be deployed. Then it selects an appropriate compute node and schedules the task, pod, or service, taking resource limitations into consideration.

- The **controller manager** is a daemon that runs the Kubernetes cluster using several controller functions.

- **ETCD** is an open-source, key-value store database that stores configuration data and information about the state of the cluster. It may be configured externally, but usually, it is a part of the control plane.

1. The Kubernetes cluster is consisted of one or many nodes working together, forming a powerful computing unit. On each node, there can be several components that serve different purposes:

- **Kubelet** is an agent that communicates with the control plane to ensure the containers in a pod are running. It receives the pod specifications through the API server and executes the action.

- The **kube-proxy** serves as a network proxy and service load balancer on its node, and it either forwards traffic or relies on the packet filtering layer of the operating system to handle network communications both outside and inside the cluster.
- Each node runs and manages container life cycles using a **container runtime engine**. Kubernetes supports Open Container Initiative-compliant runtimes such as Docker, CRI-O, and rkt.

Control plane and nodes

A useful way to remember the Kubernetes architecture is:

• The control plane makes decisions about the cluster
• The nodes do the actual work of running containers

For example, when you ask Kubernetes to run three copies of an application, the control plane figures out where those pods should live. Then each node uses its local Kubernetes components, such as the kubelet, to start the pods and report their status back.

In other words:

control plane = desired state and scheduling
nodes         = running pods and reporting health

This is why Kubernetes is often described as a system that constantly tries to make the real cluster match the desired configuration.

A Kubernetes *node * is consisted of one or more containers wrapped together.

Deployment and Service

Two Kubernetes files often work together:

• A Deployment describes the pods Kubernetes should create and maintain
• A Service gives those pods a stable way to be reached

The important link between them is usually a label. The Deployment gives pods a label, and the Service uses a selector to find pods with that label.

A simplified configuration looks like this:

```pseudo
Deployment:
  name: web
  replicas: 3
  pod_template:
    labels:
      app: web

Service:
  name: web-service
  selector:
    app: web
  port: 80
```

How does a Kubernetes Service usually know which pods it should send traffic to?

Kubernetes configuration

All of the necessary configuration to deploy a Kubernetes cluster is done with .yaml files where all the necessary information about the nodes, pods, and the cluster itself are specified.

The basic configuration should consist of a few files, but the most important ones are the Service ,Deployment, and Ingress files. The deployment file takes care of the deployment itself, the service file tells the cluster how your pods can be accessed, and the ingress file opens up the pods to be accessed externally.

The yaml **configuration files consist of 3 main parts: **metadata, specification, and status. The attributes of the specification file are different based on the type of file (Service/Deployment). The status part is automatically discovered by Kubernetes, and it is automatically filled. That information comes from the etcd.

In the following snippet we can see an example of a deployment file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx

The **yaml **configuration file that defines how the nodes will be open to be accessed externally is called:

Docker + Kubernetes

Docker can be used as a container runtime that Kubernetes orchestrates.

The way that these two technologies work together looks something like this: When Kubernetes schedules a pod to a node, the kubelet on that node will instruct Docker to launch the specified containers. Then, the kubelet will collect the status of the containers constantly and will give that information to the control plane. Docker then pulls containers onto that node and starts and stops those containers.

Docker and Kubernetes work together in a way that the kubelet instructs Docker to launch the containers.

One Pager Cheat Sheet

• Kubernetes, a container orchestration system, provides automated configuration, coordination, and management of complex computing networks, systems and services, helping to reduce time and manual effort required for aligning applications, data and infrastructure.
• Kubernetes is an open-source orchestration system that automates the deployment, scaling, and management of containerized applications in order to efficiently manage workloads across on-premises, hybrid, or public cloud infrastructure.
• - Kubernetes manages containers by comparing desired state against actual state, then scheduling, scaling, restarting, and routing as needed.
• Kubernetes can orchestrate many processes related to the management of containerized applications, such as automated rollouts and rollbacks, storage orchestration, automatic bin packing, service discovery and load balancing, secret and configuration management, batch execution, horizontal scaling, and self-healing, therefore allowing these processes to be automated.
• Kubernetes architecture consists of two parts: the control plane, which houses Kubernetes components, and nodes with Pods composed of Containers running the Kubelet, kube-proxy, and container runtime engine.
• - The control plane decides what should happen; nodes run pods and report what is happening.
• A Kubernetes node is the smallest unit of computing hardware, and is not composed of pods (one or more containers bundled together).
• - Deployments create and maintain pods; Services find matching pods using selectors and labels.
• - A Service routes traffic to pods selected by matching labels.
• K Kuberentes configuration consists of a few .yaml files that set metadata, specification and status, with the deployment, service and ingress files being the most important components.
• The Ingress file is essential for connecting the nodes of a Kubernetes configuration to the outside world, providing information such as URLs and IP addresses, and controlling how requests are routed.
• Kubernetes utilizes Docker as its container runtime to orchestrate the launching, starting, and stopping of containers.
• The kubelet in Kubernetes communicates with Docker to launch and manage the containers.