Define the Pravda Kubernetes deployment model

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.

Start by reviewing the FastAPI service, the headed-Chrome process exposed through playwright run-server, and the linked zavod logging setup. Compare the sidecar and separately scaled Deployment options, then define the container configuration, health endpoint semantics, Cloud SQL and GCS access, resources, and scaling assumptions. Done means the selected topology and all acceptance criteria are documented.