kubernetes——计算资源管理

在pod中申请资源

apiVersion: v1
kind: Pod## 标题
metadata:
  name: kubia-ce
  namespace: test
  labels:
    name: kubia-ce
spec:
  containers:
  - name: kubia-ce
    image: luksa/kubia
    resources:
      requests:
        cpu: 100m
        memory: 10Mi
      limits:
        cpu: 200m
        memory: 15Mi
    ports:
      - containerPort: 8080

通过设置资源requests我们指定了pod对资源需求的最小值，当在调度pod时，会根据需求和节点的可分配的量进行调度。

注意：调度时，不会关注各资源当前实际的使用量，只会关注当前各资源的所有pod的requests占用的资源量和。

CPU request如何影响CPU时间分配

CPU requests不仅仅在调度时会起作用，它还决定着剩余的CPU时间如何在pod之间分配。

举例：

如果两个pod对cpu的需求量是1:5，如果该节点的cpu未满负荷运行，则剩下的cpu资源，按照1:5的分配，将资源分配给两个pod。

限制容器可用资源

如果在创建yaml没有指定requests，它将被设置未与资源limits相同的值。

与资源requests不同的是，资源limits可以超过节点资源总和的100%。但是如果节点使用资源超过100%，一些容器将被杀掉。

定义Qos等级

kubernetes将pod分为三个等级

• BestEffort，优先级最低
• Burstable
• Guaranteed，优先级最高

BestEffort等级

该等级会分配给那些没有设置任何requests和limits的pod。

Guaranteed等级

分配该等级符合：
cpu和内存都要设置requests和limits
每个容器都要设置资源量
他们必须相等

则分配给Guaranteed等级

Burstable等级

此等级介于BestEffort等级和Guaranteed等级之间。

内存不足时，哪个进程会被杀死

按照从低到高的等级排列，低等级的进程会被首先杀掉，但是如何处理相同的Qos等级的容器。

当等级相同时，系统会比较现在OOM分数的值，当需要释放内存时，系统找到等级最低的分数最高的进程，该进程将被杀死。

LimitRange

limitrange可以给每种资源配置最大值和最小值，也可以给容器配置最大值和最小值、默认值等。

创建LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: test
  namespace: test
spec:
  limits:
    - type: Pod#在pod层面上，最小的需求和限制最大的需求量
      min:
        cpu: "100m"
        memory: "10Mi"
      max:
        cpu: "200m"
        memory: "20Mi"
    - type: Container#在容器层面上，设置默认值。
      defaultRequest:
        cpu: "100m"
        memory: "15Mi"
      default:
        cpu: "200m"
        memory: "20Mi"
        

ResourceQuota资源

LimitRange只应用于单独的pod，我们也需要一种手段限制命名空间的可用资源总量。

创建ResourceQuota

apiVersion: v1
kind: ResourceQuota
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 10Mi
    limits.cpu: 1000m
    limits.memory: 15Mi