Contexte
Apache Camel est un framework d’intégration open-source, développé par la Fondation Apache. Cet outil a comme philosophie de suivre les Enterprise Integration Patterns.
Le framework repose sur le principe de “routes”, ayant chacune une entrée et une ou plusieurs sorties. Ces entrées et sorties peuvent être très variées, allant du simple log dans la console à l’appel REST, en passant par de l’I/O SQL ou FTP. De nombreuses intégrations existent aussi avec les solutions issues du Cloud (AWS, Azure et GCP sont tous représentés).
C’est un outil très puissant, extrêmement polyvalent, supportant plusieurs DSL (principalement Java et XML).
Camel-K est une version spécifique de Camel qui s’exécute sur une plateforme Kubernetes. Outil tout-en-un, il robustifie les intégrations, facilite le déploiement multi-environnements et accélère le développement.
Dans un précédent article, nous expliquions comment mettre à jour depuis la version 1.X. Nous allons ici évoquer la mise à jour en 2.6+ qui invalide certains éléments existant dans le passé.
Pourquoi effectuer une installation multi-namespaces
Camel-K peut s’installer de deux façons différentes : en descoped, ou dans un namespace spécifique.
L’installation par défaut
La première option, descoped, installe Camel-K dans le namespace par défaut. Cela a comme grand inconvénient de causer des coupures de services lors de vos futures mises à jour.
Ainsi, lors d’une mise à jour “déscopée”, il faudra :
- Supprimer l’ancien opérateur (ce qui supprimera les routes).
- Installer le nouvel opérateur, recompiler les routes.
- En cas d’exposition, pointer vers les nouvelles routes.
Durant l’ensemble du processus, le service sera coupé.

Cette organisation n’est pas acceptable dans un environnement à forte disponibilité.
L’installation propre à un namespace
Pour réaliser des passages d’une version à l’autre, il est nécessaire de réaliser une installation ciblée et organisée en “espace de nommage” ou “namespace”. Chaque namespace porte une version unique et spécifique de Camel-K.
Pour réaliser cela, il convient de :
- Installer le nouvel opérateur dans un namespace dédié, par exemple kamel-2-6-0.
- Compiler les routes dans la nouvelle version de CamelK.
- Déployer les routes dans le namespace de la version.
- En cas d’exposition via un load-balancer (voir tout simplement un ingress k8s), modifier la configuration pour pointer vers les nouvelles routes.
- Supprimer progressivement les routes Camel-K. Elles sont exécutées en doubles, dans l’ancien et le nouveau namespace.
- Supprimer l’ancien namespace, par exemple kamel-2.1.0. Cela supprimera au passage l’ancien opérateur CamelK.

En suivant ce processus :
- La durée de coupure de service est réduite au strict minimum, voir inexistante.
- En cas de régression sur la nouvelle version, le retour arrière est possible et rapide.
- Plusieurs versions peuvent coexister, la migration des routes est maîtrisée et sans contrainte de temps.
Procédure d’installation multi-namespaces
La procédure d’installation qui suit décrit comment installer la version 2.6.0 dans un namespace. Elle est inspirée de la documentation Camel.
1. Clone local
La procédure d’installation est plus simple à effectuer comme suit. Dans un premier temps, nous souhaitons cloner le repository Camel-K afin de modifier et exécuter leur configuration.
# Clone du repo
git clone https://github.com/apache/camel-k.git
# Sélection du bon tag
cd camel-k && git checkout v2.6.0
2. Configuration de l’opérateur
Nous configurons :
- Le namespace. Chez nos clients, nous utilisons le format
kamel-{version}
par exemple, kamel-2.6.0 . - Les teintes, sélection de nœud, tolérance, …
Pour le namespace, c’est très simple, il vous suffit de modifier la ligne namespace
du fichier install/overlays/kubernetes/namespaced/kustomization.yaml
. Remplacez “default” par “kamel-2-6-0”.
Pour le reste, cela va dépendre de vos besoins.
Nous mettons à profit les nœuds Azure Spot pour leur faible coût. Pour que l’opérateur s’exécute sur un nœud Spot, modifiez le fichier install/overlays/kubernetes/namespaced/patch-toleration.yaml
comme suit :
apiVersion: apps/v1
kind: Deployment
metadata:
name: camel-k-operator
spec:
template:
spec:
tolerations:
- key: "kubernetes.azure.com/scalesetpriority"
operator: "Equal"
value: "spot"
effect: "NoSchedule"
Il faudra penser à décommenter la ligne faisant référence au patch dans kustomization.yaml
.
Une fois que vous êtes prêts, créez le namespace (kubectl create namespace kamel-2-6-0
), puis lancez:
kubectl apply -k install/overlays/kubernetes/namespaced --server-side
3. Installation de la plateforme d’Intégration
Désormais, votre opérateur est fonctionnel. Il vous faudra cependant aussi une plateforme d’intégration configurée avec un registre d’artefacts. C’est ce composant qui va permettre à l’opérateur de compiler les routes, et de les stocker dans le registre de container.
Il vous faudra un secret, à mettre dans le bon namespace. Voici la commande à effectuer :
SECRET_NAME="camelk-secret-itp" # La variable sert uniquement à améliorer la lisibilité
kubectl create secret docker-registry \
$SECRET_NAME \
--docker-username $REGISTRY_USER \
--docker-password $REGISTRY_PWD \
--docker-server $REGISTRY_ADDRESS \
--namespace kamel-2-6-0
De plus, une référence de déploiement sera requise. Dans un fichier, inscrivez :
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
labels:
app: camel-k
name: camel-k
namespace: kamel-2-6-0
spec:
build:
registry:
address: "<même chose que dans le secret plus haut>"
secret: camelk-secret-itp
insecure: false
Ça y est, vous pouvez faire un kubectl apply
sur ce fichier.
4. Supprimer l’ancienne version
Si votre ancienne version de Camel-K était elle aussi contenue dans un namespace, vous pouvez tout simplement effectuer
kubectl delete namespace <ancien_namespace>