我的部署有内存限制
resources:
limits:
memory: 128Mi
但是我的应用程序在接近限制时开始失败，因此，有什么方法可以在 pod 达到内存限制的百分比之前重新启动 pod 吗？
例如，如果限制为 128Mi，则在达到 85% 时重新启动 pod。
我将从 Kuberentes 方面来回答这个问题。
正如 arjain13 已经提到的，您想到的解决方案不是可行的方法，因为它违背了请求和限制的想法：
如果您为该容器设置 4GiB 的内存限制，kubelet（和容器运行时）将强制执行该限制。运行时会阻止容器使用超过配置的资源限制。例如：当容器中的进程尝试消耗超过允许的内存量时，系统内核会终止尝试分配的进程，并出现内存不足 (OOM) 错误。
您还可以找到超出容器内存限制的示例：
如果节点有可用内存，容器可能会超出其内存请求。但容器使用的内存不得超过其限制。如果容器分配的内存超过其限制，则该容器将成为终止的候选者。如果容器继续消耗超出其限制的内存，则容器将被终止。如果可以重新启动已终止的容器，kubelet 会重新启动它，就像任何其他类型的运行时故障一样。
我想建议您在当前的用例中尝试以下两件事：
调试您的应用程序以消除内存泄漏，这似乎是此问题的根源。
指示容器是否正在运行。如果活性探测失败，kubelet 将终止容器，并且容器将遵循其重新启动策略。
可以使用以下字段进行配置：
initialDelaySeconds：容器启动后启动活动或就绪探测之前的秒数。默认为 0 秒。最小值为 0。
periodSeconds：执行探测的频率（以秒为单位）。默认为 10 秒。最小值为 1。
timeoutSeconds：探测超时之前的秒数。默认为 1 秒。最小值为 1。
successThreshold：探测失败后被视为成功的最小连续成功次数。默认为 1。活性必须为 1。最小值为 1。
failureThreshold：当探测失败时，Kubernetes 会尝试failureThreshold多次然后放弃。在活性探测的情况下放弃意味着重新启动容器。如果进行就绪探测，Pod 将被标记为“未就绪”。默认为 3。最小值为 1。
periodSeconds如果您设置、 、的最小值timeoutSeconds，successThreshold则failureThreshold可以期待更频繁的检查和更快的重新启动。
您将在下面找到一些有用的资源和指南：
| 归档时间： |
|
| 查看次数： |
9973 次 |
| 最近记录： |