# 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]` 可以用来限制日志的最大占用空间。

> [Docker 官方文档](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 版本。

## 网络

在 1.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`