實際應用中發現，部分節點性能不足，某些較大的服務如果跑在這些機器上。會很快消耗該機器的內存和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 設置的大一點