GKE 容器被“Memory cgroup out of memory”殺死，但監控、本地測試和 pprof 顯示使用量遠低於限制

Question

我最近將一個新的容器映像推送到我的一個 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

查看 memory 使用圖，看起來這些 pod 使用的 memory 總和不超過 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 二進制文件的變化，沒有明顯的 memory 泄漏。 當我在本地運行它時，它最多使用 80MB 的 memory，即使在與生產中相同的請求負載下也是如此。

我從 GKE 控制台獲得的上圖也顯示了 pod 使用的容量遠低於 1GB memory 限制。

所以我的問題是：當 GKE 監控和本地運行僅使用 1GB 限制中的 80MB 時，什么可能導致 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 memory 的容器。 但同樣，指標顯示該容器僅使用 2MB 的 memory：

我再次感到難過，因為即使在負載下，當我在本地運行它時，這個二進制文件也不會使用超過 80MB。

我還嘗試運行go tool pprof <url>/debug/pprof/heap 。 它顯示了幾個不同的值，因為 Kubernetes 不斷顛簸容器。 但沒有一個高於 ~20MB 並且沒有 memory 使用異常

編輯 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

memory 指標仍顯示單位數 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 memory 指標顯示一切正常？

Answer 1

我猜這是由Pod QoS class引起的

當系統過度使用時，QoS 類確定首先殺死哪個 pod，以便可以將釋放的資源分配給更高優先級的 pod。

在您的情況下，您的 pod 的 QoS 將是Burstable

每個正在運行的進程都有一個 OutOfMemory(OOM) 分數。 系統通過比較所有正在運行的進程的OOM分數來選擇要殺死的進程。 當 memory 需要被釋放時，得分最高的進程將被殺死。 score計算方法請參考kernel oom 分數是如何計算的？ .

如果兩者都在Burstable class 中，哪個 pod 將首先被殺死？

簡而言之，系統將以百分比方式殺死使用更多請求的 memory 的一個。

Pod A

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

Pod B

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

Pod A將在Pod B之前被殺死，因為它使用了請求的 memory 的 90%，而Pod B僅使用了請求的 memory 的 75%。

Answer 2

這里的資源規范是 OOM 的根本原因。

在 Kubernetes 中，必需和受限 memory 的定義不同。 必選 memory 是 memory must-have 。 限定memory是容器可以爆破的memory。 但是有限的 memory 並不能保證容器可以擁有該資源。

在大多數生產系統中，不建議有限資源和所需資源相差太大。 例如，在您的情況下，

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

容器只能保證 80Mi memory 但它可以以某種方式爆發到 1024Mi。 節點可能沒有足夠的 memory 供容器使用，容器本身會 go 進入 OOM。

所以，如果你想改善這種情況，你需要把資源配置成這樣。

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

請注意，CPU 很好，因為您不會在低 CPU 時間下殺死進程。 但是OOM會導致進程被殺。

正如上面提到的答案，這與吊艙中的服務質量有關。 一般來說，對於大多數最終用戶，您應該始終將您的容器配置為保證 class，即請求 == 受限。 在將其配置為突發 class 之前，您可能需要有一些理由。