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>
apps/<app>/uralkal mirrors apps/<app>/vad for all 36 apps from
clusters/vad/kustomization.yaml, with domains remapped (not a suffix swap —
vad's sarex-login.vadroad.ru etc. use a different host scheme than uralkal's
login.sarex.local.uralkali.com). Two things are left as explicit
placeholders pending real infra: the Zitadel client_id/org_id
(TBD_URALKAL_ZITADEL_CLIENT_ID, since uralkal's Zitadel has no application
registered yet) and the Kafka CA cert in pm/issues/message-hub/flows
(copied from vad, will need swapping once uralkal's Kafka actually
generates its own CA, same as vad's history).
infrastructure/s3-proxy/uralkal: new component, nginx upstream points at
the single uralkal minio endpoint (10.133.0.245:9000) from terraform,
unlike vad's 4-node list.
clusters/uralkal/kustomization.yaml: wires in s3-proxy + all 36 apps.
infrastructure/istio-config/uralkal/istio-config.yaml: adds the 28
path-routed virtualServices under sarex.local.uralkali.com (mirroring
vad's sarex.vadroad.ru routing, incl. the documentations-api CORS policy)
plus stamp-verification/document-link/s3 on their already-declared hosts.
Pre-existing zitadel/superset/camunda-operate blocks are untouched.
apps/django/vad/backend.yaml: drop a stale explanatory comment (also
removed from the uralkal copy before this commit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause: apps/*/ugok extended ../base via kustomize patches, but base
is vault-native (Vault Agent Injector annotations + serviceAccount +
command/args wrapper sourcing /vault/secrets/*). The Vault Agent Injector
webhook IS deployed cluster-wide in ugok (infrastructure/vault/ugok), so
it actually intercepted these pods — but no per-app Vault roles/secrets
were ever provisioned there, so every pod hung in Init.
Fix, mirrored from apps/*/wb (which never extends base for these apps):
rebuild every affected app as a standalone HelmRelease per service, with
no serviceAccount/podAnnotations override and no vault-sourcing wrapper
in command/args (dropped entirely, or replaced with the real functional
command where base's wrapper did double duty — e.g. celery invocations,
pm's `python manage.py migrate`, pdf-markings-amqp's `start-amqp-worker`).
Also recreates ConfigMaps that were referenced by name in volumes but
never actually captured into the repo (eav, subscriptions, pm, issues,
django) — copied verbatim from the cluster dump and verified byte-for-byte
against it.
Incidental bugs found and fixed along the way:
- message-hub was still extending base (missed in an earlier pass).
- system-log's patches targeted services.api/services.worker while base
uses services.backend for both — would have produced duplicate
Deployments per release, one of them permanently vault-broken.
- contracts' real container port is 8080, not base's default 8000.
- drawings' Service.targetPort (8000) didn't match the real containerPort
(8080), breaking routing.
- inspections/ugok was missing entirely from this pass.
apps/documentations: intentionally left without a redis Deployment even
though VALKEY_ADDR now points at one — the cluster dump has no redis in
that namespace, so provisioning one is a scope decision, not a bug fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds apps/<app>/ugok overlays for 31 applications, derived strictly from
a live cluster dump (kubectl get deployment/service/configmap/secret),
following the wb overlay pattern (standalone HelmRelease patches on
universal-chart, plain k8s Secret + secretKeyRef instead of Vault Agent
since the ugok cluster has zero Vault usage cluster-wide).
- processing (workflow namespace) does not extend base: base is
vault-native, ugok is not, so it's four standalone HelmReleases
modeled on apps/processing/wb/*.
- issues/redis and django/redis are raw Deployments patched via JSON6902.
- documentations/pdf-markings and django/auth-flow-frontend,
export-project are copied in as standalone files (base has no
HelmRelease for them, and kustomize forbids cross-overlay references
outside a directory's own tree).
- Images and images-with-registry updated to match wb where the same
build lineage applies; left as-is where the wb tag carries a distinct
client/cluster name (donstroi1, brusnika_*, dev4, UGOK_*, ugok1_*) or
points at a different image repository entirely.
- Missing backend envs backfilled from wb where safe (internal
svc.cluster.local refs, feature flags, already-established ugok
domains); skipped where wb-specific (external DB/Kafka hosts, TLS CA
content, features not deployed in ugok like gatekeeper/Superset).
- message-hub patch was missing its entire env block from the original
bootstrap; rebuilt from the raw dump (not wb, whose Kafka/DB config is
incompatible) plus a handful of small env gaps found while
cross-checking every ugok app's rendered envs against the raw dump.
clusters/ugok/kustomization.yaml keeps the apps section commented out —
not wired into the Flux Kustomization yet, pending review.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
