KubeDB

By AppsCode

CONTACT SALES

New to KubeDB? Please start here.

Vertical Scaling Milvus

This guide will show you how to use the KubeDB Ops-manager operator to update the resources (CPU/memory) of a Milvus database.

Before You Begin

Note: The yaml files used in this tutorial are stored in docs/guides/milvus/scaling/vertical-scaling/yamls folder in GitHub repository kubedb/docs.

Vertical Scaling Standalone Milvus

Deploy the standalone quickstart manifest and wait until it is Ready. By default the standalone workload requests cpu: 500m / memory: 1Gi:

If you deleted a Milvus of the same name in an earlier guide, delete its object-storage prefix first, as shown in Prepare Dependencies. Otherwise the new database can hang in Provisioning.

$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.10.12/docs/guides/milvus/quickstart/yamls/standalone.yaml
milvus.kubedb.com/milvus-standalone created

$ kubectl get milvuses.kubedb.com -n demo milvus-standalone -w

$ kubectl get petset milvus-standalone -n demo -o jsonpath='{.spec.template.spec.containers[0].resources}'
{"limits":{"memory":"1Gi"},"requests":{"cpu":"500m","memory":"1Gi"}}

Apply the VerticalScaling OpsRequest

vertical-scaling-standalone.yaml

apiVersion: ops.kubedb.com/v1alpha1
kind: MilvusOpsRequest
metadata:
  name: vertical-scaling-standalone
  namespace: demo
spec:
  type: VerticalScaling
  databaseRef:
    name: milvus-standalone
  verticalScaling:
    node:
      resources:
        requests:
          memory: "2Gi"
          cpu: "1"
        limits:
          memory: "2Gi"
          cpu: "1"
  timeout: 5m
  apply: IfReady

Here,

  • spec.verticalScaling.node carries the new resources for the standalone workload (use the node key for standalone).
  • spec.verticalScaling.mode specifies how the scaling is actuated — Restart (default, restarts the Pods) or InPlace (resizes the running Pods without a restart, falling back to restart if a Node can’t fit the new resources). See Vertical Scaling Modes.
$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.10.12/docs/guides/milvus/scaling/vertical-scaling/yamls/vertical-scaling-standalone.yaml
milvusopsrequest.ops.kubedb.com/vertical-scaling-standalone created

Watch Progress

$ kubectl get milvusopsrequest vertical-scaling-standalone -n demo
NAME                          TYPE              STATUS       AGE
vertical-scaling-standalone   VerticalScaling   Successful   56s

$ kubectl describe milvusopsrequest vertical-scaling-standalone -n demo
...
Status:
  Conditions:
    Message:  Milvus ops-request has started to vertically scale the Milvus nodes
    Reason:   VerticalScaling
    Type:     VerticalScaling
    Message:  Successfully updated PetSets Resources
    Reason:   UpdatePetSets
    Type:     UpdatePetSets
    Message:  check pod running; ConditionStatus:True; PodName:milvus-standalone-0
    Type:     CheckPodRunning--milvus-standalone-0
    Message:  Successfully Restarted Pods With Resources
    Reason:   RestartPods
    Type:     RestartPods
    Message:  Successfully completed the vertical scaling for Milvus
    Reason:   Successful
    Type:     Successful
  Phase:      Successful

Verify the New Resources

Both the Milvus spec and the PetSet pod template now carry the new resources:

$ kubectl get milvuses.kubedb.com milvus-standalone -n demo -o jsonpath='{.spec.podTemplate.spec.containers[0].resources}'
{"limits":{"cpu":"1","memory":"2Gi"},"requests":{"cpu":"1","memory":"2Gi"}}

$ kubectl get petset milvus-standalone -n demo -o jsonpath='{.spec.template.spec.containers[0].resources}'
{"limits":{"cpu":"1","memory":"2Gi"},"requests":{"cpu":"1","memory":"2Gi"}}

In-Place Vertical Scaling

To resize the Pods without a restart, set spec.verticalScaling.mode to InPlace in the MilvusOpsRequest. The operator resizes the running containers via the Kubernetes pods/resize subresource and only restarts a Pod if its Node cannot accommodate the new resources.

This sample continues from the previous step and raises the standalone workload from 1 CPU / 2Gi to 2 CPU / 3Gi. Before applying it, record the Pod’s UID, restart count and current resources:

