如何在Kubernetes中OOM所有BestEffort Pod？

Question

为了演示kubelet的驱逐行为，我尝试部署一个Kubernetes工作负载，它将消耗内存，直到kubelet由于内存压力而驱逐所有BestEffort Pod，但不会杀死我的工作负载(或者至少不会在BestEffort Pod之前)。

下面是我最好的尝试。它写入两个tmpfs卷(因为在缺省情况下，tmpfs卷的限制是节点总内存的一半)。100来自于--eviction-hard=memory.available<100Mi设置在kubelet上的事实：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fallocate
  namespace: developer
spec:
  selector:
    matchLabels:
      app: fallocate
  template:
    metadata:
      labels:
        app: fallocate
    spec:
      containers:
      - name: alpine
        image: alpine
        command:
        - /bin/sh
        - -c
        - |
          count=1
          while true
          do          

            AVAILABLE_DISK_KB=$(df /cache-1 | grep /cache-1 | awk '{print $4}')
            AVAILABLE_DISK_MB=$(( $AVAILABLE_DISK_KB / 1000 ))
            AVAILABLE_MEMORY_MB=$(free -m | grep Mem | awk '{print $4}')
            MINIMUM=$(( $AVAILABLE_DISK_MB > $AVAILABLE_MEMORY_MB ?  $AVAILABLE_MEMORY_MB : $AVAILABLE_DISK_MB ))
            fallocate -l $(( $MINIMUM - 100 ))MB /cache-1/$count

            AVAILABLE_DISK_KB=$(df /cache-2 | grep /cache-2 | awk '{print $4}')
            AVAILABLE_DISK_MB=$(( $AVAILABLE_DISK_KB / 1000 ))
            AVAILABLE_MEMORY_MB=$(free -m | grep Mem | awk '{print $4}')
            MINIMUM=$(( $AVAILABLE_DISK_MB > $AVAILABLE_MEMORY_MB ?  $AVAILABLE_MEMORY_MB : $AVAILABLE_DISK_MB ))
            fallocate -l $(( $MINIMUM - 100 ))MB /cache-2/$count            

            count=$(( $count+1 ))
            sleep 1

          done
        resources:
          requests:
            memory: 2Gi
            cpu: 100m
          limits:
            cpu: 100m
        volumeMounts:
        - name: cache-1
          mountPath: /cache-1
        - name: cache-2
          mountPath: /cache-2
      volumes:
      - name: cache-1
        emptyDir:
          medium: Memory
      - name: cache-2
        emptyDir:
          medium: Memory

此脚本的目的是耗尽内存，使Node内存使用量达到硬驱逐阈值边界，从而导致kubelet开始驱逐。它会逐出一些BestEfforts Pod，但在大多数情况下，工作负载会在所有BestEffort Pod被逐出之前被杀死。有没有更好的方法来做这件事？

我在集群版本为1.9.3-gke.0的GKE上运行。

编辑：

我也尝试过使用simmemleak：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: simmemleak
  namespace: developer
spec:
  selector:
    matchLabels:
      app: simmemleak
  template:
    metadata:
      labels:
        app: simmemleak
    spec:
      containers:
      - name: simmemleak
        image: saadali/simmemleak
        resources:
          requests:
            memory: 1Gi
            cpu: 1m
          limits:
            cpu: 1m

但是在任何驱逐之前，这个工作负载一直在消亡。我认为问题在于kubelet还没来得及做出反应，它就被内核杀死了。

Answer 1

为了避免系统对象模型在kubelet驱逐之前生效，您可以配置kubepod内存限制--system-reserved和--enforce-node-allocatable Read more。

例如，Node有32G的内存，配置为将kubepods的内存限制为20G

--eviction-hard=memory.available<500Mi

Answer 2

我在Kubernetes docs上找到了这个，我希望它能有所帮助：

kubelet可能不会立即观察到内存压力，kubelet当前会定期轮询cAdvisor以收集内存使用情况统计数据。

如果在该窗口内内存使用量迅速增加，则kubelet可能不能足够快地观察到MemoryPressure，且OOMKiller仍将被调用。

我们打算在未来的版本中集成memcg通知API来减少这种延迟，而不是让内核在超过阈值时立即通知我们。

如果您不想实现极端的利用率，而是一种合理的过度使用措施，则此问题的可行解决方法是将回收阈值设置为大约75%的容量。

这增加了此功能防止系统OOM的能力，并促进了工作负载的驱逐，以便群集状态可以重新平衡。

==EDIT==：由于OOM和kubelet之间似乎有一场竞赛，而且您的脚本分配的内存增长得比Kubelet意识到pod需要被驱逐的时间更快，所以在脚本中尝试更慢地分配内存可能是明智的。