Thanks!
Most of those systems such as Zookeeper, Kubernetes, and the IBM zSystem Parallel Sysplex Coupling Facility are more of a problem than a solution.
I know some people run Hazelcast as a cluster separate from the application cluster (think Redis) but you can embed it inside the application servers in which case it disappears as an element of infrastructure (one less problem!) and you benefit from having shared data structures that implement the Java collection interfaces. In a lot of cases you don't have to think much about how the data structures span multiple address spaces. Application servers can discover each other and self-organize the data structures required to coordinate them, whether you are running N instances of the same application server or if you are running M different services.
What is great is that it "just works" if N=1 and M=1 so you can do a lot of testing without having to spin up extra infrastructure servers (points of failure! headaches of configuration! more gigabytes of docker downloads!) to do control plane coordination.
If there isn't something like that for go there should be.
My take is that most people can live with occasional "split brain" problems in the control plane so long as the algorithms involved have a latch structure with a bias towards progressing. (Think of the arguments as to why Bubble Sort completes even though it has free loops.) You might get some work units stuck and performance will be less than optimal but the main fear is that the degraded state is so hard to detect that it goes on for a long time.
Data plane problems are worse because people really do expect to get the right answer. There are many things other than "distributed system BS" that lead to incorrectness, such as floating point numbers, but I like the restartability paradigm behind Spark.