Go GKE集装箱被'炸死；内存cgroup内存不足'；但监测、本地测试和pprof显示使用量远远低于限制

我最近将一个新的容器映像推送到我的一个GKE部署中，并注意到API延迟增加，请求开始返回502

查看日志，我发现由于以下原因，容器开始崩溃：

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

从内存使用率图上看，这些豆荚总共使用的内存并没有超过50MB。我最初的资源请求是：

...
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二进制文件中的更改，没有明显的内存泄漏。当我在本地运行它时，它最多使用80MB的内存，即使是在与生产中相同的请求负载下

我从GKE控制台得到的上图也显示了pod使用的内存远低于1GB的限制

所以我的问题是：当GKE监控和本地运行它只使用1GB限制外的80MB时，是什么原因导致GKE终止我的OOM进程

==编辑===

添加同一中断的另一个图表。这一次将吊舱中的两个容器分开。如果我理解正确，这里的指标是：

2021年4月26日编辑 我尝试将部署yaml中的resources字段更新为请求的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\u server\u部署进行更新后，它得到了相同的结果。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内存的容器。但是，这些指标再次表明，容器仅使用2MB内存：

我再一次被难住了，因为即使在负载下，当我在本地运行它时，这个二进制文件也不会使用超过80MB的内存

我还试着运行

go工具pprof/debug/pprof/heap

。它显示了几个不同的值，因为库伯内特斯不断地敲打容器。但没有一个内存高于~20MB，而且内存使用率也不正常

编辑04/27 我尝试设置pod中两个容器的请求=限制：

 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显示使用情况

更新04/30 通过一个接一个地仔细检查我最近的提交，我找到了引起这个问题的变化

在《冒犯的承诺》中，我有几句话

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

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

其中

picture.Resize

最终调用。 我把它改成：

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

这解决了我眼前的问题，容器现在运行良好。但它并没有回答我最初的问题：

为什么这些线导致GKE打开我的容器

为什么GKE内存指标显示一切正常

我猜是因为

当系统过度提交时，QoS类确定哪个pod首先被终止，以便将释放的资源分配给更高优先级的pod

在您的情况下，pod的QoS将是

每个正在运行的进程都有一个OutOfMemory（OOM）分数。系统通过比较所有正在运行的进程的OOM分数来选择要终止的进程。当需要释放内存时，得分最高的进程将被终止。有关如何计算

分数的详细信息，请参阅

如果同时在
Burstable
类中，哪个吊舱将首先被杀死？

简言之，系统将以百分比的方式杀死一个使用其请求的内存多于另一个的内存

Pod A

used: 90m
requests: 100m
limits: 200m

Pod A
将在
Pod B
之前被杀死，因为它使用了90%的请求内存，而
Pod B
只使用了75%的请求内存。
这里的资源规范是OOM的根本原因

在Kubernetes中，所需内存和有限内存的定义不同。所需内存是
必须拥有的内存
。有限内存是容器可以装入的内存。但是有限的内存不能保证容器可以拥有这些资源

在大多数生产系统中，不建议有限资源和所需资源相差太大。比如你的情况,

请求：
cpu：“150米”
内存：“80Mi”
限制：
中央处理器：“1”
内存：“1024Mi”

容器只能有80Mi保证内存，但它可以以某种方式突发到1024Mi。节点可能没有足够的内存用于容器，容器本身将进入OOM

因此，如果您想改善这种情况，您需要将资源配置为如下所示

请求：
cpu：“150米”
内存：“1024Mi”
限制：
中央处理器：“1”
内存：“1024Mi”

请注意，CPU很好，因为在CPU时间较短的情况下，不会导致进程死亡。但OOM将导致进程被终止

如上所述，这与pod中的服务质量有关。通常，对于大多数最终用户来说，您应该始终将容器配置为保证类，即request==limited。在将其配置为bursted类之前，您可能需要一些理由。
可能是临时分配大块？@BurakSerdar我想这是可能的，尽管我很难理解为什么Go会分配超过1GB的内存，而不是50MB。为了不显示在内存图中，分配必须是如何“临时”的？内存图显示的是什么？运行时报告的已分配内存总量，还是操作系统内存总量？如果是操作系统内存，你是对的，它应该显示在图表中。如果它是运行时报告的活动分配内存的度量，那么alloc和free of a 500M数据可以解释它。如果我理解正确，它会显示操作系统内存。我添加了一个链接，指向更详细的图表和度量的定义。我猜一种可能性是它在60年代的sampl之间分配了1GB内存
Pod A

used: 90m
requests: 100m
limits: 200m

Pod B

used: 150m
requests: 200m
limits: 400m