karmada Resources cannot be rescheduled

What happened: member3集群（两个节点，每个节点CPU为16核） member4集群（1个节点，每个节点CPU为16核）

deployment.yaml文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        resources:
          requests:
            cpu: "9"

PropagationPolicy文件如下：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member3

修改后的PropagationPolicy文件如下：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member3
        - member4
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas

发现资源无法调度：

[root@master ldy]# kubectl karmada get po
NAME                          CLUSTER   READY   STATUS      RESTARTS   AGE
busybox                       member3   1/1     Running     0          16d
nginx-6468549c48-jmxtr        member3   1/1     Running     0          20m
nginx-6468549c48-t5cjv        member3   1/1     Running     0          20m
nginx-6468549c48-tg258        member3   0/1     Pending     0          20m

What you expected to happen: 能够根据资源情况自动非配，进行重新调度，一个pod在member4集群，另外两个pod在member3集群

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

Karmada version:
kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version):
Others:

Jul 14 '22 09:07 first-sight12

你是否部署了karmada-scheduler-estimator?

Jul 15 '22 02:07 chaunceyjiang

第一次提交PropagationPolicy时，使用的策略是：

  placement:
    clusterAffinity:
      clusterNames:
        - member3

此时是复制的，也就是3个副本都分到了member3中。

第二次提交的PropagationPolicy时，使用的策略是：

    clusterAffinity:
      clusterNames:
        - member3
        - member4
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas

此时指示拆分副本，因为3个副本都已经分配到member3，没有触发重新调度，应该是预期行为。

这种情况，把deployment删除重建是可以的。或者，告诉我们你的场景，看下如何做？

Jul 15 '22 03:07 RainbowMango

你是否部署了karmada-scheduler-estimator?

已经部署

Jul 15 '22 03:07 first-sight12

第一次提交PropagationPolicy时，使用的策略是：

虽然第一次提交的PropagationPolicy分发到了member3，但是member3只够跑两个pod，此时pod的状态是2个running，一个pending，此时修改PropagationPolicy为descheduler模式，是否应该将那个pending状态的pod调度到member4更合理一些呢？毕竟查看pp的内容，已经是descheduler模式了

Jul 15 '22 03:07 luoMonkeyKing

此时修改PropagationPolicy为descheduler模式，是否应该将那个pending状态的pod调度到member4更合理一些呢？毕竟查看pp的内容，已经是descheduler模式了

首先，没有descheduler模式，我猜你想表达的是divide模式。

是的，我同意应该把pending的pod状态调度到member4，当前这部分能力应该在descheduler中。请问你是否部署了descheduler? https://github.com/karmada-io/karmada/blob/master/docs/descheduler.md

Jul 15 '22 03:07 RainbowMango

此时修改PropagationPolicy为descheduler模式，是否应该将那个pending状态的pod调度到member4更合理一些呢？毕竟查看pp的内容，已经是descheduler模式了

首先，没有descheduler模式，我猜你想表达的是divide模式。

是的，我同意应该把pending的pod状态调度到member4，当前这部分能力应该在descheduler中。请问你是否部署了descheduler? https://github.com/karmada-io/karmada/blob/master/docs/descheduler.md

sorry，确实是divided模式，不是descheduler模式。已经部署了descheduler组件，并且直接部署divided模式的pp时，是可以成功调度的，调度的结果是member3中2个pod，member4中1个pod，这种已经达到了预期行为。但是如果先部署该issue中的第一个pp，然后再修改为divided模式时，就不会再调度了，没有资源的pod会一直显示pending状态

Jul 15 '22 04:07 luoMonkeyKing

此时修改PropagationPolicy为descheduler模式，是否应该将那个pending状态的pod调度到member4更合理一些呢？毕竟查看pp的内容，已经是descheduler模式了

首先，没有descheduler模式，我猜你想表达的是divide模式。是的，我同意应该把pending的pod状态调度到member4，当前这部分能力应该在descheduler中。请问你是否部署了descheduler? https://github.com/karmada-io/karmada/blob/master/docs/descheduler.md

sorry，确实是divided模式，不是descheduler模式。已经部署了descheduler组件，并且直接部署divided模式的pp时，是可以成功调度的，调度的结果是member3中2个pod，member4中1个pod，这种已经达到了预期行为。但是如果先部署该issue中的第一个pp，然后再修改为divided模式时，就不会再调度了，没有足够资源运行的pod会一直显示pending状态

Jul 15 '22 06:07 luoMonkeyKing

补充一下，下面是scheduler组件的日志：

I0715 06:15:16.932154       1 select_clusters.go:19] select all clusters
I0715 06:15:16.932175       1 generic_scheduler.go:75] selected clusters: [member3 member4]
I0715 06:15:16.933609       1 util.go:72] Target cluster: [{member3 0} {member4 1}]
E0715 06:15:16.933648       1 scheduler.go:426] Failed scheduling ResourceBinding default/nginx-deployment: failed to assignReplicas: failed to scaleUp: clusters resources are not enough to schedule, max 1 replicas are support
I0715 06:15:16.933667       1 scheduler.go:427] "End scheduling resource binding" resourceBinding="default/nginx-deployment"

