Kubernetes的系统资源分为可压缩资源（CPU）和不可压缩资源（memory、storage）。默认情况下，kubelet没有做资源预留限制，这样节点上的所有资源都能被Pod使用。若节点上的pod负载较大，会引发一系列问题。本文介绍了针对该问题Kubernetes提供的kubelet的Node Allocatable特性。

背景简介

Kubernetes的系统资源分为可压缩资源（CPU）和不可压缩资源（memory、storage）。可压缩资源(比如CPU)在系统满负荷时会划分时间片分时运行进程，通常情况下系统整体会变慢；不可压缩资源(如Memory)在系统满负荷时，严重时会导致某些进程被系统OOM killer机制杀掉。

默认情况下，kubelet没有做资源预留限制，这样节点上的所有资源都能被Pod使用。若节点上的pod负载较大，这些pod可能会与节点上的系统守护进程和k8s组件争夺资源，严重时甚至会引发系统OOM而杀掉一些进程。若被杀掉的进程是系统进程或K8S组件，可能导致更严重的问题，甚至会导致集群的雪崩。

针对这种问题，kubernetes提供了kubelet的Node Allocatable特性，为系统进程和k8s组件预留资源。

资源预留

1 Node Allocatable

kubelet的启动配置中有一个Node Allocatable特性，来为系统守护进程和k8s组件预留计算资源，使得即使节点满负载运行时，也不至于出现pod去和系统守护进程以及k8s组件争抢资源，导致节点挂掉的情况。目前支持对CPU, memory, ephemeral-storage三种资源进行预留。kubernetes官方建议根据各个节点的负载情况来具体配置相关参数。

节点计算资源的分配如下图所示：

其中各个部分的含义如下：

Node Capacity：Node的硬件资源总量；
kube-reserved：为k8s系统进程预留的资源(包括kubelet、container runtime等，不包括以pod形式的资源)；
system-reserved：为linux系统守护进程预留的资源；
eviction-threshold：通过–eviction-hard参数为节点预留内存；
allocatable：可供节点上Pod使用的容量，kube-scheduler调度Pod时的参考此值。

# 节点可供Pod使用资源总量的计算公式：
allocatable = NodeCapacity - [kube-reserved] - [system-reserved] - [eviction-threshold]

从公式可以看出，默认情况下（不设置kube-reserved、system-reserved、eviction-threshold）节点上提供给Pod使用的资源总量等于节点的总容量。

2 参数含义及配置

Kubelet Node Allocatable的代码比较简单，主要在pkg/kubelet/cm/node_container_manager.go，感兴趣的同学可以看一下。以下是相关配置参数：

–enforce-node-allocatable，默认为pods（默认情况下，kubelet会为所有pod的总cgroup做资源限制，限制为公式计算出的allocatable的大小）。要为kube组件和System进程预留资源，则需要设置为pods,kube-reserved,system-reserve，同时还要分别加上–kube-reserved-cgroup和–system-reserved-cgroup以指定分别限制在哪个cgroup里；
–cgroups-per-qos，Enabling QoS and Pod level cgroups，默认开启。开启后，kubelet会将管理所有workload Pods的cgroups；
–cgroup-driver，默认为cgroupfs，另一可选项为systemd。取决于容器运行时使用的cgroup driver，kubelet与其保持一致；
–kube-reserved，用于配置为kube组件（kubelet,kube-proxy,dockerd等）预留的资源量，比如—kube-reserved=cpu=2000m,memory=8Gi，ephemeral-storage=16Gi；
–kube-reserved-cgroup，如果设置了–kube-reserved，需设置对应的cgroup，且该cgroup目录要事先创建好，否则kubelet将不会自动创建导致kubelet启动失败。比如设置为kube-reserved-cgroup=/kubelet.service；
–system-reserved，用于配置为System进程预留的资源量，比如—system-reserved=cpu=2000m,memory=4Gi,ephemeral-storage=8Gi；
–system-reserved-cgroup，如果设置了–system-reserved，需设置对应的cgroup，且该cgroup目录要事先创建好，否则kubelet将不会自动创建导致kubelet启动失败。比如设置为system-reserved-cgroup=/system.slice。
–eviction-hard，用来配置kubelet的hard eviction条件，只支持memory和ephemeral-storage两种不可压缩资源。当出现MemoryPressure时，Scheduler不会调度新的Best-Effort QoS Pods到此节点。当出现DiskPressure时，Scheduler不会调度任何新Pods到此节点。

配置与验证

针对pod、system、kube均做cgroup级别限制，需要进行以下配置：

# 在kubelet的启动参数中添加：
--enforce-node-allocatable=pods,kube-reserved,system-reserved \
--cgroup-driver=cgroupfs \
--kube-reserved=cpu=1,memory=1Gi,ephemeral-storage=10Gi \
--kube-reserved-cgroup=/system.slice/kubelet.service \
--system-reserved cpu=1,memory=2Gi,ephemeral-storage=10Gi \
--system-reserved-cgroup=/system.slice \
# 设置cgroup结构可参考官方建议。

为system.slice、kubelet.service创建cpuset子系统:未创建前system.slice这个cgroup是没有cpuset子系统的，而kubelet(1.9)启动时会去查看这些cgroup子系统是否存在，如果不存在会报相应的cgroup错误。

// Exists checks if all subsystem cgroups already exist
func (m *cgroupManagerImpl) Exists(name CgroupName) bool {
  // Get map of all cgroup paths on the system for the particular cgroup
  cgroupPaths := m.buildCgroupPaths(name)

  // the presence of alternative control groups not known to runc confuses
  // the kubelet existence checks.
  // ideally, we would have a mechanism in runc to support Exists() logic
  // scoped to the set control groups it understands.  this is being discussed
  // in https://github.com/opencontainers/runc/issues/1440
  // once resolved, we can remove this code.
  whitelistControllers := sets.NewString("cpu", "cpuacct", "cpuset", "memory", "systemd")

  // If even one cgroup path doesn't exist, then the cgroup doesn't exist.
  for controller, path := range cgroupPaths {
    // ignore mounts we don't care about
    if !whitelistControllers.Has(controller) {
      continue
    }
    if !libcontainercgroups.PathExists(path) {
      return false
    }
  }

  return true
}

# 所以需要手工创建相应cpuset子系统：
sudo mkdir -p /sys/fs/cgroup/cpuset/system.slice
sudo mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service

重启kubelet后，可以验证（以内存为例）：

通过公式计算、节点实际capacity及allocatable的值(kubectl describe node xxx)、 kubepods控制组中对内存的限制值(/sys/fs/cgroup/memory/kubepods/memory.limit_in_bytes)均与预期相符。

并且system.slice(/sys/fs/cgroup/memory/system.slice/memory.limit_in_bytes)、kubelet.service(/sys/fs/cgroup/memory/system.slice/kubelet.service/memory.limit_in_bytes)控制组对内存的限制值也与预期相符。

最佳实践

生产环境中，建议同时限制pod、k8s系统组件、linux system进程资源，以免任一类资源负载过高影响其他组件，甚至造成雪崩；
针对daemonset创建出来的系统级别pod，建议为其配置Guaranteed的服务质量等级。

本文转载自公众号360云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/CmHok-9gKVrHfiXpYUQ4nw

创作场景

浅析 Kubernetes 资源管理