Draft and Helm vs Ksonnet? [closed]

Question

As I understand all of these tools Draft,Helm and Ksonnet have overlapping functionality such as creating a chart as well as deploying kubernetes configurations.

I understand that purpose of these tool would be to describe and configure the application as well as the k8s environments.

By using Draft we can create Dockerfile, Chart. Nevertheless we can do same thing with Helm and Ksonnet.

My question is If these components create a pipeline in CI/CD then what will be the order?

for example,

draft -> ksonnet > helm or

draft -> helm -> ksonnet

Answer 1

In short, draft and helm are more or less complimentary and ksonnet is orthogonal, specifically providing an alternative to helm.

In elaborating I will split my answer up into three major sections, the first of which describes how draft and helm interact, the second describing how ksonnet is orthogonal to the others, and finally a section explaining how I understand these with respect to CI/CD.

Helm & Draft

Helm and Draft are complimentary in the sense that Helm, which can be considered to be a package management system for Kubernetes, provides a portion of the functionality offered by Draft which itself is essentially a Kubernetes application development tool.

The relationship between Draft and Helm can be summarized by pointing out that in pursuit of its goal of simplifying Kubernetes application development, Draft produces a Helm chart using metadata inferred from your current application type (more about that below) if one does not already exist or uses and existing one in order to deploy/update a development version of your application without you having to know anything about how it does that.

Helm for Kubernetes Package Management

As mentioned previously, Helm is a package management system for Kubernetes-based applications. It provides the following features:

• A templating approach for defining Kubernetes manifests (called "charts")
• Package management, including a basic package repository service to host released packages.
• Application lifecycle management including deploy, update, and purging of Helm applications
• Package dependencies

Helm takes a templated YAML approach to parameterizing Kubernetes manifests and allows values to be shared and overridden between dependent packages. ie, supposed Package A depends on Package B; Package A can re-use configuration values set on Package B and it can override those parameters with values of its own. Values for all packages in a given deployment can also be overridden using the Helm command line tool.

Also worth mentioning is the fact that Helm depends on the availability of its cluster-side component named "Tiller" to actually do the work of reifying templates and deploying the generated Kubernetes manifests to the cluster.

Draft for Kubernetes Application Development

The aim of Draft is to dramatically simplify development of Kubernetes applications by being quickly building and deploying the Helm charts/packages and corresponding docker images necessary to run a project -- provided that the following exist:

• A Kubernetes cluster
• Helm's Tiller pod installed in the Kubernetes cluster
• A Docker registry

The draft installation guide provides details for getting these pieces set up to try it out yourself.

Draft also builds on Helm by providing a high-level "packaging" format that includes both the application helm chart and the Dockerfile, the latter giving it the ability to build docker images.

Finally, it has built-in support for specific programming languages and will to a limited extent attempt to infer which programming language and framework(s) you are using when initially creating a new Draft project using draft create.

Ksonnet for Kubernetes Package Management

As mentioned previously, Ksonnet is orthogonal in many ways to Helm, providing essentially the same features with respect to package management wrapped in different terminology -- see its core concepts documentation. It's worth noting that it is not compatible with nor does it address the same concerns as Draft.

I say that Ksonnet and Helm are orthogonal because they take mutually incompatible approaches to generating and deploying Kubernetes manifests. Whereas Helm uses templated YAML, Ksonnet generates Kubernetes manifests using a "data templating" language called Jsonnet. Also, rather than conceiving of "dependent" packages as is the case with Helm, Ksonnet blurs the line between dependent services by representing them as composable "prototypes". Finally, rather than depending on a cluster-side application that reifies and deployes manifest templates, Ksonnet has an apply subcommand analogous to kubectl apply.

CI/CD

So where do these pieces fit into a CI/CD workflow? Well since there are essentially two mutually incompatible toolsets, let's consider them on a case-by-case basis:

Draft + Helm

According to the Draft design Q&A section, it is meant only as a developer tool intended to abstract much of the complexity of dealing with kubernetes, helm, and docker from developers primarily interested in seeing their application run in a development cluster.

With this in mind, any CD approach involving this set of tools would have to do the following:

• Build docker image(s) using the docker CLI if necessary
• Build Helm package(s) using the helm CLI
• Deploy Helm package(s) to Helm repository using the helm CLI
• Install/update Helm package(s) on the appropriate staging/prod Kubernetes cluster(s) using the helm CLI

Ksonnet

The Ksonnet CD workflow is somewhat abbreviated compared to the helm workflow above:

• Build docker image(s) using the docker CLI if necessary
• Apply the Ksonnet manifest using the ks CLI

Whereas with Helm you would deploy your applicat's package to a Helm registry for re-use, if your Ksonnet manifest contains re-usable prototypes that might be of use to another Ksonnet-based application you would want to ensure it is available in a git repo as described in the Ksonnet registry documentation.

This means that how Ksonnet definitions are dealt with in CI/CD is largely dependent on which git repo(s) you decide to store them in and how they are structured.