Kusk 0.2.0 released
Today the Kubeshop team released Kusk version 0.2.0 featuring Traefik V2 support, further improvements on x-kusk OpenAPI extension and bugfixes.
The list of supported Kubernetes Ingress controllers manifests generators now consists of:
- Ambassador 1.x
- Linkerd
- Nginx-ingress
- Traefik V2
with the plans to further add:
- Ambassador 2.x
- Gateway API
- Contour
One of the improvements is the initial support in the x-kusk OpenAPI extension to disable all paths with the possibility to specifically enable only selected ones — a great way to start developing without exposing paths not ready. Available for Nginx-Ingress and Ambassador so far, it is going to be enabled for all other generators as well.
You can see the full ChangeLog and grab the binaries from the Releases page.
If you are not aware of what is this all about — Kusk is a command-line tool that allows developers to use OpenAPI (Swagger) file as the source of truth when configuring external access to the deployed into Kubernetes application.
When software engineers create RESTful web services, such file is almost always crafted even before the first line of code is written.
It clearly defines the contract of the Web application with the external world and nudges you to design your API first.
Having such an approach allows the Backend and Frontend developers to write code independently and simultaneously.
Even more, it can help you to write the application faster — there are code generators that can produce server and client code for each described in the file endpoint.
You can generate an application skeleton and then write the business logic itself.
And if you are using Kubernetes to deploy the app (who doesn’t?), you will write Ingress to expose the application to the world.
Say, you have Nginx-ingress or Traefik installed as a load balancer, do you know how to write Ingress for it?
Let’s face it, Kubernetes is hard.
It was designed to automate containerized applications management and thus decrease operational expenses but created a whole new world to learn on the way.
Today application developers must study Kubernetes to be productive or face being stuck in the siloed teams when any change in API means passing the baton to DevOps team to deploy.
The process can be slow. And will DevOps team configure your Ingress right? Will you configure it right?
Let’s see the example, here we have a small OpenAPI file:
We have endpoint /books defined with operations.
How would one setup Traefik IngressRoute to support this definition with webapp deployed?
Looks right.
It will allow to develop new endpoints and not bother changing the Ingress, convenient, isn’t it?
Nope
We only want POST on /books and GET on /books/{id}.
What if we write /healthcheck or enable /actuator in SpringBoot application? We don’t want it to be accessible to the world!
Let’s try Kusk to generate all the things. Our webapp service is in booksapp namespace, so:
This looks much cleaner and secure. No top-level / is exposed, there is also an additional ServersTransport allows you to specify timeouts for the application.
There is a number of command line parameters supported, but they are limited. We can use x-kusk extension and provide all parameters in the file in top-level or even override some on path and operation level.
Let’s expose the API on /bookstore path, but strip it away for application.
And add CORS globally, but make it a bit different for /books/{id}.
And let’s disable posting to /books completely until we’ve fully developed it.
The result:
That’s a lot of YAML, but we’re all set.
And for even more convenience Kusk supports wizard mode, which allows you to connect to your cluster, detect the installed Ingress controller and guide you through all the steps.
So give it a try for your use cases, the team will gladly see your feedback and ideas on GitHub or Discord channel.
