Re:Reasons Kubernetes is so complex
by felipelemos on Thursday January 27, 2022 @11:43AM
(#30102720)
> VMWare has had a high availability mode for over a decade. It keeps checkpoints of system state elsewhere and synchronously replicates them.
So you don't have one VM's, but two. In case of Op's scenario you are paying for 196 CPUS instead of 98.
> If the primary reboots, it checkpoints RAM to the secondary pauses the VM and unpauses it on the secondary a few milliseconds later.
So a very small downtime, but not 0.
It depends on your SLA. Under 10ms 99.9% of the time is pretty tight. Even if the migration takes a second, you'll meet your SLA for the hour.
Re:Reasons Kubernetes is so complex
by sockpuppet69 on Thursday January 27, 2022 @11:37AM
(#30102611)
So not 0 down time then
If the primary catches fire or crashes, the secondary boots the VM quickly without data loss.
If the primary reboots, it checkpoints RAM to the secondary pauses the VM and unpauses it on the secondary a few milliseconds later.
Note that this transparently handles storage replication, which is something that is notoriously difficult in Kubernetes.
If your cluster fits on one machine, you've paid for a lot of (currently) unnecessary complexity up front, both in dev time and in hardware cost.
If your app scales to need the cluster, congrats. Sometimes delaying time to market to allow for a smoother ramp makes sense. Sometimes it does not.
(Wikipedia is a good example of succeeding without ever needing to scale out the back end. I doubt they'd have won out over their competition if they took an extra 12-24 months to launch.)