k8s 资源管理

it噩梦

已于 2024-09-12 16:58:01 修改

阅读量1.3k

点赞数 30

文章标签： kubernetes 贪心算法 java

于 2024-09-10 22:11:51 首次发布

本文链接：https://blog.csdn.net/qq_37362891/article/details/142091787

版权

文章目录

ResourceQuota
LimitRange
QoS

节点故障大部分都是由于资源分配不合理、超额分配引起的，因此需要用某个技术手段保证节点的资源不会过大地超额分配。Kubernetes为我们提供了开箱即用的资源管理，可以通过ResourceQuota和LimitRange的配合防止节点资源超额分配。

ResourceQuota

首先看一下ResourceQuota（资源配额）的使用，资源配额是限制某个命名空间对资源使用的一个总量限制，比如内存、CPU、Pod数量等。

什么是资源配额

在生产环境中，可能会有多个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-quota
  namespace: default
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "10Gi"
    limits.cpu: "8"
    limits.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-quota
  namespace: 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-pvc
  namespace: quota-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: 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-pvc2
  namespace: quota-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

kubectl create -f pvc2.yaml -n quota-example

在这里插入图片描述

可以看到此时无法创建PVC，其他资源的限制类似，在此不再演示。

环境清理：

LimitRange

和ResourceQuota不同的是，LimitRange用来配置默认值，也就是一个Pod如果没有配置要用多少内存、CPU，LimitRange会在创建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.5（0.5为半颗CPU，1个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.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
  namespace: default
spec:
  limits:
  - default:
      cpu: 1
      memory: 512Mi
    defaultRequest:
      cpu: 0.5
      memory: 256Mi
    type: Container

default: 当 Pod 没有指定资源限制时，为容器设置默认的 CPU 和内存上限。
defaultRequest: 当 Pod 没有指定资源请求时，为容器设置默认的 CPU 和内存请求。
type: 规定该规则适用于容器级别。

应用 LimitRange：
使用 kubectl 命令将 LimitRange 对象应用到 Kubernetes 集群中。

kubectl apply -f cpu-mem-limit-range.yaml
验证 LimitRange：
可以使用以下命令查看已经定义的 LimitRange：

kubectl get limitrange -n default

删除limit range

kubectl delete limitrange cpu-mem-limit-range -n default

定义pod，touch nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

kubectl apply -f nginx-pod.yaml

kubectl 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.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-min-max-demo-1r
spec:
  limits:
  - max:
      cpu: "800m"
      memory: "1Gi"
    min:
      cpu: "200m"
      memory: "500Mi"
    type: Container

kubectl apply -f cpu-mem-limit-range.yaml
验证 LimitRange：
可以使用以下命令查看已经定义的 LimitRange：

kubectl get limitrange -n default

kubectl get limitrange cpu-min-max-demo-1r -o yaml

在这里插入图片描述
假设创建一个内存最大值超过limits限制的Pod：

vim nginx-pod1.yaml
kubectl apply -f nginx-pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      limits:
        memory: "1.5Gi"
      requests:
        memory: "800Mi"

在这里插入图片描述

假设创建一个内存最小值小于limits最小值的Pod：

vim nginx-pod2.yaml
kubectl apply -f nginx-pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      limits:
        memory: "1.5Gi"
      requests:
        memory: "100Mi"

在这里插入图片描述

QoS

虽然我们进行了资源限制，但是实际使用时依旧会造成节点资源不足，针对资源不足Kubernetes会通过重启或驱逐Pod释放资源，再重启时，难免会造成一些很重要的服务不可用。但实际情况可能是，如果重启或驱逐一些不重要的Pod可能会更好，而这种决策是通过QoS（Quality 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-container
    image: nginx
    resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在这里插入图片描述

如果容器指定了limits的cpu和memory配置，但是没有指定requests的cpu和memory配置，Kubernetes会自动添加和limits配置相同的requests配置。

示例2：实现QoS为Burstable的Pod

创建一个QoS为Burstable的Pod需要满足以下条件：

1）Pod不符合Guaranteed的配置要求。

2）Pod中至少有一个容器配置了requests.cpu或者requests.memory。

定义一个Burstable的Pod：

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: nginx-container-1
    image: nginx:latest
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
    - containerPort: 80
    env:
    - name: NGINX_PORT
      value: "80"
    command: [ "sh", "-c", "nginx -g 'daemon off;' -c /etc/nginx/nginx.conf" ]
  - name: nginx-container-2
    image: nginx:latest
    resources:
      requests:
        memory: "32Mi"
        cpu: "100m"
    ports:
    - containerPort: 8080
    env:
    - name: NGINX_PORT
      value: "8080"
    command: [ "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-1
    image: nginx

kubectl describe pod besteffort-pod

在这里插入图片描述