2

我有多环境 k8s 集群 ( EKS )，我正在尝试为 ResourceQuotas 设置准确的值。

我注意到的一件有趣的事情是，当作业成功完成并有效地释放它正在使用的 cpu/内存资源时，指定的 CPU/内存请求/限制在 k8s 集群中保持“占用” 。

由于我希望在环境中执行很多作业，这给我带来了问题。当然，我已经为成功执行的作业添加了对运行 cleanup cronjob 的支持，但这只是解决方案的一部分。

我知道k8s 上的 TTL 功能：https ://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#ttl-mechanism-for-finished-jobs 仍处于 alpha阶段状态，因此在 EKS k8s 集群上不可用。

我希望在该特定 pod（容器/s）上指定的请求/限制也被“释放”，但是在查看 Grafana 上的 k8s 指标时，我发现这不是真的。

这是一个示例（绿线标记当前资源使用情况，黄色标记资源请求，而蓝色标记资源限制）： 在此处输入图像描述

我的问题是：

  • 这是预期的行为吗？
  • 如果是，在作业（pod）执行完成后请求/限制没有释放的技术原因是什么？
4

2 回答 2

3

我已经对我的环境进行了“负载”测试，以测试在已完成作业（pod）上分配的请求/限制是否确实会对我设置的 ResourceQuota 产生影响。

这就是我的 ResourceQuota 的样子：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 2Gi
    limits.cpu: "2"
    limits.memory: 3Gi

这是每个 k8s 作业上存在的 cpu/内存的请求/限制（准确地说是在由作业启动的 Pod 中运行的容器上）：

resources:
  limits:
    cpu: 250m
    memory: 250Mi
  requests:
    cpu: 100m
    memory: 100Mi

测试结果：

  • 当前运行的作业数：66
  • CPU 请求的预期总和（如果问题的假设是正确的）~= 6.6m
  • 内存请求的预期总和（如果问题的假设是正确的）~= 6.6Mi
  • CPU 限制的预期总和（如果问题的假设是正确的）~= 16.5
  • 内存限制的预期总和（如果问题的假设是正确的）~= 16.5

我创建了显示以下内容的 Grafana 图表：

一个命名空间中作业的 CPU 使用率/请求/限制

sum(rate(container_cpu_usage_seconds_total{namespace="${namespace}", container="myjob"}[5m]))
sum(kube_pod_container_resource_requests_cpu_cores{namespace="${namespace}", container="myjob"})
sum(kube_pod_container_resource_limits_cpu_cores{namespace="${namespace}", container="myjob"})

一个命名空间中作业的内存使用/请求/限制

sum(rate(container_memory_usage_bytes{namespace="${namespace}", container="myjob"}[5m]))
sum(kube_pod_container_resource_requests_memory_bytes{namespace="${namespace}", container="myjob"})
sum(kube_pod_container_resource_limits_memory_bytes{namespace="${namespace}", container="myjob"})

这是图表的样子： 在此处输入图像描述

根据该图，请求/限制会累积并远远超出 ResourceQuota 阈值。但是，我仍然可以毫无问题地运行新工作。

此时，我开始怀疑显示的指标是什么，并选择检查指标的其他部分。具体来说，我使用了以下一组指标：

中央处理器：

sum (rate(container_cpu_usage_seconds_total{namespace="$namespace"}[1m]))
kube_resourcequota{namespace="$namespace", resource="limits.cpu", type="hard"}
kube_resourcequota{namespace="$namespace", resource="requests.cpu", type="hard"}
kube_resourcequota{namespace="$namespace", resource="limits.cpu", type="used"}
kube_resourcequota{namespace="$namespace", resource="requests.cpu", type="used"}

记忆：

sum (container_memory_usage_bytes{image!="",name=~"^k8s_.*", namespace="$namespace"})
kube_resourcequota{namespace="$namespace", resource="limits.memory", type="hard"}
kube_resourcequota{namespace="$namespace", resource="requests.memory", type="hard"}
kube_resourcequota{namespace="$namespace", resource="limits.memory", type="used"}
kube_resourcequota{namespace="$namespace", resource="requests.memory", type="used"}

这是图表的样子： 在此处输入图像描述

结论：

从这个屏幕截图中可以清楚地看出，一旦负载测试完成并且作业进入完成状态，即使 pod 仍然存在(with READY: 0/1 and STATUS: Completed)，cpu/memory request/limits 将被释放并且没有更长的表示需要计算到 ResourceQuota 阈值中的约束。这可以通过观察图表上的以下数据来看出：

CPU allocated requests
CPU allocated limits
Memory allocated requests
Memory allocated limits

当系统上发生负载并创建新作业时，所有这些都会增加，但一旦作业完成就会恢复到以前的状态（即使它们没有从环境中删除）

换句话说，只有当作业（及其对应的 Pod）处于 RUNNING 状态时，才会考虑 CPU/内存的资源使用/限制/请求

于 2020-03-07T20:44:01.593 回答
1

如果你这样做kubectl get pod了，你可以看到由 Job 创建的 pod 仍然存在于列表中，例如：

NAME                                                            READY   STATUS      RESTARTS   AGE
cert-generator-11b35c51b71ea3086396a780dbf20b5cd695b25d-wvb7t   0/1     Completed   0          57d

因此，pod 仍然使用任何资源请求/限制。要释放资源，您可以手动删除 pod。它将在下次作业运行时重新创建。

您还可以通过在作业上使用将作业（以及因此的 pod）配置为在成功和/或失败时从历史记录中自动删除.spec.ttlSecondsAfterFinished。但是，您将无法知道工作是否成功。

或者，如果您的作业实际上是由 CronJob 创建的，那么您可以将作业（以及 Pod）配置为自动删除.spec.successfulJobsHistoryLimit并.spec.failedJobsHistoryLimit在 CronJob 上。

于 2020-03-07T09:06:23.190 回答