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 进行授权之外的访问的途径。
本文转自中文社区-Kubernetes 集群资源的那些事
