If you're going distributed the first place, doesn't that often imply that big team / big codebase?
In those cases, I'd argue things will likely come up quite quickly. Kubernetes is key component of a platform, but not a PaaS, e.g. you are required to understand to low level stuff, even if it's managed by a public cloud provider.
Cue out of memory apps, recovering GB+ JVM thread dumps out of a transient container, lack of troubleshooting tools, the kinda of stuff falcolas said above, plus high pressure to resolve because it's highly visible production app and you're got a recipe for sadness.
Even at google AFAIK, K8S ran in the context of BORG/ BORGMON and a host of other internal tools.
I wouldn't say it's Java EE based, acutally. It's a superset of Java EE. It's wraps the APIs people still actually care about like JPA, Servlet, and works with JAX-RS. The rest of the Java EE APIs are pretty much irrelevant these days, as evidenced by the constant introduction of new "profiles".
