Top 11 Continuous Delivery Tools for Kubernetes (Part 1)
In this blog we look at the top 11 tools for continuous delivery to Kubernetes and discuss the pros and cons of each one.
Standing up Kubernetes and getting your apps running on it is a fairly straightforward process, but when it comes to updating and deploying apps, it is not always so simple. In particular, performing manual Kubernetes deployments with a large development team can be error prone:
- Almost everything related to deployments or most user facing components in Kubernetes are defined in YAML files. These can be frustratingly error prone with no feedback when things go wrong.
- Kubernetes applications are comprised of several different resource types, some of which may need upgrading, and depending on the type of app you are working on, knowing what to update can make deployments complex.
- Keeping track of the diff history, managing rollbacks of new and old deployments especially when you are working on a large application within a team can be challenging.
- Managing secrets in Kubernetes between team members working on the same app across different repos requires that you are careful.
To mitigate these problems the ultimate goal for developers working with apps running in Kubernetes is to automate the workflow for code updates to achieve an end-to-end Continuous Integration/Continuous Delivery (CI/CD) pipeline.
Depending on your team’s needs and workflows, some tools might be better than others. In this two part blog series, we discuss some of the more popular tools and highlight the pros and cons of each.
Throughout this survey of CICD tools for Kubernetes, three different patterns emerge:
- Package Managers
- CI with CD support for Kubernetes
- CD only tools
In part 1 of this series, we’ll be looking at tools that fall under package managers and CI tools with CD support for Kubernetes.
Package Managers
Traditional package managers have been around for some time and is a development pattern that is recognized by most engineers. Kubernetes package managers attempt to emulate the functionality of classic packagement tools like: apt, yum, apk, and Homebrew.
CD tools in this category update, version and delete Kubernetes configuration assets for your application as well as deploy new features to your cluster.
1. Helm
Helm has been referred to as the package manager for Kubernetes that works similarly to apt, yum or npm.
Helm uses ‘charts’ where a package of Kubernetes resources and any dependencies needed for your app are defined. Helm charts for a service or set of services reside in their own directory. At a minimum the directory must contain a file that describes the package, called a Chart.yaml file and a values.yaml that specifies the default configuration options.
Once a developer calls a chart from the command line, Helm generates the YAML files for the Kubernetes deployment and then applies them to the cluster.
Since Helm is open source, there are a number of OSS community charts that attempt to standardize configurations for many common services used across common applications. These open source charts can be downloaded, amended and used within your own organization from Kubeapps Hub.
An advantage of using Helm is that it makes deploying complex applications more portable, supports automatic rollbacks and is a familiar pattern for developers that makes it easy for them to understand. The drawbacks are that Helm is complex to setup and keeping secrets secure across your pipeline can be difficult to configure.
2. ksonnet and jsonnet
Another popular package manager type tool is ksonnet and jsonnet. Much like Helm, it provides a way of packaging up Kubernetes resources that can be used to generate the required configuration files for your deployments. Ksonnet is the command line utility and jsonnet, described as a superset of JSON, is the language used to describe your application.
An advantage of this approach is that developers who are already familiar with JSON can easily adopt jsonnet and use it to describe application objects and then deploy their applications without having to wrangle a pile of YAML files. But then, jsonnet is not pure JSON and still requires you to learn its differences.
3. Draft
Draft is Microsoft’s open source build and deployment tool. It is like a pipeline orchestration CLI that could also be classed as a package manager. Developers can use Draft to generate Docker images after code has finished going through CI. It can also be used to create Helm charts that generate the YAML files Kubernetes needs to deploy your application.
A pro of using Draft is that you can use it with Helm to package their applications and deploy them to Kubernetes running on Azure.
A drawback is that it requires a lot of configuration to ensure a large team of developers are not leaking cluster secrets, in addition to this, the project is also only in Alpha stage.
CI Tools with Kubernetes Support
Continuous Integration (CI) tools have been around for quite some time. They were designed to unit test and integrate your changes with the rest of your code base. If your tests pass, you can ask it to build a Docker image and send it to a repository. With Kubernetes fast becoming an established part of the development process for cloud native apps, CI tools have further evolved and many have added cluster deployment capability.
4. Jenkins (Cloudbees)
Out of all of the CI tools that have added Kubernetes deployments to their feature set, Jenkins is probably the most popular and powerful tool used by developers today. Jenkins is the open source project and Cloudbees is its equivalent commercial product.
Jenkins describes itself is an automation server and originally the tool offered CI only. It includes a plugin for Kubernetes deployments that allows for Jenkins agents to run inside the cluster and make on demand deployments as well as set up Blue/Green deployments.
Jenkins allows for declarative pipelines to be built where configuration files can be kept in Git. While it’s powerful, and many developers use it in their development environments, it can be complex, and error prone. It also relies on a single tool for your entire pipeline which if cluster secrets are leaked outside can be insecure when you are working across multiple teams.
5. CircleCI
CircleCI is another a well-known and powerful Continuous Integration tool that includes an API for automatic Kubernetes deployments. But if you want to use CircleCI for Kubernetes, you’ll need to add the missing pieces of the deployment pipeline with custom scripts.
While CircleCI does continuous integration well and it also supports automatic deployments to a number of different cloud providers, it lacks rest of the pieces to make a complete pipeline. As a result, it’s up to you to harden the security and to build the scripts to deploy your updates to the cluster. Again, you could use CircleCI with Weave Cloud and not have to worry about the security issue.
6. Travis
Travis is a CI tool that you can use to trigger a set of commands after you’ve pushed code to your GitHub repo. It does not come with “out-of-the-box” support for Kubernetes.
Many people have forged their own pipelines with Travis CI, but it relies on connecting a pile of scripts together. And since in this type of pipeline, the CI portion needs the credentials for the cluster to kickoff the deployment, this method also suffers from the security issue of needing cluster secrets outside of Kubernetes itself.
An advantage of this approach though is that you can choose the tools you want and therefore have the best tools to create your pipeline. To mitigate the security issue, you could use Travis for what it was intended and build and incorporate Weave Cloud for cluster deployments.
7. Gitlab
If you’re looking for an end-to-end pipeline that doesn’t require much configuration and works right ‘out of the box’, then GitLab may be the answer. Gitlab comes with built-in support for CI and comes with a native auto-deploy component for Kubernetes. It can also support Helm charts if you don’t want to use their native auto deploy component.
In Conclusion
As mentioned earlier, only Weave Cloud handles cluster credentials in a safe manner and keeps them inside the cluster where they belong, rather than outside of the cluster where they may be exposed to unauthorized access to your cluster and by using a pull based pipeline pattern, it decouples deployments from the rest of the pipeline. This means that you are free to choose the tools that best suit your needs without compromising security in order to do so.
For more information on Continuous Delivery pipelines see: Kubernetes CICD - CI/CD for Kubernetes.
Try Weave Cloud Deploy in your browser with this interactive tutorial Deploy: Continuous Delivery with Weave Cloud.
Read our latest ebook, "Building Continuous Delivery Pipelines" to learn how to plan and implement a CD pipeline in your organization, including the benefits and best practises.
