provider-milvus

Warning

Pre-alpha. OpenEverest v2 and this provider are under active development. CRD schemas, chart values and defaults change frequently, including in breaking ways, and there is no supported upgrade path between versions yet. Not for production use.

Run Milvus on Kubernetes through OpenEverest, backed by the Milvus Operator.

What this is

OpenEverest providers translate a single, technology-agnostic Instance custom resource into the native custom resources of an upstream Kubernetes operator — for databases, but equally for caches, message queues, object storage, or model-serving runtimes. This repository is the provider for <technology>: it owns the technology-specific knowledge — topologies, versions, parameters, backup wiring — so that users, the API server, and the UI stay technology-agnostic.

Important

This provider is not standalone. It requires an OpenEverest installation (core CRDs and controller) in the cluster. Installing this chart on its own does nothing. See Install OpenEverest.

flowchart LR
    U([User / API / UI]) -->|creates| I["Instance<br/>core.openeverest.io"]
    I --> P["provider-milvus<br/>(this repository)"]
    P -->|reconciles into| O["Operator CR<br/>milvus.io"]
    O --> W["Upstream operator"]
    W --> R[("Workloads, Services,<br/>Secrets, PVCs")]
    P -->|status, endpoints,<br/>credentials| I

Loading

The provider watches Instance resources whose spec.providerRef.name is milvus, and reports workload health back onto Instance.status. It never manages pods directly — all lifecycle work is delegated to the operator.

Compatibility

provider-milvus	OpenEverest	Operator	Kubernetes
0.1.x	>= 2.0.0	1.3.9	1.30 – 1.34

Capabilities

What you can do to a running instance through the Instance API. Upgrading the provider itself is covered under Installation.

Capability	Status	Notes
Provisioning	✅	Standalone and cluster topologies
Horizontal scaling	✅	Per-component replica counts
Vertical scaling (CPU / memory)	✅	Per-component resource limits
Version upgrades	✅	spec.version; the operator performs the rolling update
Custom configuration	✅	Milvus engine config via component parameters.configuration
Authentication	✅	A root credential is generated and published to the connection Secret
Network exposure	✅	ClusterIP, NodePort or LoadBalancer via the component service
Monitoring	❌
TLS	❌

Stateful workloads additionally report:

Capability	Status	Notes
Persistent storage	✅	Object storage (MinIO) sized via the component storage
Storage expansion	❌
Backups (on demand)	❌
Backups (scheduled)	❌
Point-in-time recovery	❌
Restore	❌

Installation

The provider chart is published as an OCI artifact:

helm install provider-milvus \
  oci://ghcr.io/openeverest/charts/provider-milvus \
  --version <chart-version> \
  --namespace everest-system

• The Milvus operator is bundled as a chart dependency and is installed automatically.

Upgrade and uninstall:

helm upgrade provider-milvus oci://ghcr.io/openeverest/charts/provider-milvus
helm uninstall provider-milvus --namespace everest-system

Uninstalling the chart does not delete running Instance resources or their data.

Usage

Verify that the provider registered itself:

kubectl get providers.core.openeverest.io milvus

Create an instance:

apiVersion: core.openeverest.io/v1alpha1
kind: Instance
metadata:
  name: milvus-standalone
spec:
  providerRef:
    name: milvus
  topology:
    type: standalone          # optional; standalone is the default
  components:
    standalone:
      type: milvus
      replicas: 1
      resources:
        limits:
          cpu: "1"
          memory: 4Gi
      storage:
        size: 10Gi

Component names are defined by this provider — see definition/provider.yaml. spec.version and spec.topology are optional; the provider defaults apply. More examples (including a full cluster topology) live in examples/.

Watch it come up:

kubectl get instance milvus-standalone -w

Connect

Authentication is enabled by default. On first boot the provider generates a random password for the built-in root user and publishes the connection details to the Secret referenced by .status.connectionSecretRef (named milvus-standalone-conn):

