Milvus Architecture in KubeBlocks

KubeBlocks supports two distinct Milvus deployment architectures:

Standalone Architecture

Milvus Standalone runs all coordinator and worker roles as goroutines inside a single milvus process. There is no inter-pod communication within the Milvus layer — all work happens in memory within one pod. External storage (etcd and MinIO) is still managed as separate KubeBlocks Components.

Resource Hierarchy

Cluster  →  Component (etcd)    →  InstanceSet  →  Pod × 1
         →  Component (minio)   →  InstanceSet  →  Pod × 1
         →  Component (milvus)  →  InstanceSet  →  Pod × 1

KubeBlocks provisions the components in order: etcd and minio first (in parallel), then milvus (which reads the etcd and minio endpoints on startup).

Containers

Limitations

Standalone is not highly available:

• The single milvus pod is a single point of failure
• No automatic failover — KubeBlocks restarts the pod on crash (pod-level recovery only)
• etcd and minio are also single replicas by default
• Cannot be horizontally scaled

For production workloads, use the Distributed topology.

Traffic Routing

Distributed Architecture

Milvus Distributed separates each functional role into its own independently scalable KubeBlocks Component. The Proxy is the single client entry point; internal components communicate through the MixCoord (unified coordinator) and share state via etcd (metadata), Pulsar or Kafka (log/message queue), and MinIO (object storage).

Resource Hierarchy

Cluster  →  Component (proxy)     →  InstanceSet  →  Pod × N
         →  Component (mixcoord)  →  InstanceSet  →  Pod × 1
         →  Component (datanode)  →  InstanceSet  →  Pod × N
         →  Component (indexnode) →  InstanceSet  →  Pod × N
         →  Component (querynode) →  InstanceSet  →  Pod × N

etcd, Pulsar/Kafka, and MinIO are not internal Components of the Distributed topology. They are external dependencies — either separately deployed KubeBlocks clusters or external services — declared via three serviceRefDeclarations: milvus-meta-storage (etcd), milvus-log-storage (Pulsar or Kafka), and milvus-object-storage (MinIO).

Component Roles

Containers (per Milvus role pod)

Each role runs a container named after the role itself (plus a setup init container that copies run.sh, merge, and iam-verify into /milvus/tools/ before the main process starts):

Only the proxy container exposes port 19530 (gRPC) for client traffic. All components expose port 9091 for metrics and health checks — it is not a client-facing REST API endpoint.

High Availability

MixCoord Recovery

MixCoord is the only single-replica component in the Distributed topology. When it crashes, KubeBlocks automatically recovers it without data loss:

1. MixCoord pod crashes — coordinator functions (DDL, segment lifecycle, query assignments, index scheduling) are temporarily unavailable
2. KubeBlocks InstanceSet detects the pod failure and schedules a restart
3. New MixCoord pod starts and reloads all coordinator state from etcd — no data is lost because MixCoord is fully stateless against etcd
4. Worker nodes reconnect — QueryNode, DataNode, and IndexNode pods reconnect to the restored MixCoord and resume their assigned work
5. Cluster resumes serving requests through the Proxy

Worker nodes (QueryNode, DataNode, IndexNode) run multiple replicas and tolerate individual pod failures without coordinator involvement — KubeBlocks restarts the failed pod, and MixCoord reassigns its work to healthy replicas.

Traffic Routing

Client applications (Milvus SDK) connect to the proxy on port 19530 (gRPC). Port 9091 is the metrics/health endpoint — it is not a client-facing REST API. The proxy is the single entry point — it handles authentication, routing, and result aggregation across worker components.

System Accounts

In the Milvus add-on, only the in-cluster MinIO object-storage Component (ComponentDefinition milvus-minio) declares KubeBlocks systemAccounts. Other Milvus stack components in this add-on (for example etcd, milvus, proxy, mixcoord, DataNode, QueryNode, IndexNode) do not define systemAccounts in their ComponentDefinitions. If you use an external object store instead of the bundled MinIO, this managed account does not apply to that store.

For the bundled MinIO component (typically named minio in componentSpecs, for example in standalone topology), KubeBlocks creates one account. Passwords are auto-generated unless overridden at the Cluster level. Credentials are stored in a Secret named {cluster}-minio-account-admin when the component name is minio (substitute your Cluster metadata.name and the MinIO component’s name).