[milvus] Support component deployment groups - #306

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: chyezh
To complete the pull request process, please assign haorenfsa after the PR has been reviewed.
You can assign the PR to them by writing /assign @haorenfsa in a comment when ready.

The full list of commands accepted by this bot can be found here.

QA Verification Summary

I verified this PR in the qa-milvus namespace with Helm release yezhen-dg.

What was validated

• proxy.groups, dataNode.groups, queryNode.groups, and streamingNode.groups can render multiple independent Deployments.
• Each Deployment group can independently configure replicas, labels, extraEnv, and scheduling through nodeSelector.
• mixCoordinator remains a single Deployment and supports custom labels.
• QueryNode and StreamingNode resource group labels are decoupled from Helm deployment groups and are controlled through MILVUS_SERVER_LABEL_RESOURCE_GROUP.

Runtime examples verified:

• querynode-new-a: MILVUS_SERVER_LABEL_RESOURCE_GROUP=new_rg_a
• querynode-new-b: MILVUS_SERVER_LABEL_RESOURCE_GROUP=new_rg_b
• streamingnode-new-a: MILVUS_SERVER_LABEL_RESOURCE_GROUP=new_rg_a
• streamingnode-new-b: MILVUS_SERVER_LABEL_RESOURCE_GROUP=new_rg_b

Proxy and DataNode were also split into separate AZ-style deployment groups with independent labels and env vars.

Blue-green flow verified

I validated a multi-replica to multi-replica blue-green flow. Runtime load and streaming settings were changed through etcd dynamic config, not through user.yaml.

Sequence:

1. Blue: replicaNumber=2, resourceGroups=old_rg_a,old_rg_b, streaming.primaryResourceGroup=old_rg_a
2. Overlap: replicaNumber=4, resourceGroups=old_rg_a,old_rg_b,new_rg_a,new_rg_b
3. Green: replicaNumber=2, resourceGroups=new_rg_a,new_rg_b, streaming.primaryResourceGroup=new_rg_a
4. Removed old QueryNode and StreamingNode deployment groups with a Helm upgrade.

Final state:

• Old QueryNode/StreamingNode Deployments were removed.
• New QueryNode/StreamingNode Deployments stayed Ready.
• /management/replica/loadconfig/compliance returned {"state":"Ready"}.
• new_rg_a and new_rg_b each had one loaded replica for the test collection.
• old_rg_a and old_rg_b had no nodes and no loaded replicas.

Workload result

A continuous search/query workload ran through baseline, overlap expansion, dynamic config switch, green cutover, and old deployment removal.

Final workload summary:

{"count": 1860, "errors": 0, "elapsed": 467.11}

Error log:

/tmp/yezhen_bg_errors.log: 0 lines

No serviceability or routing errors were observed, including:

• channel distribution is not serviceable
• channel not available
• no available shard leader
• partial-result errors

Compatibility check

I also checked the old paths:

• When groups are not configured, the default render path is unchanged except for chart/app/image version metadata.
• The existing replicaResourceGroups compatibility path still renders per-RG QueryNode and StreamingNode Deployments and writes the corresponding generated load config.

I added a documentation update to clarify that groups and replicaResourceGroups should not be mixed in the same release, because groups control the rendered Deployments while replicaResourceGroups still writes generated Milvus load config.