There are lots of tools out there to help you develop on Kubernetes, whether you are writing an app alone or in a team environment. Several of them, such as Minikube, Minishift and Docker for Windows/Mac, support pure offline development, which means you don’t have to pay for using cloud resources. With others such as Telepresence, a proxied set-up that involves forwarding traffic into and from the cluster, is preferable.
Asides from CodeReady, the tools we cover here are all for specific tasks. You can build your own stack from entirely open source or proprietary solutions, or a mix of both.
Even for established technologies like JSON vs. YAML vs. XML, the right tooling will depend on your background as a developer, other preferences and organizational requirements. Tools for the Kubernetes ecosystem can be particularly tricky as they evolve so quickly with new tools being launched on a near weekly basis.
This post will review a few of the most popular tooling options, starting with CodeReady, the only one that combines all these tools with support, add-on functionality and middleware.
CodeReady
RedHat just introduced the first Kubernetes native browser-based Integrated Development Environment (IDE), the Red Hat CodeReady Workspace. RedHat calls it a “collaborative kubernetes-native development solution that delivers OpenShift workspaces and in-browser IDE for rapid cloud application development”. It works directly with Red Hat Enterprise Linux and OpenShift, Red Hat’s PaaS built on Docker and Kubernetes.
The New Stack calls RedHat’s solution as an opportunity to ensure “compatible and secure developer tools”.
As with many other tools for Kubernetes app development, CodeReady is based on a free open source tool, Eclipse Che. CodeReady offers “a shareable developer environment that includes the tools and dependencies needed to code, build, test, run and debug container-based applications”. Unlike its open source foundation, the Red Hat offering will have releases on a three-month cycle, ensuring support and stability.
CodeReady occupies an unique space in the market for being the first IDE to run inside a Kubernetes cluster and manage the code, dependencies and artifacts inside both OpenShift pods and containers.
The goal, according to Brad Micklea, Red Hat’s senior director of developer experience and programs, is to assist teams in operating more securely and efficiently. Micklea was previously the Chief Operating Office at CodeEnvy, which developed Eclipse Che before it was acquired by Red Hat two years ago.
Micklea says CodeReady shines in Kubernetes-first environments. “Unlike other developer IDEs, which you can use to build containers and deploy to Kubernetes, they haven’t been designed where Kubernetes is the native or default runtime for everything you do,” said Micklea. “With CodeReady workspaces, the moment you start coding, you’re inside a container inside a pod inside Kubernetes. You kind of don’t have a choice but to be inside Kubernetes.” The release offers support for various languages, including Node.js, Java for Red Hat Enterprise Linux, and C/C++, Net, Golang, PHP and Python.
CodeReady also offers a simplified route to reliable security. As everything is stored centrally and accessed inside the web-based IDE or through a developer’s chosen IDE via SSH, the attack surface is dramatically reduced. Developer onboarding is also simpler because the developer’s environment is replicated inside the pod as opposed to on the local machine using “Factories”, a template that contains the source code location, runtime and tooling configuration, along with commands the project needs.
Skaffold
Skaffold is a Google Cloud tool released last March to help onboarding developers new to Kubernetes with a command line tool “that facilitates continuous development for Kubernetes applications”. The wider goal is to offer developers “an iteration and deployment experience that closely mirrors production”.
In Skaffold, developers can write application source code locally that is continually updated and made ready for validation or testing in either their local or remote Kubernetes clusters. By automating the development workflow, time is saved, potentially allowing for an increase in the quality of the application through to production stage. Skaffold aims to supply portability for CI integrations with a set of different build system, image registry and deployment tools. It also offers a basic set of capabilities for generating manifests, but this isn’t a central feature. It is still at an early phase of development with new features being added regularly.
Skaffold has a pluggable architecture, allowing users to pick tools for use in each step involved in building and deploying their app, and as such, is extensible.
Features:
- Works independently of any CI vendor, meaning a user doesn’t need their own Docker or Kubernetes plugin, and as it works without CI as such, it can be run from portable environments, such as the developer’s laptop
- Facilitates continuous development for Kubernetes applications
- Skaffold can watch local changes in your source code and automatically trigger build/push deployments to local or remote Kubernetes clusters
- Support for various application components (only necessary to deploy the pieces of the stack that have changed)
- Supports existing tooling and workflows with the ability to build and deploy APIs that make each implementation composable to support various different workflows
- Skaffold handles the workflow for building, pushing and deploying your production
- It can be used to automate a CI/CD pipeline to leverage the workflow and tooling if moving applications to production
- It can be used to deploy to production, users can configure their preferences for how to do this and provide different pipelines for each target environment
- Can be used instead of Draft, and alongside most other tools
Draft
Draft is a project developed by Microsoft Azure following its acquisition of container platform Deis, a company originally behind some of the most used tools for building and managing applications on top of Kubernetes.
The goal behind Draft is to “help you begin that first draft of a containerized application running in Kubernetes. When you first run the draft tool, it automatically discovers the code that you are working on and builds out the scaffolding to support containerizing your application”. In addition to scaffolding files to help developers create their applications, it also deploys a server into your existing Kubernetes cluster, which is kept in sync with your laptop’s code automatically. Whenever you issue changes to your application, the draft daemon on your laptop syncs the new code with the Kubernetes draft server, which leads to the build of a new container and automatic deployment with no user action necessary. In essence, “Draft enables the ‘inner loop’ development experience for the cloud”. Therefore, it’s a tool which will assist you with deploying any app to Kubernetes. It applies heuristics to whatever programming language your app is written in and generates a Dockerfile and a Helm chart. The resulting image deployed to the target cluster is sent via the Helm chart (another option can’t be chosen for deployment). Draft also enables easy setup of port forwarding to localhost.
Features:
- The Helm chart and Dockerfile templates can be customized to the user’s preferences or a custom pack can be built for future use
- A range of draft-pack supported languages without the need to write dockerfile or k8s manifests
- Draft streamlines development of an app or service that can run on Kubernetes
- Draft writes out build and deployment configuration into the source tree, making it trivial to construct continuous integration pipelines
- As of Draft version 0.12.0, builds are executed locally (older builds are slower as Draft has to copy every change to the cluster, run the build, push the image and release the updated chart)
- Draft can watch local changes and trigger deployments (this isn’t by default, so needs to be turned on by the user)
- It allows the developer to use either the local or remote Kubernetes cluster
- Deploying to production is up to the user
- Can be used instead of Skaffold, and alongside Squash
Squash
Squash is comprised of a debug server, which is integrated with Kubernetes, and an IDE plugin. It is one of the first debuggers available for development of distributed applications. It lets you insert breakpoints, in addition to other necessary functions involved in debugging an application using an IDE. By letting you attach the debugger to a pod running in your Kubernetes cluster, it bridges between the orchestration platform (without affecting it) and the IDE.
Features:
- Easily extensible – it can be used independently of other tools you select and be deployed in combination with various other tools
- Needs a privileged DaemonSet
- Integrates with numerous IDEs
- Supports multiple languages, including Go, Python, Node.js, Java and gdb
- User must make sure that application binaries inside the container image are compiled with debug symbols
- Squash can be used with either a local or remote cluster in Kubernetes
Telepresence
Telepresence is a tool that enables the running of a single service locally as that service is connected to a remote Kubernetes cluster. Telepresence was built at Datawire, which focuses on building open source tools for develops building cloud-native applications. Other tools it has developed include Forge and Ambassador. Telepresence connects containers that run on a developer’s workstation with a remote Kubernetes cluster leveraging a two-way proxy and mimics in-cluster environment, in addition to offering access to config maps and secrets.
One of its goals is to improve iteration time for development of container apps by getting rid of the need for deploying the app to the cluster and leveraging a local container to abstract network and filesystem interface to make it seem as if the app was running in the cluster.
Features:
- It can be used independently of other tools you chose
- It can be used in combination with Squash, although Squash would then need to be used for pods in the cluster, while a conventional/local debugger would need to be used to debug the local container that is connected to the cluster via Telepresence
- It offers connectivity via a side-car process, which is based on SSH
- A more intrusive dependency injection mode is available
- Telepresence gives the developer a rapid development workflow in developing a multi-container application on Kubernetes
- It is most commonly used with a remote Kubernetes cluster, but it can be used with a local Docker container while proxying it to your Kubernetes cluster.
Ksync
Similarly to Telepresence, Ksync also helps you debug issues when developing new features for apps running on Kubernetes. It saves time during development, and is especially useful in the prototyping stage of development.
Ksync transparently synchronizes application code and configuration between the local dev environment and the container running in Kubernetes, similar to what oc rsync does in OpenShift. This means working inside the cluster straight from the IDE in order to step through and debug code more easily.
The goal of Ksync is to help improve iteration time for app development by getting rid of some of the build and deployment steps.
Features:
- Ksync bypasses container image build and revision control
- Compiled language users must run builds inside the pod
- Two-way sync works by remote files being copied to the local directory
- Every time the container is restarted, the remote filesystem is updated
- No security features – it can be used only for development
- Utilizes Syncthing, a Go library that performs peer-to-peer sync
- Ksync requires a privileged DaemonSet running in the cluster
- Node has to use Docker with overlayfs2g
Kubernetes has a hands-on walkthrough of the tools on its blog using a stock market simulator for the demo. There is an extensive list of further resources on the same page, including a list of YouTube video tutorials.