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
Tentacle offers four options for hostname configuration during registration:
PublicIP
FQDN
ComputerName
Custom (Paired with CustomPublicHostName)
However, when standing up a listening worker in AKS, these all fail. PublicIP resolves to the Azure IP address (52.x.x.x), which isn't registerable within the cluster. The FQDN/ComputerName options utilize the hostname, which maps to the container name in the pod. However, these aren't routable through https:// from the Octopus server. Finally, Custom would work if it were possible to know the cluster IP at registration time, which isn't currently possible.
Running hostname -i on the container provides the internal cluster IP, which can be used to successfully register and route tasks to a listening tentacle. Being able to choose that internal IP would make listening tentacles function in Kubernetes in a similar fashion to other Octopus server registration workflows.
The text was updated successfully, but these errors were encountered:
I know it's been 2 years after the original post, but I managed to configure tentacle in listening mode in K8S. The key is to use the "Custom" PublicHostNameConfiguration and specify pod's IP as the value for CustomPublicHostName, like below
Another useful tip is to have tentacle automatically unregistering from Octopus Server once the pod is killed:
lifecycle:
preStop: # Deregister tentacle from the server when pod is killed (e.g. during deployments)
exec:
command: ["sh", "-c", "tentacle deregister-worker --server=$ServerUrl --apiKey=$ServerApiKey"]
Tentacle offers four options for hostname configuration during registration:
However, when standing up a listening worker in AKS, these all fail. PublicIP resolves to the Azure IP address (52.x.x.x), which isn't registerable within the cluster. The FQDN/ComputerName options utilize the hostname, which maps to the container name in the pod. However, these aren't routable through https:// from the Octopus server. Finally, Custom would work if it were possible to know the cluster IP at registration time, which isn't currently possible.
Running
hostname -i
on the container provides the internal cluster IP, which can be used to successfully register and route tasks to a listening tentacle. Being able to choose that internal IP would make listening tentacles function in Kubernetes in a similar fashion to other Octopus server registration workflows.The text was updated successfully, but these errors were encountered: