Shulou(Shulou.com)06/02 Report--

This article mainly explains "which build Kubernetes clusters". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "which build Kubernetes clusters".

Cluster analysis

In different application development environments, you usually develop and run multiple applications. In addition, multiple instances of these applications are usually run in different environments, such as you may use a development environment, a test environment, and a production environment.

As a result, this will result in a different intersection of the application and the environment. In the following example, there are 3 applications and 3 environments, resulting in 9 instances of applications. Each application instance is a separate deployment unit that can run independently.

Note that an application instance may consist of multiple components, such as front end, back end, database, and so on. In a micro-service application, an application instance will consist of all the micro-service components.

As a user of Kubernetes, some questions will make you think. Should all application instances be run on a single cluster? Or should there be a separate cluster for each application instance? Or should it be used in combination?

Here are some options you can choose from:

A large shared cluster

Many small disposable clusters

Cluster for each application

Cluster for each environment

The first two methods are the size limit from several large clusters to multiple small clusters, as shown in the following figure:

In general, if the cluster contains the sum of larger nodes and Pod, it can be defined as "larger". For example, a cluster with 10 nodes and 100 Pods is larger than a cluster with 1 node and 10 Pods.

A large shared cluster

The first option is to run all workloads in the same cluster. In this way, the cluster can be used like a common infrastructure platform. Whatever you need to run, you can deploy it to an existing Kubernetes cluster.

Kubernetes provides namespaces to logically separate parts of the cluster from each other, in which case a separate namespace can be used for each application instance.

Advantages: effective use of resources

If you have only one Kubernetes cluster, you only need to have a copy of all the resources needed to run and manage the Kubernetes cluster.

For example, this includes the master node, a Kubernetes cluster usually has three master nodes, and if there is only one cluster, a total of only three master nodes are needed (if there are 10 Kubernetes clusters, there are only 30 master nodes).

But this also includes other cluster-wide services, such as load balancing, ingress controllers, authentication, logging, and monitoring.

If there is only one cluster, these services can be reused for all workloads, and you do not have to have multiple service replicas for multiple clusters.

Advantages: low cost

Fewer clusters usually cost less, because the more clusters there are, the more resources are spent. This is especially true for the primary node, which can cost a lot of money, whether locally or in the cloud.

Some hosted Kubernetes services offer free Kubernetes control platforms, such as Google GKE or Azure's AKS, so cost-effectiveness is not an issue in this case.

However, there are also managed Kubernetes services that charge a fixed fee for running a Kubernetes cluster, such as AWS's EKS.

Advantages: efficient management

It is easier to manage a single cluster than to manage multiple clusters. This may include the following tasks: upgrading the Kubernetes version, setting up the CI/CD pipeline, installing the CNI plug-in, setting up the user authentication system, and installing the admission controller.

If there is only one cluster, it only needs to be done once. If you have many clusters, you need to apply everything multiple times, which may require the development of automated processes and tools to do this consistently.

Disadvantages: single point of failure

If there is only one cluster and the cluster fails, then all workloads will go wrong. There are also many actions that can lead to failures, such as Kubernetes upgrades, cluster-wide components (such as CNI plug-ins) that do not work properly, misconfigured cluster components, and infrastructure failures. Therefore, if there is only one shared cluster, all workloads may be affected.

Disadvantages: no hard security isolation

If multiple applications are running in the same Kubernetes cluster, these applications share hardware, network, and operating systems on the nodes of the cluster. Specifically, two containers of two different applications running on the same node are technically two processes running on the same hardware and operating system kernel.

The Linux container provides some form of isolation, but this isolation is not as strong as the isolation provided by virtual machines. In the background, the processes in the container are still just processes running on the host operating system. From a security point of view, this may be a problem. In theory, it allows unrelated applications to have unexpected interactions.

In addition, all Kubernetes clusters share certain cluster-wide services, such as workload DNS, which allows applications to discover the services of other applications in the cluster.

Therefore, whether or not these problems may occur depends on the security requirements of the application.

Kubernetes provides a variety of ways to prevent security vulnerabilities, such as PodSecurityPolicies and NetworkPolicies, but it requires experience to adjust these tools in exactly the right way, and they do not prevent all security vulnerabilities.

Moreover, Kubernetes is designed for sharing, not for isolation and security.

Disadvantages: multi-tenant resource encroachment

There are many shared resources in the Kubernetes cluster, and different applications can encroach on resources in many ways. For example, an application may occupy a shared resource, such as CPU or memory, making it impossible for other applications running on the same node to run.

Kubernetes provides several ways to control this behavior, such as resource requests and restrictions, ResourceQuotas and LimitRanges. However, it is not easy to adjust these tools in the right way, and they do not prevent all unnecessary side effects.

