Docker Compose vs Kubernetes Development Tools

By Kasper Siig

When getting started with Docker, many developers quickly turn to Docker Compose to run their applications. Compose offers many advantages, such as having your configuration stored as code, making it easy to maintain and expand upon. Unfortunately, although it is possible to use Compose with Kubernetes, it's not the recommended approach.

Devs will often bang their head against the wall trying to make this scenario work when they start using Kubernetes, without knowing that there's a better way. After all, they have become used to Compose and have integrated it deeply into their workflow. It can be hard to let go.

This article will go over why it's best to leave Compose out of Kubernetes, and give resources to help you with improving your workflow without it. You'll be introduced to tools that will provide you with the same advantages as you would have with Compose traditionally.

Avoiding Docker Compose in Kubernetes

So you've started to use Kubernetes with your project, and you're wondering what to do with all of your work in Docker Compose. Rather than having to abandon all of your work and start completely from scratch, it's possible to use a tool like Kompose as a way of converting your docker-compose.yml files into Kubernetes manifests. Being familiar with Compose, this can give you great insights into how things are mapped into Kubernetes, and act as a starting point for your research into manifests.

However, when you start moving from the learning phase to the production phase, it's important to think about whether you want to keep Compose in your toolchain at all. Even though tools like Kompose exist to help bring Compose into a Kubernetes environment, it's still not considered best practice. Instead, you should consider switching over to using Kubernetes manifests.

Using Compose in production can be fine initially, and if your goal is to get simple containers deployed, it's not a big deal. That being said, once your cluster starts maturing and your use cases become more complex, you will find that trying to define everything in a docker-compose.yml is either tough or impossible.

You'll likely get to a point where you're spending a significant amount of time developing and maintaining docker-compose.yml files. So much so that it would have been easier to just start over with Kubernetes manifests. This is an important point to consider when deciding whether to use one tool over another. One may be easier initially but perhaps limits the possibilities in the future, or be harder to work with in complex scenarios.

Compose's Consequences and Risks

By using Compose in Kubernetes, you are limited in functionality. While Compose is a robust tool with a rich feature library, there are many things it cannot do. Objects like CRDs, Jobs, and StatefulSets cannot be created with Compose. Networking is possible, but it can quickly become unwieldy to define it in a docker-compose.yml file.

There are some technical downsides to the continuing use of Compose, but you will have to also consider the impact on your team, both current and future. Not many people are using Compose in production, so you'll likely struggle to find a new hire that's able to jump right in. There are also features of Compose that are not typically used, which you'll have to get familiar with to configure Kubernetes.

If you manage to get your engineers to learn and use Compose efficiently, and you're fine with onboarding new people into the toolchain, you may still run into issues. Since not many teams use Compose in production, it can be tough to find guides and tutorials with examples. Many online resources will only include Kubernetes manifests as examples, and from here two things can happen:

• One option is that the engineer in the team will understand the tutorial and get everything defined in a .yml file. This way, you'll continue to purely use Compose, but you'll have to carry the cost of engineering time spent converting the Kubernetes manifest. This also means that your engineers understand manifests well enough to convert them to another format, weakening the argument for using Compose.
• The other option is that the example manifest will be used as a Proof of Concept, but it will end up being used in production because of a deadline or other reasons. Now you have a mix of Compose files and Kubernetes manifests, which can quickly lead to confusion.

You will have a tough time integrating with other tools on the market since many tools exist to expand upon existing Kubernetes manifests. Some of these tools help in easing deployment, like Helm. Other tools like Skaffold work with your manifests to run your application in Kubernetes as you work on it. You might find workarounds that allow you to use these tools, but you won't find any official documentation on setting them up. You'll have to maintain these workarounds, and it creates more room for error.

Finally, you run the risk of having different teams using different tools. Developers may want to use Compose as it's more user-friendly on the surface, and they mostly care about getting the application to run and making optimizations through the code. Ops may want to get deeper into the roots of Kubernetes in ways only possible when using native Kubernetes tools. Typically they care about optimizations in the infrastructure, like networking and load balancing. Using Kubernetes manifests won't guarantee different teams using the exact same tools, but they will have the same common ground.

Other Options

As stated before, there are many tools available to help you work with Kubernetes. Many stick with Compose because it's easy to define containers, networking, and volumes, and that's a fair point. However, tools like Skaffold, DevSpace, and Tilt exist to make working on code that's meant to run in Kubernetes easier. These tools offer features such as watching your code, automatically building and deploying your application, and much more that's native to Kubernetes.

These tools can help you transition from a Compose-based approach into something more akin to native Kubernetes. Their sole goal is to make life easier for developers while still using the basis of Kubernetes; manifests. Give them a try and see how they work for you, and whether you can find a way of getting them into your current toolchain. To get started, you can use Kompose as a way of converting your existing docker-compose.yaml files into Kubernetes manifests. From here, you can either deploy them and get familiar with the deployment process, or you can look into the generated files and try to understand them.

Whatever tool you choose to go with, the most important thing is that you know why you're using it. Many best practices exist because they're what suits most organizations. However, there will always be outliers, and you may be one of them. You may be in a situation where it indeed does make the most sense to use Compose as your only tool, and that is perfectly acceptable.

You just need to know why you've chosen to go with the tool that you have, making it possible to reevaluate down the line whether it's still right for you or if you should consider switching to best practices.

Conclusion

On the surface, it can seem challenging to learn a new tool, and Kubernetes is quite heavy for new users. However, transitioning from Compose to native Kubernetes isn't as complicated as it may seem, and as you've now seen, there are many tools available to assist you with this. Switching to manifests will help you in many ways. Whether you make the switch is up to you, but consider whether it's the right choice and what advantages it can bring to you.

You can start by converting your docker-compose.yml to Kubernetes manifests with Kompose. That way you'll be using an application and definition that you're already familiar with instead of starting from scratch with an application you don't know.

Photo by Campbell on Unsplash