Karmada version: v1.20.10

seems like you put the wrong version here,1.31 is karmada latest version, what's your karmada version.

@LivingCcj have you figured out the root cause? It would be great if you could point out the code that doesn't work as expected.

At Predicate step, the UndateFunc should ignore the requeue if only cluster.status changed. Only if cluster_status controller requeue cluster object only by the interval of cluster-status-update-frequency

In pull mode, the Predicate func for karmada-agent.

In push mode, the Predicate func for karmada-controller-manager.

Are you saying that for both pull mode and push mode, the cluster-status-controller updates the Cluster status continuously, regardless of the --cluster-status-update-frequency flag?

If so, it would be a serious mistake that affects the performance heavily.

cc @zach593 @CharlesQQ take a look

yeah，just like your saying

this pr which could fix the issue

I add and delete workload for many times, but not find the update the Cluster status continuously, which same as --cluster-status-update-frequency, @LivingCcj Could you please detailed description on the steps to reproduce your problem?

@CharlesQQ You've done the test I wanted to do! Thank you very much!

Thank you for attentions firstly @RainbowMango @CharlesQQ.
This test scenario needs to add or delete workload frequently in member cluster. like the shell script in member cluster

kubectl delete -f deployment.yaml
sleep 1
kubectl apply -f deployment.yaml
for i in {1..1000}; do
    sleep 1
    random_number=$((RANDOM % 11))
    echo $random_number
    kubectl scale -f deployment.yaml --replicas=$random_number
done

kubectl delete -f deployment.yaml

@LivingCcj can you share some logs? Like @CharlesQQ posted above, showing the sync timeline.

Load some log from prod member cluster, the period of requeue is less more

@LivingCcj Can you figure out which cluster status fields are changing?

@LivingCcj Can this be reproduced with the upstream version?

In member cluster，there are more short-period workloads, the number of pod and the request resource of pod will be changed frequently，and the cluster.status.resourceSummary will be updated frequently. @CharlesQQ
In the upstream version, the following code will cause the same issue. @RainbowMango

At Predicate step, the UndateFunc should ignore the requeue if only cluster.status changed. Only if cluster_status controller requeue cluster object only by the interval of cluster-status-update-frequency

In pull mode, the Predicate func for karmada-agent.

karmada/pkg/util/helper/predicate.go

Lines 158 to 174 in 787fd3a

// NewClusterPredicateOnAgent generates an event filter function with Cluster for karmada-agent.
func NewClusterPredicateOnAgent(clusterName string) predicate.Funcs {
return predicate.Funcs{
CreateFunc: func(createEvent event.CreateEvent) bool {
return createEvent.Object.GetName() == clusterName
},
UpdateFunc: func(updateEvent event.UpdateEvent) bool {
return updateEvent.ObjectOld.GetName() == clusterName
},
DeleteFunc: func(deleteEvent event.DeleteEvent) bool {
return deleteEvent.Object.GetName() == clusterName
},
GenericFunc: func(event.GenericEvent) bool {
return false
},
}
}
In push mode, the Predicate func for karmada-controller-manager.

karmada/cmd/controller-manager/app/controllermanager.go

Lines 290 to 321 in 787fd3a

clusterPredicateFunc := predicate.Funcs{
CreateFunc: func(createEvent event.CreateEvent) bool {
obj := createEvent.Object.(*clusterv1alpha1.Cluster)

  if obj.Spec.SecretRef == nil { 
  	return false 
  } 

  return obj.Spec.SyncMode == clusterv1alpha1.Push 

},
UpdateFunc: func(updateEvent event.UpdateEvent) bool {
obj := updateEvent.ObjectNew.(*clusterv1alpha1.Cluster)

  if obj.Spec.SecretRef == nil { 
  	return false 
  } 

  return obj.Spec.SyncMode == clusterv1alpha1.Push 

},
DeleteFunc: func(deleteEvent event.DeleteEvent) bool {
obj := deleteEvent.Object.(*clusterv1alpha1.Cluster)

  if obj.Spec.SecretRef == nil { 
  	return false 
  } 

  return obj.Spec.SyncMode == clusterv1alpha1.Push 

},
GenericFunc: func(event.GenericEvent) bool {
return false
},
}

Seems I reproduced it on my side:

I0414 10:24:48.915092       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:24:58.925379       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:24:58.943743       1 cluster_status_controller.go:129] Syncing cluster status: member3  // this one       
I0414 10:25:08.942816       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:25:18.948969       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:25:28.954873       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:25:38.965408       1 cluster_status_controller.go:129] Syncing cluster status: member3
I0414 10:25:38.994816       1 cluster_status_controller.go:129] Syncing cluster status: member3  // this one
I0414 10:25:48.994952       1 cluster_status_controller.go:129] Syncing cluster status: member3

Hi @LivingCcj not only the pull cluster has this problem, but the push cluster also has the same problem?

/assign @LivingCcj
In favor of #6284

Hi @LivingCcj not only the pull cluster has this problem, but the push cluster also has the same problem?

Thanks for your attentions, the same problem will be issued in karmada-controller-manager(in push mode) and karmada-agent (in pull mode)

Thanks for your attentions, the same problem will be issued in karmada-controller-manager(in push mode) and karmada-agent (in pull mode)

Would you mind changing the title of this issue to make it clearer?

/retitle cluster status update interval inconsistent with --cluster-status-update-frequency in both push and pull mode