Kubernetes is an open-source container orchestrator popular among Software Engineers, DevOps Engineers, and it’s gaining momentum in Data. In this post, I’m sharing the notes I took while studying Kubernetes Architecture. Before starting, I’d like to summarize some key-words.

The Jargon

  • Agent: it’s a software that acts in behalf of an user or other software, which can also be an agent.
  • Container: containers are all about resources isolation. An application running in a container shares the same hardware as the host, but it only gets the amount of computing resources, i.e. CPU, memory and network, that the developer allows. It’s like setting a slice of a computer dedicated to run an application.
  • Containerized Application: an application running in a container.
  • Container Engine: it’s a high-level software tool responsible for automating the process of creating isolated, lightweight environments. It’s the component humans usually interact with in order to create containers. This include managing container images and container orchestration. Container engines use a container runtime to process requests made by an user.
  • Container Runtime: it’s the container engine component responsible for the interactions between the application in a container and the host operating system, resource allocation and container execution.
  • Controller: controllers are non-terminating loops that regulates the state of a system. For example, a thermostat in a room keeps checking the temperature in order to decide to turn on or off an air-conditioner.
  • Cluster: is a set of computers (nodes) connected in a network in order to work together as they were a single computer.
  • Orchestrator: an orchestrator is a system that reacts to a demand for computing resources. The orchestrator is responsible for allocating the desired amount of resources when tasks are submitted, checking if the proper amount of resources are available during the execution of an application and self-healing when something breaks.
  • Pods: are the smallest deployable unit of computing that you can create and manage in Kubernetes. Pods are composed by one or more containers, depending on the need. Containers in a Pod share the same network, storage, and run in the same node.

The Big Picture

A 40000ft look on Kubernetes Architecture looks like this:

Kubernetes ARchitecture-40000ft

The image above is available in the Kubernetes Documentation. A Kubernetes cluster is composed by Control Plane Nodes and Worker Nodes. The Control Plane hosts managerial services and has different components than the Worker Nodes, except for the Kubelet in most of the situations. The components are:

  • cloud-controller-manager: responsible for building a native interface between a Kubernetes cluster and third-party APIs of infrastructure providers. It has internal controllers that manages and capture node objects, set routes, and integrate infrastructure services such as managed load balancers, IP addresses, network packet filtering and target health checking.
  • Etcd: a highly-available key-value store used as Kubernetes “brain”. All data in etcdis collected by kube-api-server.
  • Scheduler: distributes newly created Pods across cluster nodes.
  • Controller Manager: runs controller processes responsible for node health checking, watches and manages pods that run one-off tasks jobs, populate objects to provide link between services and pods, and creates default service accounts for new namespaces.
  • kube-apiserver: responsible for validating and configuring data for Kubernetes API objects, which includes Pods, Deployments, ReplicaSets. It’s the cluster front-end.

The worker nodes are responsible for running applications deployed as Pods through a container runtime interface (CRI). The components in a Kubernetes worker node are:

  • kubelet: an agent that guarantees containers are running in a Podwith a given desired state. It also exists in Control Plane nodes when components, like the Etcd, run in Pods.
  • kube-proxy: a network proxy that runs on each node in order to allow communication across Pods or services in a cluster, or with services outside a cluster.
  • CRI (Container Runtime Interface): allows Kubernetes to manage the container execution and its lifecycle in the Kubernetes environment. At the time of this writing, the most popular runtimes allowed are containerd and CRI-O.

Kubernetes Objects

Kubernetes objects are entities that represents the cluster desired state, such as:

  • What containerized applications are running at which node.
  • The resources available to those applications.
  • The policies governing how those applications behave, including restart, upgrades and fault-tolerance

When a Kubernetes object is created through the Kubernetes API, its system ensures that the object remains in the desired state. Virtually, every Kubernetes object includes two nested fields, status and spec, whose work is to make this happen. The field statusdescribes the current status of the object, while spec provides the desired state.

Kubernetes objects are usually created by providing a manifest YAML file to a CLI tool named kubectl. The manifest must have the following fields:

  • apiVersion: the API version needed to create the object.
  • kind: the kind of object that is going to be created.
  • metadata: data that helps to uniquely identify an object. This field includes a name string parameter (mandatory) and the namespace (optional).
  • spec: the desired state of the object. The details of this field varies accordingly to the kind of object being created.

At this point, it’s important to learn about the objects Pod, Deployment and ReplicaSet.

The Pod Object

Pods are the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is composed by one or more containers, and a specification for how to run them. The contents of a Pod are always co-scheduled, co-located and run in a shared context. That is, the specified storage, computing and network resources will run in the same machine. Also, if a solution requires a multi-container Pod approach, all containers will run in the same Worker node.

The Deployment Object

Deployment Objects manage a set of Pods running an application workload. When creating a Deployment YAML manifest, we provide a replica parameter that creates replicas of Pods, a Podtemplate, and a selectorthat finds which Pods the Deployment is going to manage. The replica parameter creates a ReplicaSet object.

The ReplicaSet Object

ReplicaSet Object has the purpose of maintaining a set of replica Pods running at any given time. Despite being possible to define ReplicaSets through manifests directly, it’s recommended to create them only through Deployment Objects. When ReplicaSets are not managed by Deployments, Pods need to be managed manually. For example, if Pods are created by a unmanaged ReplicaSet, and then an update to these Pods need to be made, you must delete the ReplicaSet, update the manifest, and create a new ReplicaSet. In a Deployment, all we need to do is to update the manifest and apply the manifest to update the application.

References