Docker Compose on K8s

Docker Compose is currently used by millions of developers and with over 650,000 Compose files on GitHub, Compose has been widely embraced by developers because it is a simple cloud and platform-agnostic way of defining multi-container based applications.

Problem statement

Today docker-compose is used on local development environments and in integration tests on physical Jenkins nodes. Moving almost everything to Kubernetes means that either we must make docker-compose work without hassle on the Kubernetes platform or agree upon another preferred way of working.

Important to take into consideration are:

  • Testability: Support for Ephemeral deploys.

  • Simplicity: Hide complex and technical implementation details for developers behind a simple to use api with a lot of sensible default values.

    1. Because developers should focus on business logic and not build and deploy scaffolding.
    2. Because with an api as an abstraction layer on top we can be flexible and replace underlying implementations like Jenkins, docker-compose and kubernetes without developers having to make a change.
  • Reproducibility: Make different environments as similar as possible to each other.

  • Delivery speed: Provide a smooth and quick process from code commit to production.

The idea to make all environments, including local dev environments, as similar as possible is very appealing. The reason for making all environments as similar as possible is to minimize bugs and minimize time spent in trouble shooting due to differences in environments.

Production, staging, QA environments all run on the Kubernetes platform, therefore, in order to be similar, local dev environment should also run on kubernetes.

This can be achieved by:

  • Running Kubernetes on docker-desktop or mini-kube or similar.

  • Extending local-dev environment to be developer laptop + Kubernetes namespace in “the cloud”.

Sadly, this approach will almost certainly be:

  • Heavy on resources, all developer laptops are not beasts.

  • Complex for the average developer, all developers should not have to know or care about kubernetes.

For numerous developers we should provide a solution where their dev environments are:

  • Lightweight

  • Simple to use (hide unwanted complexity)

Requirements (on the development environment)

First, let’s define the average developer as:

A fairly new frontend-developer who is great at javascript and React and has little knowledge or interest in backend-code, Kubernetes and deploy-pipelines.

The average developer should:

  • Be able to work offline

  • Not need deep knowledge in Kubernetes.

  • Be able to spin up (mock) auxiliary services like backend api/service and databases.

  • Not need a very powerful pc.


  • Let the developers do what ever they want on their machines but do not try to reuse it. Accept that developer setup is very different from other environments.

  • Try to reuse docker-compose files created by developers to also run integration-tests in deploy and build pipelines.

  • Try to reuse docker-compose files created by developers to also run integration-tests in deploy and build pipelines and to deploy to different (ephemeral) environments.

  • Deprecate the use of docker-compose files for developers and introduce another lightweight format which under the hood can work well in offline mode on a developer machine and be the base for a production deploy.

  • Run Kubernetes locally on docker-desktop or mini-kube or similar.

  • Extend local-dev environment to be developer laptop + Kubernetes namespace in “the cloud”. More about this approach here:

Current state of Docker Compose in K8s

It’s possible to use different tools to convert docker-compose files to kube-configs.

How to convert and use your docker-compose files in K8s

Project Description Note
Kompose Translates docker-compose to kubectl configs -
Blimp Docker Compose, (and your dev environment) in the K8s cloud -
Compose on Kubernetes Deploy Docker Compose files onto a Kubernetes cluster no progress this year (2020)
Docker App and CNAB Build Cloud Native Application Bundles (CNAB) from docker-compose -
Podman Compose An implementation of docker-compose with Podman backend -


Simplify your development process with Docker Compose and then deploy your containers to a production cluster Convert your docker-compose.yaml with one simple command kompose convert.

kompose is a convenience tool to go from local Docker development to managing your application with Kubernetes. Transformation of the Docker Compose format to Kubernetes resources manifest may not be exact, but it helps tremendously when first deploying an application on Kubernetes.


Blimp is a drop-in replacement for Docker Compose that enables development in the cloud. Laptop struggling to keep up? It’s time to blimp up and get your Docker containers in the cloud.

Blimp is for developers working with containers that use Docker Compose to run their dependencies locally, even if they’re using Kubernetes in production. Blimp runs on Kubernetes in the backend; however, the interface it exposes to developers looks and feels like Docker Compose. As a result, it may be easier to start using for Developers that aren’t familiar with Kubernetes.

Blimp runs entirely in your own Kubernetes cluster. No requests are made to external Blimp servers.

Your containers are isolated in their own Kubernetes namespace.

Which one is the best?

  • Recommendation is Kompose, but it is not the “silver bullet”.

Compose on Kubernetes

Compose on Kubernetes allows you to deploy Docker Compose files onto a Kubernetes cluster. no progress this year (2020)

Docker App & CNAB

Build CNAP bundles from docker-compose.

Docker App Docker App is a way to define, package, execute, and manage distributed applications and coupled services as a single, immutable object.


Cloud Native Application Bundles (CNAB) are a package format specification that describes a technology for bundling, installing, and managing distributed applications, that are by design, cloud agnostic.

The future of Docker Compose

docker-compose is no longer only a stand-alone tool, it has moved inside docker. Instead of writing docker-compose you write `docker compose.

By using docker context to switch context, it’s possible to use the same docker compose up on Azure cloud or to create Amazon ec2 instances.

Docker has created a new open community to develop the Compose-Specification.

The intention is that the Compose-Specification/API can be used with different backend technologies to describe (parts of) multiple environments, switched between by using docker context.

docker compose contains things that developers care about. It does not aim to be the whole description of production, just the developer-facing pieces.

This is not ready for us to use, but it will be interesting to follow and see what happens here.

Development with K8s locally

Docker  K8s