Define the Pravda Kubernetes deployment model

[pudo]

Define how Pravda should run on GCP Kubernetes.

Pravda consists of a FastAPI service and a separate headed-Chrome process exposed through playwright run-server. Decide whether these should run as two containers in one Pod or as separate Deployments connected through an internal Service.

Cover

• Pravda and browser container responsibilities.
• Required environment configuration.
• /healthz and /readyz endpoints.
• CPU and memory requirements.
• Cloud SQL connectivity.
• GCS access through Workload Identity.
• Initial replica and scaling model.
• Structured logging based on zavod’s logging setup.

Questions

• Should each Pravda replica own a browser sidecar?
• Should browsers run as a separately scaled pool?
• Can playwright run-server safely serve concurrent captures?
• Which dependency checks belong in /readyz and /healthz?

Acceptance criteria

• The Pod/Deployment topology is selected and documented.
• Required container and Kubernetes configuration is specified.
• Health endpoint semantics are defined.
• Resource and scaling assumptions are explicit.

[jbothma]

I think the core requirements are

• k8s cron jobs can reach playwright at some endpoint
• k8s cron jobs (incl pravda the library) can reach our postgres
• k8 cron jobs can reach the internet
• browser containers can reach the internet
• browser containers can't reach services internal to our VPC, e.g. redis, postgres

What would be nice but maybe doesn't have to be a hard requirement yet

• isolation between jobs. If one job's container gets compromised, the next job has another
• some degree of concurrency control, unless there's a browser per job
• can scale down to zero for now while it's only in use now and then

I looked at 4 options:

• A. Sidecar in the CronJob pod - sidecars get same network policy as the crawler pod
• B. Separate Deployment + Service inside GKE, egress NetworkPolicy on browser pods - enabling network policy sounds like a Big Deal
• C. Cloud Run service, no VPC connector, IAM-auth'd
  • simple, well known, except it's websocket with max connection life of 60m
  • scales down to zero, starts quite quickly
  • no job isolation
  • we pay for egress from k8s and from cloud run
• D. Dedicated GKE node pool + tag-based VPC firewall
  • sounds simple, just a longer cold start time, like 2ish minutes to start a node

I like option C to start with