Ketch is a very new open source project by Shipa that shares a similar concept with the Shipa DNA.
Ketch is heavily focused on easing out application deployments for developers, aiming for a situation where a developer does not have to write any YAML configuration files, and can directly deploy their application on any Kubernetes cluster.
In this post we will go through Ketch Concepts and then deploy an application to a managed k3s cluster on Civo.
if you prefer a video walkthrough, we've also uploaded a hands-on guide over at our YouTube channel.
The official definition of Ketch from Shipa is "an application delivery framework that facilitates the deployment and management of applications on Kubernetes using a simple command line interface. No YAML required!"
This simply means that you can deploy applications onto any Kubernetes cluster by just using the Ketch CLI. But there is much more!
Kubernetes has become the de facto standard for deploying microservices and containerized applications, but there is a learning curve for a developer to get familiar with Kubernetes concepts, Kubernetes objects, how to write the required YAML files, and then how to create and manage them. These issues are there for any organization, big or small, as Kubernetes itself is complex and requires a lot of knowledge to get up and running. Ketch works toward solving these issues by eliminating the need for writing YAML files and directly deploying applications onto a cluster.
The above image is from the Ketch documentation, and displays the architecture overview. Inside our cluster, we have a Ketch Controller, custom resource definitions (CRD) for the Pool and App, and an Ingress controller.
Pool CRD - It's basically used to isolate different applications deployed. Each pool created will configure a namespace and other components onto the cluster.
App CRD - Provides App context to applications and is responsible for running the application and managing its lifecycle.
Ketch Controller - Monitors the changes that happen in the Pool and App CRDs. Ketch can also create a complete Helm chart for the application which can be used in different ways.
Ingress Controllers - As of the writing of this guide, Ketch supports Traefik and Istio.
- A Kubernetes cluster you control. We'll take advantage of Civo's super-fast managed k3s service to experiment with this quickly. If you don't yet have an account, sign up to the beta now to take advantage of quick deploy times and $70 free credit per month! Alternatively, you could also use any other Kubernetes cluster.
- kubectl installed, and the
kubeconfigfile for your cluster downloaded.
Make sure you can connect to your Kubernetes cluster by running
kubectl get nodes
You should see the names of the nodes in your cluster displayed.
First the Ketch Binary has to be downloaded in order to deploy the application to our Kubernetes cluster. In this case I am installing Ketch CLI on my Mac:
$ curl -s https://raw.githubusercontent.com/shipa-corp/ketch/main/install.sh | bash Downloading Ketch binary from https://github.com/shipa-corp/ketch/releases/download/v0.1.0/ketch-darwin-amd64 to /usr/local/bin/ketch Ketch client installation was successful $ ketch -v ketch version 0.1.0
As of the writing of this guide, Ketch supports two ingress controllers, Traefik and Istio, with a plan to add more in the future. By default k3s comes with Traefik Ingress controller, which you can check using the following commands that show the pods that should include your Traefik pods, as well as the running service to manage traffic:
$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system metrics-server-7566d596c8-ks9ss 1/1 Running 0 5m45s kube-system local-path-provisioner-6d59f47c7-d74ng 1/1 Running 0 5m45s kube-system helm-install-traefik-fwr9s 0/1 Completed 0 5m45s kube-system svclb-traefik-886fk 2/2 Running 0 5m27s kube-system coredns-8655855d6-zzr8z 1/1 Running 0 5m45s kube-system traefik-758cd5fc85-2jf57 1/1 Running 0 5m27s kube-system svclb-traefik-lz8bl 2/2 Running 0 4m59s kube-system svclb-traefik-xz2r7 2/2 Running 0 4m51s $ kubectl get svc -A | grep traefik kube-system traefik-prometheus ClusterIP 192.168.219.19 <none> 9100/TCP 6m18s kube-system traefik LoadBalancer 192.168.145.176 22.214.171.124 80:32596/TCP,443:30706/TCP 6m18s
You can see that Traefik comes pre-installed when you spin up a k3s cluster on Civo, and serves up an external IP address.
Note - If you are using a different Kubernetes cluster make sure you install Traefik or Istio from here.
Ketch Requires a certificate manager to be installed onto the cluster. This can be installed via the Civo Marketplace, either on the web on your cluster management page, or with Civo CLI.
# Installing cert-manager via civo cli, to our cluster called "ketch" civo kubernetes applications add cert-manager --cluster=ketch
If you are using a different or self-hosted Kubernetes cluster, you can install cert-manager by using the below command:
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.yaml
Whichever option you choose, check that cert-manager is running:
kubectl get pods -n cert-manager NAME READY STATUS RESTARTS AGE cert-manager-cainjector-6d5dfbc779-jsrpj 1/1 Running 0 103s cert-manager-68d4985c5d-v6fw9 1/1 Running 0 103s cert-manager-webhook-59fccfc69b-xjwjt 1/1 Running 0 103s
As we have seen in the Architecture section, our cluster will need a Ketch Controller that will be creating and watching the Pool CRD and App CRD.
$ kubectl apply -f https://github.com/shipa-corp/ketch/releases/download/v0.1.0/ketch-controller.yaml namespace/ketch-system created customresourcedefinition.apiextensions.k8s.io/apps.theketch.io created customresourcedefinition.apiextensions.k8s.io/pools.theketch.io created role.rbac.authorization.k8s.io/ketch-leader-election-role created clusterrole.rbac.authorization.k8s.io/ketch-manager-role created clusterrole.rbac.authorization.k8s.io/ketch-proxy-role created clusterrole.rbac.authorization.k8s.io/ketch-metrics-reader created rolebinding.rbac.authorization.k8s.io/ketch-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/ketch-manager-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/ketch-proxy-rolebinding created service/ketch-controller-manager-metrics-service created service/ketch-webhook-service created deployment.apps/ketch-controller-manager created certificate.cert-manager.io/ketch-serving-cert created issuer.cert-manager.io/ketch-selfsigned-issuer created mutatingwebhookconfiguration.admissionregistration.k8s.io/ketch-mutating-webhook-configuration created validatingwebhookconfiguration.admissionregistration.k8s.io/ketch-validating-webhook-configuration created
Before deploying an app you need to create a Ketch pool. This is where we will need the external IP address of our ingress. We will get it by checking our Traefik service:
$ kubectl get svc -A | grep traefik kube-system traefik-prometheus ClusterIP 192.168.219.19 <none> 9100/TCP 93m kube-system traefik LoadBalancer 192.168.145.176 126.96.36.199 80:32596/TCP,443:30706/TCP 93m
Then, we run
ketch pool to add our pool:
$ ketch pool add saiyam --ingress-service-endpoint 188.8.131.52 --ingress-type traefik Successfully added!
Running the above created a new namespace
$ ketch pool list NAME STATUS NAMESPACE INGRESS TYPE INGRESS CLASS NAME CLUSTER ISSUER APPS saiyam Created ketch-saiyam traefik 0 $ kubectl get ns | grep saiyam NAME STATUS AGE ketch-saiyam Active 20s
As of now there are 0 apps in the pool, so let's create an application
$ ketch app create demo --pool saiyam $ ketch app list NAME POOL UNITS ADDRESSES DESCRIPTION hello saiyam 0 http://demo.184.108.40.206.shipa.cloud $ ketch pool list NAME STATUS NAMESPACE INGRESS TYPE INGRESS CLASS NAME CLUSTER ISSUER APPS saiyam Created ketch-saiyam traefik 1
You can see that the App has 0 units as we have not deployed any app but just by creating the app, it created the endpoint automatically.
Now let's actually deploy an image onto the k3s cluster.
$ ketch app deploy demo -i docker.io/saiyam911/ketch-demo Successfully deployed! $ ketch app list NAME POOL UNITS ADDRESSES DESCRIPTION demo saiyam 1 http://demo.220.127.116.11.shipa.cloud
The application has been deployed successfully from the image provided. If we visit the address provided by the
ketch app list command above, we should see the following:
Behind the scenes, Ketch has created a deployment and other Kubernetes objects to expose the application. Additionally, Ketch can export your application as a helm chart which can be used to distribute your application. This is a really cool feature in my opinion, which will be discussed in more detail below.
There is an option to customize the file using
ketch.yaml and a
Procfile. It looks like below:
kubernetes: processes: web: ports: - name: apache-http # an optional name for the port protocol: TCP port: 80 # The port that is going to be exposed on the router. target_port: 9999 # The port on which the application listens on. worker: ports: - name: http protocol: TCP port: 80 worker-2: ports: 
The Ketch documentation has much more information on Application management - https://learn.theketch.io/docs/application-management.
You can add the CNAME of your choice and it gets added to the application - another handy feature:
$ ketch cname add ketch.b84abe49-7e01-4c64-8dcb-3c7cde73947f.k8s.civo.com -a demo $ ketch app list NAME POOL UNITS ADDRESSES DESCRIPTION demo saiyam 1 http://demo.18.104.22.168.shipa.cloud http://ketch.b84abe49-7e01-4c64-8dcb-3c7cde73947f.k8s.civo.com
You will now be able to visit the defined CNAME url and have the application served to you:
As mentioned above, you can export your application as a Helm chart which is really cool!
$ ketch app export demo -d /Users/saiyampathak/ Successfully exported! $ ls Chart.yaml templates values.yaml templates $ ls -ltr -rw-r--r-- 1 saiyampathak app 3361 Nov 26 14:24 deployment.yaml -rw-r--r-- 1 saiyampathak app 2513 Nov 26 14:24 ingress.yaml -rw-r--r-- 1 saiyampathak app 1020 Nov 26 14:24 service.yaml
With this you can push these files to a Git repository and make changes as required, and you can also export a commonly-used Application as Helm charts for others to use. A really cool feature in my opinion.
Overall Ketch is a good product trying to solve a common problem, and as it's open source, the wider community can get involved and create issues, suggestions for features they'd like to see, and raise pull requests to make it more valuable for the end user.
I personally would like to see some options that I can configure before deploying an application, maybe via the CLI, or possbly a minimal UI. If in the future we can have the application YAML generated even before the app gets deployed, it would be even cooler.