This model maps Dubbo Service to the concept of Kubernetes Service, eliminating the need for traditional registries like Nacos, with the Kubernetes APISERVER taking on the role of the registry.
In this model, we need to install dubbo-control-plane
Should it work with istio (providing xds push capability), or should dubbo-control-plane implement the xds server itself?
dubboctl manifests install --profile=control-plane
Please refer to dubbo-samples for examples.
kind: service
kind: deployment
Configure probe Configure pre-stop
Pod Lifecycle is closely related to service scheduling. By implementing Kubernetes official probes, Dubbo3 and the entire application’s lifecycle can be affected throughout the Pod’s lifecycle through health checks, which can be configured using liveness probe and readiness probe.
Through Dubbo3’s SPI mechanism, multiple “probes” are internally implemented based on Dubbo3 QOS operations module’s HTTP services, enabling container probes to obtain corresponding probe states within the application. Moreover, the SPI implementation mechanism also facilitates users to extend internal “probes,” making the entire application lifecycle more effectively governed.
Three Probes Corresponding SPI Interfaces
org.apache.dubbo.qos.probe.LivenessProbe
org.apache.dubbo.qos.probe.ReadinessProbe
org.apache.dubbo.qos.probe.StartupProbe
The interface will automatically acquire all SPI implementations of the current application, returning success if all corresponding SPI implementations are successfully ready.
See more about Dubbo3 SPI extensions at Dubbo SPI Extensions
liveness probe
to determine if your application is running and check if it is alive.
readiness probe
to determine whether the container is ready to receive traffic, whether it is prepared, and whether it can start working.
startup probe
to determine whether the application inside the container has started. If a startup probe is provided, all other probes are disabled until it succeeds. If the startup probe fails, the container will be killed, and it will follow its restart policy. If no startup probe is provided, the default state is successful.
For livenessProbe checks, since the Dubbo3 framework cannot obtain the application’s liveness status, this interface has no default implementation and defaults to returning success. Developers can extend this SPI interface to determine liveness from the application level.
See liveness probe extension example.
For readinessProbe checks, Dubbo3 currently provides two dimensions for checking; one is to determine if Dubbo3 services are starting and stopping, and the other is to check if all registered interfaces exist. If all services are offline from the registry (which can be operated via QOS), it will return an unready status.
See readiness probe extension example.
For startupProbe checks, Dubbo3 currently provides a check dimension where it returns a ready state after all startup processes (interface exposure, writing to registry, etc.) are complete.
See startup probe extension example.
livenessProbe:
httpGet:
path: /live
port: 22222
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 22222
initialDelaySeconds: 5
periodSeconds: 5
startupProbe:
httpGet:
path: /startup
port: 22222
failureThreshold: 30
periodSeconds: 10
When the QOS calculates that the node detects memory pressure, Kubernetes will evict Pods in the order of BestEffort -> Burstable -> Guaranteed.
Currently, all three probes have corresponding interfaces, with paths being commands in QOS, and port information should be modified according to QOS configuration (default port is 22222). Refer to the Kubernetes official documentation for other parameters.