elastic quota 弹性抢占疑问[question]

[zj619]

What happened: kubectl create ns namespace1 kubectl create ns namespace2 相关配置 创建队列 队列配置文件如下 root.yml apiVersion: scheduling.sigs.k8s.io/v1alpha1 kind: ElasticQuota metadata: name: root labels: quota.scheduling.koordinator.sh/is-parent: "true" quota.scheduling.koordinator.sh/allow-lent-resource: "true" spec: max: cpu: 2 memory: 2Gi min: cpu: 2 memory: 2Gi

queue-a.yml apiVersion: scheduling.sigs.k8s.io/v1alpha1 kind: ElasticQuota metadata: name: a namespace: namespace1 labels: quota.scheduling.koordinator.sh/parent: "root" quota.scheduling.koordinator.sh/is-parent: "false" quota.scheduling.koordinator.sh/allow-lent-resource: "true" annotations: quota.scheduling.koordinator.sh/shared-weight: '{"cpu":"1","memory":"1Gi"}' spec: max: cpu: 2 memory: 2Gi min: cpu: 1 memory: 1Gi

queue-b.yaml apiVersion: scheduling.sigs.k8s.io/v1alpha1 kind: ElasticQuota metadata: name: b namespace: namespace2 labels: quota.scheduling.koordinator.sh/parent: "root" quota.scheduling.koordinator.sh/is-parent: "false" quota.scheduling.koordinator.sh/allow-lent-resource: "true" annotations: quota.scheduling.koordinator.sh/shared-weight: '{"cpu":"1","memory":"1Gi"}' spec: max: cpu: 2 memory: 2Gi min: cpu: 1 memory: 1Gi

先运行pod-a.yaml，qos等级为BE apiVersion: v1 kind: Pod metadata: name: pod-a namespace: namespace1 labels: quota.scheduling.koordinator.sh/name: "a" koordinator.sh/qosClass: BE #qos spec: schedulerName: koord-scheduler priorityClassName: koord-batch containers:

• command:
  • sleep
  • 365d image: kde1:8025/warehouse/nginx imagePullPolicy: IfNotPresent name: curlimage resources: limits: cpu: 1 memory: 1Gi requests: cpu: 1 memory: 1Gi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File restartPolicy: Always

再次运行pod-d.yaml，qos等级为LSE apiVersion: v1 kind: Pod metadata: name: pod-d namespace: namespace2 labels: quota.scheduling.koordinator.sh/name: "b" koordinator.sh/qosClass: "LSE" spec: schedulerName: koord-scheduler priorityClassName: koord-prod containers:

• command:
  • sleep
  • 365d image: kde1:8025/warehouse/nginx imagePullPolicy: IfNotPresent name: curlimage resources: limits: cpu: 1 memory: 1Gi requests: cpu: 1 memory: 1Gi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File restartPolicy: Always

结果如下，pod-a和pod-d都running

再运行一个qos等级为LSE的pod-e，不能抢占pod-a的资源

pod-e.yaml apiVersion: v1 kind: Pod metadata: name: pod-e namespace: namespace2 labels: quota.scheduling.koordinator.sh/name: "b" koordinator.sh/qosClass: "LSE" spec: schedulerName: koord-scheduler priorityClassName: koord-prod containers:

• command:
  • sleep
  • 365d image: kde1:8025/warehouse/nginx imagePullPolicy: IfNotPresent name: curlimage resources: limits: cpu: 1 memory: 1Gi requests: cpu: 1 memory: 1Gi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File restartPolicy: Always

为什么pod-e不会抢占pod-a的资源 ~
：

What you expected to happen:

Environment:

• Koordinator version: - v1.5.0
• Kubernetes version (use kubectl version): v1.22.5
• docker/containerd version: containerd 1.5.0
• OS (e.g: cat /etc/os-release): Ubuntu 20.04.4 LTS
• Kernel (e.g. uname -a): Linux 5.10.112-11.al8.x86_64 #1 SMP Tue May 24 16:05:50 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

Anything else we need to know:

[saintube]

PTAL @shaloulcy

[saintube]

@zj619 It seems the pod-e is firstly admitted by the quota-b and rejected due to exceeding the quota min.

[zj619]

@zj619 It seems the pod-e is firstly admitted by the quota-b and rejected due to exceeding the quota min. 高qos的不是能抢占低qos的资源吗，为什么pod-e没有抢占pod-a的资源

[saintube]

@zj619 It seems the pod-e is firstly admitted by the quota-b and rejected due to exceeding the quota min. 高qos的不是能抢占低qos的资源吗，为什么pod-e没有抢占pod-a的资源

首先，pod-e 的调度需要满足叶子节点的限制。否则，即使 pod-a 被抢占，pod-e 因为叶子结点超限也无法调度。