Local development environment

If you plan on contributing to Camel K, you will end up needing to run and troubleshoot your operator code locally. Here is a guideline that will help you configure your local operator running.

you can also run and debug the operator as a local process: see Operator - local execution

Running a development operator

As soon as you build your operator locally you will ask yourself how to test it. In this space we propose a way to locally install and run your development Camel K operator as it was a "normal" installation.

Once you have done your development, you will need to build and push Camel K Operator container image to the container registry your Kubernetes is later going to use. If you’re on a local machine, you are probably using Minikube or Kind. In such case you can make your Docker daemon to use the cluster container registry. In Minikube it would be like the following:

eval $(minikube -p minikube docker-env)

For other cluster types you may check the specific documentation. As soon as you’re connected to the Docker daemon you can build images via:

make images

This command will build and publish your actual Camel K development version to the container registry. At this stage installing the Camel K development version will be as easy as a typical installation. We are supporting a series of makefile targets to let you easily install the operator on your local cluster in one single line. These targets are though to cover plain Kubernetes and Openshift cluster in either global (default in camel-k namespace) and namespaced (default in default namespace) installation:

make install-k8s-global (default in camel-k namespace)
make install-k8s-ns (default in default namespace)
make install-openshift-global (default in camel-k namespace)
make install-openshift-ns (default in default namespace)

Those targets may use two variables, NAMESPACE and REGISTRY in order to let you specify the namespace where to install the operator and the container registry to use. For instance:

NAMESPACE=test REGISTRY=1.2.3.4 make install-k8s-global

Will install a global operator in the test namespace with the registry located at IP 1.2.3.4. Mind that when you’re using Minikube, the target will be able to automatically detect any existing local registry and set it up for you. For more complex customization you’ll need to use the regular Kustomization installation procedure.

In order to uninstall the local operator you can also run make uninstall (will keep CRDs) and make uninstall-all (will remove CRDs and consequently any running Integration). You can use variable NAMESPACE as well if the operator was installed in a namespace different than default.

Local Camel K runtime

Camel K integrations are based on Camel K runtime, generally paired with the operator release. If you need to specify a different runtime, or you have a local Camel K Runtime that you want to test you need to build a Camel K version bundled with the local Camel K Runtime bits

make images CAMEL_K_RUNTIME_DIR=<path/to/local/ck-runtime/project>

Once this is done you need to re-install via make install-k8s-global.

Local Multiple Architecture

Since Camel K version 2 we’re introducing the support for multiple architecture. If you want to build your container image operator for a specific architecture, you can provide a parameter, IMAGE_ARCH. See the example:

IMAGE_ARCH=arm64 make images

With this configuration, you will build an ARM64 architecture container image that you can reference later as apache/camel-k:<version>-arm64.