k6-operator
k6-operator copied to clipboard
grafana
Fix IPv6 compatibility issue with starter pod
Summary Bug Fixed: Starter doesn't work in an IPv6 cluster
This pull request addresses the IPv6 compatibility issue in the k6-operator as outlined in the referenced issue. Specifically, the changes ensure that the k6-curl container can correctly handle IPv6 addresses.
Changes Made Introduced the net package to handle IPv6 addresses. Hostname Wrapping: Utilized net.JoinHostPort to wrap the hostname in square brackets if it is a literal IPv6 address, ensuring proper formatting.
Testing Verified that the k6-curl container now supports both IPv6 and IPv4 addresses. Conducted tests on local k8s cluster via KIND to confirm the functionality of the k6 operator with the updated IPv6 support.
Snapshot of starter pod that deals with IPv6 address correctly:
Snapshot of starter pod that still works with IPv4 address:
Impact These changes enhance the compatibility and robustness of the k6-operator, allowing it to function correctly in environments utilizing IPv6 addresses.
While I highly appreciate IPv6 to be working ... and this PR is nothing more than a bugix. But there also is https://github.com/grafana/k6-operator/issues/87.
If you, @yorugac, agree to move to a native k6 client / HTTP call by the Operator to kick off them K6 runners that change can also "fix" the IPv6 endpoint issue.
While I highly appreciate IPv6 to be working ... and this PR is nothing more than a bugix. But there also is https://github.com/grafana/k6-operator/issues/87.
I don't think one solution excludes the other. The fix with brackets is here, and would be greatly appreciated. For now we're using a fork.
I'd suggest attacking both fronts: this fix as a quick win and #87 as a more robust, long-term approach. :-)
Hi @yorugac
could you please add reproducible examples with kind cluster? It appears they have it here: https://kind.sigs.k8s.io/docs/user/configuration/#ip-family I assume you mentioned the same in your description.
That is correct. I created the ipv6 local cluster via KIND using the exactly same config file in this url.
If you could add a folder e2e/ipv6 with relevant files for such a test, that'd be great.
You needed me to add the kind config file in the e2e/ipv6 folder? For the test script and crd file, the test.js and test.yaml that are already in e2e folder work. And I did test with dual cluster as well. With dual configuration, the primary ip would be ipv4. And it works with both ipv4 and ipv6 as the snapshots show in the description.
PS Signing CLA is a hard requirement for any PR: please sign it 🙂
Signed.
I'd suggest attacking both fronts: this fix as a quick win and https://github.com/grafana/k6-operator/issues/87 as a more robust, long-term approach. :-)
Yes, I think the same. Removal of starter won't happen fast, but this fix is small and a quick win :raised_hands:
Hi @yorugac Can I ask when are you planning to build a image that includes this fix? The latest image was built 2 months ago.
@zzhao2010, yes, there was a bit of a skew with the releases last time: 2 releases were done with the short window. The next one will be after k6 v0.54 so ~ next week. (k6 will be released on Tuesday) And yes, in case anyone is wondering, we do intend to improve this workflow so that releases of k6-operator are less dependent on k6 (issue).