Add the option to inject the integration container as a side car to another deployment

[hguerrero]

When deploying an application it would be good to have the integration running on the same pod using the sidecar pattern to avoid additional network trips. Currently, the camel k operator is deploying the result container on its own but would be good to have the possibility to have it running in the same pod as another deployment.

[astefanutti]

There is the pod trait that enables adding sidecar containers to the integration pod(s): https://camel.apache.org/camel-k/latest/traits/pod.html#_example.

It's not "injecting" the integration container into existing Deployment / pods, but I think that achieves the same result.

[hguerrero]

@astefanutti this is promising, is there more docs on how it should be configured?

[astefanutti]

@hguerrero it's rather an advanced feature, and the only documentation is available at https://camel.apache.org/camel-k/latest/traits/pod.html.

In essence, you can pass a template.yaml file with the --pod-template option, that contains your sidecar containers, e.g.:

$ kamel run --pod-template template.yaml

And these will be automatically injected / merged into the integration pod(s).

[tadayosi]

While it's nothing to do with sider car, if the whole concern is just additional network trips, you may also use Affinity trait: https://camel.apache.org/camel-k/latest/traits/affinity.html so that you can make sure the deployment and the integration are assigned to the same node.

[hguerrero]

@tadayosi I was looking more on being able to deploy my API gateways with a Camel integration doing some heavyweight transformation running as a sidecar as it would be a single deployment to manage. That's why I was looking to dynamically inject the integration (when updated/modified) back to the gateway deployment.

[astefanutti]

I realise the pod trait approach may not fit the use case where the Integration is not the "central unit", and you rather want to plug it into something more "central".

I haven't thought much about it, but I think it should be quite possible to add a new sidecar deployment strategy, that would reference the controller resource to inject the integration container into.

[hguerrero]

I realise the pod trait approach may not fit the use case where the Integration is not the "central unit", and you rather want to plug it into something more "central".

Correct @astefanutti in my case the gateway is the central deployment

I haven't thought much about it, but I think it should be quite possible to add a new sidecar deployment strategy, that would reference the controller resource to inject the integration container into.

This could allow to cluster several integrations in the same pod.

[github-actions[bot]]

This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!

[hguerrero]

Hi @astefanutti any update on the possible sidecar deployment strategy?

[astefanutti]

Hi @hguerrero no update yet. While the general idea seems clear, I realise that this could help if you have a pointer to a use case that you would want use to reuse / focus on, so as to make sure we are in line with what you have in mind.

[lburgazzoli]

IMHO one of the main use case it to have something that is similar to dapr rather than grouping integrations.

As example, the right integration is injected depending on an environment, abstracting the business logic from the platform so, on azure you may inject an Azure specific wrapper for their pub/sub buts, whereas on GCP you may want to inject a goggle specific one but for the business logic POV, it is always a RPC (REST, gRPC) call to a sidecar.

Given Camel's flexibility, I find the pattern very interesting and it is something we were looking at in the past.