Comparison of Draft, Gitkube, Helm, Ksonnet, Metaparticle and Skaffold

Original author: Shahidh K Muhammed
  • Transfer
image

Recently, Kubernetes is very popular, and developers are looking for additional ways and methods to deploy applications in the cluster of this system. Even the command line kubectlhas come to be seen as a low-level tool, while users continue to look for even simpler ways to interact with the cluster. Draft, Gitkube, Helm, Ksonnet, Metaparticle and Skaffold are just some of the tools that help developers create and deploy applications in Kubernetes.

Draft, Gitkube, and Skaffold simplify application development by letting developers run them in the Kubernetes cluster as quickly as possible. Helm and Ksonnet help with the deployment process, as can determine the readiness of the application for sending, as well as control the release of new versions, processing of various clusters, etc. Metaparticle is an unusual tool that allows you to work with any format (YAML, dockerfile) within your own code.

So what to use in a specific situation?

Let's get a look.

Craft


Easy application development and deployment in any Kubernetes cluster.

As the name suggests, Draft simplifies the development of applications running within Kubernetes clusters. The official statement said that Draft is a tool for developing applications that run on Kubernetes, and not for deploying them. In the design documentation of the Draft application deployment tool, it is recommended to use Helm.

The main task of Draft is to transfer the code that the developer is still working on from his computer to the Kubernetes cluster before the changes are committed to the version control system. Their fixation will occur only after the developer is satisfied with the edits added and launched using Draft in the Kubernetes cluster.

Draft is not designed for production deployment, as it is intended solely for the rapid development of applications for Kubernetes. However, this tool integrates well with Helm, as it uses it to post changes.

Architecture


image

Draft: architecture diagram

As you can see in the diagram, the CLI draftis a key component. With its help, the application language used in the source code is determined and the corresponding package from the repository is applied . A package is a combination of dockerfile and the Helm chart, which defines the environment for the application. Packages can be defined and added to the repository. Users can define their own packages and repositories , as they are presented as files on local systems or in the Git repository.

Any source directory can be expanded if there is a corresponding package for this stack . After the directory is configured using the commanddraft create(adds dockerfile, Helm chart and draft.toml file), you can use the command draft upto create a docker image, transfer it to the registry and launch the application using the Helm chart (provided that Helm is installed). Executing this command after each change will lead to the deployment of a new assembly.

In addition, there is a command draft connectthat can redirect connections to the local system, as well as transfer log streams from the container. It can be used with the team nginx-Ingressto provide domain names for each deployed application.

From scratch to k8s


Below are the steps that will allow you to run an application written in Python in a k8s cluster using Draft (a more detailed guide is in this document ).

Requirements:

  • a k8s cluster (hence the kubectl interface);
  • Helm CLI;
  • Draft CLI;
  • Docker
  • Docker repository for storing images.

$ helm init
$ draft init
$ draft config set registry docker.io/myusername
$ git clone https://github.com/Azure/draft
$ cd draft/examples/example-python
$ draft create
$ draft up
## edit code
$ draft up

Using


  • Application development within the Kubernetes cluster.
  • Used in the “internal development cycle” before changes to the code are committed to the version control system.
  • Pre-CI: Once development using Draft is complete, the concept of continuous integration and delivery (CI / CD) is applied.
  • Not suitable for deployment on production.

More details here .

Gitkube


Creating and deploying docker images in Kubernetes using git push

Gitkube is a tool with which you can create and deploy docker images in Kubernetes using the command git push. Unlike Draft, Gitkube does not have a command line interface, and it runs exclusively in a cluster.

Any source repository with dockerfile can be deployed using Gitkube. After Gitkube is installed and open in the cluster, the developer can create a user resource remote that provides the remote Git URL. Now you can send changes to this address, after which the kubectl-assembly of Docker will be deployed in the cluster. Application manifests can be created using any tool (kubectl, helm, etc.)

Everything is focused on plug and play installation and the use of popular tools (Git and kubectl). Flexibilities regarding deployable repository are not allowed. The Docker build context, the dockerfile path, and updated deployments are configurable.

Authentication to execute the git remote command is based on the SSH public key. Each time changes made to the code are committed and applied using Git, the assembly and deployment processes are launched.

Architecture


image

Gitkube: architecture diagram

There are 3 components in a cluster: remote CRD, which determines what should happen when sending to a remote URL; gitkubed , which creates Docker images and updates the deployment process; as well as a gitkube controller that monitors CRD to configure gitkubed .

After these objects appeared in the cluster, the developer can create his own applications using kubectl. The next step is to create a remote object that tells Gitkube what should happen when the git push command is executed against a specific remote address. Gitkube writes the remote URL back to the remote object field .

