diff --git a/kubernetes/apps/matter-server/deployment.yaml b/kubernetes/apps/matter-server/deployment.yaml index 794559e7..524a91df 100644 --- a/kubernetes/apps/matter-server/deployment.yaml +++ b/kubernetes/apps/matter-server/deployment.yaml @@ -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