(no title)
davidopp__ | 9 years ago
Comcast has a prototype of YARN on Kubernetes here: https://github.com/Comcast/kube-yarn
(Disclosure: I work on the Kubernetes project at Google.)
davidopp__ | 9 years ago
Comcast has a prototype of YARN on Kubernetes here: https://github.com/Comcast/kube-yarn
(Disclosure: I work on the Kubernetes project at Google.)
agibsonccc|9 years ago
My main area of interest with this is: We have a lot of Java native interface code we run. I don't want folks to have to worry about configuring library paths and the like. My support loads get messy quick the second "c code" comes in the picture.
The ability to hook in to k8s to spin up executors would be pretty neat. The Mesos containerizer has that beat right now.
1 of the main reasons I heavily prefer mesos is also dc/os. dcos package install thing is head and shoulders above just having a docker runtime.
As for yarn: A lot of my customers use yarn and don't know what k8s is. OR if they do have a cluster that uses docker, they call it a "docker cluster" and it's often separate. It's not as hard of a sell for me for the YARN folks to just say: "install my docker daemon as an RPM or cloudera parcel so you can run executors"
vs: "Install k8s in your docker cluster with all this extra stuff in there"
K8s for me is in this limbo of: Not integrated enough or too complex for embedding in commercial use.
You guys have a great story going. Especially on the UX side of things. I know a lot of folks in the k8s ecosystem, but many of them aren't focused on big data or the JVM. Mesos on the other hand was spark's parent project. The integration levels show there. I'll be keeping an eye on it :).
My inherent problem with a lot of this is it's still prototyping. A lot of this support is still very green field and I'm stoked you guys are working on it. If anything because more competition is always good.
davidopp__|9 years ago
Disclosure: I work on the Kubernetes project at Google.