I really like CoreOS and rkt. At my company we're building our next generation infra on CoreOS and Kubernetes with Docker. We'd like to switch from Docker to rkt eventually. The two things blocking this for us are:
1. rkt is focused on production usage (which is good) but is completely lacks a development workflow akin to Docker Compose and Docker for Mac. (Kubernetes is not a suitable alternative to Docker Compose, before someone suggests it.) Since rkt doesn't use a client/server model like Docker, having a seamless experience with a VM like Docker for Mac where the client on the host is just sending requests to the server will require some work, or a different approach altogether. Yes, we could use rkt only for deployment and develop with Docker, but that complicates our stack in a way that just doesn't provide the benefit to justify it yet.
2. Integration in Kubernetes at the same level of maturity as Docker. As mentioned in that reddit thread, "rktnetes" is currently described as a "work in progress." I remember somewhat recently that official Kubernetes release notes introducing rkt support literally linked to a Google Doc filled with issues. Kubernetes itself has very bad documentation, so linking to a Google Doc isn't a huge surprise, but it still shows that rkt support is still very early. It will happen, certainly, but it's not there yet.
rkt support for a local kubernetes cluster should be in the next version of minikube[0]. A PR was just merged to master today. [1] Of course, theres still a lot of work to be done.
> (Kubernetes is not a suitable alternative to Docker Compose, before someone suggests it.)
Why not? I have been contemplating this exact thing right before I came to procrastinate on HN.
A few of my local development workflows are using minikube[1]. Kubernetes within minikube is a lot like docker-compose. The only use case I have for docker-compose is pycharm integraion[2], but someone will probably make it work with minikube one day. There is a tool to convert from docker-compose to kubernetes[3].
It has the technical capability to do what Compose does, but Compose is a tool specifically designed for development workflow, and this is not the case for Kubernetes. Application developers without any infrastructure/operations experience can have a tough time understanding and learning all this new technology, and to have to get a mental model of Kubernetes to do their work is a big barrier. One simple example is that there is no direct equivalent of `docker-compose restart` in Kubernetes. The only way to restart a pod is to remove it and recreate it (or scale an RC/RS/deployment to zero and back up to force recreation.) It may just be a couple commands more, but it's unnecessary cognitive load for many app devs. Even just comparing a Docker Compose manifest file to a Kubernetes manifest file, it's more verbose because Kubernetes is more powerful and needs more details specified.
> It may just be a couple commands more, but it's unnecessary cognitive load for many app devs.
My general approach (not only to interacting with k8s) is to create fabric files with list of commands that makes sense in given place. I've seen people do similar things with Makefiles.
You would type "fab -l" and see list of commands, including "restart_pods" with the docstring describing what it means. Or even broader command for "rebuild and restart". Not only it helps me as I get auto completion (https://gist.github.com/Fandekasp/1522827), but also others can get things done without understanding all the details. And it's easier to migrate everyone to use slightly different command, e.g. add a flag.
I really like CoreOS and rkt. At my company we're building our next generation infra on CoreOS and Kubernetes with Docker. We'd like to switch from Docker to rkt eventually. The two things blocking this for us are:
1. rkt is focused on production usage (which is good) but is completely lacks a development workflow akin to Docker Compose and Docker for Mac. (Kubernetes is not a suitable alternative to Docker Compose, before someone suggests it.) Since rkt doesn't use a client/server model like Docker, having a seamless experience with a VM like Docker for Mac where the client on the host is just sending requests to the server will require some work, or a different approach altogether. Yes, we could use rkt only for deployment and develop with Docker, but that complicates our stack in a way that just doesn't provide the benefit to justify it yet.
2. Integration in Kubernetes at the same level of maturity as Docker. As mentioned in that reddit thread, "rktnetes" is currently described as a "work in progress." I remember somewhat recently that official Kubernetes release notes introducing rkt support literally linked to a Google Doc filled with issues. Kubernetes itself has very bad documentation, so linking to a Google Doc isn't a huge surprise, but it still shows that rkt support is still very early. It will happen, certainly, but it's not there yet.