Kubernetes 101: Understanding what is K8s (The Hardware Edition)

Kubernetes 101: Understanding what is K8s (The Hardware Edition)

Lately I have been testing the GC project “El Carro” and it came to light that I hadn’t done a 101 of Kubernetes or also known as K8s and following Christine’s post on learning something new, I think this can help out newcomers. I will be doing a couple of posts on this topic, so I hope you follow the series

I am going to try to give a high-level overview of what I consider the most important components and how they fit together.

What is Kubernetes (k8s)?

First of all, let’s start by defining what is Kubernetes (K8s). It is an open source Orchestration Layer or Orchestration Platform that automates the processes involved in deploying, managing, and scaling containerized applications. This is a good point in time to mention that K8s is not a Hypervisor or a Container, as mentioned above, it is the one who orchestrates containers. K8s doesn’t limit the types of apps you can deploy (any language works). So basically if your application fits in a container, K8s will deploy it,


I do think that I need to explain what is a container before continuing. The definition from Docker is the following: “a container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another”.

A container comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.

Multiple containers can share the same base image, with this in mind it is important to remember you are trying to make containers that are stateless.

Anything important that shouldn’t be throw away when the container is dropped and run again, like your data files in a database, should be held in persistent storage, not in the container itself.

Hardware Perspective


It is the smallest unit of computing hardware in Kubernetes. It is a representation of a single machine in your cluster. A node will likely be either a physical machine or virtual machine hosted on a cloud provider. Having the abstract concept of a node, allows you to think of it a set of RAM and CPU resources, withouth thinking of the specs of the machine. 

Typically you have several nodes in a cluster and each node is managed by the control plane which contains the services necessary to run Pods. The components on a node include

  • Kubelet.- An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
  • A container runtime.- Software that is responsible for running containers.
  • kube-proxy .- Network proxy that runs on each node in the cluster

One thing to note is that two Nodes cannot have the same name at the same time.




This is a set of nodes that pool together their resources to form a more powerful environment. A cluster is comprised of one master node and a number of worker nodes. The master node controls the state of the cluster and it is the origin for all task assignments.

There must be a minimum of one master node and one worker node.

The control plane is the brain of the cluster and as nodes get added or deleted, it will shift the work around as needed. When talking about high availability, the control plane runs on multiple nodes. 

Persistent Volumes

As discussed with the containers, for us to be able to store data permanently K8s uses persistent volumes. Persistent Volumes (PV) are attached to the cluster and its lifecycle it is also independent of the nodes.

If the storage is local to the node, then it is treated as a temporary cache. Attaching to the cluster a Persistent Volume can be thought of as plugging an external hard drive in to the cluster. Withing the PV there exists a PersistentVolumeClaim (PVC)  which is a request for storage by a user. A claim can request specific size and access modes to the PV.

PersistentVolume types are implemented as plugins. K8s currently supports some of the following plugins:

  • awsElasticBlockStore – AWS Elastic Block Store (EBS)
  • azureDisk – Azure Disk
  • azureFile – Azure File
  • fc – Fibre Channel (FC) storage
  • gcePersistentDisk – GCE Persistent Disk
  • local – local storage devices mounted on nodes.

You can see what access type and the plugins available in the K8s documentation

In my next post, I will try to explain the software side of K8s so that from there we can use the project of GCP of El Carro and you understand what you are seeing.

I do want to mention that I took as reference the following 2 blog posts for the work that I’m doing and expanded on them



Rene Antunez
[email protected]
No Comments

Sorry, the comment form is closed at this time.