feat: deploy the workshop to Kubernetes (Helm chart + OVH Terraform)

[pantierra]

Deploys the workshop to Kubernetes as one full eoAPI stack per participant, plus the infrastructure under it.

Per-participant stacks (participant/, from #64).

• The stack: each participant gets one pod with the full stack: pgstac, stac-fastapi behind stac-auth-proxy, titiler-pgstac, tipg, mock-oidc, STAC Browser and STAC Manager.
• Access: their JupyterLab is the only way in. Every service is reached through it at /stac, /raster, /vector, /browser, /manager and /oidc, behind one password per participant.
• The chart (participant/chart):
  • keeps each participant's database and work/ on volumes;
  • isolates the stacks with a NetworkPolicy: ingress from the controller only, egress to DNS and public 80/443;
  • pins the Lab and DB images that publish-participant-images.yml builds for amd64;
  • can issue its own TLS certificate through a namespaced cert-manager Issuer (values-labs.yaml holds the labs settings).
• participant/deploy.sh installs exactly the participants it is given, prints their credentials as CSV, and tears down without touching the namespace. participant/warm.sh warms each stack's first map tiles.
• The notebooks follow a per-participant URL contract (docs/workshop_setup.py).
• Design and trade-offs are written up in participant/README.md, including the single STAC database connection per stack, the release freeze during the event, and cold tiles.
• The earlier shared-stack chart (infrastructure/charts/eoapi-workshop) has been removed from this branch.

Terraform (infrastructure/terraform). An OVH managed cluster, ingress-nginx, cert-manager, a Route53 wildcard record, and an optional workshop node pool. The pool comes from workshop_node_count, or from the standalone workshop-pool/ root for an existing cluster.

CI. Helm lint and render of participant/chart (including the labs values), and ruff. The participant images publish on pushes to main and feat/k8s.

Tested

• Notebooks 00–08 run without errors on one participant's local stack.
• On kind, the chart passes its 61 checks: isolation, egress both ways, persistence across pod replacement, and upgrades that restart nobody.
• The images build and publish in CI.
• Rehearsal on the labs cluster, 2026-10-02, 3 participants:
  • TLS and a Secure login cookie;
  • kernel websockets through ingress-nginx;
  • egress enforced by Calico, checked against a control pod;
  • isolation between participants;
  • the database and work/ surviving a pod restart on Cinder volumes;
  • notebooks 00–08 executed inside a participant's Lab with no errored cells;
  • all embedded links resolving.

Not done

• Sizing: a participant pod requests 2.75 GiB, so 20 participants need about 6× b3-16 (or 3–4× b3-32) plus a spare. The workshop-pool/ root still defaults to 3 nodes.
• kube_version = "1.31" in the Terraform is likely out of date for OVH.
• Not yet tested: 20 stacks at once, a node failure, and the browser logins in Safari and Firefox.

🤖 Generated with Claude Code

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[lhoupert]

Hi @hrodmn and all! Before marking this PR ready I want to know your thought about the wording in the notebooks. They currently need to run on three deployments: a) the shared AWS stack, b) one stack per participant on Kubernetes (this PR), and c) local docker compose.

I ran a review of notebooks 00–08 with Claude and it found 22 places where the text is right for one deployment and wrong for another. What was wrong everywhere is already fixed in 4e63e81.

My question is: Should the notebooks describe all three deployments? or only the one we run at the workshop?

I put a proposal that keeps the text correct on all three, for discussion: lhoupert:notebook-review-fixes

Some of the most visible difference are maybe:

• 04 · cell 10 says titiler-pgstac "is running as a Lambda (serverless) function in AWS". -> only true on AWS, in the per-participant and compose stacks it is a container
• 04 · cell 30 says the glad map comes from NASA MAAP's titiler-pgstac, but cell 31 queries the stack's own titiler-pgstac.
• 08 · cell 4 walks through STAC Browser's login with the root docker-compose.yml, but SB_authConfig is commented out there, so login can't work in a local run.