Istio support

[stud0r]

Is your feature request related to a problem? Please describe.
Based on the reply from #1761, an istio environment is currently not supported.
The described workaround to disable istio for the testkube namespace requires to disable mTLS on each service within the kubernets cluster to be tested.

Describe the solution you'd like
The current issue we have is with the init-container, which requires accesses the s3 bucket. Within an istio setup in the init-container the istio-proxy is not yet ready and outgoing traffic to minIO is not possible.
Is it possible to have the components that access external services only as a "normal" container and not as an init-container?

[TheBrunoLopes]

Hey @stud0r thanks for opening this ticket. You have an interesting use case.
Pinging @dejanzele so he can take a look at this.

[ypoplavs]

Hello @stud0r,
Testkube doesn't explicitly talk to services in other namespaces so disabling mTLS in TK namespace only should be sufficient. Have you tried it?

[stud0r]

Hi @ypoplavs
If we disable istio in the TK namespace have to disable the strict mTLS in the target applications otherwise the connection fails.
I expect that this is also the same behavior with other service mesh like Linkerd

[ypoplavs]

Apparently, this is a known issue for Istio as per istio/istio#11130
There is a suggestion to run init-container as uid 1337:

securityContext:
  runAsUser: 1337

Could you please try this workaround? Job template can be adjusted using this approach:
https://kubeshop.github.io/testkube/using-testkube/tests/tests-creating#changing-the-default-job-template-used-for-test-execution

[TheBrunoLopes]

Hey @stud0r did the suggestion for @ypoplavs work for you ?
Closing this issue for now, let us know if this issue persists. We'll reopen it.