Container technology is a means of packaging an application so that it may run with separated dependencies, and its compartmentalization of a computer system has radically transformed software development today. In this section, we'll look at some of the key aspects, including where this technology originated and the background behind the container technology:

Figure 1.3 – A brief history of container technology

Early containers (chroot systems with Unix version 7), developed in the 1970s, offered an isolated environment in which services and applications could operate without interfering with other processes, thereby creating a sandbox for testing programs, services, and other processes. The original concept was to separate the workload of the container from that of production systems, allowing developers to test their apps and procedures on production hardware without disrupting other services. Containers have improved their abilities to isolate users, data, networking, and more throughout time.

With the release of Free BSD Jails in the 2000s, container technology finally gained traction. "Jails" are computer partitions that can have several jails/partitions on the same system. This jail architecture was developed in 2001 with Linux VServer, which included resource partitioning and was later linked to the Linux kernel with OpenVZ in 2005. Jails were merged with boundary separation to become Solaris Containers in 2004.

Container technology advanced substantially after the introduction of control groups in 2006. Control groups, or cgroups, were created to track and isolate resource utilization, such as CPU and memory. They were quickly adopted and improved upon in Linux Containers (LXC) in 2008, which was the most full and stable version of any container technology at the time since it functioned without changes having to be made to the Linux kernel. Many new technologies have sprung up because of LXC's reliability and stability, the first of which was Warden in 2011 and, more importantly, Docker in 2013.

Containers have gained a lot of usage since 2013 due to a slew of Linux distributions releasing new deployment and management tools. Containers running on Linux systems have been transformed into virtualization solutions at the operating system level, aiming to provide several isolated Linux environments on a single Linux host. Linux containers don't need their own guest operating systems; instead, they share the kernel of the host operating system. Containers spin up significantly faster than virtual machines since they don't require a specialized operating system.

Containers can employ Linux kernel technologies such as namespaces, Apparmor, SELinux profiles, chroot, and cgroups to create an isolated operational environment, while Linux security modules offer an extra degree of protection, ensuring that containers can't access the host machine or kernel. Containerization in terms of Linux provided even more versatility by allowing containers to run various Linux distributions from their host operating system if both were running on the same CPU architecture.

Linux containers provided us with a way to build container images based on a variety of Linux distributions, as well as an API for managing the containers' lifespan. Linux distributions also included client tools for dealing with the API, as well as snapshot features and support for moving container instances from one container host to another.

However, while containers running on a Linux platform broadened their applicability, they still faced several fundamental hurdles, including unified management, real portability, compatibility, and scaling control.

The emergence of Apache Mesos, Google Borg, and Facebook Tupperware, all of which provided varying degrees of container orchestration and cluster management capabilities, marked a significant advancement in the use of containers on Linux platforms. These platforms allowed hundreds of containers to be created instantly, and also provided support for automated failover and other mission-critical features that are required for container management at scale. However, it wasn't until Docker, a variation of containers, that the container revolution began in earnest.

Because of Docker's popularity, several management platforms have emerged, including Marathon, Kubernetes, Docker Swarm, and, more broadly, the DC/OS environment that Mesosphere built on top of Mesos to manage not only containers but also a wide range of legacy applications and data services written in, for example, Java. Even though each platform has its unique approach to orchestration and administration, they all share one goal: to make containers more mainstream in the workplace.

The momentum of container technology accelerated in 2017 with the launch of Kubernetes, a highly effective container orchestration solution. Kubernetes became the industry norm after being adopted by CNCF and receiving backing from Docker. Thus, using a combination of Kubernetes and other container tools became the industry standard.

With the release of cgroups v2 (Linux version 4.5), several new features have been added, including rootless containers, enhanced management, and, most crucially, the simplicity of cgroup controllers.

