[英]GKE container killed by 'Memory cgroup out of memory' but monitoring, local testing and pprof shows usage far below limit
我最近将一个新的容器映像推送到我的一个 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.
我尝试将部署 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 使用异常
我尝试为 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 的使用情况。
我通过煞费苦心地逐一检查我的最新提交来确定似乎导致此问题的更改。
在有问题的提交中,我有几行像
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)
这解决了我的直接问题,容器现在运行良好。 但它没有回答我原来的问题:
我猜这是由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%。
这里的资源规范是 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 之前,您可能需要有一些理由。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.