Kubernetes Local Development Solutions

I just started recently diving deeper into Kubernetes and fell instantly in love. Coming from Symfony there has been a lot of progress, like the Api-Platform project shipping directly dockerized using Docker Compose and ready for deployment via Kubernetes and Helm.

But why Docker Compose and Kubernetes in combination? We want to be able to develop our application and infrastructure locally as well as deploying it easily for production. Ideally we want to have the same infrastructure local and production.

So why are we using two different technologies then with Compose and Kubernetes? What are the solutions?

Solution 1: Docker Compose and Swarm

Compose allows us to simply define a cluster of containers running and interacting with each other. Pretty sweet and easy, especially if your app is already dockerized.

Swarm should integrate nicely with Compose, though I never tried it myself. I mean both are coming from Docker itself. This would sound like the solution, though Swarm is not that prevalent in existing IaaS solutions and the Github repo is not as actively developed like Kubernetes.

Kubernetes just seems to be better for projects with high complexity, and that’s what all our projects are or will be soon, right? ;) Check out this link for a deeper differentiation between those two.

Solution 2: Compose and Kubernetes

This seems common today. First we describe our infrastructure locally using Compose and start development. Once we feel ready we describe the infrastructure for Kubernetes and deploy. There are some good tools for automatic conversion like Kompose (from Kubernetes) and compose-on-kubernetes from Docker.

I have used Kompose in production for converting an existing docker-compose.yml and it works nice, but in reality you have to make manual adjustments to the generated Kubernetes infrastructure files afterwards. And then when you change your compose.yaml you can’t just re-run your Kompose command.

So you end up having to manage two different infrastructure configs again. Also you run different environments local and production, something we were running from away in the first place, right?

Solution 3: Kubernetes

One solution I’m looking into right now is just using Kubernetes, locally with Minkubes or Docker Desktop (only OSX and Windows) and then Google (or any) as IaaS for production. I’m investigating this solution at the moment and will be comparing the following parameters:

1. Development speed. Like: how many ms reload time of a browser application. The old issue on OSX and Windows where the shared volumes between host and container are slow or syncing a lot of files. This was “solved” with Docker Sync.
2. Local Memory usage. Could this run on a 4 to 8GB development machine or does the local cluster take too much ram?
3. Local CPU usage. Lets check that CPU usage!
4. Different Configs? Can we really use the exact same config (just with the help of a bit of templating using Helm) for local and production?
5. Simple Config? Can we define infrastructure simply with not too much complexity overhead?

Lets find this out in the next episode of Lets find this out ! PART ONE

Kim