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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to