The overlay inherited base env copied from SaaS prod: DJANGO_HOST
https://lk.sarex.io, workspaces/workflows on api.sarex.io and PG_SSL_MODE
verify-full. From the closed contour every request to django failed with
CERTIFICATE_VERIFY_FAILED. Point django, workspaces and workflows at their
uralkal services, attachments at its real port 8000, disable postgres SSL
(the uralkal server has none). FAAS_SERVICE and RESOURCE_URL stay as in base:
neither service exists in uralkal.
Every services.<svc>.deployment.resources.requests.{cpu,memory} across the
36 uralkal apps (69 HelmRelease/service entries total) is now nulled via a
kustomize patch, so Helm never renders a requests block for these pods on
uralkal — Kubernetes won't reserve CPU/memory for them there.
Where a uralkal patch already existed for that service (13 cases:
documentations api/filestream/pdf-markings-amqp, django backend, flows
backend/celery, pm backend/celery, transmittal backend/worker, bi,
document-link, stamp-verification, message-hub), the null block was added
into that same file. Where no uralkal patch existed yet (55 cases,
including all 13 cde workers and every plain frontend), a new minimal
patch file was added and wired into that app's kustomization.yaml.
vad and the other clusters are untouched — only apps/*/uralkal/* changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
