回复
Kubernetes应用质量管理（上）
fldj
发布于 2022-9-5 17:57
浏览
0收藏
作者 | 老郑
来源 |运维开发故事(ID：mygsdcsf)
转载请联系授权(微信ID：wanger5354)
服务质量管理
在Kubernetes中，Pod是最小的调度单元，所以跟资源和调度相关的属性都是Pod对象的字段，而其中最重要的就是CPU和内存。如下所示：
---
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
spec:
containers:
- name: myweb
image: wordpress
imagePullPolicy: IfNotPresent
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"其中resources就是资源限制部分。
注：由于一个Pod里可以定义多个Containers，而每个资源限制都是配置在各自的Container，所以Pod的整体配置资源是所有Containers的总和。
在Kubernetes中，CPU这样的资源被称为"可压缩资源"，所谓可压缩资源就是当可用资源不足的时候，Pod只会"饥饿"，不会退出。而向Memory这样的资源被称为"不可压缩资源"，所谓的不可压缩资源就是当资源不足的时候Pod只会OOM。
其中CPU的设置单位是CPU的个数，比如CPU=1就表示这个Pod的CPU限额是1个CPU，而到底是1个CPU核心、是1个vCPU还是1个CPU超线程，这要取决于宿主机上CPU实现方式，而Kunernetes只需要保证该Pod能够使用到1个CPU的使用能力。
Kubernetes允许将CPU的限额设置位分数，比如上面我们设置的CPU.limits的值为500m，而所谓的500m就是500milliCPU，也就是0.5个CPU，这样，这个Pod就会被分到一个CPU一半的计算能力。所以我们可以直接把配置写成cpu=0.5，不过官方推荐500m的写法，这是Kubernetes内部的CPU计算方式。
在Kubernetes中，内存资源的单位是bytes，支持使用Ei，Pi，Ti，Gi，Mi，Ki的方式作为bytes的值，其中需要注意Mi和M的区别（1Mi=10241024，1M=10001000）。
Kubernetes中Pod的CPU和内存的资源限制，实际上分为requests和limits两种情况。
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory这两者的区别如下：
- 在调度的时候，kube-scheduler会安requests的值进行计算；
- 在设置CGroups的时候，kubelet会安limits的值来进行设置；
QoS模型
Kubernetes中支持三种QoS模型。其分类是基于requests和limits的不同配置。
Guaranteed
当Pod里的每一个Containers都设置了requests和limits，并且其值都相等的时候，这种Pod就属于Guaranteed类别，如下：
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
namespace: qos-example
spec:
containers:
- name: qos-demo-ctr
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "700m"
requests:
memory: "200Mi"
cpu: "700m"注意，当这Pod仅设置limits，没有设置requests的时候，系统默认为它分配于limits相等的requests值，也就会被划分为Guaranteed类别。
Burstable
而当这个Pod不满足Guaranteed条件，但至少有一个Contaienrs设置了requests，那么这个Pod就会被划分为Burstable类别。如下：
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-2
namespace: qos-example
spec:
containers:
- name: qos-demo-2-ctr
image: nginx
resources:
limits
memory: "200Mi"
requests:
memory: "100Mi"BestEffort
如果这个Pod既没有设置requests值，也没有设置limits的值的时候，那么它的QoS类别就是BestEffort类别。
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-3
namespace: qos-example
spec:
containers:
- name: qos-demo-3-ctr
image: nginx而QoS划分的主要场景就是当宿主机资源紧张的时候，kubelet对资源进行Eviction时需要用到。目前Kubernetes设置的默认Eviction的阈值如下：
memory.available<100Mi
nodefs.available<10%
nodefs.inodesFree<5%
imagefs.available<15%上述条件可以在kubelet中设置：
kubelet --eviction-hard=imagefs.available<10%,memory.available<500Mi,nodefs.available<5%,nodefs.inodesFree<5% --eviction-soft=imagefs.available<30%,nodefs.available<10% --eviction-soft-grace-period=imagefs.available=2m,nodefs.available=2m --eviction-max-pod-grace-period=600Kubernetes中的Eviction分为Soft Eviction和Hard Eviction两种模式。
- Soft Eviction允许设置优雅等待时间，如上设置imagefs.available=2m，允许在Imagefs不足阈值达到2分钟之后才进行Eviction;
- Hard Eviction在达到阈值就进行Eviction；
当宿主机的Eviction阈值达到后，就会进入MemoryPressure或者DiskPressure状态，从而避免新的Pod调度到上面去。而当Eviction发生时，kubelet删除Pod的先后顺序如下：
- BestEffort 类型的Pod；
- Burstable类别并且发生"饥饿"的资源使用量已经超出了requests的Pod；
- Guaranteed类别并且只有当Guaranteed类别的Pod的资源使用量超过了其limits限制，或者宿主机本身处于Memory Pressure状态时，Guaranteed才会被选中被Eviction;
cpuset
cpuset，就是把容器绑定到某个CPU核上，减少CPU的上下文切换。
- Pod必须是Guaranteed类型；
- 只需要将Pod的CPU资源的requests和limits设置为同一个相等的数值；
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
requests:
memory: "200Mi"
cpu: "2"LimitRange
在正常配置应用Pod的时候，都会把服务质量加上，也就是配置好requests和limits，但是，如果Pod非常多，而且很多Pod只需要相同的限制，我们还是像上面那样一个一个的加就非常繁琐了，这时候我们就可以通过LimitRange做一个全局限制。如果在部署Pod的时候指定了requests和Limits，则指定的生效。反之则由全局的给Pod加上默认的限制。
总结，LimitRange可以实现的功能：
- 限制namespace中每个pod或container的最小和最大资源用量。
- 限制namespace中每个PVC的资源请求范围。
- 限制namespace中资源请求和限制数量的比例。
- 配置资源的默认限制。
常用的场景如下（来自《Kubernetes权威指南》） - 集群中的每个节点都有2GB内存，集群管理员不希望任何Pod申请超过2GB的内存：因为在整个集群中都没有任何节点能满足超过2GB内存的请求。如果某个Pod的内存配置超过2GB，那么该Pod将永远都无法被调度到任何节点上执行。为了防止这种情况的发生，集群管理员希望能在系统管理功能中设置禁止Pod申请超过2GB内存。
- 集群由同一个组织中的两个团队共享，分别运行生产环境和开发环境。生产环境最多可以使用8GB内存，而开发环境最多可以使用512MB内存。集群管理员希望通过为这两个环境创建不同的命名空间，并为每个命名空间设置不同的限制来满足这个需求。
- 用户创建Pod时使用的资源可能会刚好比整个机器资源的上限稍小，而恰好剩下的资源大小非常尴尬：不足以运行其他任务但整个集群加起来又非常浪费。因此，集群管理员希望设置每个Pod都必须至少使用集群平均资源值（CPU和内存）的20%，这样集群能够提供更好的资源一致性的调度，从而减少了资源浪费。
（1）、首先创建一个namespace
apiVersion: v1
kind: Namespace
metadata:
name: coolops（2）、为namespace配置LimitRange
apiVersion: v1
kind: LimitRange
metadata:
name: mylimit
namespace: coolops
spec:
limits:
- max:
cpu: "1"
memory: 1Gi
min:
cpu: 100m
memory: 10Mi
maxLimitRequestRatio:
cpu: 3
memory: 4
type: Pod
- default:
cpu: 300m
memory: 200Mi
defaultRequest:
cpu: 200m
memory: 100Mi
max:
cpu: "2"
memory: 1Gi
min:
cpu: 100m
memory: 10Mi
maxLimitRequestRatio:
cpu: 5
memory: 4
type: Container参数说明：
- max：如果type是Pod，则表示pod中所有容器资源的Limit值和的上限，也就是整个pod资源的最大Limit，如果pod定义中的Limit值大于LimitRange中的值，则pod无法成功创建。如果type是Container，意义类似。
- min：如果type是Pod，则表示pod中所有容器资源请求总和的下限，也就是所有容器request的资源总和不能小于min中的值，否则pod无法成功创建。如果type是Container，意义类似。
- maxLimitRequestRatio：如果type是Pod，表示pod中所有容器资源请求的Limit值和request值比值的上限，例如该pod中cpu的Limit值为3，而request为0.5，此时比值为6，创建pod将会失败。
- defaultrequest和defaultlimit则是默认值，只有type为Container才有这两项配置
注意：
（1）、如果container设置了max， pod中的容器必须设置limit，如果未设置，则使用defaultlimt的值，如果defaultlimit也没有设置，则无法成功创建
（2）、如果设置了container的min，创建容器的时候必须设置request的值，如果没有设置，则使用defaultrequest，如果没有defaultrequest，则默认等于容器的limit值，如果limit也没有，启动就会报错
创建上面配置的LimitRange：
$ kubectl apply -f limitrange.yaml
limitrange/mylimit created
$ kubectl get limitrange -n coolops
NAME CREATED AT
mylimit 2022-08-02T06:08:43Z
$ kubectl describe limitranges -n coolops mylimit
Name: mylimit
Namespace: coolops
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Pod cpu 100m 1 - - 3
Pod memory 10Mi 1Gi - - 4
Container cpu 100m 2 200m 300m 5
Container memory 10Mi 1Gi 100Mi 200Mi 4（3）、创建一个允许范围之内的requests和limits的pod
apiVersion: v1
kind: Pod
metadata:
name: pod01
namespace: coolops
spec:
containers:
- name: pod-01
image: nginx
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
memory: 30Mi
limits:
cpu: 300m
memory: 50Mi我们通过kubectl apply -f pod-01.yaml可以正常创建Pod。
（4）、创建一个cpu超出允许访问的Pod
apiVersion: v1
kind: Pod
metadata:
name: pod02
namespace: coolops
spec:
containers:
- name: pod-02
image: nginx
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
memory: 30Mi
limits:
cpu: 2
memory: 50Mi然后我们创建会报如下错误：
# kubectl apply -f pod-02.yaml
Error from server (Forbidden): error when creating "pod-02.yaml": pods "pod02" is forbidden: [maximum cpu usage per Pod is 1, but limit is 2, cpu max limit to request ratio per Pod is 3, but provided ratio is 10.000000, cpu max limit to request ratio per Container is 5, but provided ratio is 10.000000]（5）创建低于允许范围的Pod
apiVersion: v1
kind: Pod
metadata:
name: pod03
namespace: coolops
spec:
containers:
- name: pod-03
image: nginx
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
memory: 30Mi
limits:
cpu: 100m
memory: 10Mi然后会报如下错误：
# kubectl apply -f pod-03.yaml
The Pod "pod03" is invalid:
* spec.containers[0].resources.requests: Invalid value: "200m": must be less than or equal to cpu limit
* spec.containers[0].resources.requests: Invalid value: "30Mi": must be less than or equal to memory limit（6）、创建一个未定义request或Limits的Pod
apiVersion: v1
kind: Pod
metadata:
name: pod04
namespace: coolops
spec:
containers:
- name: pod-04
image: nginx
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
memory: 200Mi然后我们创建完Pod后会发现自动给我们加上了limits。如下：
# kubectl describe pod -n coolops pod04
...
Limits:
cpu: 300m
memory: 200Mi
Requests:
cpu: 200m
memory: 200Mi
...上面我指定了requests，LimitRange自动给我们加上了defaultLimits，你也可以试一下全都不加或者加一个，道理是一样的。值得注意的是这里要注意一下我们设置的maxLimitRequestRatio，配置的比列必须小于等于我们设置的值。
上文有介绍LimitRange还可以限制还可以限制PVC，如下：
apiVersion: v1
kind: LimitRange
metadata:
name: storagelimits
namespace: coolops
spec:
limits:
- type: PersistentVolumeClaim
max:
storage: 2Gi
min:
storage: 1Gi创建完后即可查看：
kubectl describe limitranges -n coolops storagelimits
Name: storagelimits
Namespace: coolops
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
PersistentVolumeClaim storage 1Gi 2Gi - - -你可以创建PVC进行测试，道理是一样的。
分类
标签
已于2022-9-5 17:57:01修改
赞
收藏
回复
相关推荐
