Live data from Hacker News

Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

thenewstack.io

1–10 of 22 posts

Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

#2
Reminds me of the Mesos Unified Containerizer. Very good stuff. The docker client is wonderful for developers, but the docker engine is the bane of operations. The bugs in it are not fun. My favorite one was in docker 1.6.0. When you did:

    docker exec -it $container bash
It caused a Nil pointer dereference and crashed the daemon. All of the other running containers then would die as a result.

Awesome.

Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

#3
I've a hard time positioning this along side the effort to support rkt in Kubernetes. Would OCID be necessary because there's too much Docker-only code to interface with the container runtime in Kubernetes?

I think I expected rkt to be fully OCI compatible in the future but it looks like Kubernetes itself needs to be able to interface with OCI runtimes and there's work to be done in that area? The Docker integration cuts too deep currently?

Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

#6
post #3

I've a hard time positioning this along side the effort to support rkt in Kubernetes. Would OCID be necessary because there's too much Docker-only code to interface with the container runtime in Kubernetes? I think I expected rkt to be fully OCI compatible in the future but it looks like Kubernetes itself needs to be able to interface with OCI runtimes and there's work to be done in that area? The Docker integration…

rkt can already download and run OCI (draft) container images[0].

As for Kubernetes rkt support: it is usable today and continues to develop nicely. If you want to try it out on your laptop it is super easy with minikube: https://tectonic.com/blog/minikube-and-rkt.html

Overall, the rkt support is in a good spot, works today, and the team is working on how to make all of the corners of Kubernetes work flawlessly. And it will support all of the parts of OCI as that specification matures.

If people are interested in joining in and adding a runc backend to rkt that would be great. However, all of the pieces needed to support Kubernetes is already there so we haven't seen much reason to do it. Inside of rkt there is an abstraction called a "stage1" that enables swaping out of the actual containerization system. This is what has enabled us to support Virtual Machine "wrapped" containers[1] inside of rkt for a long time.

For some more background on this article in particular. Folks in the community working at Google, CoreOS, and Red Hat have been working on a container runtime interface[2]. This interface is helping the Kubernetes team refactor the code that currently interfaces with Docker and rkt into a cleaner subsystem. As part of that effort the team is also exposing a gRPC interface to enable various implementations and experimentation. This is the interface the team at Red Hat building cri-o (formerly OCID) is using.

[0] https://groups.google.com/a/opencontainers.org/forum/#!topic...

[1] https://coreos.com/rkt/docs/latest/running-lkvm-stage1.html

[2] https://github.com/kubernetes/kubernetes/blob/master/docs/pr...

Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

#9
post #7

Is anyone here running Docker or Kubernetes in production? If so, what parts of your stack are running inside of it, versus what parts are running elsewhere in VMs or bare metal?

I've built Kubernetes architecture and a general container "mentality" to development and operations for a couple of clients and I would still not recommend you put your "pets" (relational databases and other stateful stuff) in Kubernetes just yet if it's the crown jewels in your organisation.

I don't mind putting some RDBMS that is not alpha and omega in the business in K8s but I would still exercise caution. K8s does have "PetSets" to help with this but it's still alpha quality. You can do a reasonable job of it without it by using PersistentVolumes and selectors to ensure your pod gets the volume bound dynamically. That does work very well indeed.

Most other things are fairly easy to migrate over but the hardest part -- and the bit that few people leave enough time to do well -- is integrating Kubernetes into the fabric of your business: accessing the service network, proper DNS that works across your organisation both into and out of K8s, access control, etc.

Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

#10
post #8

Containerization gives me a lot of anxiety. When will a clear winner emerge?

Hopefully we'll rally around something like OCI as a standard. But then we all know how well standards are followed...

Still, provided you can build your artefacts -- somehow -- as a container image you can focus on building a stable infrastructure (by using something like Kubernetes) around that and let the container engine makers fight it out in the background. In theory you can swap out backends very easily with K8s so that should futureproof it.

Post reply on HN