Each tenant namespace carries two NetworkPolicies created by KubePlus:
restrict-cross-ns-traffic podSelector {} same-namespace only
allow-external-traffic podSelector partof=<release> allow all
Without the partof label only the first applies, so the ingress controller - which
lives in another namespace - is blocked and every request to the tenant returns 502
from nginx while Label Studio itself is perfectly healthy.
That label was only ever applied by the KubePlus mutating webhook at pod creation
time, and that webhook runs with failurePolicy: Ignore. When the webhook is broken,
pods are still admitted, just without the label, and the tenant goes dark silently.
Every pod recreated during such a window loses external access.
Set it in the pod template instead so it no longer depends on the webhook. The Helm
release name is exactly the value the policy expects (labelstudioservice-<namespace>).
The selector is left untouched, so this stays a valid in-place upgrade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Repackaged from the exact 2.0.0 tree that was published here (sha256
371cff69...05bcf4); the only difference in the rendered output is the three
resources blocks.
Every tenant namespace has a ResourceQuota named labelstudioservice-<ns> that
requires limits and requests on every container, and the chart left
app.resources, app.initContainer.resources and app.nginx.resources empty. Pod
creation was rejected outright:
pods "studio-vegastar-..." is forbidden: failed quota: labelstudioservice-<ns>:
must specify limits.cpu for: db-migrations,nginx; limits.memory for: ...
17 of 22 tenants sit at 0/1 with no pods because of it. The 5 still running were
created before the quota took effect and would fail the same way on restart.
The quota is requests 200m/512Mi, limits 500m/1Gi - exactly what the app container
alone takes, because the KubePlus podconfig webhook only injects resources into the
first container. A pod is charged max(sum of regular containers, max init container),
so db-migrations does not add to the total. This split fits the existing quota
exactly, so no ResourcePolicy or per-namespace quota needs changing:
app requests 170m/448Mi limits 400m/928Mi
nginx requests 30m/ 64Mi limits 100m/ 96Mi
db-migrations requests 100m/256Mi limits 400m/768Mi
Sized from live usage on the 5 healthy tenants: app 5-8m CPU and 782-806Mi, nginx
1m and 15-29Mi.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Duc NguyenandClaude Opus 5