visit
Is Kubernetes difficult to use?
Kubernetes offers extensive documentation and a wealth of community experience. You can use the Helm package manager (similar to Apt and Yum) to significantly simplify deployment. Helm uses “charts”, or data sets, to create an instance of the application in the Kubernetes cluster.There are many ready-to-use chart templates, and you can use an existing solution from Kubeapps, the application directory for the Kubernetes infrastructure. This allows you to configure your app deployment with just one button. You can also create your own chart, but in most cases, there will already be a chart that is suitable for your needs. If a chart does not fully meet your requirements, then it is easy to write your own, using the existing chart as a reference.Is Kubernetes expensive?
Since Kubernetes uses nodes, or machines in a cluster, that contain many components and require vast resources, many people believe that it is prohibitively expensive. The minimum comfortable configuration starts with five to six machines with dual-core CPUs and 4 GB of RAM. For highly loaded services, the recommended RAM on the master node rises to 8 GB. But this does not correlate with the concept we stated earlier - using high load approaches on a weak server. This was made possible by the development of K3S, a lightweight Kubernetes distribution that drastically reduces the minimum infrastructure requirements.How we use Kubernetes at Evrone
We began working with Kubernetes three years ago when we were developing the , a CI/CD service that grew from an internal product into a commercial solution. Kubernetes made it possible to integrate the entire architecture, which used to run on several virtual machines, into a single environment with scalable resources.Since the services inside the product were now weakly connected and the data was exchanged through the RabbitMQ message broker, we could easily migrate containers from one machine to another depending on the required resources. Kubernetes conveniently took care of all the mechanisms of migration, scheduling, routing of requests, and monitoring the life cycle of services.Now we launch all new projects in the Kubernetes environment, regardless of their size and complexity, and we’ve also transferred parts of existing projects to this stack from other containerization solutions, such as docker-swarm and Nomad.At Evrone, we have had great experiences deploying Kubernetes infrastructure on bare-metal servers. This method is a little more complicated than doing it in the cloud, because you are forced to work specific hardware, rather than ordering a typical server with a standard configuration. So it requires you to solve the issues of balancing traffic, adding new nodes to the cluster, allocating disk space for permanent data storage, etc.There are also projects where it's necessary to deploy the Kubernetes environment in single-node mode (on one bare-metal machine) in a secure circuit, accessible exclusively via VPN, with external traffic available only through HTTP-proxy.In this situation, working with a critically small amount of resources, we are deploying a cluster based on a certified K3S distribution. This allows you to work productively on, let's say, a rather weak machine. It also makes it possible to migrate to a large cluster, without rewriting the entire configuration stack.Scaling with Kubernetes
It’s worth it to take future scaling into account from the very beginning of the project. Containerization has become an efficient way to ensure that your project will have room to grow. Kubernetes is becoming increasingly popular and is compatible with almost all large cloud platforms, makes it easy to scale the project (if it is initially packed in containers), using a horizontal or vertical approach.With horizontal scaling, the number of replicas of loaded services automatically increases, allowing you to parallelize traffic between several models and reduce the load on each of them. In this case, as soon as the load drops, the number of replicas is diminished and the resources they occupied are freed.Vertical scaling is a little more complex. Depending on the resource consumption of the application, more efficient servers are allocated, while the underloaded ones are disabled. However, it is difficult to determine the necessary hardware requirements. So you may end up either paying more for overly powerful servers, or not take into account peak loads and "fall" at the most crucial moment.Getting started with Kubernetes
If you do not take future growth into account at the start of your project, eventually your developers will be faced with the challenge of quickly scaling a high load project which is filled with users and generates profit. According to the available statistics, you can experience significant losses from just one minute of downtime. In this situation, your service may be disabled for hours. Our Kubernetes approach guarantees that scaling can be done quickly and smoothly with minimal service disruptions.