search

grafana / k6-operator

An operator for running distributed k6 tests.
Apache License 2.0
541 stars 147 forks source link

Preserve background process from initContainers to runner #394

Open robooo opened 2 months ago

robooo commented 2 months ago

Feature Description

My current deployment requires to do vpn connections which are done by executing a process in the background e.g. ./scripts/vpn &. If I don't execute it in background then k6 pod is waiting forever. I'm not able to change the connection approach/logic.

I hoped initContainers can help me, like I can setup the interface and other commands but can't keep alive the background process for k6 execution.

Suggested Solution (optional)

I'm not sure if allowing shareProcessNamespace: true would solve this? Based on this https://stackoverflow.com/questions/65576193/how-to-keep-a-process-running-throughout-pod-lifecycle

If there is some easier way please let me know.

Already existing or connected issues / PRs (optional)

No response

yorugac commented 2 months ago

Hi @robooo, thanks for opening the issue!

This is an interesting case. AFAIS, shareProcessNamespace is more meant to help with debugging. So IMHO, your case sounds like it requires another regular container instead of initContainer (docs).

This never came up before and there is an argument to be made that k6 container in the runner pod shouldn't have any other containers in order to avoid skewing results of the test.

I'm not able to change the connection approach/logic.

Out of curiosity, why is it not possible? I.e. "normally", Kubernetes access can be set up so that one won't need to run custom VPN scripts inside.

robooo commented 2 months ago

Thanks @yorugac! I understand, but I don't want to create some new "proxy pod" with installed binaries and running vpn and then route k6 via it, since it can be a bottleneck. Or are there some recommended deployment examples in case of using vpn + k6?

I just really want to execute the binaries before k6 run to be able to access the backend and route the traffic via it. The init container was the first approach which I've tried and yesterday I found another way with xk6-exec which allowed me to execute the vpn binary right from the test case (in the k6 container) after few tweaks I'm able to run it in the background too. But wouldn't it be easier to allow command for k6 runner or something similar?

yorugac commented 2 months ago

I found another way with xk6-exec which allowed me to execute the vpn binary right from the test case (in the k6 container) after few tweaks I'm able to run it in the background too

This is a good workaround :+1: Thanks for sharing, @robooo!

Or are there some recommended deployment examples in case of using vpn + k6?

Not really, AFAIK... In your use case, there's a restriction that you have to run this script "manually" before k6 execution. I imagine usually people make their Kubernetes setup for k6-operator without such internal restrictions. Why do you need VPN inside Kubernetes cluster? Or is it that you're trying to test some service outside of Kubernetes cluster that is reachable only via VPN? Some details would really help here.

yorugac commented 2 months ago

This topic actually reminded of multi-cluster problem and related projects, like this one.

robooo commented 2 months ago

@yorugac exactly! I'm trying to test/reach webserver from outside of Kubernetes cluster that is reachable only via VPN. It is no openvpn or something opensourced but more internal. The next step will be execute it from a different cluster in cloud not from local private server but I think the approach needs to be the same.