Kubernetes
It could be weird to start this category with Kubernetes because probably you think Kubernetes is for the DevOps people, but if you are a full-stack developer, probably you are interested in DevOps. Kubernetes is used by many developers to orchestrate containers and deploy applications. This post assumes that the reader has knowledge about containers, Docker, or Podman.
Introduction.
We have tools to create and maintain containers like Docker or Podman. These allow us to keep the application isolated in the same system. They avoid the classic “This works on my side” situation. For software development this is enough, but what about when we want to deploy containers? Of course we can deploy containers. Actually, we could create images and commit them in some repository so we can deploy Docker/Podman containers to our server and expose the application. But What about if you need to handle those containers in several servers, probably tens, hundreds, or thousands of servers? What about if one of them failed?
What’s Kubernetes?
Kubernetes, also known as K8s is an open-source container orchestration system for automating software deployment, scaling, and management. Originally designed by Google, the project is now maintained by a worldwide community of contributors, and the trademark is held by the Cloud Native Computing Foundation. Wikipedia.
So Kubernetes gives us the possibility to handle several containers through several nodes, getting high availability and removing downtime. The way that Kubernetes ensures high availability is by creating replicas of the applications. So you can have several copies of your application and its environment; if a copy fails, Kubernetes will send the traffic to another copy. So the final user never notices when the application fails. Kubernetes ensures the scalability by sending the traffic to different copies of your application. So if your application receives more traffic, you can increase the number of replicas.
Architecture.
Kubernetes has two groups of daemons: master and nodes.
Master
This group contains the following daemons: kube-apiserver, kube-controller-manager, and kube-scheduler (we will name them as API Server, Controller Manager, and Scheduler).
- API Server: It exposes an interface for different clients to interact with Kubernetes. These clients could be web platforms or web UIs, third-party clients, or clients that the community or even you can build, and the most common client that we have is the kubectl command on our terminal.
- Controller Manager: It manages the cluster, so it has to be aware of the containers that are running, and the containers that should be running.
- Scheduler: It receives the commands from the Controller Manager and moves the pods (we will define pod) on the basis of that.
- etcd: It is a database that stores all the information about the status of the cluster, and the configuration.
Nodes
This group contains the following daemons: kublet and kube-proxy.
- Pod: It’s a set of containers that shares the same namespace of network and exposes the same IP.
- Node: It’s a virtual or physical machine. A physical machine could be a Dell or HP server in a data center or your own PC running in your home. On the other hand, a virtual machine could be AWS EC2, Google Compute Engine, Azure VM, Minikube, VirtualBox, VMware, Virt-Manager, or KIND (Kubernetes in Docker).
- Kublet: It’s the primary node agent that communicates with the Master group. It manages and coordinates the pods and nodes based on the Master commands.
- Kublet proxy: It reflects the services as defined in the API on each node. It does simple TCP, UDP, and SCTP stream. In manages the traffic between pods an services.
Important concepts.
In addition to the concepts that we read in the Architecture section being important, there are other important ones.
- Service: It’s a method for exposing a network that is running as one or more pods. Think of this like a proxy that connects pods; instead of communicating pod to pod, there is a layer between them that is the service. There are different types of services.
- Volumes: They provide a way to share data for a container in a pod to the filesystem; there are different types of volumes.
- Namespace: It’s a virtual space in the cluster that allows us to organize and isolate different resources such as pods, services, deployments, and configurations.
Manifest and Deployments
When we are working with Docker or Podman, we can create images using the docker/podman command. But we have the alternative to create a Dockerfile. Same situation with containers; we could create them using Docker commands but also with a YAML file named docker-compose.yml. With manifest YAML files, we can create deployments instead of creating them with the kubectl command. In a future post I will explain how to create a manifest.