Kubernetes Memory Requests超标引发的血案

Namespace quotas（名称空间配额）

Kubernetes 允许管理人员对特定的命令空间（namespace）设置配额，以此对资源使用进行严格限制。如果在某命名空间下设置了 CPU 请求配额（request quotas），那么该命名空间下的所有 Pod 都需要在其定义中设置 CPU 资源情况，否则将不会对其进行调度。

pod requests and limits

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
 name: redis
 labels:
   name: redis-deployment
   app: example-voting-app
spec:
 replicas: 1
 selector:
   matchLabels:
    name: redis
    role: redisdb
    app: example-voting-app
 template:
   spec:
     containers:
       - name: redis
         image: redis:5.0.3-alpine
         resources:
           limits:
             memory: 600Mi
             cpu: 1
           requests:
             memory: 300Mi
             cpu: 500m
       - name: busybox
         image: busybox:1.28
         resources:
           limits:
             memory: 200Mi
             cpu: 300m
           requests:
             memory: 100Mi
             cpu: 100m

现象

线程池里的线程无法继续进行大规模的内存操作

监控（Prometheus）

紫色是代表应用的实际内存请求代销
红色的是k8s限制的大小
黄色的是代表pod的实际内存大小

Kubernetes限制是针对每个容器而不是每个 Pod。

总结

在工作中使用了一段时间的 Kubernetes 集群后，发现合理设置 requests 和 limits 对应用程序和集群性能至关重要。

理想情况下，应用程序应该持续准确地使用请求(requests)的资源量。但现实往往不可预估，容器对资源的使用从来都不是经常性的或可预测的。一般可以考虑在求值上下浮动25％视为运行良好情况。如果资源使用量远低于设置的请求量，则资源存在极大浪费。如果资源使用量比请求量很多，则存在应用程序和节点性能下降风险。