# host, port, username, password, uri and a ready-to-use root:<password> token
kubectl get secret milvus-standalone-conn \
  -o go-template='{{range $k,$v := .data}}{{$k}}={{$v | base64decode}}{{"\n"}}{{end}}'

From your workstation, port-forward the service and connect with pymilvus:

kubectl port-forward svc/milvus-standalone-milvus 19530:19530

from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530", token="root:<password>")
client.create_collection("demo", dimension=8)

Expose it outside the cluster

Set the service type on the client-facing component (standalone for standalone, proxy for cluster). The connection details then report the external address automatically:

spec:
  components:
    standalone:
      type: milvus
      service:
        serviceType: LoadBalancer   # or NodePort
      storage:
        size: 10Gi

• ClusterIP (default) — reachable only inside the cluster.
• LoadBalancer — the connection host is the load balancer address once assigned.
• NodePort — the connection host is a node address paired with the assigned node port.

Topologies

Topology	Default	Description
standalone	✅	Single-process Milvus; smallest footprint, ideal for experimentation
cluster		Independently scalable components with Pulsar as the message stream

Versions

Version bundle	Default
2.6.11	✅
2.6.10

Source of truth: definition/versions.yaml.

Configuration

• Chart values: charts/provider-milvus/values.yaml
• Instance parameters: per-component and per-topology parameters schemas, defined under definition/ and published on the Provider resource (kubectl get provider milvus -o yaml). The API server and the UI validate user input against these schemas.

Development

Requires Go (see go.mod), Docker, Helm, kubectl, and a Kubernetes cluster you can reach. dev/README.md covers the environment end to end: the recommended local k3d setup, running against a cluster you already have, and every dev/.env setting.

make dev-up             # local cluster + Tilt dev environment (see dev/README.md)
make generate           # RBAC, provider spec, Helm chart sync
make run                # run the provider locally against the cluster
make test-unit
make test-integration   # chainsaw suites under test/integration/
make dev-down

make help lists every target. make verify fails when generated files are stale — run make generate and commit the result.

The provider contract (Validate / Sync / Status / Cleanup), RBAC markers, watches, code generation, and the backup/restore interfaces are documented once for all providers in PROVIDER_DEVELOPMENT.md.

Layout

Path	Purpose
cmd/provider/	Entry point
internal/provider/	ProviderInterface implementation, backup interfaces, RBAC markers
internal/common/	Component name constants
definition/	Provider identity, component types, versions, topologies, backup classes
charts/provider-milvus/	Helm chart (generated/ is produced by make generate)
config/rbac/role.yaml	Generated ClusterRole — do not edit
test/integration/	Chainsaw suites (see its README.md)
test/vars.sh	Pinned operator and workload versions used by tests
examples/	Example Instance resources
dev/	Tilt dev environment, .env configuration, k3d cluster config
.github/workflows/	CI: lint, build, unit and integration tests, release

Testing

• Unit tests — make test-unit.
• Integration tests — chainsaw suites under test/integration/. The scaffolded core/ suite is a skeleton: it verifies the provider deployment and includes commented-out lifecycle steps to enable as you implement the provider. See test/integration/README.md.
• CI — .github/workflows/ci.yaml runs lint, build, unit tests, generated-file verification, Helm lint, and each integration suite on every pull request.

Troubleshooting

kubectl logs -n everest-system deploy/provider-milvus -f

Symptom	Where to look
Instance stuck in Creating	kubectl describe instance <name> conditions, then the provider logs
No Provider resource in the cluster	Is the chart installed? Check the provider deployment logs
Instance ignored entirely	spec.providerRef.name must be milvus
Operator resource created but no pods	Inspect the operator's custom resource status — the failure is upstream

Contributing

Issues and pull requests are welcome. See PROVIDER_DEVELOPMENT.md and the OpenEverest Code of Conduct.

Security

Report vulnerabilities per the OpenEverest security policy. Please do not open public issues for security reports.

License

Apache License 2.0 — see LICENSE for details.