$ kubectl get pod milvus-standalone-0 -n demo -o jsonpath='{.metadata.uid} {.status.containerStatuses[0].restartCount} {.status.containerStatuses[0].resources}{"\n"}'

vertical-scaling-standalone-inplace.yaml

apiVersion: ops.kubedb.com/v1alpha1
kind: MilvusOpsRequest
metadata:
  name: vertical-scaling-standalone-inplace
  namespace: demo
spec:
  type: VerticalScaling
  databaseRef:
    name: milvus-standalone
  verticalScaling:
    mode: InPlace
    node:
      resources:
        requests:
          memory: "3Gi"
          cpu: "2"
        limits:
          memory: "3Gi"
          cpu: "2"
  timeout: 5m
  apply: IfReady

$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.10.12/docs/guides/milvus/scaling/vertical-scaling/yamls/vertical-scaling-standalone-inplace.yaml
milvusopsrequest.ops.kubedb.com/vertical-scaling-standalone-inplace created

Once the OpsRequest is Successful, run the same command again. The Pod UID and restart count are unchanged, which shows the Pod was neither recreated nor restarted, while its resources now report 2 CPU / 3Gi:

$ kubectl get milvusopsrequest vertical-scaling-standalone-inplace -n demo

$ kubectl get pod milvus-standalone-0 -n demo -o jsonpath='{.metadata.uid} {.status.containerStatuses[0].restartCount} {.status.containerStatuses[0].resources}{"\n"}'

Vertical Scaling Distributed Milvus

For a distributed Milvus, set the resources per role under spec.verticalScaling. You can scale several roles in a single OpsRequest. The sample below scales mixcoord and proxy.

Deploy the distributed quickstart manifest and wait until it is Ready:

$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.10.12/docs/guides/milvus/quickstart/yamls/distributed.yaml
milvus.kubedb.com/milvus-cluster created

$ kubectl get milvuses.kubedb.com -n demo milvus-cluster -w

vertical-scaling-distributed.yaml

apiVersion: ops.kubedb.com/v1alpha1
kind: MilvusOpsRequest
metadata:
  name: vertical-scaling
  namespace: demo
spec:
  type: VerticalScaling
  databaseRef:
    name: milvus-cluster
  verticalScaling:
    mixcoord:
      resources:
        requests:
          memory: "2Gi"
          cpu: "1"
        limits:
          memory: "2Gi"
          cpu: "1"
    proxy:
      resources:
        requests:
          memory: "2Gi"
          cpu: "1"
        limits:
          memory: "2Gi"
          cpu: "1"
  timeout: 5m
  apply: IfReady

The same approach applies to datanode, querynode and streamingnode. (In spec.verticalScaling the key is datanode; horizontal scaling uses dataNode for the same role.)

$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.10.12/docs/guides/milvus/scaling/vertical-scaling/yamls/vertical-scaling-distributed.yaml
milvusopsrequest.ops.kubedb.com/vertical-scaling created

$ kubectl get milvusopsrequest vertical-scaling -n demo
NAME               TYPE              STATUS       AGE
vertical-scaling   VerticalScaling   Successful   36s

Both the mixcoord and proxy PetSets now carry the new resources (other roles are unchanged):

$ kubectl get petset milvus-cluster-mixcoord -n demo -o jsonpath='{.spec.template.spec.containers[0].resources}'
{"limits":{"cpu":"1","memory":"2Gi"},"requests":{"cpu":"1","memory":"2Gi"}}

$ kubectl get petset milvus-cluster-proxy -n demo -o jsonpath='{.spec.template.spec.containers[0].resources}'
{"limits":{"cpu":"1","memory":"2Gi"},"requests":{"cpu":"1","memory":"2Gi"}}

Cleaning up

$ kubectl delete milvusopsrequest -n demo vertical-scaling-standalone vertical-scaling-standalone-inplace vertical-scaling
$ kubectl patch -n demo milvus.kubedb.com milvus-standalone -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge"
$ kubectl patch -n demo milvus.kubedb.com milvus-cluster -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge"
$ kubectl delete milvus.kubedb.com -n demo milvus-standalone milvus-cluster
$ kubectl delete ns demo

Next Steps

What's on this Page

Search
Improve This Page