Configuring Registry

Every Camel K installation needs a container registry that will be used to host integration container images. This is required to host the images that will be used by Kubernetes to execute the Camel application you’ve built.

Container registry in action

The Camel K operator is in charge to build a Camel application and to "containerize" it, storing the result into a container registry. The same registry is used by the cluster to run the Camel application. Basically the operator push the image and the cluster pull it from the same source.

For the reason above it’s important that you provide a container registry which is accessible from both the operator Pod and the cluster internal mechanisms. However, a default registry is present in certain platforms such as Minikube, Openshift or Docker Desktop.

For any other platform that do not provide a default container registry, then, a registry must be provided accordingly.

Configure the registry at installation time

Registry configuration can be set upon installation using command:

$ kamel install --registry registry-host.io [--organization your-user-id-or-org] [--registry-secret my-secret-registry-conf]

Although optionals, the organization and registry-secret parameters are strongly suggested in order to secure the pull/push operations on a registry that is private, although accessible through the Internet. The secret is something that will included at deployment time as imagePullSecret configuration.

As each registry may have a slightly different way of securing the access you can use the guidelines provided in Docker Hub registry configuration and adjust accordingly.

Configure the registry after installation

The settings you’ve provided in the chapter above are applied to the IntegrationPlatform custom resource. In particular you can find them in the .spec.pipeline.registry.

apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
  labels:
    app: camel-k
  name: camel-k
spec:
  build:
    registry:
      address: registry-host.io
      organization: your-user-id-or-org
      secret: my-secret-registry-conf

You can therefore update the values in the IntegrationPlatform in order to perform any change to the registry configuration after the Camel K operator is installed. The changes will be immediately reconciled and ready to use.

Container registry requirements

Each platform may have its default registry of choice. And each container registry may have a slight different configuration. Please, be aware that we won’t be able to support all the available solutions.

The only requirement we have is that the registry must be able to produce/consume images with the following tagging convention: <registry-host>[:<registry-port>]/<k8s-namespace>/kit-<hash-code>@sha256:<sha256-code>, ie 10.110.251.124/default/kit-ck0612dahvgs73ffe5g0@sha256:3c9589dd093b689aee6bf5c2d35aa1fce9d0e76d5bb7da8b61d87e7a1ed6f36a.

This should be within the standard convention adopted by pulling a Docker image by digest (immutable).

you can configure Camel K to use an insecure private registry. However, your Kubernetes cluster may not be able to pull images from an insecure registry without proper configuration.

Special container registry requirements

We have some hints that can help you configuring on the most common platforms:

Run your own container registry

You can also run your own registry, but this option is recommended only for advanced use cases as it may requires certain changes in the cluster configuration, so, make sure to understand how each change may affect your cluster. As you’ve seen in the diagram above, the cluster has to be aware of the presence of the registry in order to pull the images pushed by the operator.

Pruning unused images from container registry

Over time, while building integrations the produced images are stored in the container registry and it may become outdated and may require pruning old unused images.

Each container registry vendor can provide unique details about the pruning policy, check your vendor documentation.
This is an unsupported functionality, use at your own risk.

It’s recommended only to delete container images from container registry if the corresponding Integration or IntegrationKit doesn’t exist anymore or has no expectation to be used. Then if you delete the container image, you should also delete corresponding Integrationkit custom resource object.

Camel K materializes the Camel integration in one of the two kubernetes objects: Deployment or CronJob.

You have to check if the Integration is running or scaled down to zero pods, which is the case for CronJobs or Knative deployments.

Then, we can provide some general guide about how to inspect the Camel K objects to prune unused images.

For this guide, we assume you are connected to the container registry with docker login.

Step 1: List all Camel K container images, prefixed with camel-k

$ docker images |grep k-kit
10.98.248.245/camel-k/camel-k-kit-cpth0mtf799b89lheon0  <none>  bd52ae6e32af   54 years ago    481MB
10.98.248.245/camel-k/camel-k-kit-cptguntf799b89lheok0  <none>  b7f347193b3c   54 years ago    471MB
10.98.248.245/camel-k/camel-k-kit-cptgv0tf799b89lheokg  <none>  8d2d963396ca   54 years ago    477MB
10.98.248.245/camel-k/camel-k-kit-cpth0mtf799b89lheomg  <none>  dc11800ef203   54 years ago    481MB
10.98.248.245/camel-k/camel-k-kit-cptgvd5f799b89lheol0  <none>  0bbdf20f2f49   54 years ago    479MB

Step 2: List the container images of the Camel K Integrations (don’t print the sha256 digest)

$ kubectl get -A it -oyaml|grep 'image:'|sed 's/^\s*image: //g;s/@sha256.*//g'|sort|uniq
10.98.248.245/camel-k/camel-k-kit-cptguntf799b89lheok0
10.98.248.245/camel-k/camel-k-kit-cptgv0tf799b89lheokg
10.98.248.245/camel-k/camel-k-kit-cptgvd5f799b89lheol0
10.98.248.245/camel-k/camel-k-kit-cpth0mtf799b89lheon0

Step 3: Compare them and remove the container images and IntegrationKit from list 1 not found in list 2

docker rmi dc11800ef203
kubectl delete ik/kit-cpth0mtf799b89lheomg

There is a prune-camel-k-kit-images.sh script to help you in this task. This script requires the following cli tools: kubectl, comm, docker. The script lists the dangling images from the container registry, it accepts two parameters with no arguments: -v (verbose) and -p (prune images).

An example of an execution:

$ prune-camel-k-kit-images.sh -p
> Images from container registry, eligible for pruning.
10.98.248.245/camel-k/camel-k-kit-cpth0mtf799b89lheom0

> Delete Container Images
integrationkit.camel.apache.org "kit-cpth0mtf799b89lheom0" deleted
Untagged: 10.98.248.245/camel-k/camel-k-kit-cpth0mtf799b89lheom0@sha256:3857f8e331e50ded6529641e668de8781eb3cb7b881ea14b89cfc4f6b6e9d455
Deleted: sha256:1015a6b18f164e9b086337e69a98e5850149c158cb778bac6059984756dc0528
Deleted: sha256:2f0d224916e77654c4401f6fc4b1147a9a6e3ccf713213c38e877d7b939bab81
Back to top