From scratch to k8s


Requirements:

  • k8s cluster (kubectl);
  • Git
  • Gitkube installed in the cluster (command kubectl create).

The following are the steps required to deploy applications to Kubernetes, including installing Gitkube:

$ git clone https://github.com/hasura/gitkube-example
$ cd gitkube-example
$ kubectl create -f k8s.yaml
$ cat ~/.ssh/id_rsa.pub | awk '$0="  - "$0' >> "remote.yaml"
$ kubectl create -f remote.yaml
$ kubectl get remote example -o json | jq -r '.status.remoteUrl'
$ git remote add example [remoteUrl]
$ git push example master
## edit code
## commit and push

Using


  • Easy deployment using Git (no Docker build).
  • Application development on Kubernetes.
  • During development, the current branch (WIP, work in progress) can be pushed many times to quickly get results.

→ More details here

Helm


Package Manager for Kubernetes

The Helm tool, as described in the description, allows you to manage Kubernetes applications using charts . Helm builds Kubernetes manifests and manages their versions, providing the ability to roll back to any object (and not just to deploy). Charts can include deployments, services, ConfigMap interfaces, etc. They also support the use of templates so that variables can be easily changed. Charts can be used for complex applications with many dependencies.

Helm is primarily intended for deploying and managing manifests in a production environment. Unlike Draft or Gitkube, which help with application development, Helm focuses solely on production deployment. There is a wide range of built-incharts that can be used with Helm.

Architecture


image

Helm: architecture diagram

First, let's look at the charts themselves. As mentioned earlier, a chart is a set of information needed to instantiate a Kubernetes application. It can contain deployments, services, ConfigMap interfaces, Secret plugins, ingress controller, etc. All of them are defined as YAML files, which, in turn, are templates. Developers can also determine whether some charts are dependent on others or include some charts in others. Charts can be published or merged into a chart repository.

There are two main components to Helm: the Helm command-line interface and the Tiller server. The command line helps in managing charts and repositories, and also interacts with Tiller to deploy these charts.

Tiller is a component running in a cluster that communicates with the k8s API server to create and manage real objects. It also plays charts for the release build. When the developer executes the command , the client contacts the server and reports the name of the chart. After that, Tiller finds a chart, creates a template and expands it in a cluster. Helm does not process the source code. To create an image, you need any CI / CD system, after which you can use Helm for deployment.helm install



From scratch to k8s


Requirements:

  • k8s cluster;
  • Helm CLI;

An example of deploying Wordpress in a k8s cluster using Helm:

$ helm init
$ helm repo update
$ helm install stable/wordpress
## make new version
$ helm upgrade [release-name] [chart-name]

Using


  • Comprehensive application layout (with many k8s objects).
  • Chart repository for reuse.
  • Easy deployment in multiple environments.
  • Nesting Charts: Dependencies.
  • Templates: ease of change.
  • Distribution and reusability.
  • Deployment at the last stage: continuous delivery.
  • Deploy an already created image.
  • Joint updating and rollback of many k8s objects - life cycle management.

More details here .

Ksonnet


CLI-enabled infrastructure for creating flexible Kubernetes cluster configurations The Ksonnet

tool provides an alternative way to determine the application configuration for Kubernetes. It uses Jsonnet (the JSON template language) to define k8s manifests, not standard YAML files. The Ksonnet command line generates the final YAML file and then applies it to the cluster.

Ksonnet is designed to identify components that can be reused when building applications.

Architecture


image

Ksonnet: Overview

The key elements are called parts. Combining parts, we create prototypes . After adding parameters to the prototype , it becomes a component, and the components are grouped together and form an application . Applications can be deployed in multiple environments .

There are three main stages of Ksonnet's work: creating the application directory (command ks init), automatically generating a manifest (or writing your own) for the component (command ks generate), and deploying the application in a cluster / environment (command ). Management of various environments is carried out using a team .ks apply ks env

In short, Ksonnet helps you manage applications as a group of components using Jsonnet, and then deploy them to different Kubernetes clusters.

Like Helm, Ksonnet does not process source code. This is a tool for defining applications for Kubernetes using Jsonnet.

From scratch to k8s


Requirements:

  • k8s cluster;
  • Ksonnet CLI.

Guest book example:

$ ks init
$ ks generate deployed-service guestbook-ui \
     --image gcr.io/heptio-images/ks-guestbook-demo:0.1 \
     --type ClusterIP
$ ks apply default
## make changes
$ ks apply default

