AIOps 一场颠覆传统运维的盛筵
729
2022-10-27
Kubernetes 集群资源的那些事
大多数时候,我们在跟 K8S 玩耍的时候,主要目的就是:“把 XXX 打个镜像,在集群上跑起来 ——— 诶快看,真的跑起来了嘿!”。
Kubernetes 和 Docker 的缺省配置,就能够帮我们省却很多麻烦。不过大家都很清楚,资源问题是无法回避的,我们在传统 IT 环境下遇到的各种资源相关问题,在容器集群环境下一样要得到解决,多租户动态分配环境下,这些问题会更加复杂。
本文仅是一个索引,不准备也没能力做过多的深入,只是将一些需要注意的内容罗列出来做一些大致介绍。
有些内容称作资源可能并不是很恰当,暂时存在资源这个筐里吧。
一般我们会用存储卷的方式来给 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(Kubelet) 的健康有重大影响。Kubelet 有几个参数用于对存储使用进行控制:
--low-diskspace-threshold-mb
--image-gc-high-threshold
--image-gc-low-threshold
在驱逐策略中,提供了如下几个磁盘相关的参数:
这里把 Node 磁盘分为 node 和 image 两种分别度量其 available 和 inodes,应该说比上面的 threshold 更加精确了
这一对资源应该算是 Kubernetes 中的 “经典” 资源了。Kubernetes 对 CPU 和内存提供了 requests/limits 两种度量,可以在 Container 的 Spec 中进行指定。
在 namespace 一级中,提供了如下的总量限制:
和前面的磁盘的情况类似,Kubelet 中对 CPU 和内存也有新旧两套切换中的体系来进行限制:
--kube-reserved
驱逐策略中提供了如下参数:
这是两个不同的 API Object,分别对应 namespace 的配额,和运行应用(Pod/Container)的资源限制。
这方面基本没有接触,但是随着深度学习之类名词的迅速炒热,相信 Kubernetes 会快速跟进的。
将在 1.6 中推出多 GPU 支持的 Alpha 版本。
在 1.5 中,网络策略已经成为 Beta 版本,利用这一对象,横向可以实现 namespace 之间的隔离;纵向可以定义 namespace 内不同职责应用的网络访问能力。这就有效的阻断了不同租户之间利用 dns 进行授权之外的访问的途径。
数据库
评论
发表评论
暂时没有评论,来抢沙发吧~