实际应用中发现，部分节点性能不足，某些较大的服务如果跑在这些机器上。会很快消耗该机器的内存和cpu资源，如果用uptime看一下的就会发现负载特别高（合理的范围这个值应该等于cpu个数），高到一定值就会导致该节点挂了。
比较好的方式是
0：节点超过110个pod怎么办？
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 设置的大一点