Cheers
Mesos is much more mature, but is more low-level, and schedulers like Aurora or Marathon do not give you the same service abstraction, but they have many features not currently present in Kubernetes. But, in return for being more low-level, you can run things that are simply impossible in a declarative system like Kubernetes. Personally I see Kubernetes-on-Mesos as being a really bright future choice, but like pretty much anything other than Marathon/Aurora on Mesos, it's pretty nascent.
Can you give an example? I know next to nothing about Mesos, Aurora, or Marathon.
One area where we've been seeing some interesting work happening is in stateful services running on top of schedulers. With something like postgres, there is interesting logic that must happen for responsible management beyond just throwing up 3 of them. You need to manage replication carefully. When a node goes down somewhere, you need to react somewhere else in a controlled way. With Mesos, you can write a scheduler that encodes your runbook. With kubernetes, you need a lot more out-of-band stuff.
You're correct that the scheduler in the box is declarative. However, it is easy (well, as easy as writing a framework) to swap out a scheduler that might be a better fit for what you're looking for.
See this stackoverflow answer by one of the core Kubernetes team for more info: http://stackoverflow.com/questions/28857993/how-does-kuberne...
What worked for us: Accessing the the master by DNS and putting etcd on a persistent volume. This way we're able to replace the master within a DNS records ttl. As the api server is not a hard requirement for the workload, this is HA enough for us.
We would (biasedly) say that Kubernetes is ready for production today, and have lots of public folks (Samsung, eBay, Porch, and thousands more) who are doing so.
If you're in any way concerned about the management, feel free to get a trial on GKE (the hosted version of Kubernetes) on the Google Cloud ($300 trial free). We have a 99.5% SLA on it, so it's backed by Google engineers.
The underlying scheduler, Diego, has some interesting constructs, like supporting Windows, Docker, and buildpack-built containers (aka. droplets).
I think it's obvious that k8s is designed for staging/production usage and I can't see where lattice fits there.
Also, lattice is not running docker containers, but garden containers. There are a lot of issues on their issue tracker about people not being able to run images from docker registry.
That said I would say it is just a matter of time (this Fall) however. I mentioned it because it is a way to wrap one's head around Cloud Foundry ; really the production alternative to K8S is Cloud Foundry today, depending on your goal. (If you must have rootfs control and Docker, then no. If you want to stage/run your app in a scalable, reliable container scheduler with a set rootfs then yes.)
As for Garden containers, yes, the main issue has been security -related gaps between Docker images and the Garden runtime, as Garden locks things down differently. Most (not all) of these have been fixed in recent builds, as the push for Diego GA in Cloud Foundry gets close over the next few weeks.