matter-server: add startup/readiness/liveness probes #149
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user