GKE容器异常终止，显示使用量远低于内存限制

在 GKE 部署中，容器由于内存不足（OOM）而崩溃，尽管监控和本地运行显示内存使用量仅为 1GB 限制之外的 80MB。资源请求和限制已更新为 1GB，但容器仍被终止。原因尚不清楚，因为内存指标显示使用量很低，并且 go 工具 pprof 未显示异常内存使用情况。

我最近将一个新的容器映像推送到我的一个 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 所使用的内存合计并没有超过 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 而终止我的进程？

===编辑===

添加同一中断的另一个图表。这次将 pod 中的两个容器分开。如果我理解正确的话，这里的指标是不可驱逐的容器/内存/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 和 1gb ram 限制，如 paul 和 ryan 的建议：

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 内存的容器。但同样，指标显示容器仅使用 2mb 内存：

我再次被难住了，因为即使在负载下，当我在本地运行该二进制文件时，它也不会使用超过 80mb。

我还尝试运行 go 工具 pprof /debug/pprof/heap。当 kubernetes 不断地破坏容器时，它显示了几个不同的值。但没有一个高于~20mb，并且内存使用量没有异常

编辑 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 的使用情况。

更新 04/30

通过煞费苦心地逐一检查我的最新提交，我查明了似乎导致此问题的更改。

在有问题的提交中，我有几行，例如

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 我的容器？
2. 为什么 gke 内存指标显示一切正常？

正确答案

确保“保证”的 qos 等级对您的场景没有帮助。您的进程之一会导致父 cgroup 超出其内存限制（反过来由您针对相应容器指定的内存限制值设置），并且 oom 杀手会终止它。这不是 pod 驱逐，因为您可以在日志中清楚地看到 oom 杀手的商标消息。在这种情况下，如果另一个 pod 分配了如此多的内存，导致节点面临内存压力，那么“保证”的 qos 类别将会有所帮助 - 在这种情况下，您的“保证”的 pod 将不会受到影响。但就您而言，kubelet 从未在这一切中得到任何消息 - 例如决定完全驱逐 pod - 如 OOM killer acts faster。

burak serdar 在其评论中有一个很好的观点 - 大内存块的临时分配。考虑到在您的情况下，从您粘贴的消息中收集数据的分辨率是 60 秒，情况很可能就是这样。那是很多时间。不到 1 秒即可轻松充满 gb ram。我的假设是，内存“峰值”永远不会被渲染，因为指标永远不会及时收集（即使您直接查询 cadvisor，这也会很棘手，因为它收集指标的分辨率为 10-15 秒）。

如何了解更多正在发生的事情？一些想法：

• 有一些工具可以显示应用程序实际分配的数量，直至框架级别。在 .net 中，dotmemory 是一种常用的工具，可以在容器内运行并捕获发生的情况。 go 可能有一个等价的东西。这种方法的问题在于，当容器被 oomkilled 时，该工具也会随之被删除
• 编写有关您自己的应用内内存使用情况的详细信息。 Here 你会发现一个电影，它捕获了一个进程分配内存，直到其父容器被 oom 杀死。相应的 .net 应用程序会不时地将其使用的内存量写入控制台，即使容器不再存在，kubernetes 日志也会显示这些内存量，从而可以查看发生了什么
• 限制应用程序，使其处理少量数据（例如，如果每分钟仅处理 1 张图片，则暂时从内存的角度来看会发生什么情况）
• 查看详细的 oom killer 内核日志以查看 cgroup 中的所有进程。在一个容器内拥有多个进程是完全有效的（就像在该容器中除了 pid 1 之外的其他进程一样），并且 oom 杀手很可能杀死其中任何一个进程。在这种情况下，您可能会偶然发现 unexpected twists。然而，在您的场景中，主进程似乎已终止，否则容器不会被 oomkilled，因此这种情况不太可能发生。

只是为了完整性：底层框架可以强制执行比容器内存限制更低的限制。例如。在 .net 中，当在具有内存限制的容器中运行时，该比例为 75%。换句话说，在具有 2,000 mib 限制的容器内分配内存的 .net 应用程序将在 1,500 mib 时出错。但在这种情况下，您会得到退出代码 139 (sigsegv)。这似乎并不适用于此，因为 oom 杀手会终止进程，并且从内核日志中可以清楚地看到所有 1 gib 均已实际使用 (anon-rss:1043688kb)。据我所知，go 还没有类似的设置，尽管社区多次要求这样做。

我猜测这是由 Pod QoS class 引起的

当系统过度使用时，qos 类别会确定哪个 pod 首先被终止，以便将释放的资源分配给更高优先级的 pod。

在您的情况下，您的 pod 的 qos 将为 Burstable

每个正在运行的进程都有一个 outofmemory(oom) 分数。系统通过比较所有正在运行的进程的oom分数来选择要杀死的进程。当需要释放内存时，得分最高的进程将被杀死。 score的计算方法请参考How is kernel oom score calculated?。

如果两个 pod 都属于 burstable 类，那么哪个 pod 将首先被杀死？

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

pod a

used: 90mi
requests: 100mi
limits: 200mi

Pod B

used: 150Mi
requests: 200Mi
limits: 400Mi

pod a 将在 pod b 之前被杀死，因为它使用了其请求内存的 90%，而 pod b 仅使用了其请求内存的 75%。

今天关于《GKE容器异常终止，显示使用量远低于内存限制》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！