Kubernetes has become the dominant container orchestration framework. One of the reasons is because of its ability to meet a diverse set of application development and deployment requirements. Though the framework has solved many problems, many functionality gaps have popped it, requiring additional tools. The open-source community is active, introducing tools at a rapid pace, so many in fact that it’s hard to keep track of all of them. Below is an overview of five tools that’ll help users on their Kubernetes journey.
Helm is a package manager developed for Kubernetes applications. It streamlines the installation, management, and use of Kubernetes. Using this tool, developers and operators can easily package, configure, upgrade, and deploy Kubernetes packages that are called charts.
Presently, more than 70% of Kubernetes users use Helm. This tool is being used across industries, from academia to the Fortune 1000 to startups.
A CNCF survey observed that Helm usage grew from 41% to 69% in 2019. In 2020, the tool has become a major CNCF project, moving from the incubating level to the graduate level.
Helm provides the following functionality with charts:
- Create new charts
- Package charts into chart archive (tgz) files
- Manage charts installed with Helm
- Add and manage chart repositories
- Install/uninstall charts into Kubernetes cluster
Components of Helm
The three main components are:
- Command-line (helm): Provides an easy-to-use user interface for Helm functionality.
- Tiller: A companion server component that communicates with the Kubernetes API to manage the packages. (Not included in Helm 3)
- Charts repositories: Contains prepackaged charts for popular open-source software programs.
- Helm Chart: Helm packaging format
Helm Chart Repository
Helm charts refer to the collections of manifests that describe related Kubernetes resources. Users can easily create, share, and publish charts using Helm without copy-paste.
A chart repository refers to any HTTP server where helm charts are stored and shared.
The server has an index.yaml file that consists of an index of all charts in the repository, along with some packaged charts. To share charts, a user must upload them to a chart repository.
In November 2019, The Helm Team announced the release of Helm 3. The latest version consists of a 3-way strategic merge patching: the old chart > live state > new chart.
With RBAC (Role-based Access Control) enabled by default, Helm 3 does not involve the use of Tiller.
Templates in the new version do not use Lua. When it comes to creating namespaces, Helm 3 does not create them automatically for releases. It throws an error message following the kubectl convention, in case users try to create a release with no namespace.
There are many reasons to use Helm. The Kubernetes tool automatically maintains a versioned history of all releases. In case something goes wrong, users can run the helm rollback command. Users can easily combine it with CI/CD to integrate actions into pipelines before installation.
Skaffold is one of the latest tools that simplify local Kubernetes deployment and saves developers time by automating most of the development workflow. Since it operates completely on the client-side, Skaffold doesn’t need components on the user’s cluster, making it highly performant and lightweight.
The command-line tool tracks changes in users’ local application directories, and automatically builds and deploys application images to any location, including remote Kubernetes clusters.
When the tool detects any code changes, it automatically builds artifacts, including the local Dockerfile, Dockerfile in-cluster, and Dockerfile in the cloud. Thereafter, it tests and tags artifacts before publishing them in order to prevent unwanted changes from harming the production environment.
The main configuration file skaffold.yaml controls the Skaffold pipeline. Users can define global commands, configurations in the files, and Skaffold APIs. These can be:
- apiVersion: Dictates the desired Skaffold API
- build: Includes details on Skaffold artifacts. Users can define the steps to create, review, tag, and push artifacts for further processing.
- test: Defines the testing parameters for every artifact.
- deploy: Allows users to choose between artifact deployment tools, including Helm, kubectl, and Kustomize.
- profiles: Lets users override previous configs and set up predefined profiles.
Skaffold divides CD pipeline into three blocks:
- Artifacts block
- Push block (test/tag/push)
- Deploy block
The artifact block handles the real-time automation of deployment and makes CI/CD pipelines more agile. Users can create artifacts using Jib and Bazel.
Jib is a Google Container tool that lets users build Docker images within Gradle or Maven. On the other hand, Bazel provides high-level, human-readable language to create images in a more manageable manner.
The Sync command makes Skaffold natively copy all changed files to deployed containers by creating and sending an archive to the target container. Using this command, users can synchronize .firebaserc file to /etc/ in the container for an easy configuration update. It also helps to synchronize dynamic and static applications.
On-Cluster Application Debugging
Skaffold also supports the direct debugging of Java, NodeJS, Golang, and Python code on the cluster. The debug command continuously runs a develop and deploy loop for users’ applications, forwarding debugging ports to local machines. Thus, Skaffold automatically manages configuration changes dynamically, providing users with a simplified and powerful tool for developing native applications.
Tilt helps programmers in the areas of continuous development and continuous deployment of microservices applications. The tool automates the entire process, starting from changing code to watching files to updating the development environment.
The tool monitors all changes made to Dockerfiles. Then, it deploys these changes incrementally to containers located in the Kubernetes cluster. With this tool, developers can update live clusters in real-time simply by updating the Dockerfile. On top of that, users can create snapshots of the cluster state to share with teams for debugging.
In addition, Tilt reuses Kubernetes manifests in Tiltfile, making it faster and easier to develop and deploy microservices that have highly complex dependencies between Docker images.
Developers can use the console to monitor the development and deployment of their applications easily.
The UI consists of all the information about pods in the cluster using Tilt, the deployment history, and pod logs. This information is helpful when it comes to developing interrelated microservices for a particular application.
Tilt works well with Helm charts for deployment to Kubernetes clusters. It also supports Docker-compose to orchestrate deployed services that do not require Kubernetes clusters.
Tilt is a highly versatile and easily configurable platform. Users can integrate the tool in stages. Also, Tilt has a Python-like DSL for its format that makes it easy for users to access the full programming language in the configuration files.
Microsoft launched Draft in 2017, with a goal to streamline Kubernetes development. Using only two simple commands, developers can build container-based applications that run on Kubernetes. It’s simple to use and can be installed via GitHub:
- draft init: Set up the draft.
- draft create: Containerize application according to Draft packs.
- draft up: Deploy the application to a Kubernetes dev sandbox.
Modify the application using a local editor and deploy changes to Kubernetes in seconds. Since Draft builds upon the Kubernetes Chart format and Kubernetes Helm, users can easily develop CI pipelines for applications.
Run draft create to ship and build source code to a Kubernetes cluster using Dockerfile. The command uses the Helm Chart to deploy the source code in a dev environment where users can test their app live. All changes become available in seconds.
Developers can create applications on a tight interaction loop that runs from code through deployment, using a Jenkins registry and a Kubernetes cluster.
Keep in mind that Draft works well on a remote Kubernetes cluster, allowing developers to code locally and run it in the cloud where they can access the application’s dependencies.
Draft automatically detects the programming language of the application. Thereafter, it uses packs to create a Helm Chart and Dockerfile for that language.
Packs identify dockerfiles and manifests required for particular coding languages, including (as of now) GO, JAVA, Python, NODE, .NET, PHP, and Ruby.
The extensible pack architecture allows developers to code their own extensions based on the application’s particular needs.
Other important features of Draft include:
- The generated configuration files can be customized to fully match the application developed.
- Supports a wide range of programming languages without writing dockerfiles or Kubernetes manifests. It makes Draft great for developers who are new to Kubernetes and Docker.
- All applications execute locally without requiring any external system.
- Users can easily modify and extend configuration files into a CI/CD pipeline.
- The Kubernetes tool automatically tracks all local code changes that trigger cluster deployments. Developers can enable/disable this functionality.
Garden is a development tool designed for distributed systems and microservices. It takes care of everything from the application development deployment life cycle to building specific services to running various tests and keeping everything up-to-date in real-time. Garden’s features include the following:
- After it is deployed within the environment, it watches Git repositories and automatically spins up a testing environment as requested.
- Users can embed it in existing CI pipelines and configure to spin up a testing environment.
- Users can pull up an ad hoc testing environment in an on-demand private namespace environment to troubleshoot before pushing it to git.
The Kubernetes testing environments created by Garden features:
- In-cluster builds: Build images in your Kubernetes cluster without using local clusters.
- Test orchestration: Users can easily define tests to be run in-cluster.
- Result caching: Since the tool is aware of relationships of all services in the stack, it tests only those parts that have been affected by the changes. These results are cached and shared among teams. Faster test runs and feedback loops for developers are the by-products.
Garden runs from the developer’s machine or CI. Users can use it to codify a complete stack description, making workflows portable.
Each part of the stack uses an intuitive declaration to describe itself. Garden collects these declarations into a full-stack graph and uses it to help develop and test applications faster.
When Garden runs with a shared Kubernetes cluster, it uses the following services to set its own namespace:
- Image cache and test cache: Garden always saves images and test results and shares them across developer teams. The cached instances reduce builds and tests by about 80%.
- Build service: CI and developer processes don’t have to run Docker and Kubernetes. The build service handles it for every Kubernetes cluster.
Users can run Garden in the cloud or on-prem and build, deploy, and test Helm Charts, Docker containers, and more. Moreover, users can select from a wide range of CI tools and Kubernetes platforms.
Another important feature of Garden is the Terraform functionality. With Terraform integration, Garden validates and provisions infrastructure before deploying the rest of the stack. Garden’s overall plugin system lets users form custom module types based on their needs.
Although the Kubernetes ecosystem is complex and many gaps exist in the platform, the development community continues to create tools to fill in the gaps