In this tutorial, we’ll introduce you to Kubernetes and will discuss its architecture.
As a prerequisite, it’s good to have some basic knowledge of the container world.
Kubernetes, popularly known as K8s, is an open-source container orchestration engine for microservices-based containerized applications.
A K8s cluster comprises of a master and multiple worker nodes:
The master node is responsible for allocating work to all other configured nodes in the cluster.
A K8s master comprises of the following key components:
Let’s now talk about the Kubernetes worker nodes.
Every node will have:
The kubectl command-line utility helps us trigger commands to the API Server. For instance, to create or update a resource on our cluster, we’ll have:
kubectl apply -f deployment.yaml
where deployment.yaml is a file with our intended resource specifications.
Now that we understand the architecture of a Kubernetes cluster, let’s look at some frequently used terminologies:
With namespaces, we can logically split a physical cluster into many virtual clusters. This feature comes handy when we have multiple users or teams using our cluster resources. It enables us to have a more logical grouping of K8s objects.
We can think of a pod as the smallest deployable unit in a K8s cluster. They get scheduled on the cluster nodes and are created/destroyed on demand.
A pod can be composed of one or more containers. All the containers running inside a single pod share the same IP address, network namespace, cgroups, etc. In most usual cases, we usually have a pod comprising of a single container.
A replica set is a K8s object that defines and maintains the expected number of pod replicas at any point in time. If one of the pod goes down, another is brought up to keep up with the set expectations.
A K8s deployment is another layer of abstraction over ReplicaSets. Once we define a deployment manifest, we don’t need to explicitly define ReplicaSets and pods.
K8s deployments can manage and update replica sets. It also supports rollbacks.
Once a pod dies, the same pod can never be brought up again. The replacement pod that’s brought up will have a different IP address. And so, it’s hard to establish communication in that way.
A Kubernetes service is an abstraction acting as a gateway for a logical set of pods. With it, a client pod now just needs to know of the exposed service.
In this tutorial, we looked at the Kubernetes architecture and explored a few important terminologies.