如何在 kubernetes 中处理 apache 的资源限制答案

【问题标题】：How to handle resource limits for apache in kubernetes如何在 kubernetes 中处理 apache 的资源限制
【发布时间】：2018-09-26 12:09:45
【问题描述】：

我正在尝试在谷歌云上部署一个可扩展的网络应用程序。我有 kubernetes 部署，它创建了 apache+php pod 的多个副本。这些设置了 cpu/内存资源/限制。

假设每个副本的内存限制为 2GB。如何正确配置 apache 以遵守此限制？

我可以修改最大进程计数和/或每个进程的最大内存以防止内存溢出（因此副本不会因为 OOM 而被杀死）。但这确实会产生新问题，此设置还将限制我的副本可以处理的最大请求数。在 DDOS 攻击（或更多流量）的情况下，瓶颈可能是最大进程限制，而不是内存/cpu 限制。我认为这可能经常发生，因为这些限制是针对最坏的情况设置的，而不是基于平均流量。

我想配置自动缩放器，以便在发生此类事件时创建多个副本，而不仅仅是在 cpu/内存使用量接近限制时。

我该如何正确解决这个问题？感谢您的帮助！

【问题讨论】：

我认为可以根据自定义指标（我可以从 apache 内部获得）创建自动缩放器，但这似乎很模糊。我认为必须有更好的解决方案。

标签： apache kubernetes google-cloud-platform

【解决方案1】：

我建议您执行以下操作，而不是尝试将 apache 配置为内部限制：

对 pod 实施资源限制。即让他们OOM。（但见注*）
根据您的负载为您的部署定义自动缩放指标。
设置命名空间范围的资源配额。这对该命名空间中的 Pod 可以使用的资源实施了集群范围的限制。

这样，您可以让您的 Apache+PHP pod 处理尽可能多的请求，直到它们 OOM，此时它们重新生成并再次加入池，这很好*（因为希望它们是无状态的）并且在任何时候您的所有资源利用率是否超过了对命名空间实施的资源限制（配额）。

* 注意：这仅在您不使用 websockets 或基于流的 HTTP 等花哨的东西时才适用，在这种情况下，OOMing Apache 实例会关闭其他持有该实例的打开套接字的客户端。如果您愿意，您应该始终能够根据它运行的线程/进程的数量来强制限制 apache，但除非您确实需要它，否则最好不要这样做。有了这种设置，无论你做什么，你都无法躲避大规模的 DDoS 攻击。您要么是破坏了套接字（在 OOM 的情况下），要么是请求超时（没有足够的线程来处理请求）。您需要更复杂的网络/过滤设备来防止“良好”流量受到打击。

【讨论】：

感谢您的回答。但是故意让 Pod OOM 不是一个坏习惯吗？在这种情况下，如果不是 request_count * max_mem_per_request + 开销，我该如何计算 pod 的适当资源限制？
re：OOM 是一种不好的做法——您通常不希望您的 pod 在正常运行期间发生 OOM，但如果您处于 DDoS 之下，那么尝试防范这种情况没有什么意义，所以没关系让 pods OOM 消失，让 kubernetes 担心保持你的容量。除非您发现此设置在实践中实际上是有害的，否则我不建议您尝试提出更复杂的东西（但是，请务必在您的监控系统中监控 OOM 杀死的数量）。
re：资源限制，对您的用例有意义的都是“适当的”。 request_count * max_mem_per_request + overhead 很好。或者，您可以将其设置为节点上可用 CPU/Mem 的乘法因子 (GCD) 的大小，以便您可以在集群中进行更好的 bin 打包。归根结底，资源配额有两个目的：（1）防止恶意实体破坏集群上运行的所有其他东西（2）充当调度程序提示/值，以提高集群范围内的资源利用率，并减少资源争用.
谢谢。我会将此标记为答案。虽然我不确定如何正确调整 pod 资源配额。
@JanImrich 随着您更好地了解工作负载和集群利用率，您的资源配额会随着时间的推移而变化，但对于初学者，您可以选择主机资源的一部分。例如，如果你有一台 24core，128G 的机器，你可以为每个 pod 分配 4CPU/21G。您可以根据单个 pod 的需求来更小或更高，因此您可能希望持续测量您的 pod、节点和集群的利用率，然后进行调整以最大限度地减少浪费。如果不了解您的确切设置并查看利用率数字，我无法为您提供更好的建议。