Ketch

Helm vs. Ketch when Deploying Applications

Kubernetes has become the de-facto standard for deploying microservices and containerized applications. Still, there is a learning curve for a developer to get familiar with Kubernetes concepts and objects, how to write and manage the required YAML files, etc. While there is undoubtedly value in learning these concepts and tasks, I believe there is even greater value in getting your applications deployed faster and spending more time on your application code than on infrastructure-related objects.

That’s where Ketch (https://www.theketch.io) comes in. Ketch focuses on easing application deployments for developers so they do not have to spend time creating Helm charts, Kustomize, YAML, etc, freeing them up to get their applications deployed and running quickly.

This blog post will cover the deployment of a sample application using Ketch vs. using Helm or Kustomize. For the sample application, we will use one called PodInfo, a Golang web application that showcases practices for running microservices in Kubernetes, developed by Stefan Prodan and found here: https://github.com/stefanprodan/podinfo.

** Note that we will not cover how you can install Ketch in this blog post. If you need more information on that, you can quickly get started with the instructions available on https://learn.theketch.io/docs/getting-started

For this example, you can find a pre-built Helm Chart and the Kustomize scripts, but assuming you had to build these for your application to get deployed, here is the structure you would have to create for your Helm charts:

For this example, you can find a pre-built Helm Chart and the Kustomize scripts, but assuming you had to build these for your application to get deployed, here is the structure you would have to create for your Helm charts:

This is the sample structure you would use for Kustomize:

This is the sample structure you would use for Kustomize:

To create these, you would have to have a good knowledge of crucial Kubernetes concepts, spend time building, and test it. Again, there is a great advantage in learning what each of those files do and what their roles are, but as a developer, it’s also a significant advantage if you can focus less on these objects and more on your application code; this increases the experience when developing and deploying applications on Kubernetes, and it also makes your application more portable and less dependent on infrastructure objects (which is what those YAML files are creating).

The complete folder structure for this project, including Kustomize, Helm charts, and others, can get pretty complex:

The complete folder structure for this project, including Kustomize, Helm charts, and others, can get pretty complex:

If you deployed the same application using Ketch, the project structure would be simpler and more focused on your application code than on the underlying cluster, objects, and charts. Since Ketch automatically creates the required objects for your application to run, you can remove both the Kustomize and charts folders since Ketch won’t need to leverage any of these to deploy your application.

Ketch for Kubernetes Architecture

Let’s see how we can quickly deploy the same application in an Amazon Elastic Kubernetes Service (EKS) cluster using Ketch and without the need to create and maintain Kubernetes related objects. For this example, we assume you already have an EKS cluster running and already installed Ketch (more details on how to get started with Ketch here: https://learn.theketch.io/docs/getting-started )

With Ketch installed, let’s start by adding a pool where we will deploy our application. Pools are created using the ketch pool add command, and once created, Ketch automatically configures a Kubernetes namespace, ingress controller parameters, and default templates for the application.

Kubernetes namespace, ingress controller parameters, and default templates for the application.

We can create our pool using the following command:

$ ketch pool add podinfo –ingress-service-endpoint ab2e08f4a7d944f2cab906edb996a8df-115895280.us-east-1.elb.amazonaws.com –ingress-type istio –cluster-issuer le

** Note that I am using a flag called –cluster-issuer when creating the pool, which will allow Ketch to later generate a certificate for HTTPS CNAMES. This is an optional flag in case you want Ketch to auto-generate certs for you; the name used should be the one you used when implementing your Kubernetes cluster-issuer.

** Also note that when creating a pool in Ketch, you will need to use the ingress service endpoint as part of the command and the ingress type. In our case, we are using Istio. You can find your ingress service endpoint by running the following command:

kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}’

With our pool created, we can now create our application, which will then be used to deploy our code. You can create the application by running the following command:

$ ketch app create podinfo –pool podinfo

Now that we have both our pool and application created, we can deploy our application. For the pod info, we will need to expose the following ports:

Ketch for Kubernetes PodInfo ports

To expose these ports, we will need to create a file called ketch.yaml, which will be used to deploy our application and dynamically provision these. Click here to download an example of the ketch.yaml file: https://github.com/brunoa19/podinfo/blob/main/ketch.yaml

With our ketch.yaml file in place, we can now deploy our podinfo application. To simplify the process, we can use the pre-built Docker image and the following command:

$ ketch app deploy podinfo -i stefanprodan/podinfo –ketch-yaml ketch.yaml

As part of the Kubernetes deployment process, Ketch will automatically create the endpoint for our podinfo application using the Istio ingress controller tied to our pool. You can find the application endpoint using the following command:

$ ketch app list

If we try accessing the address endpoint assigned by Ketch, we get the podinfo application UI:

PodInfo UI

If we try calling some API endpoints, we get this:

Ketch for Kubernetes API endpoints

And now, we have a much simpler and faster deployment of the podinfo application, and we shift the focus more and more to our application code rather than on Kubernetes related objects. 

Some might say, “but I have so much flexibility with Helm and wanted to customize some parameters, and Ketch can block me from being able to do that.” Not really! 

With the application deployed, Ketch can automatically generate a Helm chart for you to make any required customizations to your app, and speed up creating a Helm chart instead of doing it manually. You can do that by running the following command:

ketch app export podinfo -d helm

If we check the content of the folder, we can see that Ketch generated our application’s charts that we can leverage for any customization:

If we check the content of the folder, we can see that Ketch generated our application’s charts that we can leverage for any customization:

If you have control over your DNS and want to add a CNAME to the application deployed by Ketch, you can do that as well by using the following command:

ketch cname add podinfo-demo.theketch.io -a podinfo

With that, you can now access your podinfo using the CNAME defined.

With that, you can now access your podinfo using the CNAME defined.

In the next blog post, we will cover how to tie Ketch to your CI pipeline and have a complete workflow to deploy our podinfo application from Git all the way to our EKS clusters in a faster, dynamic, and more developer-friendly way.

Ketch Launch Announcement

Deploy cloud native applications to Kubernetes without a single YAML file

Read Here