Camel K

Camel K operator installation

Camel K allows us to run Camel integrations directly on a Kubernetes cluster. To use it, you need to be connected to a cloud environment or to a local cluster created for development purposes (ie, Minikube or Kind).

Installation via Kustomize

Kustomize provides a declarative approach to the configuration customization of a Camel-K installation. Kustomize works either with a standalone executable or as a built-in to kubectl. The /install directory provides a series of base and overlays configuration that you can use. You can create your own overlays or customize the one available in the repository to accommodate your need.

$ kubectl apply -k github.com/apache/camel-k/install/overlays/all-namespaces?ref=v2.11.0 --server-side

You can specify as ref parameter the version you’re willing to install (ie, v2.11.0). The command above will install a descoped (global) operator in the camel namespace. This is the suggested configuration in order to manage Integrations in all namespaces.

Installation via Helm Hub

Camel K is available in Helm Hub:

$ helm repo add camel-k https://apache.github.io/camel-k/charts/
$ helm install camel-k camel-k/camel-k -n camel

More instructions on the Camel K Helm page.

Installation via Operator Hub

Camel K is also available in Operator Hub. You will need the OLM framework to be properly installed in your cluster. More instructions on the Camel K Operator Hub page.

$ kubectl create -f https://operatorhub.io/install/camel-k.yaml

You can edit the Subscription custom resource, setting the channel you want to use. From Camel K version 2 onward, we’re going to provide an installation channel for each major version we’re releasing (ie, stable-v2). This will simplify the upgrade process if you choose to perform an automatic upgrade.

Some Kubernetes clusters such as Openshift may let you to perform the same operation from a GUI as well. Refer to the cluster instruction to learn how to perform such action from user interface.

Installation topology

When you decide to install the operator, you can decide to install the following topology:

Global operator: a single global operator watching all namespaces.
Own namespace operator: a namespaces operator watching its own namespace only.
Single namespace operator: an operator installed in a namespace and watching another namespace.
Multi namespace operator: an operator installed in a namespace and watching multiple namespaces.

The namespace(s) to watch is configured via WATCH_NAMESPACE variable in the operator Deployment resource. You can provide an empty value (watch all namespaces), a single value (watch either the own namespace or any other namespace) or a comma separated value (watching as many namespaces as provided).

It’s important to notice that when running the single or multiple namespace operator, you may need to provide the RBACs which are expected by the operator to run properly. For such a configuration you can take as a reference the Kustomize examples available in /install/overlays/single-namespace/ and /install/overlays/multi-namespace/. The last topology is probably the most secure as it will avoid the operator to access to any resource outside those namespaces for which you’ve provided the proper security rules.

RBAC custom configuration may vary depending on the installation methodology.

Install a multi namespace operator with Kustomize

The repository includes a complete Kustomize example for an operator installed in one namespace and watching two tenant namespaces. The multi-namespace overlay installs the operator in operators, configures WATCH_NAMESPACE to tenant-a,tenant-b, and grants the operator’s ServiceAccount the required namespaced permissions in both tenant namespaces. The operator also watches its own operators namespace for the resources it manages there.

The overlay does not create namespaces. Create the operator and tenant namespaces before applying it:

$ kubectl create namespace operators
$ kubectl create namespace tenant-a
$ kubectl create namespace tenant-b

Apply the overlay for the Camel K version you want to install:

$ kubectl apply -k github.com/apache/camel-k/install/overlays/multi-namespace?ref=v2.11.0 --server-side

The example creates the camel-k-operator-tenant-ab ServiceAccount in operators. Each tenant RoleBinding points to that ServiceAccount across namespaces, so the binding must be installed in every namespace listed in WATCH_NAMESPACE. Granting the operator access to only one tenant namespace will leave it unable to reconcile resources in the other namespaces.

Verify the deployment, watched namespaces, and cross-namespace RoleBinding:

