@Rocky hey rocky. do you know when we create custom resource of starrocks which is running on k8s with starrock operator, why CR resourceversion change a lot because of cn pod? how can we stop this change of rv?

When you see the

resourceVersion

(RV) of your

StarRocksCluster

(SRC) custom resource changing frequently, it is almost always because the StarRocks Operator is updating the

status

field of that resource. In the case of CN (Compute Node) pods, this happens more frequently than with FE or BE pods for several specific reasons: 1. Why it happens (The "Why") * Autoscaling (HPA): If you have

autoScalingPolicy

enabled for your CN cluster, the Horizontal Pod Autoscaler (HPA) will frequently change the number of CN replicas based on CPU/Memory usage. Every time the replica count or the set of active pods changes, the Operator reconciles the state and updates the

status.cnStatus

field in the CR to reflect the current pod names, readiness, and registration status. * Status Tracking: The StarRocks Operator tracks the state of each CN pod. If a pod transitions between

Pending

,

Running

, or

Ready

(even briefly), or if a pod restarts, the Operator writes this update to the CR's status section. * Node Registration: CN nodes are stateless and often transient. The Operator manages their registration with the FE. If the Operator detects changes in the network or registration state of CN pods, it updates the status. * Redundant Status Updates (Operator Behavior): In some versions of the StarRocks Operator, the reconciliation loop may perform "blind" status updates—meaning it writes the status back to the API server in every loop even if nothing has significantly changed. Since every write operation increments the

resourceVersion

, the RV will climb rapidly. 2. How to stop or reduce the frequency (The "How") While you cannot "disable" the

resourceVersion

(as it is a core Kubernetes mechanism for concurrency control), you can stabilize the resource to stop the frequent updates: * Stabilize CN Pods: Check if your CN pods are frequently restarting or failing readiness probes. If pods are unstable, the Operator will constantly update the status. Use

kubectl get pods -n <namespace>

to check for restarts. * Tune HPA Settings: If the RV changes are driven by autoscaling, consider tuning the

behavior

in your

autoScalingPolicy

. You can set a longer

stabilizationWindowSeconds

for scaling down to prevent "flapping" (rapidly scaling up and down).

yaml
    autoScalingPolicy:
      hpaPolicy:
        behavior:
          scaleDown:
            stabilizationWindowSeconds: 300 # Wait 5 mins before scaling down

* Upgrade the StarRocks Operator: Recent versions of the operator (v1.9.x and later) have optimized how sub-resources (like StateFulSets or Deployments) are managed. Specifically, switching from full updates to patches helps prevent unnecessary reconciliation triggers. * Check for External Controllers: Ensure that external tools (like ArgoCD or a Service Mesh) aren't fighting with the Operator by adding/removing annotations or labels on the CR, which would also trigger a reconciliation and a status update. * Ignore Status in Watches: If your concern is that the frequent RV changes are triggering other automations (like a CI/CD pipeline or a custom script), configure those tools to ignore changes to the

.status

field and only react to changes in

.spec

or

.metadata.generation

. Summary: The RV change is a symptom of the Operator keeping the CR status in sync with the real-world state of the CN pods. If the pods or the scale are changing, the RV must change. If the RV is changing while the cluster is completely idle, it is likely a bug in the Operator's status-update logic, and you should upgrade to the latest version. References • deployment/sr_operator.md • faq/operation_maintenance_faq.md • administration/management/BE_configuration.md