k8s实验-资源配置

k8s实验-资源配置

配置pod的资源配额

1 创建实验目录

mkdir ~/huawei_k8s/labfile/qosfile && cd ~/huawei_k8s/labfile/qosfile

2 查看pod资源

kubectl get node nod1 -o yaml

确认资源信息

3 创建实验namespace

kubectl create namespace qos-namespace

4配置一个BestEffort级别的pod

#vim best-pod.yamlapiVersion: v1kind: Podmetadata: name: best-pod namespace: qos-namespacespec: containers: - name: best-container image: nginx

5 创建pod并查看pod类型

kubectl apply -f best-pod.yamlkubectl describe pods best-pod -n qos-namespace

6 创建Burstabel的pod的yaml

#vim bur-pod.yamlapiVersion: v1kind: Podmetadata: name: bur-pod namespace: qos-namespacespec: containers: - name: bur-contianer image: nginx resources: limits: memory: "200Mi" requests: memory: "100Mi"

7 创建pod,并确认pod的qos类型

8 创建Guaranteed类型的pod的yaml

#vim gua-pod.yamlapiVersion: v1kind: Podmetadata: name: gua-pod namespace: qos-namespacespec: containers: - name: gua-container image: nginx resources: limits: memory: "200Mi" cpu: "700m" requests: memory: "200Mi" cpu: "700m"

9 创建pod并确认qos类型

测试内存限制

1 创建一个yaml文件，该文件定义了一个stress应用的pod，并且pod内程序运行会占用超过pod限额的内存

#vim outmem.yamlapiVersion: v1kind: Podmetadata: name: memory-demo namespace: qos-namespacespec: containers: - name: memory-demo-ctr image: polinux/stress resources: limits: memory: "100Mi" requests: memory: "50Mi" command: ["stress"] args: ["--vm","1","--vm-bytes","150M","--vm-hang","1"]

2 运行pod

3 查看pod状态，可以看到状态是OOMKilled

kubectl get pod -n qos-namespace

查看详细信息，可以看到pod出现的问题是OOMKilled

测试节点资源限额

1 创建一个yaml，该文件定义了一个pod,但是这个pod使用资源的超出了节点拥有的资源。

#vim outnode.yamlapiVersion: v1kind: Podmetadata: name: memory-demo2 namespace: qos-namespacespec: containers: - name: memory-demo2-ctr image: polinx/stress resources: limits: memory: "1000Gi" requests: memory: "1000Gi" command: ["stress"] args: ["--vm","1","--vm-bytes","150M","--vm-hang","1"]

2 创建pod

3 查看pod状态，pod一致无法创建成功

4 查看pod创建不成功的原因，可以看到是由于没有节点有足够的资源运行pod

ResourceQuota和LimitRange

集群管理员根据集群用户的数量来调整集群的配置，需要能够控制特定命名空间的资源使用量，最终实现集群的公平使用和成本控制。

目标：

限制运行状态的pod的计算资源用量限制持久存储卷的数量以控制对存储的访问限制负载均衡的数量以控制成本防止滥用网络端口提供默认计算资源Request以便对系统做出更优化的调度

创建quota-example命名空间

#vim quto-exampleapiVersion: v1kind: Namespacemetadata: name: quota-example

查看命名空间

设置限定对象数量的资源配额

通过设置限定对象数量的资源配额。可以控制持久卷，负载均衡，NodePort这些资源的数量。

创建ResourceQuota

#object-counts.yamlapiVersion: v1kind: ResourceQuotametadata: name: object-counts namespace: quota-examplespec: hard: persistentvolumeclaims: "2" services.loadbalancers: "2" services.nodeports: "0"

配额系统会检测到资源配额的创建，统计和限制该命名空间的资源消耗

确认配置是否生效

kb describe quota object-counts -n quota-example

至此，配额系统会自动阻止超过限制的请求。

设置限定计算资源的资源配额

创建一项限定计算资源的资源配额，以限制该命名空间中计算资源的使用总量。

#compute-resources.yamlapiVersion: v1kind: ResourceQuotametadata: name: compute-resources namespace: quota-examplespec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi

确认是否生效

kubectl describe quota compute-resources -n quota-example

配额系统会自动防止在该命名空间中同时拥有超过4个非“终止态"的pod,此外，由于该资源配额限制了CPU和内存Limits和Requests的总量，因此会强制要求命名空间中所有的容器都显示定义CPU和内存的Limits，Requests，可使用默认值，两者相等。

配置默认的Requests和Limits

在命名空间中已经配置了限定计算资源和资源配额的情况下，如果尝试在该命名空间中创建一个不指定Reqeuests和Limits的Pod,那么Pod可能会失败。以下是失败的例子

创建一个Nginx的Deployment

kubectl run nginx --image=nginx -n quota-example

显示没有创建成功。系统提示没有指定CPU和内存的 Requests，Limts

为了避免这种失败，可以使用LimitRange为这个空间中所有的pod都提供一个资源配置的默认值。

示例

#limit.yamlapiVersion: v1kind: LimitRangemetadata: name: limits namespace: quota-examplespec: limits: - default: cpu: 200m memory: 512Mi defaultRequest: cpu: 100m memory: 256Mi type: Container ================ #创建并查看 kubectl apply -f limits.yaml -n quota-example kubectl describe limits limits -n quota-example

再次建立pod

kubectl run nginx \--image=nginx \--requests=cpu=100m,memory=256Mi \--limits=cpu=200m,memory=512Mi \--namespace=quota-example

pod创建成功

查看资源配额的情况

kubectl describe quota -n quota-example

可以看到，每个pod在创建的时候都会消耗指定的资源量，这些资源量都会被准确跟踪，监控和管理。

指定资源配额的作用域

如果不限为某个命名空间配置默认的计算资源配额，而是希望限定在命名空间中。例如要集群中部分资源运行QOS为非BestEffort的服务，并要闲置的资源运行QOS为BestEffort的服务，可以避免集群的所有资源仅被大量的BestEffort pod消耗。

示例

#创建命名空间kubectl create namespace quota-scopes#创建best-effort的ResorceQuota,指定的scope为BestEffortapiVersion: v1kind: ResourceQuotametadata: name: best-effortspec: hard: pods: "10" scopes: - BestEffort =========== #创建not-best-effort.yaml，指定的scope为NotBestEffort apiVersion: v1kind: ResourceQuotametadata: name: not-best-effortspec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi scopes: - NotBestEffort

查看ResurceQuota

没有配置Request的pod将会被best-effort的ResourceQuota限制；而配置了Requests的Pod会被not-best-effort的ResourceQuota限制。

总结

k8s中资源的管理基础是容器和pod的资源配置。（Request和Limts）。容器的资源配置指定了容器请求的资源和容器能够使用的资源上限，Pod的资源配置则是POd中所有容器的资源配置的总和上限。

通过资源配额机制，可以对命名空间中所有pod使用资源的总量进行限制。

如果要对用户pod或者容器资源配置做更多的限制，则可以使用胚子和范围LimitsRange。它可以有效的限制pod和容器资源配置的最大，最小范围，也可以限制pod和容器的Limits和Requests的最大比例上线，还能为pod中的容器提供默认的资源配置。

k8s基于pod的资源配置之实现了QOS。不同QOS级别的pod在系统中拥有不同的优先级。高优先级的pod有更高的可靠性，可以用于运行对可靠性要求高的服务，低优先级的pod可以实现集群资源的超分配。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。