Hardware

Nodes

In Kubernetes, a node is the lowest unit of computer hardware. It's a depiction of one of your cluster's machines. A node in most production systems will either be a real machine in a datacenter or a virtual machine hosted on a cloud provider such as Google Cloud Platform. Don't let conventions limit you; you can construct a node out of nearly anything in theory.

We can add a layer of abstraction by thinking of a machine as a "node." Instead of worrying about the specific characteristics of each machine, we can now just look at each one as a collection of CPU and RAM resources that can be used. In this approach, any machine in a Kubernetes cluster can replace any other machine.

Working with individual nodes is possible, but it is not the Kubernetes approach. Instead of worrying about the state of individual nodes, you should think about the cluster as a whole.

Kubernetes combines the resources of its nodes to create a more powerful computer. When you deploy applications to the cluster, it automatically distributes work to specific nodes. The cluster will redistribute work around as needed if any nodes are added or deleted. Which specific machines are really running the code shouldn't matter to the programme or the author.

Persistent Volumes

Data can't be stored to any random location in the file system since programmes operating on your cluster aren't guaranteed to run on a certain node. If a programme attempts to store data to a file for later use but is subsequently moved to a different node, the file will no longer be where the application expects it to be. As a result, each node's typical local storage is considered as a temporary cache for holding programmes, but any data saved locally cannot be expected to last.

Persistent Volumes are used by Kubernetes to store data indefinitely. While the cluster efficiently pools and manages the CPU and RAM resources of all nodes, permanent file storage is not. As a Persistent Volume, local or cloud discs can be connected to the cluster. This is similar to connecting an external hard disc to the cluster. Persistent Volumes are a file system that may be mounted on the cluster without being tied to a specific node.

Software

Containers

Kubernetes applications are bundled as Linux containers. Because containers are a widely acknowledged standard, Kubernetes already has a large number of pre-built images. Containerization allows you to build Linux execution environments that are self-contained. Any software, together with all of its dependencies, may be compressed into a single file and transmitted over the internet. With very little preparation, anyone can download the container and instal it on their infrastructure. Creating a container may be done programmatically, enabling for the creation of strong CI and CD pipelines.

Multiple applications can be loaded into a single container, but if at all feasible, keep it to one process per container. It's preferable to have several little containers rather than one huge one. Updates are quicker to deploy and faults are easier to identify when each container has a narrow focus.

Pods

Kubernetes, unlike other systems, does not execute containers directly; instead, it wraps one or more containers into a higher-level structure known as a pod. Containers in the same pod will have access to the same resources and network. Containers in the same pod may easily communicate with one other as if they were on the same machine, while being isolated from the rest of the pod.

In Kubernetes, pods are utilised as the replication unit. Kubernetes may be set to deploy additional copies of your pod to the cluster as needed if your application gets too popular and a single pod instance can't handle the demand. Even when a production system is not under severe demand, it is common to have many copies of a pod operating at any same moment to allow for load balancing and failure resistance.

Although pods may store several containers, it's best to keep it to a minimum. Because pods are scaled as a whole, all containers in a pod must scale collectively, regardless of their individual requirements. This results in a waste of resources and a hefty price. To combat this, pods should be kept as tiny as possible, generally containing only a core process and a closely linked auxiliary container.

Deployments

Pods are the basic unit of computing in Kubernetes, however they are rarely deployed directly on a cluster. Pods are generally handled by an additional layer of abstraction called the deployment.

The basic function of a deployment is to specify how many clones of a pod should be running at any given moment. When you add a deployment to the cluster, it will automatically start up the appropriate number of pods and monitor them. If a pod dies, the deployment will recreate it automatically.

You don't have to deal with pods manually if you use a deployment. Simply specify the system's intended state, and it will be handled for you automatically.

Ingress

You may establish a cluster of nodes and launch pod deployments onto the cluster using the ideas mentioned above. However, there is one more issue to address: permitting external traffic into your programme.

Kubernetes offers isolation between pods and the rest of the world by default. You must create a communication channel with a service running in a pod if you wish to communicate with it. Ingress is the term for this.

Ingress may be added to your cluster in a variety of ways. The two most frequent methods are to use an Ingress controller or a LoadBalancer. The specific tradeoffs between these two methods are outside the scope of this essay, but you must be aware that ingress is something you must deal with before you can try Kubernetes.