kubernetes GKE容器被“Memory cgroup out of memory”终止,但监视、本地测试和pprof显示使用率远低于限制

iqih9akk  于 2022-11-21  发布在  Kubernetes
关注(0)|答案(3)|浏览(349)

我最近将一个新的容器映像推到我的一个GKE部署中,并注意到API延迟增加,请求开始返回502。
通过查看日志,我发现容器由于OOM而开始崩溃:

Memory cgroup out of memory: Killed process 2774370 (main) total-vm:1801348kB, anon-rss:1043688kB, file-rss:12884kB, shmem-rss:0kB, UID:0 pgtables:2236kB oom_score_adj:980

从内存使用图来看,pod总共使用的内存不超过50 MB。我最初的资源请求是:

...
spec:
...
  template:
...
    spec:
...
      containers:
      - name: api-server
...
        resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "150m"
            memory: "80Mi"
          limits:
            cpu: "1"
            memory: "1024Mi"
      - name: cloud-sql-proxy
        # It is recommended to use the latest version of the Cloud SQL proxy
        # Make sure to update on a regular schedule!
        image: gcr.io/cloudsql-docker/gce-proxy:1.17
        resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "100m"
...

然后,我尝试将API服务器的请求提升到1GB,但没有任何帮助。最后,将容器映像恢复到以前的版本才有帮助:

查看golang二进制文件中的变化,没有明显的内存泄漏。当我在本地运行它时,它最多使用80 MB内存,即使在负载与生产中相同的请求下。
我从GKE控制台得到的上图也显示了吊舱使用的内存远远低于1GB的限制。
所以我的问题是:当GKE在本地监视和运行OOM进程时,它只使用了1GB限制中的80 MB,是什么原因导致GKE终止了我的OOM进程?
===编辑===

添加同一中断的另一个图。这次将pod中的两个容器分开。如果我理解正确的话,这里的度量是non-evictable container/memory/used_bytes

container/memory/used_bytes GA
Memory usage
GAUGE, INT64, By
k8s_container   Memory usage in bytes. Sampled every 60 seconds.
memory_type: Either `evictable` or `non-evictable`. Evictable memory is memory that can be easily reclaimed by the kernel, while non-evictable memory cannot.

编辑2021年4月26日

我尝试将部署yaml中的资源字段更新为请求的1GB RAM和Paul和Ryan建议的1GB RAM限制:

resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "150m"
            memory: "1024Mi"
          limits:
            cpu: "1"
            memory: "1024Mi"

不幸的是,在使用kubectl apply -f api_server_deployment.yaml更新后,结果相同:

{
 insertId: "yyq7u3g2sy7f00"  
 jsonPayload: {
  apiVersion: "v1"   
  eventTime: null   
  involvedObject: {
   kind: "Node"    
   name: "gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy"    
   uid: "gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy"    
  }
  kind: "Event"   
  message: "Memory cgroup out of memory: Killed process 1707107 (main) total-vm:1801412kB, anon-rss:1043284kB, file-rss:9732kB, shmem-rss:0kB, UID:0 pgtables:2224kB oom_score_adj:741"   
  metadata: {
   creationTimestamp: "2021-04-26T23:13:13Z"    
   managedFields: [
    0: {
     apiVersion: "v1"      
     fieldsType: "FieldsV1"      
     fieldsV1: {
      f:count: {
      }
      f:firstTimestamp: {
      }
      f:involvedObject: {
       f:kind: {
       }
       f:name: {
       }
       f:uid: {
       }
      }
      f:lastTimestamp: {
      }
      f:message: {
      }
      f:reason: {
      }
      f:source: {
       f:component: {
       }
       f:host: {
       }
      }
      f:type: {
      }
     }
     manager: "node-problem-detector"      
     operation: "Update"      
     time: "2021-04-26T23:13:13Z"      
    }
   ]
   name: "gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy.16798b61e3b76ec7"    
   namespace: "default"    
   resourceVersion: "156359"    
   selfLink: "/api/v1/namespaces/default/events/gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy.16798b61e3b76ec7"    
   uid: "da2ad319-3f86-4ec7-8467-e7523c9eff1c"    
  }
  reason: "OOMKilling"   
  reportingComponent: ""   
  reportingInstance: ""   
  source: {
   component: "kernel-monitor"    
   host: "gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy"    
  }
  type: "Warning"   
 }
 logName: "projects/questions-279902/logs/events"  
 receiveTimestamp: "2021-04-26T23:13:16.918764734Z"  
 resource: {
  labels: {
   cluster_name: "api-us-central-1"    
   location: "us-central1-a"    
   node_name: "gke-api-us-central-1-e2-highcpu-4-nod-dfe5c3a6-c0jy"    
   project_id: "questions-279902"    
  }
  type: "k8s_node"   
 }
 severity: "WARNING"  
 timestamp: "2021-04-26T23:13:13Z"  
}

Kubernetes似乎立刻就把使用1GB内存的容器扼杀了。但是,指标再次显示,容器只使用了2 MB内存:

我再次被难住了,因为即使在负载下,当我在本地运行它时,这个二进制文件也不会使用超过80 MB的空间。
我也试着运行go tool pprof <url>/debug/pprof/heap。它显示了几个不同的值,因为Kubernetes一直在折腾容器。但没有一个高于~ 20 MB,内存使用也没有异常

编辑04/27

我尝试为pod中的两个容器设置request=limit:

requests:
   cpu: "1"
   memory: "1024Mi"
 limits:
   cpu: "1"
   memory: "1024Mi"
...
requests:
  cpu: "100m"
  memory: "200Mi"
limits:
  cpu: "100m"
  memory: "200Mi"

但也没有成功:

