[GitHub] [camel-k] pierDipi commented on issue #4347: Support for Istio sidecar injection for Kamelets data plane

["pierDipi (via GitHub)" <gi...@apache.org>]

pierDipi commented on issue #4347:
URL: https://github.com/apache/camel-k/issues/4347#issuecomment-1541564607

   Hi @christophd, the way Istio proxy works is that when the application, in this case the Kamelet data plane, connects to external systems or gets new requests from external systems, it intercept the traffic and applies some logic based on how it is configured.
   
   For example, when the Kamelet data plane, will try to send events to the injected `K_SINK` URL using HTTP (as you're currently doing), depending on how Istio is configured, it will automatically establish an mTLS connection to the `K_SINK` URL pod.
   
   In practice this means that most Kamelets will continue to have injected the same `K_SINK` env variable they are using today and istio will automatically handle the rest, which means that the `K_SINK` URL _won't_ point to the localhost of the sidecar but it will point to the actual sink URL (just like currently).
   
   ---
   
   Given the above, the challenge is when connecting to systems that are not part of the mesh, for example, using the example above for telegram (https://github.com/apache/camel-k/issues/4347#issuecomment-1539775521), the Kamelet data plane might need to be configured in a way that Istio knows how to:
   - connect to telegram 
   - connect to the sink
   
   In our case, Istio knows how to connect to the sink because it's part of the service mesh, but it doesn't (always) know how to connect to telegram so it might need to be configured in a way that allows the Kamelet data plane to connect to telegram, for example using https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/
   
   While this second problem exists and the solution really depends on the specific Kamelet, given the Kamelet nature of connecting different systems, I see the proxy injection as the first problem to solve.
   
   This second problem also a highlight the level of effort for implementing the @lburgazzoli point:
   > We could also think to add some native support for istio/service-mesh in camel-k
   
   since an ideal native integration would require not only the proxy injection but also creating additional Istio resources based on the specific Kamelet.
   
   Hope this helps!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org