Fix Kind DNS configuration for registry API and telemetry

[therealnb]

Summary

This PR fixes DNS resolution issues in Kind clusters by configuring public DNS servers via extraMounts. This is a prerequisite for proper operation of the Kubernetes registry API and OpenTelemetry telemetry collection.

Changes

• Added kind-config.yaml with DNS configuration using public DNS servers (8.8.8.8, 8.8.4.4, 1.1.1.1)
• Added resolv.conf file mounted into Kind nodes for DNS resolution
• Updated Taskfile.yml to use the new Kind config
• Added setup-kind.sh script to automate Kind cluster setup with ToolHive Operator
• Updated e2e test Kind config to include DNS configuration

Related Issues

• Addresses StacklokLabs/research#89: Call k8s registry API instead of thv registry API when running in k8s

  • The DNS fix ensures that the Kubernetes registry API can properly resolve service names and external DNS queries
  • This is a prerequisite for clients to successfully call the Kubernetes registry API service instead of the ToolHive HTTP API

• Addresses StacklokLabs/research#119: Enable open telemetry collection on toolhive-doc-mcp server in staging EKS

  • Proper DNS resolution is required for OpenTelemetry collectors to function correctly
  • The DNS configuration ensures that telemetry endpoints can be resolved properly

Testing

• Verified Kind cluster creation with DNS configuration
• Verified DNS resolution works correctly in Kind clusters
• Tested setup script end-to-end

Notes

• The DNS configuration uses public DNS servers to ensure reliable resolution
• The resolv.conf file is mounted into Kind nodes via extraMounts
• This change affects both regular Kind setup and e2e test Kind setup

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.58%. Comparing base (15f0beb) to head (b8aca27).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2877      +/-   ##
==========================================
- Coverage   56.59%   56.58%   -0.02%     
==========================================
  Files         322      322              
  Lines       31439    31439              
==========================================
- Hits        17794    17790       -4     
- Misses      12110    12120      +10     
+ Partials     1535     1529       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[therealnb]

@ChrisJBurns @danbarr
This isn't strictly necessary. I had issues getting kind dns running out of the box, so added that. Also the ingress controller (which makes forwarding ports a little more fun).

--kubeconfig kconfig.yaml just wasn't quite working for me - but I can put that back.

Was there something I should have been doing with DNS differently?
If you think you might want to keep this, I'll fix all the remaining checks.

If you don't like this, I'll probably just keep those changes as a local script.

[danbarr]

@therealnb

--kubeconfig kconfig.yaml just wasn't quite working for me - but I can put that back.

I think that's because you removed the output of the kubeconfig file here. 😄

[danbarr]

I'm not sure I understand the issue this is meant to fix? I haven't had any public DNS resolution issues with my kind clusters, MCP servers I run in my cluster are perfectly able to reach public services, same for operators like ngrok.

Personally I'm hesitant to override users' choice of upstream DNS even in a dev/test case like this; and in corporate environments this could run afoul of security practices.

[therealnb]

Thanks @danbarr . I did wonder if this was just a problem with my env. I'll close this one.