Deploying Under Pressure: Our First Real-World Use of KubeKanvas

A few weeks ago, an old customer reached out to me with an urgent request. They needed to demo their software — the one we had built for them quite some time ago — in a dedicated, isolated environment. It wasn’t just any demo. It was for a large potential customer, and the representative was eager to showcase it to his superiors.

There was just one problem. Well, actually three:

1. We hadn’t touched the codebase in several months.
2. The application was running on Kubernetes, but the YAML files were outdated and loosely maintained.
3. Time was short — very short.

The customer needed our help, and we had to decide quickly whether to take on the task. Given the urgency and the potential business impact for them, we agreed to give it a try — fully aware that it might turn into a late-night troubleshooting session.

Taking the KubeKanvas Route

We decided to rely on KubeKanvas to speed things up. It seemed like a good test for the tool in a real-world, high-pressure scenario.

We began by exporting the current resources from the running Kubernetes cluster and importing them into a new KubeKanvas project. As expected, a few things were missing: some connections between components hadn’t been defined clearly in the YAML, and certain ConfigMaps were nowhere to be found — likely never exported when the initial setup was done.

Manually connecting the missing pieces in the canvas was simple. A few drag-and-drop actions later, the visual representation started to reflect the actual system. We retrieved the missing ConfigMaps from the live cluster and brought them into the project. While doing this, we encountered a couple of small bugs in KubeKanvas. Fortunately, since I was working on the product myself, I was able to fix them on the spot.

The moment of truth came when I clicked the Deploy button and watched the release status.

Not surprisingly, the deployment failed at first — but the errors were minor and easy to fix. Being able to troubleshoot and retry right from the browser made the process remarkably smooth. After a few iterations, I saw the green status appear on the screen. That moment brought both relief and confidence.

Polishing the Setup

With a working version running locally, I decided to make some improvements. One of the services was named xlsconverterservice, which I renamed to xlsconverter-service to match common naming conventions and improve readability. I also moved several stray environment variables into a ConfigMap — not strictly necessary, but it made things tidier and easier to manage. Following is similar to what we had at this point

Next, I created a new cluster on the cloud provider and connected it with KubeKanvas. I deployed the updated setup, and once again, the green status appeared on the first try.

I opened the application in the browser… and it didn’t load.

The Ingress Hurdle

The Ingress was defined, but it wasn’t routing any traffic. After checking the cluster, I noticed that the default ingress controller was stuck in a Pending state. All its components appeared healthy, but something wasn’t working.

To avoid wasting time, I installed nginx as an alternative ingress controller and updated the annotations accordingly. That helped move things forward. The application became accessible — at least from the IP.

I then created a DNS entry and waited for it to propagate. The application loaded, but TLS wasn’t working. Cert-manager was misbehaving and seemed stuck in a strange state. I tried several steps — reinstalling the release, restarting pods, and cleaning up resources. Eventually, something clicked (I'm still not sure which change did the trick), and TLS started working.

I sent the customer the URL. He was able to log in. It was 2:00 a.m. when I finally closed the laptop, glad that we’d made it work.

One Last Detail

The next morning, the customer reported that the XLS files weren’t converting. I opened the KubeKanvas diagram again and compared it with the logs.

It didn’t take long to find the issue: a service was still being referred to as xlsconverterservice in the logs, but in our updated setup it was now called xlsconverter-service.

A simple name mismatch — easy to fix once spotted.

After correcting the service name and redeploying, everything worked as expected.

Reflections

The experience was both intense and rewarding. We were able to respond to a high-pressure request, with limited preparation time and an outdated setup, and still deliver a working solution — all using KubeKanvas.

This wasn’t just a test of functionality. It was a real use case where visual editing, rapid iteration, and integrated deployment made a measurable difference.

What I appreciated most was the ability to:

• Import existing configurations and visually inspect what was missing
• Make changes quickly without hunting through dozens of YAML files
• Iterate and deploy straight from the browser
• Catch errors early and fix them without leaving the tool

The result? A happy customer, a successful demo, and a strong proof of what KubeKanvas can offer in real-world scenarios.