KubeDB

By AppsCode

CONTACT SALES

New to KubeDB? Please start here.

Reconfigure Milvus

This guide will show you how to use the KubeDB Ops-manager operator to reconfigure a Milvus database, applying custom configuration through the milvus.yaml configuration file.

Before You Begin

  • You should be familiar with the following KubeDB concepts:

  • An object-storage secret named my-release-minio must exist in the demo namespace (Milvus requires object storage). See the quickstart for details.

  • To keep things isolated, this tutorial uses a separate namespace called demo:

    $ kubectl create ns demo
namespace/demo created

Milvus configuration is always supplied through a file named milvus.yaml. Use that exact key in config secrets and in applyConfig.

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

Reconfigure Standalone Milvus

Deploy Milvus

Deploy a standalone Milvus and wait for it to become Ready (see the standalone quickstart):

$ kubectl get milvuses.kubedb.com -n demo milvus-standalone
NAME                VERSION   STATUS   AGE
milvus-standalone   2.6.11    Ready    2m

Apply the Reconfigure OpsRequest

We will apply a new configuration through a config secret and an inline applyConfig. The OpsRequest below first references a config secret (mv-configuration), then overrides part of it inline:

reconfigure-standalone.yaml

---
apiVersion: v1
kind: Secret
metadata:
  name: mv-configuration
  namespace: demo
type: Opaque
stringData:
  milvus.yaml: |
    log:
      level: debug
      file:
        maxAge: 20
    queryNode:
      gracefulTime: 10
    dataNode:
      segment:
        maxSize: 400    
---
apiVersion: ops.kubedb.com/v1alpha1
kind: MilvusOpsRequest
metadata:
  name: reconfigure-1
  namespace: demo
spec:
  type: Reconfigure
  databaseRef:
    name: milvus-standalone
  configuration:
    removeCustomConfig: true
    configSecret:
      name: mv-configuration
    applyConfig:
      milvus.yaml: |
        log:
          level: info
          file:
            maxAge: 30
        queryNode:
          gracefulTime: 500        
    restart: "false"
  timeout: 5m
  apply: IfReady

Here,

  • spec.databaseRef.name is the Milvus we are reconfiguring.
  • spec.configuration.configSecret references a secret whose milvus.yaml holds configuration.
  • spec.configuration.applyConfig merges an inline milvus.yaml on top — here the final, effective values for log and queryNode.
  • spec.configuration.removeCustomConfig: true discards any previously applied custom configuration first.
  • spec.configuration.restart: "false" requests the configuration be applied without forcing a restart.
$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.6.19/docs/guides/milvus/reconfigure/yamls/reconfigure-standalone.yaml
secret/mv-configuration created
milvusopsrequest.ops.kubedb.com/reconfigure-1 created

Watch Progress

$ kubectl get milvusopsrequest -n demo
NAME            TYPE          STATUS       AGE
reconfigure-1   Reconfigure   Successful   28s

$ kubectl describe milvusopsrequest reconfigure-1 -n demo
...
Status:
  Conditions:
    Message:  Milvus ops-request has started to reconfigure Milvus nodes
    Reason:   Reconfigure
    Type:     Reconfigure
    Message:  Successfully prepared user provided apply configs
    Reason:   PrepareApplyConfig
    Type:     PrepareApplyConfig
    Message:  successfully reconciled the milvus with new configuration
    Reason:   UpdatePetSets
    Type:     UpdatePetSets
    Message:  Successfully completed reconfigure milvus
    Reason:   Successful
    Type:     Successful
  Phase:      Successful
Events:
  Normal  Starting       Pausing Milvus databse: demo/milvus-standalone
  Normal  UpdatePetSets  successfully reconciled the milvus with new configuration
  Normal  Starting       Resuming Milvus database: demo/milvus-standalone
  Normal  Successful     Successfully resumed Milvus database: demo/milvus-standalone for MilvusOpsRequest: reconfigure-1

Verify the New Configuration

The applied values are rendered into the configuration secret’s milvus.yaml:

$ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-standalone-[a-f0-9]{6}' | head -1)
$ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A3 -E '^log:|^queryNode:'
log:
  file:
    maxAge: 30
    maxBackups: 20
    maxSize: 300
...
  level: info
queryNode:
  gracefulTime: 500
  port: 19536

The log.level is now info, log.file.maxAge is 30, and queryNode.gracefulTime is 500 — exactly the values supplied through applyConfig.

Reconfigure Distributed Milvus

For a distributed Milvus, the flow is identical; only spec.databaseRef.name points at the distributed database (milvus-cluster). The same milvus.yaml configuration is rendered into the configuration secret and propagated to every distributed role (mixcoord, datanode, querynode, streamingnode, proxy).

reconfigure-distributed.yaml

---
apiVersion: v1
kind: Secret
metadata:
  name: mv-configuration
  namespace: demo
type: Opaque
stringData:
  milvus.yaml: |
    log:
      level: debug
      file:
        maxAge: 20
    queryNode:
      gracefulTime: 10
    dataNode:
      segment:
        maxSize: 400    
---
apiVersion: ops.kubedb.com/v1alpha1
kind: MilvusOpsRequest
metadata:
  name: reconfigure-1
  namespace: demo
spec:
  type: Reconfigure
  databaseRef:
    name: milvus-cluster
  configuration:
    removeCustomConfig: true
    configSecret:
      name: mv-configuration
    applyConfig:
      milvus.yaml: |
        log:
          level: info
          file:
            maxAge: 30
        queryNode:
          gracefulTime: 500        
    restart: "false"
  timeout: 5m
  apply: IfReady

$ kubectl apply -f https://github.com/kubedb/docs/raw/v2026.6.19/docs/guides/milvus/reconfigure/yamls/reconfigure-distributed.yaml
secret/mv-configuration created
milvusopsrequest.ops.kubedb.com/reconfigure-1 created

$ kubectl get milvusopsrequest reconfigure-1 -n demo
NAME            TYPE          STATUS       AGE
reconfigure-1   Reconfigure   Successful   21s

The applied configuration is rendered into the cluster’s configuration secret and propagated to all roles:

$ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-cluster-[a-f0-9]{6}' | head -1)
$ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A2 -E '^log:|^queryNode:|level:'
log:
  file:
    maxAge: 30
    maxBackups: 20
...
  level: info
queryNode:
  enableDisk: true
  gracefulTime: 500
  port: 21123

As with standalone, log.level is now info, log.file.maxAge is 30, and queryNode.gracefulTime is 500.

Cleaning up

$ kubectl delete milvusopsrequest -n demo reconfigure-1
$ kubectl delete secret -n demo mv-configuration
$ kubectl delete milvus.kubedb.com -n demo milvus-standalone
$ kubectl delete ns demo

Next Steps

What's on this Page

Search
Improve This Page