Translate a Docker Compose File to Kubernetes Resources

    More information can be found on the Kompose website at http://kompose.io.

    You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

    To check the version, enter kubectl version.

    Install Kompose

    We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release.

    Kompose is released via GitHub on a three-week cycle, you can see all current releases on the .

    Alternatively, you can download the tarball.

    Installing using go get pulls from the master branch with the latest development changes.

    1. go get -u github.com/kubernetes/kompose

    Kompose is in CentOS repository. If you don’t have EPEL repository already installed and enabled you can do it by running sudo yum install epel-release.

    If you have enabled in your system, you can install Kompose like any other package.

    1. sudo yum -y install kompose

    Kompose is in Fedora 24, 25 and 26 repositories. You can install it like any other package.

    1. sudo dnf -y install kompose

    On macOS you can install the latest release via Homebrew:

    1. brew install kompose

    Use Kompose

    In a few steps, we’ll take you from Docker Compose to Kubernetes. All you need is an existing docker-compose.yml file.

    1. Go to the directory containing your docker-compose.yml file. If you don’t have one, test using this one.

      1. version: "2"
      3. services:
      5.   redis-master:
      6.     image: registry.k8s.io/redis:e2e
      7.     ports:
      8.       - "6379"
      10.   redis-slave:
      11.     image: gcr.io/google_samples/gb-redisslave:v3
      12.     ports:
      13.       - "6379"
      14.     environment:
      15.       - GET_HOSTS_FROM=dns
      17.   frontend:
      18.     image: gcr.io/google-samples/gb-frontend:v4
      19.     ports:
      20.       - "80:80"
      21.     environment:
      22.       - GET_HOSTS_FROM=dns
      23.     labels:
      24.       kompose.service.type: LoadBalancer

    2. To convert the docker-compose.yml file to files that you can use with kubectl, run kompose convert and then kubectl apply -f <output file>.

      1. kompose convert

      The output is similar to:

      1. INFO Kubernetes file "frontend-service.yaml" created
      2.    INFO Kubernetes file "frontend-service.yaml" created
      3. INFO Kubernetes file "frontend-service.yaml" created
      4. INFO Kubernetes file "redis-master-service.yaml" created
      5.    INFO Kubernetes file "redis-master-service.yaml" created
      6. INFO Kubernetes file "redis-master-service.yaml" created
      7. INFO Kubernetes file "redis-slave-service.yaml" created
      8.    INFO Kubernetes file "redis-slave-service.yaml" created
      9. INFO Kubernetes file "redis-slave-service.yaml" created
      10. INFO Kubernetes file "frontend-deployment.yaml" created
      11.    INFO Kubernetes file "frontend-deployment.yaml" created
      12. INFO Kubernetes file "frontend-deployment.yaml" created
      13. INFO Kubernetes file "redis-master-deployment.yaml" created
      14.    INFO Kubernetes file "redis-master-deployment.yaml" created
      15. INFO Kubernetes file "redis-master-deployment.yaml" created
      16. INFO Kubernetes file "redis-slave-deployment.yaml" created
      17.    INFO Kubernetes file "redis-slave-deployment.yaml" created
      18. INFO Kubernetes file "redis-slave-deployment.yaml" created
        1. service/frontend created
        2. service/redis-master created
        3. service/redis-slave created
        4. deployment.apps/frontend created
        5. deployment.apps/redis-master created
        6. deployment.apps/redis-slave created

        Your deployments are running in Kubernetes.

      1. Access your application.

        If you’re already using minikube for your development process:

        1. minikube service frontend

        Otherwise, let’s look up what IP your service is using!

        1. kubectl describe svc frontend

        If you’re using a cloud provider, your IP will be listed next to LoadBalancer Ingress.

        1. curl http://192.0.2.89

      Kompose has support for two providers: OpenShift and Kubernetes. You can choose a targeted provider using global option --provider. If no provider is specified, Kubernetes is set by default.

      kompose convert

      Kompose supports conversion of V1, V2, and V3 Docker Compose files into Kubernetes and OpenShift objects.

      1. kompose --file docker-voting.yml convert
      1. WARN Unsupported key networks - ignoring
      2. WARN Unsupported key build - ignoring
      4. INFO Kubernetes file "db-svc.yaml" created
      5. INFO Kubernetes file "redis-svc.yaml" created
      6. INFO Kubernetes file "result-svc.yaml" created
      7. INFO Kubernetes file "vote-svc.yaml" created
      8. INFO Kubernetes file "redis-deployment.yaml" created
      9. INFO Kubernetes file "result-deployment.yaml" created
      10. INFO Kubernetes file "vote-deployment.yaml" created
      11. INFO Kubernetes file "worker-deployment.yaml" created
      12. INFO Kubernetes file "db-deployment.yaml" created
      1. ls
      1. db-deployment.yaml  docker-compose.yml         docker-gitlab.yml  redis-deployment.yaml  result-deployment.yaml  vote-deployment.yaml  worker-deployment.yaml
      2. db-svc.yaml         docker-voting.yml          redis-svc.yaml     result-svc.yaml        vote-svc.yaml           worker-svc.yaml

      You can also provide multiple docker-compose files at the same time:

      1. kompose -f docker-compose.yml -f docker-guestbook.yml convert
      1. INFO Kubernetes file "frontend-service.yaml" created         
      2. INFO Kubernetes file "mlbparks-service.yaml" created         
      3. INFO Kubernetes file "mongodb-service.yaml" created          
      4. INFO Kubernetes file "redis-master-service.yaml" created     
      5. INFO Kubernetes file "redis-slave-service.yaml" created      
      6. INFO Kubernetes file "frontend-deployment.yaml" created      
      7. INFO Kubernetes file "mlbparks-deployment.yaml" created      
      8. INFO Kubernetes file "mongodb-deployment.yaml" created       
      9. INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
      10. INFO Kubernetes file "redis-master-deployment.yaml" created  
      11. INFO Kubernetes file "redis-slave-deployment.yaml" created
      1. ls
      1. mlbparks-deployment.yaml  mongodb-service.yaml                       redis-slave-service.jsonmlbparks-service.yaml  
      2. frontend-deployment.yaml  mongodb-claim0-persistentvolumeclaim.yaml  redis-master-service.yaml
      3. frontend-service.yaml     mongodb-deployment.yaml                    redis-slave-deployment.yaml
      4. redis-master-deployment.yaml

      When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be overridden by subsequent file.

      1. kompose --provider openshift --file docker-voting.yml convert
      1. WARN [worker] Service cannot be created because of missing port.
      2. INFO OpenShift file "vote-service.yaml" created             
      3. INFO OpenShift file "db-service.yaml" created               
      4. INFO OpenShift file "redis-service.yaml" created            
      5. INFO OpenShift file "result-service.yaml" created           
      6. INFO OpenShift file "vote-deploymentconfig.yaml" created    
      7. INFO OpenShift file "vote-imagestream.yaml" created         
      8. INFO OpenShift file "worker-deploymentconfig.yaml" created  
      9. INFO OpenShift file "worker-imagestream.yaml" created       
      10. INFO OpenShift file "db-deploymentconfig.yaml" created      
      11. INFO OpenShift file "db-imagestream.yaml" created           
      12. INFO OpenShift file "redis-deploymentconfig.yaml" created   
      13. INFO OpenShift file "redis-imagestream.yaml" created        
      14. INFO OpenShift file "result-deploymentconfig.yaml" created  
      15. INFO OpenShift file "result-imagestream.yaml" created

      It also supports creating buildconfig for build directive in a service. By default, it uses the remote repo for the current git branch as the source repo, and the current branch as the source branch for the build. You can specify a different source repo and branch using --build-repo and --build-branch options respectively.

      1. WARN [foo] Service cannot be created because of missing port.
      2. INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
      3. INFO OpenShift file "foo-imagestream.yaml" created          
      4. INFO OpenShift file "foo-buildconfig.yaml" created

      Note: If you are manually pushing the OpenShift artifacts using oc create -f, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this OpenShift issue: .

      Alternative Conversions

      The default kompose transformation will generate Kubernetes and Services, in yaml format. You have alternative option to generate json with -j. Also, you can alternatively generate objects, Daemon Sets, or charts.

      1. kompose convert -j
      2. INFO Kubernetes file "redis-svc.json" created
      3. INFO Kubernetes file "web-svc.json" created
      4. INFO Kubernetes file "redis-deployment.json" created
      5. INFO Kubernetes file "web-deployment.json" created

      The *-deployment.json files contain the Deployment objects.

      1. kompose convert --replication-controller
      2. INFO Kubernetes file "redis-svc.yaml" created
      3. INFO Kubernetes file "web-svc.yaml" created
      4. INFO Kubernetes file "redis-replicationcontroller.yaml" created
      5. INFO Kubernetes file "web-replicationcontroller.yaml" created

      The *-replicationcontroller.yaml files contain the Replication Controller objects. If you want to specify replicas (default is 1), use --replicas flag: kompose convert --replication-controller --replicas 3.

      1. kompose convert --daemon-set
      2. INFO Kubernetes file "redis-svc.yaml" created
      3. INFO Kubernetes file "web-svc.yaml" created
      4. INFO Kubernetes file "redis-daemonset.yaml" created
      5. INFO Kubernetes file "web-daemonset.yaml" created

      The *-daemonset.yaml files contain the DaemonSet objects.

      1. INFO Kubernetes file "web-svc.yaml" created
      2. INFO Kubernetes file "redis-svc.yaml" created
      3. INFO Kubernetes file "web-deployment.yaml" created
      4. INFO Kubernetes file "redis-deployment.yaml" created
      5. chart created in "./docker-compose/"
      1. tree docker-compose/
      1. docker-compose
      2. ├── Chart.yaml
      3. ├── README.md
      4. └── templates
      5.     ├── redis-deployment.yaml
      6.     ├── redis-svc.yaml
      7.     ├── web-deployment.yaml
      8.     └── web-svc.yaml

      The chart structure is aimed at providing a skeleton for building your Helm charts.

      kompose supports Kompose-specific labels within the docker-compose.yml file in order to explicitly define a service’s behavior upon conversion.

      • kompose.service.type defines the type of service to be created.

        For example:

        1. version: "2"
        2. services:
        3.   nginx:
        4.     image: nginx
        5.     dockerfile: foobar
        6.     build: ./foobar
        7.     cap_add:
        8.       - ALL
        9.     container_name: foobar
        10.     labels:
        11.       kompose.service.type: nodeport

      • kompose.service.expose defines if the service needs to be made accessible from outside the cluster or not. If the value is set to “true”, the provider sets the endpoint automatically, and for any other value, the value is set as the hostname. If multiple ports are defined in a service, the first one is chosen to be the exposed.

        • For the Kubernetes provider, an ingress resource is created and it is assumed that an ingress controller has already been configured.
        • For the OpenShift provider, a route is created.

        For example:

        1. version: "2"
        2. services:
        3.   web:
        4.     image: tuna/docker-counter23
        5.     ports:
        6.     - "5000:5000"
        7.     links:
        8.     - redis
        9.     labels:
        10.       kompose.service.expose: "counter.example.com"
        11.   redis:
        12.     image: redis:3.0
        13.     ports:
        14.     - "6379"

      The currently supported options are:

      Note: The kompose.service.type label should be defined with ports only, otherwise kompose will fail.

      Restart

      If you want to create normal pods without controllers you can use restart construct of docker-compose to define that. Follow table below to see what happens on the restart value.

      docker-compose restartobject createdPod restartPolicy
      “”controller objectAlways
      alwayscontroller objectAlways
      on-failurePodOnFailure
      noPodNever

      Note: The controller object could be deployment or replicationcontroller.

      For example, the pival service will become pod down here. This container calculated value of pi.

      1. version: '2'
      3. services:
      4.   pival:
      5.     image: perl
      6.     command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      7.     restart: "on-failure"

      If the Docker Compose file has a volume specified for a service, the Deployment (Kubernetes) or DeploymentConfig (OpenShift) strategy is changed to “Recreate” instead of “RollingUpdate” (default). This is done to avoid multiple instances of a service from accessing a volume at the same time.

      If the Docker Compose file has service name with _ in it (for example, web_service), then it will be replaced by - and the service name will be renamed accordingly (for example, web-service). Kompose does this because “Kubernetes” doesn’t allow _ in object name.

      Please note that changing service name might break some docker-compose files.

      Docker Compose Versions

      Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on versions 2.1 and 3.2 due to their experimental nature.