post-mortem机制

生产问题从不有趣。 它们似乎总是在您不上班时发生，原因似乎总是很愚蠢。 我们最近在生产Kubernetes集群中遇到了节点内存不足的问题，但是该节点很快恢复了，没有任何明显的中断。 在这个故事中，我们将探讨集群中发生的特定问题，影响是什么以及将来如何避免该问题。

首先，有一点背景。 我为Blue Matador工作，这是AWS和Kubernetes的监视警报自动化服务。 我们在带有Kubernetes的AWS中运行的自己的系统上使用我们的产品。 这个故事是由我们一位才华横溢的软件工程师创建的，用他自己的话说。

第一次发生

下午5:12-2019年6月15日星期六

Blue Matador创建了一个警报，说我们的生产集群中的一个Kubernetes节点发生了SystemOOM事件。

下午5:16

Blue Matador创建一个警告，指出发生SystemOOM事件的节点的EBS突发平衡在根卷上较低。 虽然突发突发事件是在SystemOOM事件之后发生的，但实际的CloudWatch数据显示突发均衡处于下午5:02的最低点。 延迟的原因是EBS指标始终落后10-15分钟，因此我们的系统无法实时捕获所有内容。

下午5:18

这是我实际上开始注意到警报和警告的时间。 我快速kubectl让pods看到了影响，并很惊讶地发现我们的零个 app pods死亡了。 使用kubectl顶级节点也不会表明所讨论的节点存在内存问题-它已经恢复，内存使用率约为60％。 就在5点钟之后，我不希望Session IPA变热。 在确认该节点运行状况良好并且没有豆荚受到影响之后，我认为一定有幸。 绝对可以在星期一进行调查。

这是那天晚上我和CTO之间的整个Slack对话：

第二次发生

下午6:02-2019年6月16日星期日

蓝色斗牛士生成警报，指出另一个节点发生SystemOOM事件。 我的CTO一定一直在盯着他的手机，因为他会立即做出响应，并且由于他无法访问计算机（让我重新安装Windows？），我不得不参加这次活动。 再一次，一切似乎都很好。 我们的所有Pod都没有被杀死，节点内存使用率略低于70％。

下午6:06

蓝色斗牛士再次为EBS胸围平衡发出警告。 由于这是我们遇到问题的第二天，所以我不能放过这张幻灯片。 CloudWatch看起来与以前相同，突发问题在问题发生前约2.5小时内下降。

下午6:11

我登录Datadog并查看内存消耗。 我注意到有问题的节点确实在SystemOOM事件发生之前确实具有很高的内存使用率，并且能够快速地将其跟踪到我们熟练的豆荚舱。

在SystemOOM事件发生时，您可以清楚地看到内存使用量的急剧下降。 我推断这些Pod是占用所有内存的内存，当SystemOOM发生时，Kubernetes能够确定这些Pod可以被杀死并重新启动以回收它所需的所有内存，而不会影响我的其他Pod。 Kubernetes非常令人印象深刻。

那么，为什么在星期六尝试查看哪些豆荚已重新启动时却没有注意到这一点？ 我在一个单独的命名空间中运行流畅的Sudologic Pod，但我并不认为要匆匆忙忙地看那里。

要点1：检查重新启动的Pod时，请检查所有命名空间

有了这些信息，我能够计算出其他节点在接下来的24小时内不会用完内存，但是我继续进行并重新启动所有Sumicologic Pod，以便它们在内存不足时开始使用。 Sprint计划是第二天早上，因此我可以将这个问题纳入我的正常工作时间，而不必在周日晚上过分强调。

下午11:00

刚刚完成了《黑镜》的新剧集之一（我实际上很喜欢麦莉的那一集），并决定进行检查。 内存使用情况看起来不错，我绝对可以让事情整夜解决。

修复

在星期一，我可以花一些时间解决这个问题。 我绝对不想每天晚上处理这个问题。 我到目前为止所知道的：

1.流畅的容器使用了很多内存

2.在SystemOOM之前，有很多磁盘活动，但是我不知道是什么

起初，我认为如果突然涌入日志，流利的容器将占用大量内存。 在检查了Sumologic之后，我可以看到我们的日志使用情况相当稳定，并且在出现问题的时间里日志数据没有增加。

一些快速的搜索使我想到了这个github问题 ，这表明可以使用一些Ruby配置来降低内存使用量。 我继续将环境变量添加到我的pod规范中并进行了部署：

env:- name: RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTORvalue: "0.9"

在查看流利的摘要清单时，我注意到我没有指定任何资源请求或限制。 我已经怀疑RUBY_GCP_HEAP修复会做任何令人惊奇的事情，因此在这一点上指定内存限制很有意义。 即使这次我无法解决内存问题，至少也可以仅将这组Pod的内存使用情况包含在内。 使用kubectl顶部吊舱| grep的fluentd-sumologic我能得到多少资源的一个好主意，要求：

resources:requests:memory: "128Mi"cpu: "100m"limits:memory: "1024Mi"cpu: "250m"

要点2：指定资源限制，尤其是对于第三方应用程序

跟进

几天后，我能够确认上述修复程序有效。 节点上的内存使用情况稳定，而且Kubernetes，EC2或EBS中的任何组件都没有任何问题。 我意识到为我运行的所有Pod设置资源请求和限制是多么重要，因此实现默认资源限制和资源配额的某种组合现在就在我们的积压工作中。

剩下的最后一个谜是与SystemOOM事件相关的EBS突发平衡问题。 我知道，当内存不足时，操作系统将使用交换空间来避免完全耗尽内存。 但这不是我的第一个牛仔竞技表演，而且我知道Kubernetes甚至不会在启用了交换功能的服务器上启动。 可以肯定的是，我通过SSH进入我的节点，以查看是否同时使用free和swapon -s启用了交换功能，而没有启用交换功能。

由于交换不是问题，实际上，在节点内存不足时，导致磁盘IO增加的原因实际上我没有更多线索。 我目前的理论是，流利的Sud pod本身当时正在编写大量日志消息，也许是与Ruby GC配置有关的日志消息？ 当内存不足时，还有其他Kubernetes或日志日志源也可能变得闲谈，我可能会在流畅的配置中将它们过滤掉。 不幸的是，我再也无法在问题发生之前立即访问日志文件，并且目前没有办法进行更深入的研究。

要点3：在仍然可以解决所有问题的同时，更深入地挖掘根本原因

结论

即使我并非所见到的每个问题都有根本原因，但我相信我无需付出更多努力来再次预防此问题。 时间很宝贵，我已经在这个问题上花了足够的时间，然后写这篇文章分享。 由于我们使用Blue Matador ，因此实际上我们对这类问题有很好的报道，这使我可以揭开一些谜团，以支持重新使用我们的产品。

翻译自: https://hackernoon.com/post-mortem-kubernetes-node-oom-5ft9m38yz

post-mortem机制