feat: use kurtosis service name as the kubernetes service name #713
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
With this change, the Kubernetes service (and pod) name is now set as the Kurtosis service name and we are moving away from randomly assigned names that followed the template
user-service-<uuid>
. Instead, Kubernetes services (and pods) will be named after the Kurtosis service, e.g.webserver
.The motivation behind this change is that Kubernetes services (that operate inside the same namespace) will at times need to communicate with each other using their respective hostnames. In Kubernetes, hostnames originate from the Kubernetes service name and are managed by CoreDNS. From a Kurtosis perspective, this is fine as long as you can spin up your Kurtosis service, and thereafter wire in the assigned hostname into other services that need to know what the name was. However, at times this is not practical, particularly if the service need to be spun up with information such as the names of other hosts that in turn depend on each other in a circular fashion (a chicken-egg style problem).
With this change, Kubernetes services can depend on the Kubernetes set hostname matching the Kurtosis service name (just like it works when running on the Docker backend), thus enabling the services to deterministically resolve the names of other services, prior to actual run-time.
In the next PR, I'll add a regex to ensure that the Kurtosis service name will not take a form that is not supported by Kubernetes and docker.
Is this change user facing?
NO