Kubernetes is an amazing orchestration service. It will make sure all your services are up, restart ones that appear to be failing, and organize your logs and diagnostics. It has taken the industry by storm and has become a common link between all the cloud providers. If you know Kubernetes, you can transition relatively easily between Azure’s AKS, Amazon’s EKS, and Google’s GKE.
If you’re a developer, it holds the promise of making the development and production deployments so similar that bugs that would previously only be caught in production can be found early on in the development cycle. And it makes fully automated CI/CD almost close enough to touch without miles of handwritten scripts.
Alas, it is not all things to all people, and when given a choice, the Kubernetes team will always favor the production orchestration side and developers get left behind. Fully automated CI/CD is still an arduous task, and every development shop still requires DevOps to write those miles of handwritten scripts. In this article, I will try to enumerate where Kubernetes falls short in a development environment.
1. Docker in Docker
This should strike fear in the hearts of everyone who has needed to deal with it. Docker is not suited to run inside itself, and Kubernetes orchestrates Docker containers. So if your pipeline needs Docker to build an image and your pipeline is run under Kubernetes, you need to run Docker inside of Docker, which gives me a headache just thinking about.
There are two solutions to this problem. The first is to hijack the Docker socket of the outside host. This makes your Docker container running inside more of a sibling container than a child container. Let me explain. Docker is divided into two parts: the command-line interface and the Docker machine. The two communicate through a well-known socket, so when you type in a Docker command, the command-line program sends a message via the socket to the Docker machine, which does most of the work. So if you issue a Docker command-line instruction from inside a container, it will send the message to the Docker machine of the outside host. The drawback to this solution is that the inner container needs to be privileged to access the Docker socket of the outside host.
The second solution is to emulate Docker via another program. There are a plethora of these non-Docker emulation programs, such as Buildah or Kaniko. But Docker actually handles a lot of tasks: building images, dealing with the container registry, and running images. The two aforementioned programs only deal with building and pushing to container registries. Other programs can be used for more access to container registries.
So while there are solutions for eliminating Docker from the build process, no one does Docker like Docker.
#docker #programming #kubernetes #devops #containers
