You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wouldn't say that k6's scalability is based on docker and I can't find where we claim that in the docs, but for sure the docker image would be useful if your environment is already fully containerized. And a lot of the container orchestration solutions like kubernetes would provide very nice benefits in terms of easier up/down scaling, connectivity, monitoring, etc.
But as you correctly mention, for the moment there's no native way to orchestrate and control multiple k6 instances. There's a REST API and you can use archives to bundle and distribute source trees in one file, but currently you'd have to write the whole orchestration yourself.
We plan to implement native k6 clustering and distributed execution, but we haven't started working on that yet. This is the issue that would be used to track those efforts and it's in the end of the roadmap for this year. I'll close this for now, since it'll be referenced in the original clustering issue and some of the things you listed are actually already implemented (like the API and archive bundles). Monitor the other issue for any updates, since we'll reference it when we start work on this.
Hi.
According to documentation, k6 scalability is based on docker.
This is great, but it's not enough to fine control performance tests.
What about having a K6 Central Controler that would manage all k6
instances to perform centalized actions like:
Olivier
The text was updated successfully, but these errors were encountered: