Comparing Java threads and goroutines doesn't really work because Java's thread model maps threads 1:1 to OS threads, whereas goroutines are simply continuations that can consume any OS thread. Java threads couple both the concerns of scheduling and task definition. Java Runnables address only the concern of task definition and are closer in nature to what goroutines are, but they still don't possess the ability to suspend and yield their execution.
You can implement Go's thread model (more generally known as green threads, coroutines, fibers, lightweight threads) on the JVM. This is precisely what Project Loom intends to do and what Scala effect systems already do. You construct a program in a type called IO that only describes a computation that can be suspended and resumed, unlike Java Runnables. These IO values are cooperatively scheduled to run on a fixed thread pool. Because these IO values just represent continuations, you can have millions of them cooperatively executing at the same time. And there is no context switch penalty for switching the continuation you are executing for another.
The 1:1 mapping is just an implementation detail of of current JVMs. Originally green threads (with an M:N scheduler) were used instead. IIRC they weren't even guaranteed to be preemptively scheduled, I don't know if this has changed since.
Technically os threads are also simply continuations.
There are definitely a lot of moving parts in Kubernetes just to get it running and it was a big hurdle to get everything set up (I'm running a vanilla cluster in Vagrant).
The documentation definitely covers a lot, but I found myself hunting issues down for trying to get something to work like getting k8s to schedule pods across a flannel overlay network and making sure traffic is being routed properly. Of course, you don't have to worry about any of this if you use GKE or another cloud provider.
Once I got that set up, everything worked beautifully. I can just write a config and apply it to the cluster and services are deployed and scaled and whatnot. Treating your cluster as a pool of resources is pretty powerful. There are a lot of Kubernetes API objects (Deployments, Stateful Sets, Daemon Sets, ConfigMaps, Secrets), but everything has a purpose and Kubernetes makes everything come together nicely.
The Kubernetes Slack channel was really helpful for me as well, there's a lot of nice and friendly people there willing to answer your questions and help you debug your setup.
You can implement Go's thread model (more generally known as green threads, coroutines, fibers, lightweight threads) on the JVM. This is precisely what Project Loom intends to do and what Scala effect systems already do. You construct a program in a type called IO that only describes a computation that can be suspended and resumed, unlike Java Runnables. These IO values are cooperatively scheduled to run on a fixed thread pool. Because these IO values just represent continuations, you can have millions of them cooperatively executing at the same time. And there is no context switch penalty for switching the continuation you are executing for another.