Project reference ↗

Applications such as databases need their files to survive the loss of a container or a server. Longhorn turns storage on Kubernetes worker machines into persistent disks for applications and keeps replicas on separate storage hosts. It gives teams a way to operate their own storage where managed cloud disks are unavailable or unsuitable. Replicas help keep a volume available; an independent backup and a tested restore are still needed for recovery from deletion or corruption.

Chart ownership

The Longhorn installation guide publishes the longhorn/longhorn chart through charts.longhorn.io. Check the prerequisites for every participating node and the chosen data engine before installation. Storage components have host-level requirements that an ordinary application chart may not have.

Before adoption

Budget capacity for replicas, snapshots and rebuilds, and measure the network and disk behavior under the application's real workload. Define failure domains and a maintenance procedure that keeps enough replicas available during drains and upgrades. Configure an independent backup target and restore a volume into a replacement cluster. Replication helps with availability but does not protect against every deletion or corruption. Review volume reclaim and uninstall behavior before removing releases or persistent-volume claims.

Sources & further reading

  1. Longhorn Helm installation
  2. Longhorn architecture and storage behavior

Spotted something that needs another look?

Help improve this page →