How to ensure high availability in Qdrant on Kubernetes during node restarts?

I'm running Qdrant on Kubernetes (GKE) with 10 Qdrant pods distributed across multiple nodes.

Recently, I ran into an issue: if one of the nodes restarts (for example, due to memory pressure), the Qdrant pods on that node go down for some time and this causes downtime for the entire application.

I haven’t set resource requests and limits yet, but even if I do something like:

resources:
  limits:
    cpu: 1
    memory: 5Gi
  requests:
    cpu: 2
    memory: 10Gi

…it doesn’t seem to help. From what I understand, Qdrant’s architecture expects pods to be stable — if a pod is rescheduled or restarted, it can lead to missing shards or delayed recovery.

Horizontal Pod Autoscaling (HPA) doesn’t help here either, since scaling Qdrant pods dynamically disrupts the shard layout and can cause partial unavailability.

Questions:

1. What’s the recommended approach to make a Qdrant deployment resilient to node restarts?
2. If I do a Helm upgrade (e.g., updating resources), the pods start rolling one by one. But if my collection has shards distributed across all 10 pods, won't this rolling restart temporarily break the availability of some shards, causing downtime?
   Is there a safe upgrade pattern to avoid this?
   upgrade pattern to avoid this?

Start by reviewing the Qdrant Helm deployment, including resource requests and limits, pod distribution, HPA behavior, and the shard layout described in the issue. Reproduce a node restart and a rolling Helm upgrade, then document a safe deployment pattern that keeps collections available during pod recovery and upgrades.