Kubernetes 集群资源的那些事

大多数时候,我们在跟 K8S 玩耍的时候,主要目的就是:“把 XXX 打个镜像,在集群上跑起来 ——— 诶快看,真的跑起来了嘿!”。

Kubernetes 和 Docker 的缺省配置,就能够帮我们省却很多麻烦。不过大家都很清楚,资源问题是无法回避的,我们在传统 IT 环境下遇到的各种资源相关问题,在容器集群环境下一样要得到解决,多租户动态分配环境下,这些问题会更加复杂。

本文仅是一个索引,不准备也没能力做过多的深入,只是将一些需要注意的内容罗列出来做一些大致介绍。

有些内容称作资源可能并不是很恰当,暂时存在资源这个筐里吧。

磁盘

Volume

一般我们会用存储卷的方式来给 Pod 提供存储资源。

起初的存储卷,在用量的控制方面,只能借存储的实际提供者的能力来进行。例如可以限制 GlusterFS 中 Volume 的大小。

接下来出现了 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 这一组对象,完成了 “生产——消费” 关系,这就可以通过 Provision -> Claim 的方式,来对存储资源进行控制。

而最新版本中还出现了动态卷供给的功能,能够对这一部分功能进行简化,无需首先建立 PV,直接建立 PVC 即可。

有了 PVC 这一能力之后,Kubernetes 就借用这一对象对 Namespace 的存储访问进行了限制:

对象名称 解释
requests.storage 所有的 PVC 申请容量之和不能超过此数值
persistentvolumeclaims 一个 Namespace 中 PVC 的总数(Count)
<storage-class-name>.storageclass.storage.k8s.io/requests.storage 所有针对该 StorageClass 的 PVC 所申请的存储总容量不得超出这一数值
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims 所有针对该 StorageClass 最多能创建的 PVC 数量

日志

目前我们在实际使用中,爆磁盘的原因,除了对存储卷的控制不够之外,还有一个重要的点就是容器的日志,缺省情况下 Docker 使用的日志驱动是 json-file,这一驱动有个附加参数 --log-opt max-size=[size] 可以用来限制日志的最大占用空间。

https://docs.docker.com/engine/admin/logging/overview/ 还提供了很多其他的日志选项供选择

Node

除了上面讲到的集群层面的问题之外,磁盘空间还对 Node(Kubelet) 的健康有重大影响。Kubelet 有几个参数用于对存储使用进行控制:

  • --low-diskspace-threshold-mb:如果剩余空间低于这一限制,则拒绝在这一 Node 上新建 Pod(目前建议用新的驱逐规则来代替这一参数)。
  • --image-gc-high-threshold:高于该值则启动 GC。
  • --image-gc-low-threshold:低于该值拒绝启动 GC。

在驱逐策略中,提供了如下几个磁盘相关的参数:

  • nodefs.available
  • nodefs.inodesFree
  • imagefs.available
  • imagefs.inodesFree

这里把 Node 磁盘分为 node 和 image 两种分别度量其 available 和 inodes,应该说比上面的 threshold 更加精确了

CPU 和内存

这一对资源应该算是 Kubernetes 中的 “经典” 资源了。Kubernetes 对 CPU 和内存提供了 requests/limits 两种度量,可以在 Container 的 Spec 中进行指定。

在 namespace 一级中,提供了如下的总量限制:

  • limits.cpu:所有非结束状态的 Pod 的 CPU limit 总数。
  • limits.memory:所有非结束状态的 Pod 的 内存 limit 总数。
  • requests.cpu:所有非结束状态的 Pod 的 CPU request 总数。
  • requests.memory:所有非结束状态的 Pod 的 CPU request 总数。

Node

和前面的磁盘的情况类似,Kubelet 中对 CPU 和内存也有新旧两套切换中的体系来进行限制:

  • --kube-reserved

驱逐策略中提供了如下参数:

  • memory.available

quota 和 limitrange

这是两个不同的 API Object,分别对应 namespace 的配额,和运行应用(Pod/Container)的资源限制。

GPU

这方面基本没有接触,但是随着深度学习之类名词的迅速炒热,相信 Kubernetes 会快速跟进的。

将在 1.6 中推出多 GPU 支持的 Alpha 版本。

网络

K8S1.5版本 中,网络策略已经成为 Beta 版本,利用这一对象,横向可以实现 namespace 之间的隔离;纵向可以定义 namespace 内不同职责应用的网络访问能力。这就有效的阻断了不同租户之间利用 dns 进行授权之外的访问的途径。

参考资料:

  • 网络策略:https://kubernetes.io/docs/user-guide/networkpolicies/
  • 驱逐策略:http://blog.fleeto.us/translation/configuring-out-resource-handling
  • 存储:
    • http://blog.fleeto.us/translation/dynamic-provisioning-and-storage-classes-kubernetes
    • http://blog.fleeto.us/translation/persistent-volumes