Kompose makes a Compose application a set of Kubernetes objects

A Compose file describes enough of an application to start its containers, but moving that application to Kubernetes requires decisions about controllers and cluster resources. Kompose takes the existing file as input and generates Kubernetes objects. Its August 10 graduation announcement presents this as a transition tool for developers, alongside the release of Kompose 1.0.0.

The interesting part of the tool is the mapping between the two descriptions. An image becomes part of a container specification. A published port can require a Service. A volume declaration becomes a request that Kubernetes storage machinery must satisfy. The generated configuration is consequently more than a change in YAML vocabulary.

I like tools that make an existing application's intended structure available for inspection. Kompose can remove transcription work from a Kubernetes migration, while its output makes the new platform's resource model visible. That is a useful starting point for understanding which parts of the application description carry over directly.

Conversion can be separated from deployment

The announcement demonstrates kompose up, which creates resources for a Compose application. It also describes kompose convert as the route for generating files and choosing alternative controller types. That distinction lets a developer examine the Kubernetes representation before asking the cluster to run it.

The guestbook example has a Redis master, a Redis replica service and a frontend. Its version-pinned Compose file identifies the images and ports, with environment variables instructing the frontend and replica component to use DNS for host discovery. These declarations provide the application-specific inputs that conversion can reuse.

For example, the frontend portion includes the following configuration. It is part of the example's services mapping, rather than a complete Compose application on its own.

frontend:
  image: gcr.io/google-samples/gb-frontend:v4
  ports:
    - "80:80"
  environment:
    - GET_HOSTS_FROM=dns
  labels:
    kompose.service.type: LoadBalancer

The label carries a Kubernetes-facing choice within the Compose input. The image and environment describe the container, while the service-type instruction influences how the application is exposed. This is one place where migration knowledge enters the source file instead of being inferred from a generic container declaration.

The example also shows why merely preserving an image reference is insufficient to describe the result. Kubernetes needs a controller to manage the application's Pods and a Service where network access requires one. Kompose generates those separate objects from information that appears together in the Compose service definition.

Controller selection changes the management model

Kompose can generate a Deployment, a replication controller or a DaemonSet. Its command help in the announcement also includes an option to create a Helm chart. The availability of these alternatives means the conversion tool does not impose one controller type on every application.

The article demonstrates kompose convert --daemon-set, which writes separate Service and DaemonSet files for the guestbook components. That example demonstrates a conversion capability. It should not be read as an argument that a DaemonSet is the appropriate controller for every Redis or frontend workload.

Kubernetes' 1.7 release announcement describes a DaemonSet as creating a Pod per node and discusses its update history and rollback behavior. Choosing it therefore specifies a different placement and lifecycle model from an ordinary replicated application Deployment. A conversion flag can express the choice, but the application architecture supplies the reason to make it.

Generating files before deployment makes that decision easier to review. The result identifies the controller kind explicitly, so a developer can discuss the resulting Kubernetes behavior without relying on the original Compose file to explain it. The conversion command creates an artifact that exposes the platform decision.

Supported keys have specific boundaries

The conversion matrix shipped at the 1.0.0 tag records mappings for individual Compose keys. It maps environment to container environment variables, image to the container image and ports to Service ports. Those mappings are direct enough to explain how much routine translation the tool can perform.

Other entries show the limits of the conversion. The matrix marks depends_on and healthcheck unsupported. A dependency declaration or health check in a Compose file therefore cannot be assumed to become equivalent Kubernetes behavior merely because the rest of the file converts. The absence is a specific semantic gap, not a reason to disregard the useful mappings that do exist.

Volumes similarly involve a cluster dependency. The matrix maps them to PersistentVolumeClaims. A claim is a Kubernetes request for storage, so generating one does not itself describe the storage provider or prove the required volume is available. The application has moved into a system where allocation can involve objects and controllers outside its generated Deployment.

The release documentation also contains a discrepancy worth keeping visible. The graduation announcement advertises new Compose version 3 deploy support, while the matrix at the 1.0.0 tag still labels that key as upcoming work. An older limitation on local builds remains in that matrix, whereas the announcement advertises build-and-push support. The announcement establishes the claimed release capabilities, but that matrix cannot provide a complete specification of their detailed behavior.

That difference affects how the sources can be used. The tagged example supplies concrete image, port and environment input. Established mappings and omissions appear in the matrix. The announcement describes the release's intended additions, without resolving every key's exact conversion behavior in the older reference text.

Graduation supplies a shared maintenance home

The project began at Skippbox and grew through contributions from Google and Red Hat. The announcement credits incubation with helping contributors collaborate across companies under Kubernetes contributor and maintainer guidance. It reports 13 releases, 851 commits and 21 contributors since the first commit on June 27, 2016.

My interest in that maintenance history is practical. A conversion tool has to track two evolving configuration models, and each new key may require a decision about equivalence. The published matrix makes those decisions inspectable even where it needs updating. Kompose's graduation gives that ongoing work a place within the Kubernetes project, while the generated objects let developers examine the exact controller, networking and storage declarations their application will use.