$ kubectl -n operators get deployment camel-k-operator-tenant-ab
$ kubectl -n operators get deployment camel-k-operator-tenant-ab \
    -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="WATCH_NAMESPACE")].value}{"\n"}'
tenant-a,tenant-b
$ kubectl -n tenant-a get rolebinding camel-k-operator-tenant-a \
    -o jsonpath='{.subjects[0].namespace}/{.subjects[0].name}{"\n"}'
operators/camel-k-operator-tenant-ab

The overlay is a two-tenant example. To use different namespaces, copy the tenant-a-ns-rbac and tenant-b-ns-rbac overlay directories, change each namespace and nameSuffix, update the WATCH_NAMESPACE value in operator/patch-envvars.yaml, and add the new directories to the top-level kustomization.yaml. Keep the RoleBinding subject namespace set to operators (or change it together with the operator namespace) and keep its ServiceAccount name aligned with the operator Deployment.

Install a multi namespace operator with OLM

The Camel K ClusterServiceVersion supports the OLM MultiNamespace install mode. In this mode, the OperatorGroup selects the tenant namespaces and OLM creates the required namespaced RBAC for the operator ServiceAccount. The operator namespace is the namespace where the Subscription, OperatorGroup, and operator Deployment are installed.

Create the operator and tenant namespaces first:

$ kubectl create namespace operators
$ kubectl create namespace tenant-a
$ kubectl create namespace tenant-b

Create an OperatorGroup in the operator namespace. An OLM namespace can have only one OperatorGroup; edit the existing group instead of creating a second one when necessary:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: camel-k-multi
  namespace: operators
spec:
  targetNamespaces:
  - tenant-a
  - tenant-b

Apply the group, then create the Camel K subscription from OperatorHub:

$ kubectl apply -f operatorgroup.yaml
$ curl -fsSL https://operatorhub.io/install/camel-k.yaml | kubectl apply -f -

The OperatorHub manifest creates a Subscription in operators using the stable-v2 channel and the operatorhubio-catalog CatalogSource. If your cluster uses another catalog, keep the same MultiNamespace OperatorGroup and change the Subscription’s source and sourceNamespace to match that catalog.

Wait for the CSV to succeed and verify the selected namespaces:

$ kubectl -n operators get csv
$ kubectl -n operators get operatorgroup camel-k-multi \
    -o jsonpath='{.spec.targetNamespaces[*]}{"\n"}'
tenant-a tenant-b

The operator should now reconcile Integrations in both tenant-a and tenant-b, while an Integration in an unlisted namespace remains outside this OperatorGroup’s scope.

Install a multi namespace operator with Helm

The Helm chart currently exposes two watch modes: the release namespace (operator.global=false) and all namespaces (operator.global=true). It does not accept a static comma-separated namespace list. To run a Helm-installed operator for selected namespaces, install the chart in the operator namespace and apply a small RBAC overlay for every tenant namespace.

Install the chart using camel-k as the release name so the resource names below match the commands:

$ helm repo add camel-k https://apache.github.io/camel-k/charts/
$ helm repo update
$ kubectl create namespace operators
$ kubectl create namespace tenant-a
$ kubectl create namespace tenant-b
$ helm install camel-k camel-k/camel-k -n operators \
    --set operator.global=false \
    --set operator.env[0].name=REGISTRY_ADDRESS \
    --set operator.env[0].value=<my-registry-address>

Set the watched namespaces on the chart-created Deployment:

$ kubectl -n operators set env deployment/camel-k-operator \
    WATCH_NAMESPACE=tenant-a,tenant-b

The chart’s namespaced RBAC is scoped to operators. Create one small Kustomize overlay per tenant. You can use install/overlays/multi-namespace/tenant-a-ns-rbac/ and tenant-b-ns-rbac/ as templates, or use this equivalent overlay (replace <tenant-namespace> for each tenant):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: <tenant-namespace>
resources:
- github.com/apache/camel-k//pkg/resources/config/rbac/namespaced?ref=v{last-released-version}
patches:
- target:
    kind: RoleBinding
  patch: |-
    - op: add
      path: /subjects/0/namespace
      value: operators
    - op: replace
      path: /subjects/0/name
      value: camel-k-operator

