10、Kubernetes - Helm 及其它功能性组件/3、视屏/63、Kubernetes - Helm 及其它功能性组件 - prometheus、资源限制（3）

123456789。哇，最后一个。资源数已经下来了是吧，上不去了，那我们再开一个。CPU性能太好了是吧，嗯，我们再看一个。

一。好，我们再去进行一个新的循环。我再来一个。我们稍微等一下。

好，看到了吗？最后一个正在被创建，对吧？我现在开了两个客户端同时进行压测访问，那这边呢，它的CPU利用率终于上去了，是吧？因为现在我们已经有好几个节点在负载均衡访问了，因为我们在这里访问的是它的SVC的名称，对吧？所以会进行一个负载均衡。那我们就CT啊。Get po。一二三四五六七八九十十个，那在这里我们再等一会，看他还会不会创建更多的出来。还是超50%的对吧。按理理论上是不是等会应该去创建出来新的了。93%。你会发现这边是不是还没有创建，所以我在这里设置的概念就是它的阀值是CPU利用率，利用率的50%，也是利用我们的100兆。

合资，那在这里呢，一旦超过50的话，我们就开始创店，但最大不增长不超过十个节点。能理解我的意思吗？那如果有一天他的压力变小了，他是不是要萎缩回去，那虽缩回的最小节点不能少于一个，这就是我们的hpa的意义所在。那我们可以，现在我们把这些压测给它关掉。好，这里有个节点压力会下去对吧。看到了吗？A一个是吧。好。我们稍微等一下，压力正在往下去，对吧。

好，变成14了。那我们看看我们这里的。你会发现它的扩容的时候它的策略呢比较快，但回收的时候它的策略比较慢，原因是什么呢？我们想一下。如果我们现在被高峰访问呢？突然由于网络问题，网络原因波动，突然这个流量请求为空了。如果在为空的时候，或者在这一小段的时间内，因为我们的网络波动问题造成我们的访问压力没这么大。那你就立马把这个所谓的炮给他萎缩，萎缩成一个了。但如果一旦网络不波动了，好了，压力是不是一下上来了，就极有可能会把这个仅存的这么一个炮的给它压死，能理解我意思吗？所以它回收起来比较慢，是非诚理的好。

我们稍微等一会，看他能不能收回去。

太慢了是吧。好，我们稍微等一会吧。

那这里呢，我们经过了很长时间等待，发现它已经回收成六个节点了，对吧，那我们就不再等下去了，因为这个回收策略确实。确实很慢。那具体的原因之前给大家说过对吧，因为他怕回收的策略比较积极的话，可能会造成突然来了大压力，把这里的pod给他急死，对吧？所以回收策略是非澈慢的，那在很长时间以后呢，肯定是能够回执到一个节点的，这是完全没有问题的。

那并且呢，在现阶段呢，我们的hpa的稳定版仅支持我们的CPU和内存去进行所谓的自动的扩容缩。那在不久的将来以后呢，它会有更多的一些特性加入到稳定版里来，比如基于我们的网络IP，于我们的磁盘IO，或者是自定义的一些阀值都是没有问题的。好，那HP会随着我们的K8S的。发展越来越好，这是肯定的，以后我们必须要去借助到的一种手段。好，那还有一个问题，就是我们打开我们的文档，我们看一下。在这里呢，我有个疑问，就我们在之前在创建我们的pip阿帕奇的时候，在这里添加了一个阀值叫request CPU这里设置是200兆。

那当时给大家说的是，这是一个请求的资源为200兆B的这么一个设置方案。这讲白来说，也是我们的一个容器的资源限定。我们之前在讲do给大家说过，我们在企业中去运行的话，一定要给docker去设置对应的一些阀值，比如内存的最大利用对吧，以及CPU的利用等等。那为什么要做这种东西呢？主要是怕出现对应的OM的机制，把一些重要的一些进程给他杀死，对吧？好，所以呢，资源限制对于我们企业运营来说是很至关重要的这么一件事情，那在我们的K8S里，它有自己的资源限制，之前没有给大家提过，那在这里给大家补充一下。那在这里，在K8S里，资源限制会以两种大类型去实现，第一个是基于pod，第二个是基于民的空间的。那炮的资源限制主要设置的方案，一个就是request，另一个就是limit。Request，就是初始的时候，我为他这个炮的赋予多大的资源。

你可以理解为是一个软限制，Limit是一个硬限制，最大用这么多，不能再继续了。好，并且当我们的pot它用的资源减小以后，会被回收至request的这么一个资源大小。需要注意一下，那它的设置方案就是在我们的容器的模板下出现一个resource的字段，那的二级字段是limit和resource，里面分别是CPU和内存的设置，那这个的含义就是我们运行了一个。镜像为这么的一个东西，对吧，这么的一个，然后呢，它刚开始运行的时候，分配的CPU是250赫兹，那分配的内存是250兆B，那如果你需要的更多的资源的话，我最大给你四个CPU去用，最大给你两个G内存去用，再大就不可以了。那这就是这种资源限制的方案的这么一个说法。还是那句话对吧，快速的你可以理解为转限制，它理解为硬限制，完全就没有问题了。

第二种限制方案呢，是基于名称空间的，基于民生空间的，它的配置更广泛一点，对吧？好，那民生空间级别的资源限制有第一种设施方案，就是计算资源的配额。在这里呢，我们会创建一个叫resource框的这么一个资源的这么一个。配额对吧，好。那名称叫computer resource，放在这么一个namespace名称空间之中，能够创建的port有20个，能够创建能够使用的我们的request的CPU加在一起有20个，那能够能够使用的内存加在一起有100GB，这是我们的request的CPU和内存，对吧？那limit呢，CPU呢，最大是40个，内存是200GB，对吧，这是它的一个request和的设置，那第二是基于数量进行配额，Resource countum con map总共有十个。

就最大你只能创建十个PV，你最PVC，你最大只能创建四个RC，你装的最大能创建20个，最多创建十个SVC最多创建十个loud b，最多创建两个loud b，没忘吧，它是基于我们的云服务器负载的这么一种方案，对吧？好，那还有基于我们的CPU和内存的limiting range，这个是什么含义呢？这相当于是一个补充了，不应该把它放在名字空间下，原因是什么呢？我们之前给大家说过，对吧，如果我们的pod。没有去设置所谓的request和limit的话，它会使用当前的。当前的民下的最大资源。也就如果你的空间也没有设置的话，那就是能使用集群里的最大资源，那极有可能会出现我们的OM对吧？好，那我怎么去设置一个pad能够使用的最大的默认值呢？或叫pod里的容器的最大的默认值呢，就是采用这种方案，叫limit range。

这里定义的菜类型呢，是我们的container。那它的默认默认对吧，默认的请求也就是一上来最大分配默认CPU一个核心内存是1GB。如果你觉得不够用，最大能用到五核心和50GB的这么一个内存资源。那这个呢，就是我们能够在K8S里这么一做的这么一个资源限制的方案，还是很简单的，对吧，基本上就几个字段就可以去实现。好，那这个呢，就是我们的普罗米修斯的这么一个监控方案了，还是挺简单的，对吧。