Jul 15 '22 06:07 luoMonkeyKing

此时修改PropagationPolicy为descheduler模式，是否应该将那个pending状态的pod调度到member4更合理一些呢？毕竟查看pp的内容，已经是descheduler模式了

首先，没有descheduler模式，我猜你想表达的是divide模式。是的，我同意应该把pending的pod状态调度到member4，当前这部分能力应该在descheduler中。请问你是否部署了descheduler? https://github.com/karmada-io/karmada/blob/master/docs/descheduler.md

sorry，确实是divided模式，不是descheduler模式。已经部署了descheduler组件，并且直接部署divided模式的pp时，是可以成功调度的，调度的结果是member3中2个pod，member4中1个pod，这种已经达到了预期行为。但是如果先部署该issue中的第一个pp，然后再修改为divided模式时，就不会再调度了，没有资源的pod会一直显示pending状态

这算是一个bug吗还是使用方式不对@RainbowMango

Jul 18 '22 08:07 first-sight12

很难说是个bug，因为这个能力当前确实没有在调度器里，而是在descheduler里。

Jul 18 '22 09:07 RainbowMango

很难说是个bug，因为这个能力当前确实没有在调度器里，而是在descheduler里。

但是预期结果和pp里面的策略已经不一致了，很容易让人产生误会

Jul 18 '22 09:07 luoMonkeyKing

但是预期结果和pp里面的策略已经不一致了，很容易让人产生误会

cc @Garrybest for comments

Jul 19 '22 02:07 RainbowMango

预期结果不一致就是因为资源不够了，如果member1和member2多加点资源，这里是调度正常的。调度器一次调度中，做不到又驱逐又调度。

Jul 19 '22 02:07 Garrybest

预期结果不一致就是因为资源不够了，如果member1和member2多加点资源，这里是调度正常的。调度器一次调度中，做不到又驱逐又调度。

如果开始只添加一个集群member3（2个running，一个pending），但是后边修改pp策略把member4添加进去，这时候就会是member3（2个running），member4（1一个running）,如果按照你所说的的资源不够，无法又驱逐又调度，那member3中pending状态的pod是如何调度到member4的初始策略：

      clusterNames:
        - member3
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas

修改后：

      clusterNames:
        - member3
        - member4
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas

Jul 19 '22 02:07 first-sight12

一开始用duplicate策略强制把3个副本全部发到member3，member3启动了三个pod。现在改成divided，调度器认为member4只够一个副本，member3现在没资源（因为没法一次调度期间又驱逐又调度，之前的pod都把资源给占了）。

那member3中pending状态的pod是如何调度到member4的？

没懂这句话的意思，现在现象就是pod调度不到member4，因为没有更多资源。

Jul 19 '22 03:07 Garrybest

一开始用duplicate策略强制把3个副本全部发到member3，member3启动了三个pod。现在改成divided，调度器认为member4只够一个副本，member3现在没资源（因为没法一次调度期间又驱逐又调度，之前的pod都把资源给占了）。

那member3中pending状态的pod是如何调度到member4的？

没懂这句话的意思，现在现象就是po调度不到member4，因为没有更多资源。

意思就是一开始就是使用Divided模式，资源是可以调度的，如果使用duplicate模式切换到Divided模式是无法调度的

Jul 19 '22 04:07 first-sight12

一开始就是使用Divided模式，资源是充足的，因为现在集群里面没有pod。如果先使用duplicate模式，这3个pod已经在集群里面生产了，那么再切换为Divided，由于之前生产的pod会占用资源，所以调度器认为无资源可用，就会有资源不足的事件。这个时候如果删掉deployment重新创建就能行，或者是把集群资源稍微加大一点，就能正常。

Jul 19 '22 04:07 Garrybest

一开始就是使用Divided模式，资源是充足的，因为现在集群里面没有pod。如果先使用duplicate模式，这3个pod已经在集群里面生产了，那么再切换为Divided，由于之前生产的pod会占用资源，所以调度器认为无资源可用，就会有资源不足的事件。这个时候如果删掉deployment重新创建就能行，或者是把集群资源稍微加大一点，就能正常。

如果先使用duplicate模式，这3个pod已经在集群member3里面(2个running，1个pending)生产了，那么再切换为Divided，此时pp策略新加入集群member4（即此时有两个集群member3（两个节点）和member4（单节点）），这时期望的结果应该是member3有2个running的pod，member4有一个running的pod

Jul 19 '22 06:07 first-sight12

karmada karmada copied to clipboard

Resources cannot be rescheduled

karmada
karmada copied to clipboard