The patch points every namespaced RoleBinding at operators/camel-k-operator, the ServiceAccount created by this Helm release. Save the overlay once for tenant-a and once for tenant-b, changing only namespace and the output directory.

Apply each tenant overlay after the Helm release:

$ kubectl apply -k ./camel-k-multi-namespace/tenant-a-ns-rbac --server-side
$ kubectl apply -k ./camel-k-multi-namespace/tenant-b-ns-rbac --server-side

Verify the Deployment setting and the cross-namespace permission before creating an Integration:

$ kubectl -n operators get deployment camel-k-operator \
    -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="WATCH_NAMESPACE")].value}{"\n"}'
tenant-a,tenant-b
$ kubectl auth can-i --as=system:serviceaccount:operators:camel-k-operator \
    -n tenant-a get integrations.camel.apache.org
yes

Repeat the Deployment patch and re-apply the tenant overlays after a Helm upgrade, or maintain them as a Helm post-renderer. This keeps the chart release and the manually managed tenant RBAC in sync.

Setup the operator configuration

Each installation method have its proper way to setup configuration. A common one is the creation of a Configmap named camel-k-operator-configmap-configuration and a Secret named camel-k-operator-secret-configuration in the same namespace where the operator is installed. If available, the operator will read the environment variable from these resources.

Verify that the operator is up and running

In order to verify that the operator is up and running, you should be able to see a Camel K operator Pod running in the namespace used, for example:

kubectl get pods -n camel
NAME                                READY   STATUS    RESTARTS   AGE
camel-k-operator-5b686db99f-c2k2s   1/1     Running   0          3m46s

Run some integration

Once you’ve completed any of the above installation procedure, you’ll be ready to run some integrations.

Special clusters requirements

Camel K installation is usually straightforward, but for certain cluster types you need to apply specific configuration settings before installing it. You need customized instructions for the following cluster types:

Development container registry configuration

Camel K needs a container registry in order to push the generated Camel applications and Kubernetes needs the same registry to pull and run them live. The project offers a default development container registry that will simplify quick starts, demo and testing. When running the project for the first time or in a local environment you shouldn’t worry as it will be completely transparent to you. The development registry is controlled through the following environment variables configuration:

Name Description Default Value

Name	Description	Default Value
ENABLE_DEV_REGISTRY	Run a demo container registry application in the same namespace as the Camel K Operator.	true
ENABLE_DEV_REGISTRY_SECRET	Whether to secure the demo container registry with a default test user (`admin/password`). In this case you need to provide a secret in the Integration namespace and use the `pull-secret` trait configuration. Be aware that the operator will store a secret named `ck-dev-registry` in the same namespace where it is installed. You may copy and use it in your Integration namespace for local development purposes.	false

ENABLE_DEV_REGISTRY

Run a demo container registry application in the same namespace as the Camel K Operator.

true

ENABLE_DEV_REGISTRY_SECRET

Whether to secure the demo container registry with a default test user (admin/password). In this case you need to provide a secret in the Integration namespace and use the pull-secret trait configuration. Be aware that the operator will store a secret named ck-dev-registry in the same namespace where it is installed. You may copy and use it in your Integration namespace for local development purposes.

false

When ready to move to a real enterprise installation you will need to turn the flag off (or remove it) and provide a proper production ready registry configuration.

if you don’t remove the ENABLE_DEV_REGISTRY parameter, the operator will overwrite any registry configuration at startup with its internal demo registry.

Fine Tuning

Camel K installation can be configured with certain special settings available for experienced users. You can manage resources such as limiting memory and CPU, provide a policy for Pod scheduling and Toleration. Please have a look at Camel K fine tuning to learn more about advanced configuration.