Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
1–10 of 22 posts
Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
#2 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
#3I 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
#4Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
#5Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
#6I'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…
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
#7Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
#8Re: Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker
#9Is 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 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
#10Containerization gives me a lot of anxiety. When will a clear winner emerge?
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.