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
Currently in 0.60 beta there is an option to specify the url for a health check of the CTS worker. Depending the deployment a Consul agent might not be running locally which can cause issues with the health check. In environments with ephemeral IPs it would be beneficial to allow for the use of the go-sockaddr library to enumerate the IP address of the worker for the health check.
Use Cases
Health checks for the CTS service without having to use a Consul agent locally.
Alternative Solutions
Solution 1 - If you are using Kubernetes you could create a custom service (ClusterIP) and then use that service via kubedns for the health check of the worker. Down side with this is you would need 1 service per worker
Solution 2 - If you are on Kubernetes use the metadata from the pod status to pass in the IP as an environment variable and use additional templating to specify this IP as the health check URL (requires an container port to be defined)
Solution 3 - Run the consul agent where the CTS worker currently resides (standard for most deployments)
Solution 4 - I haven't tried this yet but you could configure liveness probes and configure the CTS worker in connect so consul incorporates those default checks in Kubernetes. https://www.consul.io/docs/k8s/connect/health
Additional context
This issue
The text was updated successfully, but these errors were encountered:
Description
Currently in 0.60 beta there is an option to specify the url for a health check of the CTS worker. Depending the deployment a Consul agent might not be running locally which can cause issues with the health check. In environments with ephemeral IPs it would be beneficial to allow for the use of the go-sockaddr library to enumerate the IP address of the worker for the health check.
Use Cases
Health checks for the CTS service without having to use a Consul agent locally.
Alternative Solutions
Solution 1 - If you are using Kubernetes you could create a custom service (ClusterIP) and then use that service via kubedns for the health check of the worker. Down side with this is you would need 1 service per worker
Solution 2 - If you are on Kubernetes use the metadata from the pod status to pass in the IP as an environment variable and use additional templating to specify this IP as the health check URL (requires an container port to be defined)
Solution 3 - Run the consul agent where the CTS worker currently resides (standard for most deployments)
Solution 4 - I haven't tried this yet but you could configure liveness probes and configure the CTS worker in connect so consul incorporates those default checks in Kubernetes. https://www.consul.io/docs/k8s/connect/health
Additional context
This issue
The text was updated successfully, but these errors were encountered: