Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cluster Domain name is not always cluster.local #233

Closed
vr opened this issue May 16, 2023 · 2 comments
Closed

Cluster Domain name is not always cluster.local #233

vr opened this issue May 16, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@vr
Copy link
Contributor

vr commented May 16, 2023

Brief summary

I encounter an issue with k6-operator which is not able to fetch status of his runners, on a cluster which do not use cluster.local (this is uncommon config but perfectly valid) because of this hardcoded code

resp, err := http.Get(fmt.Sprintf("http://%v.%v.svc.cluster.local:6565/v1/status", service.ObjectMeta.Name, service.ObjectMeta.Namespace))

What could be the way to fix this ? define some variable somewhere ? using .svc instead of .svc.cluster.local ? what do you prefer ?

as a workaround, i changed on which the cluster i deploy but could be great to fix this.

k6-operator version or image

latest

K6 YAML

apiVersion: k6.io/v1alpha1
kind: K6
metadata:
  name: k6-foo
spec:
  parallelism: 10
  arguments: --out statsd
  script:
    configMap:
      name: crocodile-stress-test
      file: test.js
  runner:
    env:
      - name: K6_STATSD_ENABLE_TAGS
        value: "true"

Other environment details (if applicable)

No response

Steps to reproduce the problem

deploy some K6 resources

Expected behaviour

runners can be joined and status fetched

Actual behaviour

runners can't be joined and nothing finish

@vr vr added the bug Something isn't working label May 16, 2023
@yorugac yorugac added enhancement New feature or request and removed bug Something isn't working labels May 23, 2023
@yorugac
Copy link
Collaborator

yorugac commented May 23, 2023

Hi @vr, thanks for opening the issue!

I think ideally, it'd be preferable to switch to using service.namespace format instead of the full domain as now, then the whole question about domains will disappear. There were several different cases raised around networking in the operator which sometimes seemed contradictory to each other, so there's an umbrella issue meant to hopefully resolve all of them at once: #186

@yorugac
Copy link
Collaborator

yorugac commented Nov 7, 2023

This should have been resolved in #288; please feel free to (re)open an issue if something else comes up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants