本文是关于Kubernetes安全系列三篇文章中的最后一篇。在第一篇文章中，我们分享了如何确保企业的Kubernetes集群免受外部***；第二篇文章介绍了三种保护Kubernetes免受内部威胁的方法。在本文中，我们将介绍如何处理资源消耗或noisy neighbor问题。

对于那些设置了多租户Kubernetes集群的集群管理员而言，他们十分关注和担心的一个问题是，如何防止共同租户成为“noisy neighbor”，即一个垄断了CPU、内存、存储和其他资源的人。Noisy neighbor会对共享基础设施的其他用户资源的性能产生极坏的影响。

如此一来，跟踪Kubernetes容器和Pod的资源使用情况，对集群管理而言非常重要，因为它不仅可以保持容器编排系统处于最佳运行状态，降低运维成本，还可以加强Kubernetes的整体安全状况。

一些运维团队可能不认为资源消耗是一种重要的安全问题，至少没有保护Kubernetes免受内部和外部网络***重要。但这种观点是不正确的。因为厉害的***会利用功能不良的基础设施，来找到***Kubernetes组件的方法。

“安全不仅仅是‘不要闯进我的房子’，而是‘我怎么能让我的房子一直保持良好的运行状态’，”Rancher Labs的高级解决方案架构师Adrian Goins表示。

运维团队需要最大限度地利用Kubernetes Pods（一组具有共享存储和网络资源的一个或多个容器）所消耗的资源，以确保每个用户都能拥有最佳性能，并且能监控成本分配的使用情况。“使用等于成本，”Goins说，“因为Kubernetes资源都是运行在AWS、谷歌云、阿里云等等云提供商的底层计算基础设施上，一切资源消耗都以为着金钱成本。即使集群是在数据中心的裸机上运行，过多的使用也会花费硬件、电力和其他资源。”

默认情况下，配置容器时，对其可以使用的资源量没有任何限制。如果容器不能高效运行，部署容器的组织必将支付超额费用。值得庆幸的是，Kubernetes具有帮助运维团队管理和优化Kubernetes资源利用能力的功能。

管理Pods中的资源

当管理员定义Pod时，他们可以选择指定每个容器需要多少CPU和内存（RAM）。当容器指定了资源请求时，调度程序可以更好地决定将Pod放在哪个节点上。根据Kubernetes的文档，当容器指定了限制时，可以按指定的方式处理节点上的资源争用。

默认情况下，Kubernetes集群中的所有资源都是在默认的命名空间中创建的。命名空间是一种逻辑地将集群资源进行分组的方法，包括用于指定资源配额的选项。

管理员可以在命名空间上设置资源限制或配额，为在命名空间中运行的工作负载或应用程序分配一定量的CPU、RAM或存储——Kubernetes集群中的三个资源。“如果在命名空间中启动另一个资源会超出预设的配额，那么任何新资源都无法启动，”Goins指出。

 “当你应用了资源配额时，意味着你强制在该命名空间中运行的所有内容为其自身设置资源限制。限制有两种类型：预留，和最大限制，”Goins解释说。例如，通过预留，管理员可以让Kubernetes集群为WordPress站点分配128 MB的RAM。对于部署的每个WordPress Pod，服务器本身将保证128 MB的RAM。因此，如果管理员将资源请求与1GB的资源配额相结合，则用户只能在超过其限制之前运行八个WordPress Pod。在那之后，他们将无法再使用RAM了。

资源限制的第二部分是最大限度。管理员可以预留128 MB的资源请求和最多256 MB的RAM。“如果Pod超过256 MB的RAM使用量，Kubernetes会杀死它并重新启动它，”Goins说。“如此以来，用户可以免受失控过程和noisy neighbor的影响。”

项目和资源配额

像Rancher这样的平台，旨在通过提供直观的界面和集中管理任务（如全局层的角色描述）来简化Kubernetes的管理。

正如前一篇关于内部威胁防护的文章所述，Rancher包含一个有助于减轻集群管理负担的“项目（Project）”资源，来超越命名空间。在Rancher中，Project允许管理员将多个命名空间作为单个实体进行管理。因此，Rancher可以将资源配额应用于Projects。

在标准Kubernetes部署中，资源配额只能应用于单独的命名空间。但是，管理员无法通过单次操作，同时将配额应用于命名空间。资源配额必须经过多次操作。

然而在Rancher中，管理员可以将资源配额应用于Project，然后将配额传播到每个命名空间。然后，Kubernetes会使用本机版本的资源配额，来强制执行管理员限制。如果管理员希望更改特定命名空间的配额，则可以覆盖以前的配额。

强化和优化Kubernetes

毋庸置疑，Kubernetes已成为容器编排的标准，这也促使大多数云和虚拟化供应商将其作为标准基础架构来提供。但是，对与Kubernetes环境相关的安全问题的普遍缺乏认识，可能会使各种组件暴露于来自网络集群内外的***中。

本系列文章的上两篇中提供了一些可行的步骤，来告诉大家如何通过使用Kubernetes功能和容器管理解决方案（如Rancher），来加强Kubernetes对外部和内部网络威胁的防范。企业应通过基于角色的访问控制（RBAC）和强身份验证从外部保护Kubernetes API访问。对于内部人员保护，由于Kubernetes集群是多用户，因此组织需要通过RBAC、逻辑隔离和NetworkPolicies来保护交叉通信。

为了防止其他租户垄断CPU、内存、存储和其他资源从而拖累整个集群的性能，Kubernetes提供资源限制和配额等功能，以帮助运维团队管理和优化Kubernetes资源利用功能。最后，除了可用的默认设置之外，业界还有一些非常有效的工具可以帮助用户完成Kubernetes集群的管理和保护。例如像Rancher这样的平台就是一种高度优化的容器管理解决方案，专为将多个集群部署到生产环境中的组织而构建，企业用户可以更轻松地管理和运行各地的Kubernetes。它可以保护Kubernetes集群免受外部***威胁、内部隐患甚至noisy neighbor。