La multi-tenancy en Kubernetes casi siempre se dibuja como un solo eje: namespace → vCluster → clúster aparte. A la izquierda barato y débil, a la derecha caro y sólido, elige un punto según tu apetito de riesgo.
El eje es cómodo y falso. vCluster ocupa desde hace poco dos lugares distintos en él, y el precio de los clústeres separados no crece con su cantidad. La decisión se descompone en tres preguntas, y su orden es rígido.
Primera pregunta: quién es el tenant
Un namespace no es una frontera de seguridad. No es una máquina virtual, el kernel es compartido, y un contenedor privilegiado sale al host por muchos roles de RBAC que le cuelguen alrededor. De ahí la primera divisoria: ¿nos protegemos del error accidental del vecino o del vecino mismo?
Para equipos propios con confianza mutua un namespace resuelve la tarea, siempre que esté montado entero: RBAC sin verbos comodín, NetworkPolicy default-deny (Kubernetes permite por defecto todo el tráfico entre namespaces, y eso es un agujero, no un ajuste), ResourceQuota junto con LimitRange. Juntos precisamente: una quota sin LimitRange significa que el primer pod sin requests se la come entera. La capa más débil fija la resistencia de toda la construcción, así que «configuramos NetworkPolicy más tarde» equivale a «no la configuramos».
En ese mismo punto está el único cambio en años que mueve de verdad la frontera de confianza. En Kubernetes 1.36 los user namespaces alcanzaron el estado stable: hostUsers: false mapea el root de dentro del contenedor a un uid sin privilegios del host, y escapar del contenedor deja de significar root en el nodo. El recorrido del gate: alpha en 1.28, beta desde 1.30, beta activada por defecto desde 1.33, stable desde 1.36. Conviene tener presente que es una opción del pod y no una propiedad del clúster: GA significa «se puede confiar», no «ya se aplica a vuestras cargas».
Segunda pregunta: necesita el tenant acceso cluster-scoped
Si un equipo necesita sus propios CRD, sus propios namespaces o cluster-admin dentro de su perímetro, ninguna configuración de RBAC hará que le sirva un namespace. No es una cuestión de confianza sino de alcance de la API. Aquí empieza vCluster: el tenant recibe su propio API server y las cargas se sincronizan hacia el clúster anfitrión.
Durante el último año esa imagen dejó de estar completa. vCluster incorporó private nodes: nodos worker propios del clúster del tenant, que pueden estar en otra VPC, en otro proveedor o en hierro desnudo, conectados al control plane por VPN. El aislamiento ya no va solo del control plane, y aquel eje «más débil, más fuerte» se ha bifurcado: vCluster sin private nodes y vCluster con ellos son dos respuestas distintas.
Después empieza lo que conviene calcular antes del piloto y no después. Las capacidades están repartidas por tiers, y las fronteras no pasan por donde uno espera:
- OSS (Apache 2.0): control planes propios, sincronización de recursos, distintos backing stores. No hace falta licencia ni conexión con una Platform externa.
- Free: gratis y sin tarjeta, pero exige conectarse a la vCluster Platform para validar la licencia. Incluye embedded etcd, private nodes, custom resource syncing, sync patches y el HostPath Mapper.
- Enterprise (Dev / Prod / Scale): sleep mode, bases de datos externas, SSO, registros de auditoría, FIPS y entrega air-gapped.
La consecuencia es afilada: un entorno cerrado se queda solo con el tier OSS, es decir sin private nodes. Una organización que eligió vCluster por los nodos dedicados y no puede llamar a casa para validar lo descubrirá durante la implantación. Conviene además corregir un dato antiguo: desde la versión 0.20 la distribución por defecto del control plane virtual es k8s vanilla y no k3s, y el soporte de EKS como distribución se retiró entonces.
Tercera pregunta: cuánto cuesta el error
El argumento estándar contra un clúster por equipo es la multiplicación de la cuota fija. En EKS son $0,10 por hora y clúster, unos $73 al mes, y treinta clústeres suman alrededor de $2.200 mensuales solo en control planes, antes de una sola carga de trabajo.
La multiplicación no es la parte cara. Cuando termina el soporte estándar de una versión, el clúster pasa automáticamente a soporte extendido a $0,60 por hora, seis veces más. Una flota de clústeres separados se encarece en proporción no al número de equipos, sino al número de equipos que no llegan a tiempo con las actualizaciones. Eso da la vuelta a la aritmética habitual: el modelo «un clúster por tenant» cuesta no $73 × N, sino $73 × N más una penalización sobre la disciplina organizativa, que a una flota creciente suele faltarle. Repartir ese dinero entre los tenants es tarea del showback: OpenCost y Kubecost calculan por etiquetas de namespace, así que las etiquetas se ponen al crear el namespace y no a posteriori.
La tabla de decisión
| Situación | Modelo | Lo que hay que aceptar |
|---|---|---|
| Equipos propios, hay confianza, no hace falta cluster-scoped | Namespace + RBAC + default-deny + Quota/LimitRange | El namespace no es frontera de seguridad; la resistencia va por la capa más débil |
| Hacen falta CRD propios y cluster-admin, entorno no cerrado | vCluster OSS | Las cargas corren en el clúster anfitrión; aislado está el control plane, no los workers |
| Hacen falta nodos dedicados por tenant | vCluster + private nodes | El tier Free y conexión permanente con la Platform para validar la licencia |
| Entorno cerrado, air-gapped | vCluster OSS o clústeres separados | Private nodes y entrega air-gapped no están en OSS |
| Código no confiable, PCI-DSS, HIPAA | Clústeres separados | $73 al mes por control plane, y $0,60 por hora en soporte extendido |
La fila del código no confiable admite una lectura más suave: gVisor o Kata mediante RuntimeClass dan aislamiento a nivel de pod dentro de un clúster compartido, al precio del rendimiento. No sustituye a un clúster aparte allí donde la separación la exige un regulador, pero funciona como opción intermedia cuando el requisito viene del sentido común y no de un auditor.
Qué no recoger en 2026
El Hierarchical Namespace Controller con su kubectl hns aparece en una de cada dos recopilaciones sobre multi-tenancy. El repositorio se trasladó a la organización kubernetes-retired y quedó archivado, su último commit es de abril de 2025 y no se ha nombrado sucesor. Construir hoy una jerarquía de namespaces sobre él significa planificar una migración.
El escenario «tenant como objeto, cuotas y políticas sobre un conjunto de namespaces» lo cubre Capsule: proyecto de la CNCF, vivo (v0.14.3 salió el 31 de agosto de 2026), grupo de API capsule.clastix.io/v1beta2, más las cuotas globales que han aparecido por encima de varios tenants. No es una migración desde HNC ni un reemplazo función por función: es otro modelo, donde el objeto raíz es un Tenant y no un árbol de namespaces.
Hay dos planos que se confunden con regularidad y conviene separar. El AppProject de Argo CD limita quién despliega qué y dónde, y eso es una frontera de entrega. No sustituye ni a ResourceQuota, ni a NetworkPolicy, ni a Pod Security Admission dentro del namespace del tenant. Un AppProject configurado sobre un perímetro de namespace vacío da la sensación de aislamiento sin aislamiento. La política a nivel de admission es una capa aparte, y el perímetro de red resulta más cómodo construirlo sobre Cilium con egress basado en DNS y reglas L7.
Un orden, no una escala
Las tres preguntas van en un orden fijo. Quién es el tenant decide si un namespace sirve siquiera. Si necesita acceso cluster-scoped decide si hace falta un control plane virtual. Y solo después se calcula el precio, porque depende de las dos primeras respuestas y de la rapidez con que la organización despliega actualizaciones.
Las respuestas a las dos primeras preguntas ya se conocen hoy, no hay que investigarlas. La tercera cambia con el tiempo, y cambia a peor justo para quienes eligieron clústeres separados para no tener que pensar en el aislamiento.