Container usage has exploded in the last few years (https://juju.is/cloud-native-kubernetes-usage-report-2021) in both emerging "cloud-native" apps and situations where IT organizations wish to "containerize" an existing legacy program to make it easier to lift and shift onto the cloud. Containers have now become the de facto standard for application delivery as acceptance of cloud-native development approaches mature.

We'll dive more into Kubernetes components in the next section.

In this section, we'll go through the various components of the Kubernetes system, as well as their abstractions.

The following diagram depicts the various components that are required for a fully functional Kubernetes cluster:

Figure 1.4 – A Kubernetes system and its abstractions

Let's describe the components of a Kubernetes cluster:

• Nodes, which are worker machines that run containerized work units, make up a Kubernetes cluster. Every cluster has at least one worker node.
• There is an API layer (Kubernetes API) that can communicate with Kubernetes clusters, which may be accessed via a command-line interface called kubectl.

There are two types of resources in a Kubernetes cluster (as shown in the preceding diagram):

• The control plane, which controls and manages the cluster
• The nodes, which are the workers' nodes that run applications

All the operations in your cluster are coordinated by the control plane, including application scheduling, maintaining the intended state of applications, scaling applications, and deploying new updates.

A cluster's nodes might be virtual machines (VMs) or physical computers that serve as worker machines. A kubelet is a node-managing agent that connects each of the nodes to Kubernetes control plane. Container management tools, such as Docker, should be present on the node as well.

The control plane executes a command to start the application containers whenever an application needs to be started on Kubernetes. Containers are scheduled to run on the cluster's nodes by the control plane.

The nodes connect to the control plane using the Kubernetes API that the control plane provides. The Kubernetes API allows end users to interface directly with the cluster. The master components offer the cluster's control plane capabilities.

API Server, Controller-Manager, and Scheduler are the three processes that make up the Kubernetes control plane. The Kubernetes API is exposed through the API Server. It is the Kubernetes control plane's frontend. Controller-Manager is in charge of the cluster's controllers, which are responsible for handling everyday activities. The Scheduler keeps an eye out for new pods that don't have a node assigned to them and assigns them one. Each worker node in the cluster is responsible for the following processes:

• Kubelet: This handles all the communication with the Kubernetes MasterControl plane.
• kube-proxy: This handles all the networking proxy services on each node.
• The container runtime, such as Docker.

Control plane components are in charge of making global cluster decisions (such as application scheduling), as well as monitoring and responding to cluster events. For clusters, there is a web-based Kubernetes dashboard. This allows users to administer and debug cluster-based applications, as well as the cluster itself. Kubernetes clusters may run on a wide range of platforms, including your laptop, cloud-hosted virtual machines, and bare-metal servers.

MicroK8s is a simplistic streamlined Kubernetes implementation that builds a Kubernetes cluster on your local workstation and deploys all the Kubernetes services on a tiny cluster that only includes one node. It can be used to experiment with your local Kubernetes setup. MicroK8s is compatible with Linux, macOS X, Raspberry Pi, and Windows and can be used to experiment with local Kubernetes setups or for edge production use cases. Start, stop, status, and delete are all basic bootstrapping procedures that are provided by the MicroK8s CLI for working with your cluster. We'll learn how to install MicroK8s, check the status of the installation, monitor and control the Kubernetes cluster, and deploy sample applications and add-ons in the next chapter.

Other objects that indicate the state of the system exist in addition to the components listed in Figure 1.4. The following are some of the most fundamental Kubernetes objects:

• Pods
• Deployments
• StatefulSets and DaemonSets
• Jobs and CronJobs
• Services

In the Kubernetes system, Kubernetes objects are persistent entities. These entities are used by Kubernetes to represent the state of your cluster. It will operate indefinitely to verify that the object exists once it has been created. You're simply telling the Kubernetes framework how your cluster's workloads should look by building an object; this is your cluster's ideal state. You must use the Kubernetes API to interact with Kubernetes objects, whether you want to create, update, or delete them. The CLI handles all Kubernetes API queries when you use the kubectl command-line interface, for example. You can also directly access the Kubernetes API in your apps by using any of the client libraries. The following diagram illustrates the various Kubernetes objects:

Figure 1.5 – Overview of Kubernetes objects

Kubernetes provides the preceding set of objects (such as pods, services, and controllers) to satisfy our application's requirements and drive its architecture. The guiding design principles and design patterns we employ to build any new services are determined by these new primitives and platform abilities. A deployment object, for example, is a Kubernetes object that can represent an application running on your cluster. When you build the deployment, you can indicate that three replicas of the application should be running in the deployment specification. The Kubernetes system parses the deployment specification and deploys three instances of your desired application, altering its status as needed. If any of those instances fail for whatever reason, the Kubernetes framework responds to the discrepancy between the specification and the status by correcting it – in this case, by establishing a new instance.

Understanding how Kubernetes works is essential, but understanding how to communicate with Kubernetes is just as important. We'll go over some of the ways to interact with a Kubernetes cluster in the next section.

Interacting with a Kubernetes cluster

In this section, we'll look at different ways to interface with a Kubernetes cluster.

Kubernetes Dashboard is a user interface that can be accessed via the web. It can be used to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and control the cluster's resources. This dashboard can be used for a variety of purposes, including the following:

• All the nodes and persistent storage volumes are listed in the Admin overview, along with aggregated metrics for each node.
• The Workloads view displays a list of all running applications by namespace, as well as current pod memory utilization and the number of pods in a deployment that are currently ready.
• The Discover view displays a list of services that have been made public and have enabled cluster discovery.
• You can drill down through logs from containers that belong to a single pod using the Logs view.
• For each clustered application and all the Kubernetes resources running in the cluster, the Storage view identifies any persistent volume claims.

Figure 1.6 – Kubernetes Dashboard

• With the help of the Kubernetes command-line tool, kubectl, you can perform commands against Kubernetes clusters. kubectl is a command-line tool for deploying applications, inspecting and managing cluster resources, and viewing logs. kubectl can be installed on a variety of Linux, macOS, and Windows platforms.

The basic syntax for kubectl looks as follows:

kubectl [command] [type] [name] [flags]

Let's look at command, type, name, and flags in more detail:

• command: This defines the action you wanted to obtain on one or more resources, such as create, get, delete, and describe.
• type: This defines the types of your resources, such as pods and jobs.
• name: This defines the name of the resource. Names are case-sensitive. If the name is omitted, details for all the resources are displayed; for example, kubectl get pods.
• flags: This defines optional flags.

We'll take a closer look at each of these Kubernetes objects in the upcoming sections.

Pods are the minimal deployable computing units that can be built and managed in Kubernetes. They are made up of one or more containers that share storage and network resources, as well as running instructions. Pods have the following components:

• An exclusive IP address that enables them to converse with one another
• Persistent storage volumes based on the application's needs
• Configuration information that determines how a container should run

The following diagram shows the various components of a pod:

Figure 1.7 – The components of a pod

Workload resources known as controllers create pods and oversee the rollout, replication, and health of pods in the cluster.

The most common types of controllers are as follows:

• Jobs for batch-type jobs that are short-lived and will run a task to completion
• Deployments for applications that are stateless and persistent, such as web servers
• StatefulSets for applications that are both stateful and persistent, such as databases

These controllers build pods using configuration information from a pod template, and they guarantee that the operating pods meet the deployment specification provided in the pod template by creating replicas in the number of instances specified in the deployment.

As we mentioned previously, the Kubectl command-line interface includes various commands that allow users to build pods, deploy them, check on the status of operating pods, and delete pods that are no longer needed.

The following are the most commonly used kubectl commands concerning pods:

• The create command creates the pod:

  kubectl create -f FILENAME.

For example, the kubectl create -f ./mypod.yaml command will create a new pod from the mypod YAML file.

• The get pod/pods command will display information about one or more resources. Information can be filtered using the respective label selectors:

  kubectl get pod pod1

• The delete command deletes the pod:

  kubectl delete -f FILENAME.

For example, the kubectl delete -f ./mypod.yaml command will delete the mypod pod from the cluster.

With that, we've learned that a pod is the smallest unit of a Kubernetes application and is made up of one or more Linux containers. In the next section, we will look at deployments.

Deployment allows you to make declarative changes to pods and ReplicaSets. You can provide a desired state for the deployment, and the deployment controller will incrementally change the actual state to the desired state.

Deployments can be used to create new ReplicaSets or to replace existing deployments with new deployments. When a new version is ready to go live in production, the deployment can easily handle the upgrade with no downtime by using predefined rules. The following diagram shows an example of a deployment:

Figure 1.8 – A deployment

The following is an example of a deployment. It creates a ReplicaSet to bring up three nginx pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-sample-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1:21
        ports:
        - containerPort: 80

In the preceding example, the following occurred:

• A deployment called nginx-sample-deployment is created, as indicated by the metadata.name field.
• The image for this deployment is set by the Spec.containers.image field (nginx:latest).
• The deployment creates three replicated pods, as indicated by the replicas field.

The most commonly used kubectl commands concerning deployment are as follows:

• The apply command creates the pod:

  kubectl apply -f FILENAME.

For example, the kubectl apply -f ./nginx-deployment.yaml command will create a new deployment from the nginx-deployment.yaml YAML file.

• The get deployments command checks the status of the deployment:

  kubectl get deployments 

This will produce the following output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-sample-deployment   3/3     0            0           1s

The following fields are displayed:

• NAME indicates the names of the deployments in the namespace.
• READY shows how many replicas of the application are available.
• UP-TO-DATE shows the number of replicas that have been updated to achieve the desired state.
• AVAILABLE shows the number of available replicas.

• AGE indicates the length of time the application has been running.
• The describe deployments command indicates the details of the deployment:

  kubectl describe deployments

• The delete command removes the deployment that was made by the apply command:

  kubectl delete -f FILENAME.

With that, we have learned that deployments are used to define the life cycle of an application, including which container images to use, how many pods you should have, and how they should be updated. In the next section, we will look at StatefulSets and DaemonSets.