


Feature | Description | Field |
Delayed Registration | Polaris enables delayed registration, allowing service registration only after the application has fully started. Polaris supports two methods of delayed registration: Time-based Delay: After the delay for registration is set, an application can register with the registry and provide services externally after full initialization. Probing-based Delay: The health check API externally exposed by the application is probed. If the API probing succeeds, the status code 200 is returned, confirming that the application can provide external services. Then, registration to the registry is allowed. | Time-based Delay: Delayed Registration Time: registration delay in the range of 0–3600 seconds. Default value: 30 seconds. |
| | Probing-based Delay: Probing Protocol: HTTP Probing Method: PUT, GET, POST, DELETE, or all. Probing API: Enter the health check API exposed by your business. When the API probing succeeds, service registration is performed. Example: /health |
Service Warm-Up | Polaris provides service warm-up capability. After verification with a small amount of traffic is successful, normal traffic is then introduced. | Warm-up Duration: The default value is 120 seconds, and the value ranges from 0 seconds to 86400 seconds (24 hours). Warm-up End Percentage: When more than a certain percentage of nodes are in the warm-up phase, warm-up terminates to prevent traffic from concentrating on a small number of nodes and causing overload. Default value: 50%. Warm-up curve value: The default value is 1. It supports integer values between 1 and 5. Traffic weight increases exponentially based on the configured warm-up curve value. The larger the value, the steeper the warm-up curve gradient. Service instance weight calculation rule: ![]() |
Readiness Check | After readiness check is enabled, an API is provided for determining whether registration is complete. This works in conjunction with the Kubernetes readiness check feature: When application registration is complete, the HTTP 200 status code is returned, helping Kubernetes determine that the application is ready; if registration is not complete, the HTTP 500 status code is returned, helping Kubernetes determine that the application is not ready.
| |

<dependencies><dependency><groupId>com.tencent.cloud</groupId><artifactId>spring-cloud-tencent-lossless-plugin</artifactId></dependency></dependencies>
피드백