kubeernetes节点资源限制

515439429

　　实际应用中发现，部分节点性能不足，某些较大的服务如果跑在这些机器上。会很快消耗该机器的内存和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>　　● 当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 设置的大一点