feat(deploy): enable deployment to local kubernetes clusters

[terryvel]

This PR adds support for deploying Camel integrations to a local Kubernetes cluster, in addition to the existing OpenShift deployment.

A new option is now available when triggering the "Deploy" command, allowing users to select the desired target platform:

• OpenShift (default behavior)
• Kubernetes (new)

If Kubernetes deployment is selected (either through a prompt or via VS Code Settings), the extension now generates a ShellExecution to run:

kamel run

This enables Kubernetes users (especially those working with Minikube, Kind, K3d, or other local clusters) to deploy and test integrations directly from the Kaoto VS Code extension.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lordrip]

Hi @terryvel, thank you for your contribution, we're gonna check it out as soon as possible. In the meantime, and just as a curiosity, are you using one of the "local" versions of k8s? If so, which one?

Thanks once again 🙏

[terryvel]

Hi @terryvel, thank you for your contribution, we're gonna check it out as soon as possible. In the meantime, and just as a curiosity, are you using one of the "local" versions of k8s? If so, which one?

Thanks once again 🙏

Hi!

I tested it using Kubernetes on Docker Desktop.

If there’s any expectation or recommendation to use a different Kubernetes setup, I’m absolutely open to install and test it as well — as long as it’s an open and accessible option.

Thanks again for taking the time to review the contribution!

[lordrip]

Hi @terryvel, I tried the PR locally and here's what I found:

This PR uses kamel as the CLI to run the integrations in k8s, but that's the CamelK CLI. It's a bit complicated for us to test and maintain 2 different CLIs, one for Camel and the CamelK.

There's a kubernetes plugin for the Camel CLI. Would you be open to using that plugin instead? I would need to double-check all the parameters to understand if it would be a 1:1 functionality-based comparison, but the advantage would be that it's the same CLI for both areas.

Onto another topic, I like having the setting defined, but I wonder if saving it directly after selecting it is a bit excessive. How do you feel about reorganizing the setting to be instead:
a. Ask
b. OpenShift
c. Kubernetes
Alternatively, we could use these values from the kubernetes run command

a. Ask
b. Kubernetes
c. OpenShift
d. Kind
e. k3s
f. minikube

Then there's no need to save the setting after selecting it while keeping the decision to the user or even to the project, as we could save this setting in the settings.json file on a project basis.

@djelinek, please feel free to also jump in and share your ideas.

[djelinek]

Hello! First of all, thank you for taking the time to make this contribution! 🙏🚀

I actually have the same observation as Ricardo mentioned.

1. Using the Camel K CLI (kamel), instead of the Camel JBang Kubernetes plugin.
   Here, I believe we can migrate to using:
   camel kubernetes run <file> --cluster-type=kind/minikube/openshift
   See: https://camel.apache.org/manual/camel-jbang-kubernetes.html#_kubernetes_export

--cluster-type The target cluster type. Special configurations may be applied to different cluster types, such as Kind or Minikube.

2. Using prompt selection as the default user setting for next time — In the first iteration, we can allow the user to select each time or predefine using his global/workspace extension settings. In an upcoming iteration, it could be beneficial to present a cache mechanism for these kinds of prompt steps. This could be handled using workspace context states, for example.

Overall, I like the idea. You've actually nailed it because it was on our to-do list as well. There will be an opportunity to implement a similar prompt step in the "Export to Maven Project" feature.

Thank you once again, and if there's anything I can help with, just let me know.

[terryvel]

Hi everyone, thanks a lot for the review and suggestions.

I wasn’t aware of the Camel JBang Kubernetes plugin before this discussion. After installing it, all I had to do was adjust the Kaoto plugin configuration to use:

--cluster-type=kubernetes --image-registry localhost:5001

and everything worked perfectly.

Given that, I really appreciate the time and feedback from you all, and it made me wonder whether it actually makes sense to introduce any changes to the current UI at this point. Do you see real value in prompting the user to explicitly select the cluster-type, or would relying on configuration / defaults be sufficient?

Happy to adapt the approach based on your guidance.

[lordrip]

Hi @terryvel, we're happy it worked for you 👌 and even more happy you took the time to put this PR together.

In the team, we were thinking that even if we prefer not moving forward with the kamel CLI bit, there's value in the remaining approach of asking the user what type of container orchestration service to use.

Here's a rough idea about what I mean:

1. Create a new setting to determine the cluster type:
   a. ask (default)
   b. OpenShift
   c. Kubernetes
   d. the remaining values

2. Since the default is ask, when the user triggers the deployment, we provide a list of the available container platforms.

3. We append that selection to the argument list

We won't need to save the setting automatically, since it's exposed through the VS Code settings page.

What do you think about this?

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud