Generally, for most use cases, just having two servers and good backups is the best option. If you have a greenzone, turn your VMs off, do your updates, turn them back on.
Updates essentially never cause issues. Not on hypervisors (at least not on KVM/Xen.) Putting in a lot of complexity, cost, or risk to mitigate a shark attack isn't worth it. You will focus on a false risk.
All of the hypervisors are built for this. It's the storage and clustering that may or may not be built for this. As a rule, highest performance systems are not clustered at all, the can't be. Clustering takes a performance hit.
But in the extreme performance space products like VMware and Starwind are the top dogs. Both have multiple solutions, but they are using tech like memory sharing, localized data, NVMEoF, log structuring, and others to do things that Gluster just can't do. So much so that products like Gluster sometimes use these techs on top to accelerate them (example: Starwind makes a CEPH accelerator platform.)
Clustering is done when the cost of clustering is low versus the risk of not clustering.
I would change that slightly to Clustering is done when the cost of clustering is low versus the cost of not clustering. A risk is always a cost, but some costs are not risks. For example taking down a hypervisor for maintenance vs moving guests to another node and taking down a free node for maintenance.
Sure, using risk cost vs investment cost as cost v cost is a perfect valid way to look at it. I use that all the time in the opposite way.
You can say that risk is a cost. Or conversely, you can look at the clustering cost up front as essentially a "financial event" similar to an outage.