aws的各种坑-甲

坑太多，用甲乙丙丁戊己庚辛壬癸编号还不一定够

挨个从support里扒吧，万一哪天跑了看不到support的记录了岂不是亏了么，留在这记录着吧，希望这一举动不会给我惹事

这个case严格的讲应该跟fluentd有关，趁着还算新鲜，记一笔吧，不完全从support里拷贝：

daemonset的fluentd在极个别场合（具体怎么个极其特别尚不可知），会往死里吃内存。

因为是按aws在github上的说明装的，没配置resource的request和limit，于是这个二百五就往死里吃内存，把节点内存吃了个精光，直到触发OOM被干掉。

最为可耻的是，触发OOM之前，还会把别的业务pod给挤掉。

因为无法复现，所以暂时不太好确定原因。只看到不少dmesg格式的log无法被fluentd解析，但这不应该成为导致OOM的理由。

第二个奇怪的地方是，同样的ami跑起来的节点，出现OOM的fluentd就只有一台，重启后时不时还会复现。

节点组更新ami后问题消失，但是根据support自己的说法，更新过的ami并无log相关调整，也无直接影响fluentd的调整。

So，这个坑没结论。