Kubernetes调度机制

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在Kubernetes 中

• CPU称为 “可压缩资源” ，可压缩资源不足时，Pod只会“饥饿”，不会退出
• 内存称为“不可压缩资源”，不可压缩资源不足时，Pod会因为OOM（Out-Of-Memory）被内核杀掉
• Pod 可以由多个 Container 组成，所以 CPU 和内存资源的限额，是要配置在每个 Container 的定义上的，而Pod整体资源配置，就由这些 Container 的配置值累加得到

三个级别，衔接上面

• Guaranteed ：Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 limits 值相等的时候，这个 Pod 就属于 Guaranteed 类别

  apiVersion: v1
  kind: Pod
  metadata:
    name: qos-demo
    namespace: qos-example
  spec:
    containers:
    - name: qos-demo-ctr
      image: nginx
      resources:
        limits:
          memory: "200Mi"
          cpu: "700m"
        requests:
          memory: "200Mi"
          cpu: "700m"
  

• Burstable ：当 Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests。那么这个 Pod 就会被划分到 Burstable 类别

  apiVersion: v1
  kind: Pod
  metadata:
    name: qos-demo-2
    namespace: qos-example
  spec:
    containers:
    - name: qos-demo-2-ctr
      image: nginx
      resources:
        limits
          memory: "200Mi"
        requests:
          memory: "100Mi"
  

• BestEffort ：如果 Pod 既没有设置 requests，也没有设置 limits，那么它的 QoS 类别就是 BestEffort

  apiVersion: v1
  kind: Pod
  metadata:
    name: qos-demo-3
    namespace: qos-example
  spec:
    containers:
    - name: qos-demo-3-ctr
      image: nginx
  

一个实际生产中非常有用的特性，衔接上面

在使用容器时，可以通过设置 cpuset 把容器绑定到某个 CPU 的核上，而不是像 cpushare 那样共享 CPU 的计算能力，这样CPU之间进行上下文切换的次数大大减少，容器里应用的性能会得到大幅提升

• Pod 必须是 Guaranteed 的 QoS 类型
• 将 Pod 的 CPU 资源的 requests 和 limits 设置为同一个相等的整数值

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

1. 第一种类型，GeneralPredicates ：这一组过滤规则，负责的是最基础的调度策略，计算的就是宿主机的 CPU 和内存资源等是否够用。
2. 第二种类型，与 Volume 相关的过滤规则 ：这一组过滤规则，负责的是跟容器持久化 Volume 相关的调度策略。
3. 第三种类型，是宿主机相关的过滤规则 ：这一组规则，主要考察待调度 Pod 是否满足 Node 本身的某些条件。比如，PodToleratesNodeTaints，负责检查的就是我们前面经常用到的 Node 的“污点”机制。
4. 第四种类型，是 Pod 相关的过滤规则 ：这一组规则，跟 GeneralPredicates 大多数是重合的。而比较特殊的，是 PodAffinityPredicate。这个规则的作用，是检查待调度 Pod 与 Node 上的已有 Pod 之间的亲密（affinity）和反亲密（anti-affinity）关系

Goroutine go语言的“线程”，比传统线程对资源的占用更合理

score = (cpu((capacity-sum(requested))10/capacity) + memory((capacity-sum(requested))10/capacity))/2

score = 10 - variance(cpuFraction,memoryFraction,volumeFraction)*10

• 先在Kubernetes里提交一个PriorityClass，如下:

  apiVersion: scheduling.k8s.io/v1beta1
  kind: PriorityClass
  metadata:
    name: high-priority
  value: 1000000
  globalDefault: false
  description: "This priority class should be used for high priority service pods only."
  

这个YAML文件名为high-priority

value ：值越大代表优先级越高（最大1000000000/10亿）

globalDefault ：声明使用该PriorityClass的Pod拥有值为1000000 的优先级，没有声明则为0。 true 的话，那就意味着这个 PriorityClass 的值会成为系统的默认值

• 然后我们在Pod就可以声明使用，如下

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
    labels:
      env: test
  spec:
    containers:
    - name: nginx
      image: nginx
      imagePullPolicy: IfNotPresent
    priorityClassName: high-priority
  

提交后，Kubernetes 的 PriorityAdmissionController 就会自动将这个 Pod 的 spec.priority 字段设置为 1000000

• 第一组，是 RuntimeService。它提供的接口，主要是跟容器相关的操作。比如，创建和启动容器、删除容器、执行 exec 命令等等。
• 而第二组，则是 ImageService。它提供的接口，主要是容器镜像相关的操作，比如拉取镜像、删除镜像等等。

• 第一 ，Pod 是 Kubernetes 的编排概念，而不是容器运行时的概念。所以，我们就不能假设所有下层容器项目，都能够暴露出可以直接映射为 Pod 的 API。
• 第二 ，如果 CRI 里引入了关于 Pod 的概念，那么接下来只要 Pod API 对象的字段发生变化，那么 CRI 就很有可能需要变更。而在 Kubernetes 开发的前期，Pod 对象的变化还是比较频繁的，但对于 CRI 这样的标准接口来说，这个变更频率就有点麻烦了。