When one tenant's heavy usage degrades performance for everyone else on the same shared resource, the cardinal multi-tenancy risk.
A noisy neighbor is a tenant or workload on a shared resource (a Kubernetes node, a database, a network link, a CPU core) whose heavy usage degrades performance for the other tenants of that resource. Examples: one pod's runaway memory usage triggers OOM-kill on neighbors, one query saturates the database's IOPS budget for everyone, one tenant's traffic exhausts a shared connection pool. Mitigations include resource quotas, dedicated tenancy tiers, per-tenant rate limits, and isolation primitives (cgroups, separate node pools).
Multi-tenant platforms are economically attractive (high utilization, low overhead) but operationally tricky because every tenant's blast radius extends to every other tenant. Detecting noisy neighbors early (per-tenant metrics, anomaly detection on per-tenant rates) is the difference between a quick mitigation and a multi-customer Sev-1.
See the part of the platform that handles noisy neighbor in production.