德清做网站,贵州建设项目门户网站,网上交易系统,网站怎么做sem优化文章目录 ResourceQuota什么是资源配额定义一个ResourceQuotaResourceQuota的使用 LimitRangeLimitRange的用途示例1#xff1a;配置默认的requests和limits示例2#xff1a;配置requests和limits的范围 QoS什么是服务质量保证示例1#xff1a;实现QoS为Guaranteed的Pod示例… 文章目录 ResourceQuota什么是资源配额定义一个ResourceQuotaResourceQuota的使用 LimitRangeLimitRange的用途示例1配置默认的requests和limits示例2配置requests和limits的范围 QoS什么是服务质量保证示例1实现QoS为Guaranteed的Pod示例2实现QoS为Burstable的Pod示例3实现QoS为BestEffort的Pod 节点故障大部分都是由于资源分配不合理、超额分配引起的因此需要用某个技术手段保证节点的资源不会过大地超额分配。Kubernetes为我们提供了开箱即用的资源管理可以通过ResourceQuota和LimitRange的配合防止节点资源超额分配。
ResourceQuota
首先看一下ResourceQuota资源配额的使用资源配额是限制某个命名空间对资源使用的一个总量限制比如内存、CPU、Pod数量等。
什么是资源配额
在生产环境中可能会有多个Kubernetes集群面向开发环境、测试环境、预生产环境和生产环境等。身为Kubernetes管理员必然知道每个环境的规模有多大、可调度资源有多少并且知道如何合理地为容器分配内存和CPU所以一个管理员去管理整个Kubernetes集群时很少会有资源分配超出集群可调度范围的情况。
在生产环境中可能会有多个Kubernetes集群面向开发环境、测试环境、预生产环境和生产环境等。身为Kubernetes管理员必然知道每个环境的规模有多大、可调度资源有多少并且知道如何合理地为容器分配内存和CPU所以一个管理员去管理整个Kubernetes集群时很少会有资源分配超出集群可调度范围的情况。
为了解决上述问题Kubernetes引入了ResourceQuota的概念以方便Kubernetes管理员方便地进行资源分配比如给A项目组分配16核64GB的资源并且最多只能部署20个Pod、30个Service等这样来对Kubernetes的各类资源进行限制。
定义一个ResourceQuota
和其他资源配置方法一样资源配额也可以通过一个YAML文件进行创建比如定义一个比较常用的ResourceQuota如下
apiVersion: v1
kind: ResourceQuota
metadata:name: example-quotanamespace: default
spec:hard:pods: 10requests.cpu: 4requests.memory: 10Gilimits.cpu: 8limits.memory: 20Gi
在此配置中
pods: “10” 限制命名空间中的 Pod 数量最多为 10 个。 requests.cpu: “4” 限制命名空间中所有 Pod 合计的 CPU 请求最多为 4 个 CPU。 requests.memory: “10Gi” 限制命名空间中所有 Pod 合计的内存请求最多为 10 GiB。 limits.cpu: “8” 限制命名空间中所有 Pod 合计的 CPU 使用量上限为 8 个 CPU。 limits.memory: “20Gi” 限制命名空间中所有 Pod 合计的内存使用量上限为 20 GiB。
ResourceQuota的使用
接下来演示ResourceQuota的具体使用方法首先创建一个用于测试的Namespace
kubectl create ns quota-example创建一个测试Demo比如限制该Namespace的PVC不能超过1个 apiVersion: v1
kind: ResourceQuota
metadata:name: pvc-quotanamespace: quota-example
spec:hard:persistentvolumeclaims: 1
创建该ResourceQuota kubectl create -f quota-objects.yaml查看创建的资源限制状态
kubectl get quota pvc-quota -n quota-example -o yaml可以从status字段的used看出当前资源限制的使用量并且Namespace只有在创建了ResourceQuota才会启用资源使用的配额没有创建ResourceQuota的Namespace不限制资源使用。
之后创建一个PVC
**touch pvc.yaml **
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: my-pvcnamespace: quota-example
spec:accessModes:- ReadWriteOnceresources:requests:storage: 10GistorageClassName: standard
kubectl create -f pvc.yaml -n quota-example
查看当前资源的使用情况 kubectl get quota pvc-quota -n quota-example -o yaml
再次尝试创建PVC
touch pvc2.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: my-pvc2namespace: quota-example
spec:accessModes:- ReadWriteOnceresources:requests:storage: 10GistorageClassName: standard
kubectl create -f pvc2.yaml -n quota-example可以看到此时无法创建PVC其他资源的限制类似在此不再演示。
环境清理 LimitRange
和ResourceQuota不同的是LimitRange用来配置默认值也就是一个Pod如果没有配置要用多少内存、CPULimitRange会在创建Pod时添加一个默认值。
LimitRange的用途
每个命名空间的最大资源使用量细心的读者可能会发现如果创建了一个Pod或Deployment没有指定requests和limits字段是不是就意味着资源配额对内存和CPU的限制变成了一个摆设答案是可想而知的CPU和内存永远不会被限制。还有另一种情况假如一个Namespace分配了16核、64GB的空间之后创建一个申请了requests.cpu为16、requests.memory为64GB的容器那么单个Pod就能把整个Namespace的资源全部占用。
为了防止这类情况发生Kubernetes又引出了另一个概念LimitRanger用于针对没有配置requests和limits的资源设置一个默认值同时配置单个资源最大的requests和limits这样就能解决上述问题注意LimitRanger不会影响已经创建的资源。
示例1配置默认的requests和limits
可以通过LimitRanger配置默认的requests和limits值用来解决创建的资源没有配置或配置过小的requests和limits带来的问题比如创建一个requests.cpu默认为0.50.5为半颗CPU1个CPU等于1000m、requests.memory为256MB、limits.cpu为1、limits.memory为512MB的LimitRanger创建完成后可以通过kubectl get limitrange cpu-mem-limit-range -oyaml查看
touch cpu-mem-limit-range.yamlapiVersion: v1
kind: LimitRange
metadata:name: cpu-mem-limit-rangenamespace: default
spec:limits:- default:cpu: 1memory: 512MidefaultRequest:cpu: 0.5memory: 256Mitype: Containerdefault: 当 Pod 没有指定资源限制时为容器设置默认的 CPU 和内存上限。 defaultRequest: 当 Pod 没有指定资源请求时为容器设置默认的 CPU 和内存请求。 type: 规定该规则适用于容器级别。
应用 LimitRange
使用 kubectl 命令将 LimitRange 对象应用到 Kubernetes 集群中。kubectl apply -f cpu-mem-limit-range.yaml
验证 LimitRange
可以使用以下命令查看已经定义的 LimitRangekubectl get limitrange -n default删除limit rangekubectl delete limitrange cpu-mem-limit-range -n default
定义podtouch nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-podlabels:app: nginx
spec:containers:- name: nginx-containerimage: nginx:latestports:- containerPort: 80kubectl apply -f nginx-pod.yamlkubectl get pod nginx-pod -o yaml可以看到该Pod被设置为LimitRanger的默认配置。 在配置了requests和limits参数时会以自行配置的为准如果没有超过LimitRanger的最大、最小限制的话。如果配置了limits而没有配置requests那么requests的默认值将被设置成limits配置的参数由于该配置和ResourceQuota类似此处不再演示可以参考ResourceQuota的步骤进行验证。 示例2配置requests和limits的范围
上述针对没有设置requests和limits字段的资源添加了默认值但是并没有限制requests和limits的最大值和最小值这样同样会给集群带来风险所以在管理资源分配时对requests和limits的最大值和最小值也需要进行管控。
touch cpu-min-max-demo-1r.yamlapiVersion: v1
kind: LimitRange
metadata:name: cpu-min-max-demo-1r
spec:limits:- max:cpu: 800mmemory: 1Gimin:cpu: 200mmemory: 500Mitype: Containerkubectl apply -f cpu-mem-limit-range.yaml
验证 LimitRange
可以使用以下命令查看已经定义的 LimitRangekubectl get limitrange -n defaultkubectl get limitrange cpu-min-max-demo-1r -o yaml 假设创建一个内存最大值超过limits限制的Pod
vim nginx-pod1.yaml
kubectl apply -f nginx-pod1.yamlapiVersion: v1
kind: Pod
metadata:name: nginx-pod
spec:containers:- name: nginximage: nginx:latestresources:limits:memory: 1.5Girequests:memory: 800Mi假设创建一个内存最小值小于limits最小值的Pod
vim nginx-pod2.yaml
kubectl apply -f nginx-pod2.yamlapiVersion: v1
kind: Pod
metadata:name: nginx-pod
spec:containers:- name: nginximage: nginx:latestresources:limits:memory: 1.5Girequests:memory: 100MiQoS
虽然我们进行了资源限制但是实际使用时依旧会造成节点资源不足针对资源不足Kubernetes会通过重启或驱逐Pod释放资源再重启时难免会造成一些很重要的服务不可用。但实际情况可能是如果重启或驱逐一些不重要的Pod可能会更好而这种决策是通过QoSQuality of Service服务质量决定的所以在生产环境中QoS是一个非常重要的环节。
什么是服务质量保证
Kubernetes为我们提供了3种级别的服务质量分别是
Guaranteed最高服务质量当宿主机内存不够时会先杀死QoS为BestEffort和Burstable的Pod如果内存还是不够才会杀死QoS为Guaranteed的Pod该级别Pod的资源占用量一般比较明确即requests字段的cpu和memory与limits字段的cpu和memory配置的一致。
Burstable服务质量低于Guaranteed当宿主机内存不够时会先杀死QoS为BestEffort的Pod如果内存还是不够就会杀死QoS级别为Burstable的Pod用来保证QoS质量为Guaranteed的Pod该级别的Pod一般知道最小资源使用量但是当机器资源充足时还是想尽可能使用更多的资源即limits字段的cpu和memory大于requests字段的cpu和memory的配置。
BestEffort尽力而为当宿主机内存不够时首先杀死的就是该QoS的Pod用以保证Burstable和Guaranteed级别的Pod正常运行。
示例1实现QoS为Guaranteed的Pod
创建一个QoS为Guaranteed的Pod需要满足以下条件 Pod中的每个容器必须指定limits.memory和requests.memory并且两者需要相等。 Pod中的每个容器必须指定limits.cpu和limits.memory并且两者需要相等。
定义一个Guaranteed的Pod
apiVersion: v1
kind: Pod
metadata:name: guaranteed-pod
spec:containers:- name: app-containerimage: nginxresources:requests:memory: 128Micpu: 500mlimits:memory: 128Micpu: 500m如果容器指定了limits的cpu和memory配置但是没有指定requests的cpu和memory配置Kubernetes会自动添加和limits配置相同的requests配置。 示例2实现QoS为Burstable的Pod
创建一个QoS为Burstable的Pod需要满足以下条件
1Pod不符合Guaranteed的配置要求。
2Pod中至少有一个容器配置了requests.cpu或者requests.memory。
定义一个Burstable的Pod
apiVersion: v1
kind: Pod
metadata:name: burstable-pod
spec:containers:- name: nginx-container-1image: nginx:latestresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500mports:- containerPort: 80env:- name: NGINX_PORTvalue: 80command: [ sh, -c, nginx -g daemon off; -c /etc/nginx/nginx.conf ]- name: nginx-container-2image: nginx:latestresources:requests:memory: 32Micpu: 100mports:- containerPort: 8080env:- name: NGINX_PORTvalue: 8080command: [ sh, -c, echo \server { listen 8080; location / { root /usr/share/nginx/html; index index.html index.htm; } }\ /etc/nginx/conf.d/default.conf nginx -g daemon off; ]kubectl describe pod burstable-pod在这个示例中Pod包含两个容器
nginx-container-1 设置了资源请求和限制但它们是不相等的。这个配置允许容器在需要的时候 “bust”即可以临时使用超过请求的资源限制但受限于定义的最大限制。
nginx-container-1 只设置了资源请求没有设置资源限制。这意味着它默认没有硬性资源限制可以利用集群中额外的可用资源。 这样配置也使得Pod属于Burstable类别。
示例3实现QoS为BestEffort的Pod
创建一个QoS为Burstable的Pod更为简单Pod中的所有容器都没有设置requests和limits字段即可比如创建一个QoS为BestEffort的Pod
apiVersion: v1
kind: Pod
metadata:name: besteffort-pod
spec:containers:- name: app-container-1image: nginxkubectl describe pod besteffort-pod
