Qdrant clusters distribute vectors across shards, but self-hosted rebalancing stays manual on Kubernetes. Learn the safe setup path. Read now.
What sharding actually does in a Qdrant cluster
In a Qdrant cluster, vectors live in collections that are split across shards. Each shard holds a subset of points and serves search over that subset; the cluster coordinates results so a client still sees one logical collection. Sharding exists to keep memory and query load within what a single node can handle, and to let you add capacity by adding nodes rather than vertical scaling alone.
Replication is separate from sharding. Replicas protect availability and read throughput; shards partition ownership of the data. Confusing the two leads to the wrong fix when a node runs hot or a disk fills: you may need more shards, more replicas, or both, depending on whether the pressure is write volume, working set size, or query concurrency.
Why rebalancing stays manual on self-hosted Kubernetes
Managed vector services often hide placement decisions. On self-hosted Kubernetes you own placement: which pods own which shards, when data moves, and how much load that move puts on the cluster. Rebalancing is not a free background process you can ignore. Moving shard data means network transfer, temporary disk growth, and query latency spikes while both source and target hold or stream points.
Operators usually rebalance only when they have a clear trigger: a new node joining the pool, a node decommissioned, uneven disk or memory use across pods, or a collection that outgrew the original shard count. Treat rebalancing as a planned change, not an automatic side effect of a rolling deploy.
A safe setup path on Kubernetes
Start with capacity math before you write manifests. Estimate points, vector dimensions, payload size, and index overhead, then size pods so a full shard set plus replicas fits with headroom for indexes and temporary rebalance copies. Prefer stable storage (persistent volumes with known performance) over ephemeral disks for anything you cannot afford to rebuild from scratch.
- Pin cluster membership and peer discovery so pods resolve each other after restarts; flaky service DNS is a common cause of split or stalled clusters.
- Choose shard count for expected growth, not only current size—resizing later is the expensive step.
- Set resource requests and limits so the scheduler does not pack multiple heavy shards onto one node by accident.
- Define readiness probes that reflect real Qdrant health (serving and peer connectivity), not only process start.
- Document a rebalance runbook: who initiates it, how you watch disk and lag, and how you abort if transfer pressure climbs.
Deploy with a StatefulSet (or equivalent stable identity per member) so each node keeps a durable identity and volume. Roll out config changes one member at a time. After the cluster is stable, exercise failover: delete a pod and confirm peers take over without silent data loss assumptions.
Operating without surprise rebalances
Monitor per-pod disk, memory, and query latency, plus collection-level point counts if you can surface them. Imbalance that grows slowly is easier to fix in a maintenance window than after a node is already full. When you must rebalance, drain or reduce write traffic if your application allows it, move work in small batches, and verify collection health and sample queries before you call the job done.
The practical goal is not zero manual work—it is predictable work. A Qdrant cluster on Kubernetes that is sized for growth, observed continuously, and rebalanced only under a controlled procedure will outlast one that “just scales” until a single hot shard forces an emergency move.