matter-server: add startup/readiness/liveness probes #149

Merged
k.renner merged 1 commits from fix/matter-server-probes into master 2026-07-10 18:27:35 +00:00
@@ -85,6 +85,48 @@ spec:
- name: ws
containerPort: 5580
protocol: TCP
# matter-server had NO probes — a hung or crashed server kept the
# pod Running while HA's WebSocket to it was dead. These probes fix
# that. `GET /` on :5580 returns 200 from the aiohttp server, so it
# is a real "the control server is up and answering HTTP" check —
# stronger than a bare tcpSocket. httpGet targets the pod IP, which
# is exactly where the server binds (--listen-address=$(POD_IP),
# PR #144), so this reaches the right socket.
#
# SCOPE, honestly: this catches server-down / hung / not-listening.
# It does NOT catch "fabric lost / 0 nodes" — that failure leaves
# the :5580 server (on eth0) answering while the net1 macvlan / SDK
# is broken, so no :5580 probe can see it. Closing that would need
# an app-level node-count signal matter-server doesn't expose over
# HTTP; out of scope here.
#
# Liveness is deliberately conservative: a restart churns the whole
# Matter fabric (~13 nodes re-subscribe over minutes, observed in
# #144). failureThreshold 5 x 30s = 2.5 min of sustained failure
# before a restart, so a transient blip never triggers fabric
# churn. The startupProbe (5 min budget) suspends liveness/readiness
# while the SDK loads the fabric and binds the socket.
startupProbe:
httpGet:
path: /
port: ws
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 30
readinessProbe:
httpGet:
path: /
port: ws
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /
port: ws
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 5
volumeMounts:
- name: data
mountPath: /data