About Kubernetes architecture(1)
It’s exciting how we can ship large applications today easily without having issues through containers. Wait, what is a container? Containers are a way to package and deliver application code. They simplify the developer's workflow and make it easy to launch applications. One of those container applications today is Kubernetes also known as K8s which would be discussed in this article.
What is Kubernetes?
Kubernetes is an open-source orchestration tool that manages containers. it was developed by Google. It manages containerized applications in various environments.
Why is Kubernetes called an orchestration tool?
It allows you to build application services that run across multiple containers, schedule containers across a cluster, scale those containers, and manage their health over time. The interesting thing about Kubernetes is that it eliminates many manual processes involved in deploying and scaling containerized applications.
Benefits of Kubernetes
→ High availability: there is a very limited possibility you would experience downtime with Kubernetes.
→ Scalability: it offers high performance, a high response rate from the application.
→ Disaster recovery: there is a great tendency of restoring or back-up.
Kubernetes architecture
Pod: this is an abstraction over a container. It is the smallest unit of Kubernetes. It creates a layer on top of the container, but you only interact with that layer. They are meant to run one application inside them i.e One application per pod. Each pod gets its own Ip address and they communicate with each other using this Ip address. the downside about pods is that they can crash easily, but when they crash, they can be easily replaced with a new Ip address. They represent a single instance of a running process in your cluster, they can contain one or more applications, when they run multiple containers, they are managed as a single entity and share the same resources. Pods always run on Nodes.
ConfigMap: it’s an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as an environment variable, command-line argument, or as configuration files in a volume. It allows you to decouple environment-specific configuration from container images; so that your applications are easily portable.
Secret: they are just like ConfigMap but its difference is that it’s used to store data in base64 encoded format. The built-in security mechanism is not enabled by default. They can be used as environmental variables or as property files.
Volumes: are used for storing data. Kubernetes cluster restarts on a clean slate, and this leads to loss of data, volumes solve that issue to ensure when the container is started, its previous data is still available. Kubernetes doesn’t manage data persistence, you are responsible for backing up the data.
Nodes: a Node is a worker machine in Kubernetes, which could be either virtual or physical, depending on the cluster. Every Node is managed by the Master. Nodes can have multiple pods. Scheduling of pods on the nodes is done automatically by the Kubernetes Master. Every Node runs a Kubelet and container runtime.
Kubelet: this is responsible for communication between the Kubernetes Master and the Node. It manages the Pods and the container running on the machine.
Container runtime: this is responsible for pulling the container image from a registry, unpacking the container, and running the application. An example of container runtime is docker and rktnetes.
Service: it’s an abstraction that defines a logical set of pods and a policy by which to access them. Its also known as a permanent Ip address attached to each pod. They enable a loose coupling between dependent pods. they enable access to pods. They select pods based on their labels. When a network request is made to the service, it selects pods in the cluster matching the service selector, chooses one of them, and forwards the network request to it.
The type property in the Service’s spec determines how the service is exposed to the network. The possible types are ClusterIP, Nodeport, and LoadBalancer.
ClusterIP: is the default service type of every Kubernetes cluster. it is only accessible from within the cluster and cannot be accessible from outside the cluster.
NodePort: This makes the service accessible on a static port on each Node in the cluster. This means the service can handle requests coming from outside the cluster.
Loadbalancer: This is an advisable and secure way of exposing your cluster externally. It automatically routes requests to your Kubernetes services. They are provided by cloud providers (AWS, Azure, GCP; Google cloud provider).
The Kubernetes cluster is made up of multiple nodes which must have a container runtime. Communication works between both worker and server through DB(Database) services. Kube proxy is responsible for forwarding requests from services to pods and needs to be installed on every node, same also goes with Kubelet, along with an independent container runtime.
Deployment: a deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. They ensure that more than one instances of your application are available to serve user requests. They are managed by the Kubernetes deployment.
Master processes (server)
The master node controls the cluster stage and worker nodes. They are four processes that run on every master node.
→ API server: this is an interaction point between the client and the cluster, it could be the Kubernetes dashboard, the command-line tool, or an API. It acts as a cluster gateway that gets the initial requests of any update in the server or the query. It also acts as a gatekeeper for authentication.
Request → API server → Validates reports → Other processes → Pods
If you want to query a request, you do that on the API server, it has one entry point into the cluster.
→ Scheduler: it is a control plane process that assigns Pods to Nodes. The scheduler determines which Nodes are valid placements for each Pod in the scheduling queue according to constraints and available resources, the scheduler then ranks each valid Node and binds the Pod to a suitable Node.
→ Controller manager: the Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. It detects the state changes in the worker nodes and tries to recover the cluster stage as soon as possible, then reschedules those Pods (By requesting to the scheduler).
Controller manager → Scheduler → Kubelet → Pods
→ Etcd: pronounced as et-see-dee, it’s known as the brain of the Kubernetes cluster system, it’s open-source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines. It is used as a back store for all cluster data. All the process on the cluster works because of the etcd’s data.
A Kubernetes cluster set up usually have two master Nodes and three worker Nodes. The master Nodes require less memory, unlike the worker Nodes which does most of the work.
Kubectl
This is a command-line tool for the Kubernetes cluster. The API server in the master processes enables interaction with the cluster, once the Kubectl makes a demand, the worker process enables the pods to run on the Node. Some Kubectl use;
kubectl create -f(filename)
kubectl get nodes
kubectl get podsKubernetes YAML configuration
Most of the Kubernetes configuration is done on a YAML file.
Every configuration file has three parts;
Metadata: this is crucial for organizing and understanding the way containers are orchestrated across many services, machines. It is used for uniquely identifying the object.
Specification: this is where you would describe the object in greater detail, the details would be specific to the kind of components you are creating.
Status: this is automatically generated and added by Kubernetes. Kubernetes will always compare what is desired state and actual. If they do not match it would know and fix. Kubernetes updates the state continuously with the aid of etcd.
Contents of yaml config file explain
apiVersion: this describes the version of theKubernetes API you’re using to create your object.
kind: describes the kind of object you want to create
metadata: this helps to uniquely identify the object
name: just a name to describe your object or application
labels and selectors: labels are key-value pairs attached to objects, they are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users.
ports: this exposes the Kubernetes service on the specified port within the cluster.
These are some basic aspect of the Kubernetes architecture, by now you would have understood Pods, Nodes, Services, Master processes, Kubernetes command-line tool(Kubectl) and its configuration file(Yaml) explained.