Disadvantages: complex user permissions

If there is only one cluster, many people in the enterprise must have access to the cluster. The more opportunities users have to use the system, the higher the risk of damage. In a cluster, you can control who can operate using role-based access control (RBAC). However, this still does not prevent users from disrupting certain behaviors within their authorized scope.

Disadvantages: clusters cannot be infinitely large

If a single cluster is used for all workloads, the cluster can be large (in terms of nodes and Pods). However, Kubernetes clusters cannot grow indefinitely.

There are some theoretical limits on the size of the cluster. The Kubernetes is defined as approximately 5000 nodes, 150000 Pods, and 300000 containers. In fact, however, using a smaller cluster size, such as 500 nodes, may already be a challenge.

The reason is that larger clusters put more pressure on the Kubernetes control plane, which requires careful planning to maintain the functionality and efficiency of the cluster.

Many small disposable clusters

Using this approach, you can use a separate Kubernetes cluster for each deployment unit (in this article, a deployment unit is an application instance, such as a development version of a single application), and with this strategy, Kubernetes is dedicated to each application instance.

Advantages: reduced radius of failure

If the cluster fails, the damage is limited to the workloads running on the cluster, while all other workloads are not affected.

Advantages: isolation

Workloads running in each cluster do not share any resources, such as CPU, memory, operating system, network, or other services.

This provides strong isolation between unrelated applications, which is a big advantage for the security of these applications.

Pros: very few users

If each cluster runs only one set of workloads, the number of people who need to access the cluster will be reduced. The fewer people who access the cluster, the lower the risk of failure.

Disadvantages: inefficient use of resources

As mentioned earlier, each Kubernetes cluster requires a set of management resources, such as master nodes, control plane components, monitoring and logging solutions. If there are many small clusters, higher total resources must be sacrificed for these management functions.

Disadvantages: high cost

Inefficient use of resources will automatically lead to higher costs. If you have to run 30 master nodes instead of 3 master nodes to get the same computing power, then the cost is inevitable.

Disadvantages: integrated management

Managing many Kubernetes clusters is more complex than managing a single Kubernetes cluster. For example, authentication and authorization need to be set up for each cluster, and multiple times if you want to upgrade the Kubernetes version. You may need to develop some automation tools.

Cluster for each application

Using this approach, you can create a separate cluster for all instances of a particular application. It can be thought of as the scope of each team responsible for the cluster, because usually one or more applications are developed by a team.

Pros: clusters can be customized for applications

If your application has specific requirements, you can install those requirements in the cluster without affecting any other clusters. Such requirements may include a worker node, a CNI plug-in, a service grid, or any other service. Each cluster can be fully equipped with the configuration required by the corresponding application.

Disadvantages: different environments in the same cluster

The disadvantage of this approach is that application instances from different environments run in the same cluster. For example, the production version of the application runs in the same cluster as the development version, which also means that the developer works in the same cluster as the production version of the application. Therefore, if a developer or development version creates some damage in the cluster, the production version may also be affected.

Cluster for each environment

Using this approach, you can create a separate cluster for each environment. For example, you can have a development, test, and production cluster that runs all application instances for a particular environment.

Advantages: isolation of product environment

Usually, this isolates all environments from each other, but in fact, it is especially important for the product environment. Now, the production version of the application is not affected by anything that happens in any other cluster or application environment.

Therefore, if some configuration errors cause damage in the development cluster, the production version of the application will continue to run.

Advantages: clusters can be customized for the environment

It can be optimized for the environment of each cluster, such as installing development and debugging tools in the development cluster, installing test frameworks and tools in the test cluster, and using stronger hardware and network connections for the product cluster; it can improve the efficiency of application development and operation.

Advantage: lock access to the production cluster

No one needs to do development work on the production cluster, so access to it can be restricted. Even no one can be granted access to the production cluster at all, and the cluster can be deployed through the automated CI/CD tool. This will greatly reduce the risk of human error in production clusters.

Disadvantages: lack of isolation between applications

The main disadvantage is the lack of hardware and resource isolation between applications. Unrelated applications share cluster resources, such as operating system kernel, CPU, memory, and other services. There may be potential security problems.

Disadvantages: application requirements are not localized

If the application has special requirements, these requirements must be met in all clusters. If an application requires a GPU, each cluster must have at least one GPU worker node, even if it is used by only one application. This may lead to increased costs and inefficient use of resources.

Thank you for your reading, the above is the content of "what is building Kubernetes clusters". After the study of this article, I believe you have a deeper understanding of the problem of building Kubernetes clusters, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.