Traditional package managers have been around for some time and are 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.
Examples of tools that fall into this category include:
Helm: The Kubernetes Package Manager
For deploying apps to Kubernetes, Helm is one of the best known package managers. Developed by Deis and open sourced, it is maintained by the Kubernetes community. Helm is gaining a lot of momentum and is quickly becoming the de facto standard for application deployment to Kubernetes.
Specifically, Helm is used to make configurable releases and can upgrade, delete, and inspect releases. It consists of two pieces: “the Helm” which is the client that sits on the developer’s laptop, and “the Tiller” or the server side to Helm that gets deployed to your cluster. The client is basically a templating engine; whereas, tiller is the release management piece that keeps track of version history and also has some health checking capabilities.
Helm uses ‘charts’ where you can define a package of Kubernetes resources and any dependencies needed for your app. Helm charts for a service or set of services reside in their own directory and 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. Other optional files and directories can be used to further define any dependencies:
Charts can describe one service and its dependencies or it can reference other charts and deploy an entire 12 factor application if needed. They can be stored on disk, or fetched from remote chart repositories (much like Debian or RedHat packages).
Once a developer calls a chart from the command line, Helm generates the YAML files for the Kubernetes continuous deployment and then applies them to the cluster.
Since Helm is open source, there are a number of OSS community charts that are attempting 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. As of the end of 2017, more than 110 charts have been contributed that can be viewed and downloaded from Kubeapps Hub.
An advantage of using Helm is that it makes deploying complex applications more portable, supports automatic rollbacks and with over 240 contributors there is a vibrant, maturing Open Source community that is continuing to grow.
Many vendors, including Weave Cloud and Flux, either support or even build upon Helm charts. Read more in “Keeping Helm changes consistent and reliable with Weave Flux”.
- Helm: The Kubernetes Package Manager
- The missing CI/CD Kubernetes component: Helm package manager
- Helm Chart Patterns
- Taking the Helm: Delivering Kubernetes-Native Applications by Michelle Noorali
- Kubeapps: Kubernetes Ready Charts
Jsonnet & Ksonnet
Kubernetes CI Tools
Kubernetes CI tools have been around for quite some time and as mentioned earlier, 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.
Now 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.
While all of these tools are good choices for continuous integration, they lack the 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 custom scripts needed to deploy your updates to the cluster. You can use any of these tools with Weave Cloud and not have to worry about your cluster credentials being outside of your cluster.
Top Kubernetes CI pipeline tools include:
Links for Kubernetes Continuous Deployment
- Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview
- Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)
- Using CircleCI and Kubernetes to achieve seamless deployments to Google Container Engine
- Continuous Delivery With Kubernetes, Docker, and CircleCI
Gitlab:How to Create CI/CD Pipeline with Auto Deploy to Kubernetes using Gitlab and Helm
This group contains tools that do only one thing -- primarily Continuous Delivery to Kubernetes. With these tools, you can choose the CI system that you want and the container registry, and the CD portion will take care of the rest.
Tools that fall into this category include:
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 and allow unauthorized access to your cluster.
Try Weave Cloud Deploy without any downloads using this interactive tutorial Deploy: Continuous Delivery with Weave Cloud
For a list of all of the CI/CD tools that were designed to support Kubernetes refer to: Kubernetes Application Management Tools