kubernetes資源優化

kubernetes資源優化方向

系統參數限制

設置系統內核參數：

vm.overcommit_memory = 0
vm.swappiness = 0
sysctl -p　＃生效

內核參數overcommit_memory

它是 內存分配策略

可選值：0、1、2。

• 0， 表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。
• 1， 表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。
• 2， 表示內核允許分配超過所有物理內存和交換空間總和的內存

設置overcommit_memory = 0．是為了避免系統發生OOM自動殺死進程.

解釋：什么是Overcommit和OOM

        Linux對大部分申請內存的請求都回復"yes"，以便能跑更多更大的程序。因為申請內存后，並不會馬上使用內存。這種技術叫做 Overcommit。當linux發現內存不足時，會發生OOM killer(OOM=out-of-memory)。它會選擇殺死一些進程(用戶態進程，不是內核線程)，以便釋放內存。
        當oom-killer發生時，linux會選擇殺死哪些進程？選擇進程的函數是oom_badness函數(在mm/oom_kill.c中)，該 函數會計算每個進程的點數(0~1000)。點數越高，這個進程越有可能被殺死。每個進程的點數跟oom_score_adj有關，而且 oom_score_adj可以被設置(-1000最低，1000最高)。

 

vm.swappiness　= 0　就是限制使用交換分區．應該kubernetes不建議使用交換分區，而且一般是關閉交換分區的.

kubelet進程設置預留內存：

cat /var/lib/kubelet/config.yaml

默認參數

eventRecordQPS: 5
evictionHard:
  imagefs.available: 15%
  memory.available: 100Mi
  nodefs.available: 10%
  nodefs.inodesFree: 5%

內存限制優化：

evictionHard:
  imagefs.available: 15%
  memory.available: 1Gi　　　　＃這里限制節點預留內存
  nodefs.available: 10%
  nodefs.inodesFree: 5%

這里自行百度了解 Kubernetes Eviction Manager工作機制

實在不行　我簡單復制粘貼一點內容吧．．．哭．．．．．．．

首先，我們來談一下kubelet通過OOM Killer來回收資源的缺點：

• System OOM events本來就是對資源敏感的，它會stall這個Node直到完成了OOM Killing Process。
• 當OOM Killer干掉某些containers之后，kubernetes Scheduler可能很快又會調度一個新的Pod到該Node上或者container 直接在node上restart，馬上又會觸發該Node上的OOM Killer啟動OOM Killing Process，事情可能會沒完沒了的進行，這可不妙啊。

我們再來看看Kubelet Eviction有何不同：

• Kubelet通過pro-actively監控並阻止Node上資源的耗盡，一旦觸發Eviction Signals，就會直接Fail一個或者多個Pod以回收資源，而不是通過Linux OOM Killer這樣本身耗資源的組件進行回收。
• 這樣的Eviction Signals的可配置的，可以做到Pro-actively。
• 另外，被Evicted Pods會在其他Node上重新調度，而不會再次觸發本Node上的再次Eviction。

下面，我們具體來研究一下Kubelet Eviction Policy的工作機制。

• kubelet預先監控本節點的資源使用，並且阻止資源被耗盡，這樣保證node的穩定性。
• kubelet會預先Fail N(>= 1)個Pod以回收出現緊缺的資源。
• kubelet會Fail一個Node時，會將Pod內所有Containners都kill掉，並把PodPhase設為Failed。
• kubelet通過事先人為設定Eviction Thresholds來觸發Eviction動作以回收資源。

 

pod資源限制

就是requests和limits參數設置內存,cpu.按自己需求設置即可.

默認是不限制資源

pod主機親和性

 

Kubernetes - GC的鏡像自動清理導致的問題

Kubernetes集群隨着應用的迭代，會產生很多無用的鏡像和容器，因此需要定時清理，分布在每個節點的Kubelet有GC（垃圾收集）的職責，當集群中有斷定為垃圾的鏡像或容器，那么kubelet會清除掉相關鏡像或容器。容器GC間隔為1分鍾，鏡像GC間隔為5分鍾。而這在某些情況下會產生問題，如：私有離線部署環境中，如果某個node節點相關的鏡像被清理了，當在這個啟動相關容器就會失敗，由於是離線，那么拉取鏡像也會失敗。

解決辦法：

• 搭建離線私有鏡像倉庫；
• 關閉Kubernetes的GC對鏡像的自動清理行為。