kubeernetes節點資源限制

實際應用中發現，部分節點性能不足，某些較大的服務若是跑在這些機器上。會很快消耗該機器的內存和cpu資源，若是用uptime看一下的就會發現負載特別高（合理的範圍這個值應該等於cpu個數），高到必定值就會致使該節點掛了。

比較好的方式是

1：底層，採用性能高的服務器用openstack分出多個虛機，經過資源的自動伸縮，可是目前尚未這個條件。直接跑在低性能的裸機上。

2：應用層，把大型服務重構成能夠水平擴展的微服務，而後多個微服務分配在多個節點。

 

因爲上述短期難以搞定，可是爲了保證集羣的健康，還有一種方式，就是當某臺節點的資源達到必定值，自動清理應用，以node第一優先級。

爲了作更可靠的調度，儘可能減小資源過量使用，kubernetes把主機的資源分爲幾個部分：
● Node Capacity：主機容量是一個固定值，是主機的實際的容量。
● System-Reserved：不屬於kubernetes的進程佔用的資源量。
● Kubelet Allocatable：能夠被kubelet用來啓動容器的資源量。
● Kube-Reserved：被kubernetes的組件佔用的資源量，包括docker daemon，kubelet，kube-proxy等。
[Allocatable] = [Node Capacity] – [Kube-Reserved] – [System-Reserved]
kubernetes調度器在調度Pod和kubelet在部署Pod作資源校驗時都使用 Allocatable 資源量做爲數據輸入。

能夠在kubelet中設置系統保留資源來提升Node節點的穩定性。參數爲 –system-reserved 和 –kube-reserved。
vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
添加

參數：
1：設置預留系統服務的資源
--system-reserved=cpu=200m,memory=1G

2：設置預留給k8s組件的資源（主要組件）
--kube-reserved=cpu=200m,memory=1G
系統內存-system-reserved-kube-reserved 就是能夠分配給pod的內存

3：驅逐條件
--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi

4：最小驅逐
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"

5：節點狀態更新時間
--node-status-update-frequency =10s

6：驅逐等待時間
--eviction-pressure-transition-period=20s

 

驗證方案：
1：設置--eviction-hard=memory.available<2Gi（建議設置25%，可是配置沒法寫百分）
2：./memtester 6G
free查看，內存使用已經超出設定的值
3：約10秒後MemoryPressure狀態變成True
4：釋放申請的內存後約10s後，MemoryPressure變回false（若是不設置node-status-update-frequency 會等5分鐘纔會變回False。設置了10秒，10秒內纔會變回False）
eviction-pressure-transition-period(default 5m0s)

問題：被驅逐的pod 狀態是The node was low on resource: memory.，沒法自動刪除，須要手動刪除

systemctl daemon-reload
systemctl restart kubelet
現有參數 新參數
—image-gc-high-threshold —eviction-hard or eviction-soft
—image-gc-low-threshold —eviction-minimum-reclaim
—maximum-dead-containers 棄用
—maximum-dead-containers-per-container 棄用
—minimum-container-ttl-duration 棄用
—low-diskspace-threshold-mb —eviction-hard or eviction-soft
—outofdisk-transition-frequency —eviction-pressure-transition-period

結論：

4g1C 以上推薦：
Environment="KUBELET_OTHER_ARGS=--pod-infra-container-image=wyun.io/google-containers/pause-amd64:3.0 --system-reserved=cpu=200m,memory=250Mi --kube-reserved=cpu=200m,memory=250Mi --eviction-hard=memory.available<1Gi,nodefs.available<1Gi,imagefs.available<1Gi --eviction-minimum-reclaim=memory.available=500Mi,nodefs.available=500Mi,imagefs.available=1Gi --node-status-update-frequency=10s --eviction-pressure-transition-period=30s"

 

 

● Kubelet經過Eviction Signal來記錄監控到的Node節點使用狀況。
● Eviction Signal支持：memory.available, nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree。
● 經過設置Hard Eviction Thresholds和Soft Eviction Thresholds相關參數來觸發Kubelet進行Evict Pods的操做。
● Evict Pods的時候根據Pod QoS和資源使用狀況挑選Pods進行Kill。
● Kubelet經過eviction-pressure-transition-period防止Node Condition來回切換引發scheduler作出錯誤的調度決定。
● Kubelet經過--eviction-minimum-reclaim來保證每次進行資源回收後，Node的最少可用資源，以免頻繁被觸發Evict Pods操做。
● 當Node Condition爲MemoryPressure時，Scheduler不會調度新的QoS Class爲BestEffort的Pods到該Node。
● 當Node Condition爲DiskPressure時，Scheduler不會調度任何新的Pods到該Node。

測試：
模擬增長內存
stress -i 1 --vm 1 --vm-bytes 2G
or
memtester

查看狀態：
while true; do kubectl describe node izbp1ijmrejjh7tz |grep MemoryPressure&& sleep 2; done
while true; do free -h&& sleep 2; done

 

問題：1：會在同一時間出現不少相同的pod Failed的狀態（MemoryPressure）改變eviction-minimum-reclaim=memory.available=500M 設置的大一點