Kubernetes Probes

.dockerignore

@@ -24,4 +24,3 @@ docs/
 # Scripts that aren't needed for runtime
 scripts/
 tests/
-**/integration

Cargo.toml

@@ -18,7 +18,10 @@ moka = { version = "0.12.10", features = ["sync"] }
 http = "1.1.0"
 dotenv = "0.15.0"
 tower = "0.4.13"
-tower-http = { version = "0.5.2", features = ["decompression-full"] }
+tower-http = { version = "0.5.2", features = [
+    "decompression-full",
+    "sensitive-headers",
+] }
 http-body-util = "0.1.2"
 hyper = { version = "1.4.1", features = ["full"] }
 hyper-util = { version = "0.1", features = ["full"] }
@@ -57,6 +60,7 @@ tokio-util = { version = "0.7.13" }
 bytes = "1.2"
 reth-rpc-layer = { git = "https://github.com/paradigmxyz/reth.git", rev = "v1.3.7" }
 ctor = "0.4.1"
+reqwest = "0.12.15"
 
 [[bin]]
 name = "rollup-boost"

docs/running-rollup-boost.md

@@ -28,6 +28,20 @@ While this does not ensure high availability for the builder, the chain will hav
 
 ![rollup-boost-op-conductor](../assets/rollup-boost-op-conductor.png)
 
+### Health Checks
+
+`rollup-boost` supports the standard array of kubernetes probes:
+
+- `/healthz` Returns various status codes to communicate `rollup-boost` health
+    - 200 OK - The builder is producing blocks
+    - 206 Partial Content - The l2 is producing blocks, but the builder is not
+    - 503 Service Unavailable - Neither the l2 or the builder is producing blocks
+`op-conductor` should eventually be able to use this signal to switch to a different sequencer in an HA sequencer setup. In a future upgrade to `op-conductor`, A sequencer leader with a healthy (200 OK) EL (`rollup-boost` in our case) could be selected preferentially over one with an unhealthy (206 or 503) EL. If no ELs are healthy, then we can fallback to an EL which is responding with `206 Partial Content`. 
+
+- `/readyz` Used by kubernetes to determine if the service is ready to accept traffic. Should always respond with `200 OK`
+
+- `/livez` determines wether or not `rollup-boost` is live (running and not deadlocked) and responding to requests. If `rollup-boost` fails to respond, kubernetes can use this as a signal to restart the pod. Should always respond with `200 OK`
+
 ## Observability
 
 To check if the rollup-boost server is running, you can check the health endpoint:

scripts/ci/kurtosis-params.yaml

@@ -14,7 +14,6 @@ optimism_package:
         fjord_time_offset: 0
         granite_time_offset: 0
         isthmus_time_offset: 5
-        fund_dev_accounts: true
       mev_params:
         rollup_boost_image: "flashbots/rollup-boost:develop"
       additional_services: