---
title: "Why do we use Kubernetes to deploy the Platform?"
canonical: "https://onesaitplatform.refined.site/space/DOCT/2220818510/Why%20do%20we%20use%20Kubernetes%20to%20deploy%20the%20Platform%3F"
format: markdown
---
Kubernetes is a growing trend. In recent years, Kubernetes (k8s) has experienced a rapid rise from a small open source Google project to the main project of the Cloud Native Computing Foundation (CNCF). What is Kubernetes? Kubernetes is a cluster orchestration system. It was designed from the ground up to be an environment for building distributed applications from containers. Kubernetes's goal is to simplify the organization and scheduling of your application through the fleet. Basically, it allows you to not worry about which specific machines in the data center run components of your application. In addition, it provides common primitives for testing and replicating your application on these machines, as well as services for connecting your application to microservices so that each layer in your application is separated from other layers so that you can scale/update/maintain them independently from each other. Why do you need Container Orchestration? 1.Deploy applications to servers without worrying about specific servers. You need container orchestrators when you have a microservice application consisting of several services, which consist of containers. And there is another part – the servers on which this application can run. The container orchestrator performs many tasks. The first task is to initially place the containers of your application on the required number of servers, taking into account the load of the servers, in order to prevent the container from reaching the overloaded server, and also considering the memory and processor requirements for a particular container. 2. Scale the application horizontally, up and down. There is another scenario, when an application needs to be scaled horizontally, adding more containers of the same type. The container orchestrator performs the task of scaling up or down the applications taking into account the resources consumed on each target server, as well as the resource requirements of each application. In this case, the orchestrator can support the so-called affinity and anti-affinity principles. The last one allows us to guarantee that, for example, all containers of the same type will be launched on different physical servers. 3. Restore the application if the server on which it worked fails. This is called container auto-healing or rescheduling. If the server fails, you need to properly restore the application. K8s can monitor every container/pod of application to see if this container/pod is alive or not. And if not, Kubernetes will restart it. In fact, in K8s, this function is called “maintaining the right number of replicas.” In the case of Kubernetes, you can say, "I want to have 5 containers of my WordPress," and K8s will ensure that you always have 5 containers. If suddenly there are less than 5 containers, Kubernetes will launch a new container to maintain the quantity. This is important for processing the application and predicting the load. K8s also monitors the state of the servers on which the application is running, and if the server is dead, it will reschedule all its containers on other servers. How Does Kubernetes Simplify Containerized Deployment? Several advantages that Kubernetes gives out of the box: In Kubernetes, there is built-in service discovery. In other words, when a new service appears, it is assigned a unique domain name and other services can get information about this service in etcd. The second point is that Kubernetes offers flexible manifests for the deployment of applications that support different deployment strategies of container applications. Kubernetes has deployment support for A/B tests. There are also built-in health checks and Prometheus-based monitoring. Kubernetes uses a rolling update strategy to roll-out pod version updates. Rolling update strategy helps to save the app from downtime by maintaining some instances up-and-running at any moment while performing the updates. When the new pods of the new deployment version are ready to handle the traffic the system first activate them and only after that shut down the old ones. What Is the Difference Between a Pod and a Container? The problem is that people who come from the Docker world only work with containers. They are trying to transfer the knowledge they gained when using Docker Swarm and containers to work with Kubernetes. But it doesn’t work this way. In Kubernetes, the control unit is the pod, not the container. A pod is a group of one or more containers that perform the same function.  This is a component of a single application. Kubernetes manages pods, scales and monitors their condition. The application in Kubernetes is scaled by the number of pods, but not containers. In one pod most often there is a single container, but there may be several of them and this set of containers is rigidly fixed. Inside pod containers do not scale in any way and this should be considered when designing applications. Why not Docker Swarm? Docker Swarm was created by Docker Inc. and grew up as an orchestrator for Docker. Kubernetes was originally made by Google for internal use and now the whole Open Source world is working on it. Docker Swarm is a closed system. Both are trying to solve the same problem – container orchestration on a large number of hosts. While these are two fundamentally similar systems, there are still differences. Kubernetes is developing much faster and occupies most of the market ( Kubernetes 51% and Docker Swarm 11% ). Docker Swarm is less scalable and there is no built-in support for load balancing, which K8s has. In fact, Docker Swarm offers only one method of load balancing, which is based on opening a fixed port for each service on each server included in the cluster. Unlike Docker Swarm, K8s offers a built-in implementation for both internal (East-West) and external load balancing (North-South). Internal balancing is provided by the Service object and allows you to reach from one application in a cluster to all the living instances of another application by referring to the Service object. The Service is an internal load balancer, that knows at each moment of time which of the backend of the application is alive and which does not work and sends requests only to live replicas. External load balancing in Kubernetes is provided by the NodePort concept (opening a fixed port on the load balancer), as well as through the built-in LoadBalancer primitive, which can automatically create a load balancer in the cloud if Kubernetes works in a cloud environment, for example,   AWS ,   Google Cloud ,   MS Azure ,   OpenStack ,   Hidora   etc. Docker Swarm does not support Auto-Scaling, neither auto-scaling containers nor auto-scaling nodes. Kubernetes supports all possible auto-scalers: vertical scaling due to Vertical Pod Autoscaler, horizontal auto-scaling applications (Horizontal Pod Autoscaler), as well as auto-scaling of the cluster itself (the number of nodes) based on the Cluster AutoScaler. Cluster Autoscaler only works if you run Kubernetes in the cloud. Docker Swarm has difficulties with monitoring. You can monitor containers mostly only with the help of proprietary tools. Persistent storage for stateful applications is not natively supported in Docker Swarm. You need to work with network attached storage, which is not good for all types of workloads. Docker Swarm only works with Docker containers, whereas K8s can work with many container runtime options, such as Docker, Rocket, ContainerD, and others. This is very important because There is no dependency on specific docker features (some of them are available only in Docker EE).