Memory cgroup out of memory: Killed process 2662217 (main) total-vm:1800900kB, anon-rss:1042888kB, file-rss:10384kB, shmem-rss:0kB, UID:0 pgtables:2224kB oom_score_adj:-998

并且内存度量仍然以单位MB显示使用情况。

2030年4月更新

我通过一个接一个地仔细检查我最近的提交,找到了导致这个问题的变化。
在这个令人不快的提交中,我有几行

type Pic struct {
        image.Image
        Proto *pb.Image
}
...

pic.Image = picture.Resize(pic, sz.Height, sz.Width)
...

其中picture.Resize最终调用resize.Resize。我将其更改为:

type Pic struct {
        Img   image.Image
        Proto *pb.Image
 }
...
pic.Img = picture.Resize(pic.Img, sz.Height, sz.Width)

这解决了我眼前的问题,容器现在运行良好。但它并没有回答我最初的问题:
1.为什么这些行会导致GKE对我的容器进行OOM?
1.为什么GKE内存指标显示一切正常?

u5rb5r59

u5rb5r591#

我猜是Pod QoS class引起的
当系统过量使用时,QoS类将确定首先终止哪个pod,以便将释放的资源分配给优先级更高的pod。
在本例中,单元的QoS为Burstable
每个正在运行的进程都有一个OutOfMemory(OOM)分数。系统通过比较所有正在运行的进程的OOM分数来选择要终止的进程。当需要释放内存时,具有最高分数的进程将被终止。有关如何计算score的详细信息,请参阅How is kernel oom score calculated?

如果两个单元都属于Burstable类,将首先终止哪个单元?

简而言之,系统将以百分比方式杀死使用了比另一个更多的请求内存的一个。
第一个
Pod A将在Pod B之前被终止,因为它使用了其所请求内存的90%,而Pod B仅使用了其所请求内存的75%。

vs91vp4v

vs91vp4v2#

确保QoS类别为“保证”在您的场景中没有帮助。您的一个进程导致父cgroup超过其内存限制-反过来由您针对相应容器指定的内存限制值设置-并且OOM killer终止了它。这不是pod逐出,因为您可以在日志中清楚地看到OOM killer的标志性消息。“保证”如果另一个pod分配了太多的内存,使节点处于内存压力之下,QoS类会有所帮助--在这种情况下,您的“有保证”pod将被备用。但在您的情况下,Kubelet永远不会得到任何消息--比如决定完全驱逐pod--因为OOM杀手的动作更快。
塞尔达尔在其评论中有一个很好的观点-临时分配大内存块,假设从粘贴的消息中收集数据的分辨率是60 s。这是一个很长的时间。人们可以在不到1 s的时间内轻松地填充GB的RAM。我的假设是,内存“尖峰”永远不会呈现,因为指标永远不会及时收集(即使您直接查询cAdvisor,也会很棘手,因为它收集度量的分辨率为10-15秒)。
如何了解更多信息?以下是一些想法:

  • 有一些工具可以显示应用程序实际分配了多少,一直到框架级别。在.NET中,dotMemory是一个常用的工具,它可以在容器内运行并捕获所发生的事情。Go语言可能也有类似的工具。这种方法的问题是,当容器被OOMCilled时,工具也会随之停止
  • 在你自己的应用中记录内存使用的详细信息。在这里你会发现一个电影,它捕捉了一个分配内存的进程,直到其父容器被OOM杀死。相应的.NET应用会不时地向控制台写入它使用的内存量,即使容器不再存在,Kubernetes日志也会显示这些内存量,这样就可以看到发生了什么
  • 调节应用程序,使其处理少量数据(例如,如果您每分钟仅处理1张图片,则从内存Angular 暂时查看会发生什么情况)
  • 查看详细的OOM killer内核日志,以查看cgroup中的所有进程。(就像在该容器中PID为1的进程之外的其他进程中一样),OOM killer很可能会杀死其中的任何一个进程。在这种情况下,您可能会遇到意想不到的转折。但在您的场景中,似乎是主进程被终止了,否则容器不会被OOM杀死,因此这种情况不太可能发生。

为了完整起见:基础框架可以强制实施比容器内存限制更低的限制(s)。例如,在.NET中,当在具有内存限制的容器中运行时,这是75%。换句话说,在具有2,000 MiB限制的容器中分配内存的.NET应用程序将在1处出错,500 MiB。但在这种情况下,您得到的退出代码为139(SIGSEGV)。这似乎不适用于这里,因为OOM killer终止了进程,而且从内核日志中可以清楚地看到所有的1GiB实际上都被使用了(anon-rss:1043688kB)。据我所知,Go语言还没有类似的设置,尽管社区一再要求这样做。

ix0qys7i

ix0qys7i3#

此处的资源规范是OOM的根本原因。
在Kubernetes中,所需内存和有限内存的定义是不同的。所需内存是must-have内存。有限内存是容器可以突发到的内存。但有限内存并不保证容器可以拥有这些资源。
在大多数生产系统中,不建议有限资源和所需资源相差太大。例如,在您的情况下,

requests:
  cpu: "150m"
  memory: "80Mi"
limits:
  cpu: "1"
  memory: "1024Mi"

容器只能有80Mi的保证内存,但它可以以某种方式突然增加到1024Mi。节点可能没有足够的内存用于容器,容器本身将进入OOM。
因此,如果您想改善这种情况,您需要将资源配置为如下所示。

requests:
  cpu: "150m"
  memory: "1024Mi"
limits:
  cpu: "1"
  memory: "1024Mi"

请注意,CPU是好的,因为你不会得到进程杀死在低CPU时间。但OOM将导致进程杀死。
正如上面提到的答案,这与单元中的服务质量有关。通常,对于大多数最终用户,您应该始终将容器配置为保证类,即requested == limited。在将其配置为突发类之前,您可能需要有一些理由。

相关问题