前言
之前發生過的，
prometheus會這樣、gitlab最近在弄新版的CI/CD也跑這個出來。
本來想要之後有空再解決，但最近被DDOS攻擊時，
發現監控的grafana會卡住，因為他的prometheus ram爆了~~
正文
從字面上看來，其實蠻好理解的，
The node was low on resource: memory. Container web was using 4236080Ki, which exceeds its request of 0.
node的資源不夠了，container 使用量達到上限。
最直覺的方式就是，資源不夠，那就加開資源阿。
但開資源前要先想一下，如果我開了，那未來資源就一定夠嗎？
開的資源又不一定是完全給prometheus用，他供應的是全體的pod。
所以要先做的是，把 resources request 的加進去 pod裡面。
template:
metadata:
creationTimestamp: null
labels:
app: webhook
version: v1
spec:
containers:
- image: prom/prometheus:v2.28.0
imagePullPolicy: Always
name: prometheus
ports:
- containerPort: 80
protocol: TCP
resources:
requests:
cpu: 30m
memory: 30Mi
limits:
memory: "128Mi"
cpu: "500m"
這邊要特別注意 limit，當limit踩到上限時，這個pod就會被終止
，並引發記憶體不足(OOM)的錯誤。
所以 limit 要設嗎？？
這邊要從掛載的服務去決定，
如果今天掛載的服務 ram的使用量通常不多，
那突然達到上限，是不是可以判斷這個服務有問題了，必須要重啟。
但如果是使用prometheus，記憶體的量本來就會隨著metric的量而增加，
那就不適合加上去了，不然只會一直看到 記憶體不足的錯誤。
後面的單位，可設定 Ki, Mi ,Gi…
補充，
當node資源不足時，刪除pod的先後順序為，
- 沒有設定 request 跟 limit的 pod
- 只要有pod設定 request 或 limit ，但使用的資源是比在資源上設置的請求還多。
- 只要有pod設定 request 或 limit ，但使用的資源是比在資源上設置的請求還少。
結論
先設定 request ，因node機器的擴展，是根據 request的值，
來判斷要不要增加node數量，如果沒設定request，
系統會認為，沒有擴展的必要。就會導致前面的問題。
ref.
0 意見:
張貼留言