Kubernetes 安全三步谈：如何监控与控制 Kubernetes 中的资源消耗问题

本文是关于 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。