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

This article is the last of a series of three articles on Kubernetes security. In the first article, we shared how to ensure that an enterprise's Kubernetes cluster is protected from external threats; the second article describes three ways to protect Kubernetes from internal threats. In this article, we will show you how to deal with resource consumption or noisy neighbor issues.

For those cluster administrators who have set up a multi-tenant Kubernetes cluster, one of their concerns and concerns is how to prevent a co-tenant from becoming a "noisy neighbor", a person who monopolizes CPU, memory, storage, and other resources. Noisy neighbor can have a very bad impact on the performance of other user resources that share the infrastructure.

In this way, tracking the resource usage of Kubernetes containers and Pod is very important for cluster management, because it can not only keep the container orchestration system running at its best, reduce operation and maintenance costs, but also enhance the overall security of Kubernetes.

Some operations teams may not think that resource consumption is an important security issue, at least not as important as protecting Kubernetes from internal and external networks. But this view is not correct. Because powerful people will take advantage of dysfunctional infrastructure to find ways to use Kubernetes components.

"Security is not just about 'Don't break into my house', it's about 'how can I keep my house running all the time'," said Adrian Goins, a senior solution architect at Rancher Labs.

The operations team needs to maximize the resources consumed by Kubernetes Pods, a set of one or more containers with shared storage and network resources, to ensure that each user has the best performance and to monitor the use of cost allocations. " Usage equals cost, "Goins said." because Kubernetes resources run on the underlying computing infrastructure of cloud providers such as AWS, Google Cloud, Aliyun, and so on, all resource consumption represents a monetary cost. Even if the cluster runs on bare metal in the data center, too much use can cost hardware, power, and other resources. "

By default, when you configure a container, there is no limit to the amount of resources it can use. If the container does not run efficiently, the organization that deploys the container will have to pay an excess fee. Fortunately, Kubernetes has the function of helping the operation and maintenance team to manage and optimize the utilization of Kubernetes resources.

Manage resources in Pods

When administrators define Pod, they can choose to specify how much CPU and memory (RAM) each container needs. When the container specifies a resource request, the scheduler can better decide on which node to place the Pod. According to the Kubernetes documentation, resource contention on the node can be handled in the specified manner when the container specifies a limit.

By default, all resources in the Kubernetes cluster are created in the default namespace. Namespaces are a way to logically group cluster resources, including options for specifying resource quotas.

Administrators can set resource limits or quotas on the namespace to allocate a certain amount of CPU, RAM, or storage-- three resources in the Kubernetes cluster-- to workloads or applications running in the namespace. "if starting another resource in the namespace exceeds the default quota, then no new resource can be started," Goins points out.

"when you apply a resource quota, it means that you force everything running in that namespace to set resource limits for itself. There are two types of restrictions: reservation, and maximum limits," Goins explained. For example, by reserving, the administrator can have the Kubernetes cluster assign 128 MB of RAM to the WordPress site. For each WordPress Pod deployed, the server itself will guarantee a 128 MB RAM. Therefore, if an administrator combines a resource request with a resource quota for 1GB, users can only run eight WordPress Pod before their limit is exceeded. After that, they will no longer be able to use RAM.

The second part of the resource limit is the maximum. Administrators can reserve resource requests of 128 MB and RAM of up to 256 MB. "if the Pod exceeds the RAM usage of 256 MB, Kubernetes will kill it and restart it," Goins said. "in this way, users can be protected from runaway processes and noisy neighbor."

Project and resource quotas

Platforms like Rancher are designed to simplify the management of Kubernetes by providing an intuitive interface and centralized management tasks, such as role descriptions at the global layer.

As mentioned in the previous article on internal threat protection, Rancher includes a "Project" resource that helps ease the burden of cluster management, transcending namespaces. In Rancher, Project allows administrators to manage multiple namespaces as a single entity. Therefore, Rancher can apply resource quotas to Projects.

In standard Kubernetes deployments, resource quotas can only be applied to individual namespaces. However, administrators cannot apply quotas to namespaces in a single operation. Resource quotas must be manipulated multiple times.

In Rancher, however, administrators can apply resource quotas to Project and then propagate quotas to each namespace. Kubernetes then uses the native version of the resource quota to enforce administrator restrictions. If administrators want to change quotas for a specific namespace, they can overwrite previous quotas.

Strengthen and optimize Kubernetes

There is no doubt that Kubernetes has become the standard for container orchestration, prompting most cloud and virtualization vendors to provide it as a standard infrastructure. However, a general lack of awareness of the security issues associated with the Kubernetes environment may expose various components from both inside and outside the network cluster.

The last two articles in this series provided some practical steps to show you how to enhance Kubernetes's protection against external and internal network threats by using Kubernetes features and container-managed solutions such as Rancher. Enterprises should protect Kubernetes API access externally through role-based access control (RBAC) and strong authentication. For insider protection, because the Kubernetes cluster is multi-user, the organization needs to protect cross communication through RBAC, logical isolation, and NetworkPolicies.

To prevent other tenants from monopolizing CPU, memory, storage, and other resources, thus dragging down the performance of the entire cluster, Kubernetes provides functions such as resource limits and quotas to help the operation and maintenance team manage and optimize Kubernetes resource utilization. Finally, in addition to the available default settings, there are some very effective tools in the industry that can help users manage and protect Kubernetes clusters. For example, a platform like Rancher is a highly optimized container management solution built for organizations that deploy multiple clusters to a production environment, making it easier for enterprise users to manage and run local Kubernetes. It protects Kubernetes clusters from external threats, internal hazards, and even noisy neighbor.

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.