kubernetes资源优化

痛定思痛。 2021-11-10 19:32 396阅读 0赞

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对镜像的自动清理行为。

转载于:https://www.cnblogs.com/xuliang666/p/11137128.html