十、Kubernetes 调度原理

十、Kubernetes 调度原理

1、RsourceQuota

https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/

1、简介

• 当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。
• 资源配额是帮助管理员解决这一问题的工具。
• 资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。
• 资源配额的工作方式如下：
  • 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。
  • 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
  • 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会 跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
  • 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
  • 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用，则用户必须为 这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

2、实战测试

https://kubernetes.io/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/

3、计算资源配额

资源名称	描述
limits.cpu	所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。
limits.memory	所有非终止状态的 Pod，其内存限额总量不能超过该值。
requests.cpu	所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。
requests.memory	所有非终止状态的 Pod，其内存需求总量不能超过该值。
hugepages-	对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。
cpu	与 requests.cpu 相同。
memory	与 requests.memory 相同。

4、存储资源配额

https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/#%E5%AD%98%E5%82%A8%E8%B5%84%E6%BA%90%E9%85%8D%E9%A2%9D

资源名称	描述
requests.storage	所有 PVC，存储资源的需求总量不能超过该值。
persistentvolumeclaims	在该命名空间中所允许的 PVC 总量。
.storageclass.storage.k8s.io/requests.storage	在所有与 相关的持久卷申领中，存储请求的总和不能超过该值。
.storageclass.storage.k8s.io/persistentvolumeclaims	在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的持久卷申领总数。

例如，如果一个操作人员针对 gold 存储类型与 bronze 存储类型设置配额， 操作人员可以定义如下配额：

• gold.storageclass.storage.k8s.io/requests.storage: 500Gi
• bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

5、对象数量配额

https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/#%E5%AF%B9%E8%B1%A1%E6%95%B0%E9%87%8F%E9%85%8D%E9%A2%9D

你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置：

• count/.：用于非核心（core）组的资源
• count/：用于核心组的资源

这是用户可能希望利用对象计数配额来管理的一组资源示例。

• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/replicationcontrollers
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch

对有限的一组资源上实施一般性的对象数量配额也是可能的。 此外，还可以进一步按资源的类型设置其配额。

支持以下类型：

资源名称	描述
configmaps	在该命名空间中允许存在的 ConfigMap 总数上限。
persistentvolumeclaims	在该命名空间中允许存在的 PVC 的总数上限。
pods	在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed, Succeeded) 为真。
replicationcontrollers	在该命名空间中允许存在的 ReplicationController 总数上限。
resourcequotas	在该命名空间中允许存在的 ResourceQuota 总数上限。
services	在该命名空间中允许存在的 Service 总数上限。
services.loadbalancers	在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。
services.nodeports	在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。
secrets	在该命名空间中允许存在的 Secret 总数上限。

6、优先级

apiVersion: v1
kind: List  ### 集合   ---
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: "1000"
      memory: 200Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: "10"
      memory: 20Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "5"
      memory: 10Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]
        
---
########################
apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "10Gi"
        cpu: "500m"
      limits:
        memory: "10Gi"
        cpu: "500m"
  priorityClassName: high  ### priorityClass指定的是什么。就优先使用这个配额约束。

2、LimitRange

https://kubernetes.io/zh/docs/concepts/policy/limit-range/

批量删除

kubectl delete pods my-dep-5b7868d854-6cgxt quota-mem-cpu-demo quota-mem-cpu-demo2 -n hello

1、简介

• 默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。
• 使用资源配额，集群管理员可以以名字空间为单位，限制其资源的使用与创建。
• 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。
• 有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象。
• 超额指定。配额 1和cpu，1g内存。
  • Pod。 requests: cpu: 1,memory: 1G。这种直接一次性占完
  • 我们需要使用LimitRange限定一个合法范围
    • 限制每个Pod能写的合理区间

一个 LimitRange（限制范围） 对象提供的限制能够做到：

• 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
• 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
• 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
• 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。

2、实战

• 如何配置每个命名空间最小和最大的 CPU 约束。
• 如何配置每个命名空间最小和最大的内存约束。
• 如何配置每个命名空间默认的 CPU 申请值和限制值。
• 如何配置每个命名空间默认的内存申请值和限制值。
• 如何配置每个命名空间最小和最大存储使用量。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-min-max-demo-lr
  namespace: hello
spec:
  limits:
  - max:
      cpu: "800m"  ## 最大不超过800m
      memory: "1Gi"  ## Pod不写limit,request，那么Limit、request就会用到默认最大值
    min: 
      cpu: "200m"  ### 起步申请200
      memory: "20m"
    type: Container

apiVersion: v1
kind: Pod
metadata:
  name: quota-mem-cpu-demo2
  namespace: hello
spec:
  containers:
  - name: quota-mem-cpu-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "20Mi"   
        cpu: "900m"   ## 违背了 max.cpu: "800m"
      requests:
        memory: "10Mi"
        cpu: "20m"   ## 20m违背了 min.cpu: "200m"

• ResourceQuota：CPU内存都限制了

• LimitRange：只给了CPU的合法区别。

  • 以后Pod只需要写内存的合法区间

  • LimitRange都指定范围。Pod可以不用指定，如下，用到默认最大值

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fcwhViS6-1657519117421)(images/9.Kubernetes-调度原理/1621050950187.png)]

  • default	[string]string>: 给limits默认值
       
    defaultRequest	[string]string>: 给requests默认值的
       
    max	[string]string>: 最大使用量
       
    maxLimitRequestRatio	[string]string>: 3 
    		limit / request <= ratio;
    		800/200 = 4 > 3 ## 被拒绝
    		
    min	[string]string>: 最小使用量
        
    type	 -required-: Container、Pod		
    		
    

  • apiVersion: v1
    kind: LimitRange
    metadata:
      name: limit-memory-ratio-pod
    spec:
      limits:
      - maxLimitRequestRatio:
          memory: 2
          cpu: 3
        type: Pod
      - type: Container
        max: 
        min: 
    

3、调度原理

Pod。scheduler要计算他应该去哪个Node合适。（调度）

nodeSelector ： 指定去哪些Node

1、nodeSelector

nodeSelector 是节点选择约束的最简单推荐形式。nodeSelector 是 PodSpec 的一个字段。 它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中 必须包含这里的每个键值对（它也可以具有其他标签）。 最常见的用法的是一对键值对。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd  ## 标签名。每个Node节点可以打标签

ingress-nginx：参照

除了你添加的标签外，节点还预先填充了一组标准标签。 这些标签有：

• kubernetes.io/hostname
• failure-domain.beta.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region
• topology.kubernetes.io/zone
• topology.kubernetes.io/region
• beta.kubernetes.io/instance-type
• node.kubernetes.io/instance-type
• kubernetes.io/os
• kubernetes.io/arch

说明：

这些标签的值是特定于云供应商的，因此不能保证可靠。 例如，kubernetes.io/hostname 的值在某些环境中可能与节点名称相同， 但在其他环境中可能是一个不同的值。

1、直接不用调度

apiVersion: v1
kind: Pod
metadata:
  name: nginx-nodename
  labels:
    env: test
spec:
  nodeName: k8s-node1  ## master默认除外  ## scheduler无需工作
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

2、Affinity(亲和) and anti-affinity(反亲和)

Pod：到底去哪些机器。

• scheduler 进行自己计算调度
• 某些机器对这些Pod有吸引力。Pod希望scheduler 把他调度到他喜欢的哪些机器。

亲和性能设置如下

kubectl explain pod.spec.affinity

KIND:     Pod
VERSION:  v1

RESOURCE: affinity >

DESCRIPTION:
     If specified, the pod's scheduling constraints

     Affinity is a group of affinity scheduling rules.

FIELDS:
   nodeAffinity