Running operator as a local process
If you need a finer control on the operator process (ie, attaching a debugger or quickly building and running the operator locally), then you can run and debug the operator binary locally. The idea is that you execute it on your machine and instruct the local process to watch a namespace on a Kubernetes cluster (it may be remote or any local environment).
if you need a simpler approach you can build and run the operator on a connected cluster (local or remote): see Local development |
Let’s use a namespace called `operator-test.
You can start with setting the environment variable WATCH_NAMESPACE
with the namespace you’d like your operator to watch. You also need to specify the name of the operator, as you may have different operators running on the cluster.
export WATCH_NAMESPACE=operator-test
export OPERATOR_ID="camel-k-dev"
The next step is to install an IntegrationPlatform
on the cluster namespace. You probably need to tweak the registry parameters in order to be able to authenticate against an image repository (see below paragraph for local repository instructions). It’s important to specify the target operator that will take care of this IntegrationPlatform (-x
or --operator-id
option).
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
annotations:
camel.apache.org/operator.id: camel-k-dev
name: camel-k
namespace: operator-test
spec:
build:
registry:
address: my-registry:5000
insecure: true
Finally, assuming you’ve built your application correctly we can run the operator:
./kamel operator
Test the local operator by creating a test Integration
:
./kamel run xyz.abc -n operator-test -x camel-k-dev
make sure no other Camel K Operators are watching this namespace, neither you have a global Camel K Operator installed on your cluster. As you may have more than one Camel K operator installed on the cluster, it’s important you specify the -x (or --operator-id ) option. |
Local operator and local cluster
If you want to run a local operator togheter with Minikube
you will need an additional step in order to let the local operator push images in the local registry. We need to expose the local registry as described in this procedure:
Enable the addon registry (this should be already in place):
minikube addons enable registry
Get the Pod
name that is in charge to run the registry and proxy the registry 5000 port to be used locally.
kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE ... registry-fttbv 1/1 Running 40 89d ... kubectl port-forward --namespace kube-system registry-fttbv 5000:5000
Update the IntegrationPlatform
to instruct it to use the localhost
registry:
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
annotations:
camel.apache.org/operator.id: camel-k-dev
name: camel-k
namespace: operator-test
spec:
build:
registry:
address: localhost:5000
insecure: true
A similar procedure may work if you use other local environments. The idea is to expose the docker registry and be able to use it from your local operator.
using build strategy as Pod won’t probably work as it will expect the registry to be available at a URL not possible to reach from a local machine. |
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, then you will need to specify it in the Integration Platform
:
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
annotations:
camel.apache.org/operator.id: camel-k-dev
name: camel-k
namespace: operator-test
spec:
build:
registry:
address: localhost:5000
insecure: true
runtimeVersion: <my-version>
The <my-version> variable must be replaced with the version you are building. For example, 1.3.1-SNAPSHOT
. With these instructions, the operator will pick up and use the snapshot version you have released locally. In order to use the local maven repository, you will also need to edit your IntegrationPlatform as follow:
$ kubectl edit ip -n operator-test ... spec: build: maven: cliOptions: - -V localRepository: /home/user/.m2/repository settings: {} ...
pointing the localRepository
where your local maven is storing the artifacts (it will look for the camel-k-runtime dependencies there).
Alternatively, if no local registry is available, you can use another type of registry as explained in the Registry section.