[fabianekc]

Summary

With one replica and 3 threads, three checks against a passport host that does not answer kept the service busy for up to 35 s: /up and every other request waited until they ended.

• Two replicas, 16 threads each (RAILS_MAX_THREADS=16): up to 32 checks run at the same time. Rolling updates start the new replica before the old one stops (maxUnavailable: 0, maxSurge: 1).
• Readiness (/version, every 5 s, 2 s timeout, out after two failures): a replica whose threads are all busy is taken out of the ingress until it answers again.
• Liveness checks only that the port is open (TCP), so a busy replica is not restarted. Requests that wait for a thread do not count against it; a process that stops listening still does.
• Memory request 512 Mi (was 384 Mi): 16 parallel checks with SOyA validation used about 480 MiB in a test, mostly the SOyA web-cli. The limit stays at 1 GiB; CPU stays at a 100m request without limit.
• Replicas keep no state of their own (no sessions, cookies or shared files; caches live for one check only), so either replica can answer any request.

Tests

• kubeconform -strict against Kubernetes 1.30: deployment, service and ingress valid.
• In a container with 16 threads and 20 checks against a host that does not answer: /version with a 2 s timeout failed until the checks ended (34.7 s); a TCP connection to the port succeeded on every one of 45 probes.
• 16 parallel checks of a passport whose host answers JSON at once and leaves other requests hanging: about 480 MiB in the container (baseline about 130 MiB).