Using


  • Flexibility in writing configurations through the use of Jsonnet.
  • Layout: Comprehensive applications can be assembled by combining and matching components.
  • Prototype library and the ability to reuse components (elimination of duplication).
  • Easy deployment in multiple environments.
  • Deployment at the last stage: the stage of continuous delivery.

More details here .

Metaparticle


The standard library for cloud-based applications running in containers and the Kubernetes

Metaparticle is the standard library for cloud-based applications. It helps to apply standard patterns for implementing proven development models of distributed systems using programming language interfaces.

Metaparticle provides idiomatic language interfaces that help you create systems that can containerize and deploy applications in Kubernetes, develop replicated load-balanced services, and much more. You do not need to define a dockerfile or Kubernetes manifest. Everything is processed using idioms specific to the programming language used.

For example, to create a Python web application, you need to add a decoratorcontainerize(imported from the Metaparticle package) into the main function. After the Python code is executed in the Kubernetes cluster, the docker image is assembled and deployed in accordance with the parameters specified in the decorator. To connect to the cluster, the standard kubectl context is used. Thus, a change of environment will also mean a change in the current context.

Similar primitives are available for NodeJS, Java, and .NET. Work is underway to add support for more languages.

Architecture


The library Metaparticlefor the corresponding language requires templates and dependencies for creating code in the form of docker images, sending it to the registry, creating k8s YAML files and deploying it in a cluster.

The Metaparticle package contains language idiomatic bindings for creating containers. Metaparticle Sync is a library inside Metaparticle for synchronizing multiple containers running on different platforms.

JavaScript / NodeJS, Python, Java, and .NET are currently supported.

From scratch to k8s


  • Requirements:
  • k8s cluster;
  • Metaparticle library for a supported language
  • Docker
  • Docker repository for storing images.

An example for Python (only the corresponding part) is to create docker images and deploy to a k8s cluster:

@containerize(
    'docker.io/your-docker-user-goes-here',
    options={
        'ports': [8080],
        'replicas': 4,
        'runner': 'metaparticle',
        'name': 'my-image',
        'publish': True
    })
def main():
    Handler = MyHandler
    httpd = SocketServer.TCPServer(("", port), Handler)
    httpd.serve_forever()

Using


  • Application development without the need for YAML or dockerfile.
  • You no longer need to learn many tools and file formats to take full advantage of containers and Kubernetes.
  • The rapid development of replicated, load-balanced services.
  • Manage synchronization, for example, locking and selecting a master copy in distributed networks.
  • Easy development of cloud patterns such as segmented systems.

More details here .

Skaffold


Simple and reproducible development in Kubernetes

Skaffold manages the process of creating, storing and deploying applications in Kubernetes. Skaffold, like Gitkube, allows you to deploy any directory with dockerfile in the k8s cluster.

Skaffold creates a local docker image, sends it to the registry, and deploys it using the command line tool skaffold. It also monitors the state of the directory and, when the code inside it changes, builds and redeploys it. In addition, it transfers logs from containers.

The process of creating, transmitting and deploying is configured using the YAML file, so the developer can use the most convenient combinations of tools at these stages. For example, you can choose docker build or Google Container Builder to create, kubectl or Helm to deploy, etc.

Architecture


image

Skaffold: A review

Skaffold CLI does all the work. We refer to the file skaffold.yamlin which the necessary actions are defined. A typical example is creating a docker image using a dockerfile in the directory where it is executed skaffold dev, tagging with the sha256 hash, transferring the image, installing it in the k8s manifest, pointing to the YAML file, and applying the manifest to the cluster. This process runs continuously, responding to every change in the directory. Logs from the running container are transferred to the same viewport.

Skaffold is very similar to Draft and Gitkube, but it is a more flexible tool as it allows you to manage different build-push-deploy process chains, as shown in the example above.

From scratch to k8s


Requirements:

  • k8s cluster;
  • Skaffold CLI;
  • Docker
  • Docker repository for storing images.

The steps that you must follow to deploy the application that displays the string hello-world:

$ git clone https://github.com/GoogleCloudPlatform/skaffold
$ cd examples/getting-started
## edit skaffold.yaml to add docker repo
$ skaffold dev
## open new terminal: edit code

Using


  • Fast deployment.
  • Loop assembly - a continuous build-roll cycle.
  • Application development on Kubernetes.
  • Defining build-push-deploy chains in a CI / CD stream

More details here .

***

You can write to the author if he missed something or was mistaken somewhere. The article does not mention tools like Ksync and Telepresence , since another article is planned about them in the near future. But if you know about other useful tools that belong to the same category that are mentioned here, write about it in the comments.

A discussion of the article on Hacker News can be found here .

Also popular now: