Multi-tenancy en Kubernetes: modelos, capas de aislamiento y buenas prácticas

TL;DR

• Multi-tenancy en Kubernetes significa ejecutar varios equipos, proyectos o clientes en un solo clúster compartido en lugar de un clúster dedicado para cada uno, y nada del aislamiento ocurre de forma automática.
• Cuatro capas fundamentales la sostienen: namespaces, RBAC, políticas de red y cuotas de recursos (incluidos los LimitRanges), además de los Pod Security Standards que protegen a nivel de workload. Si omites una, un tenant que debería permanecer aislado empieza a afectar a todos los demás.
• Existen tres modelos de aislamiento: soft (basado en namespaces, el más económico, solo aislamiento lógico), hard (clústeres virtuales como vCluster o Capsule) y físico (node pools o clústeres dedicados, el aislamiento más fuerte y el costo más alto). La mayoría de las organizaciones combina los tres en lugar de estandarizar uno solo.
• La mayoría de las fallas se debe al drift, no a una mala configuración inicial: los equipos configuran las cuotas y el RBAC correctamente una vez y nunca los vuelven a revisar cuando los workloads cambian.

Pon diez equipos en un clúster de Kubernetes y, por defecto, nada impide que el equipo A lea los secretos del equipo B, se coma su CPU o tumbe un control plane del que el equipo B también depende. La multi-tenancy en Kubernetes cierra esa brecha con cuatro capas configurables: namespaces, RBAC, políticas de red y cuotas de recursos.

La multi-tenancy permite a las organizaciones dejar de pagar por decenas de control planes ociosos y empezar a compartir infraestructura entre equipos, proyectos o clientes ("tenants"). Solo funciona si cada una de esas capas realmente se configura y se mantiene configurada. Kubernetes no viene multi-tenant de fábrica. Los namespaces trazan una frontera lógica, no una de seguridad. Si omites una capa, un tenant que debería haber permanecido aislado empieza a afectar a todos los demás en el clúster, ya se trate de una frontera de seguridad o simplemente de un workload comiéndose la CPU de otro.

Por qué los equipos comparten un clúster

Hay tres razones que aparecen en casi todos los casos: el costo, la carga operativa y la velocidad de desarrollo.

Operar diez clústeres significa diez control planes, diez conjuntos de node pools sobredimensionados y diez balanceadores de carga ociosos la mayor parte del día. Consolidar en dos o tres clústeres compartidos reduce ese overhead de forma directa. También se reduce la carga operativa: un solo clúster que parchar, un solo lugar donde vigilar la salud de etcd, un solo conjunto de políticas que mantener consistente, en lugar de repetir la misma tarea en cada clúster que operas.

La velocidad de los desarrolladores importa igual, aunque se note menos. Los equipos que esperan a que un equipo de plataforma aprovisione un clúster nuevo esperan días. Los que solicitan un namespace en un clúster multi-tenant existente pueden obtenerlo en minutos, en modo autoservicio, con cuotas y políticas de red ya aplicadas. Los equipos de plataforma lo llaman "namespace-as-a-service", y suele ser la razón principal por la que deciden construir multi-tenancy.

Los tres modelos de multi-tenancy

No todos los tenants necesitan el mismo aislamiento. El modelo que elijas es un equilibrio entre el radio de impacto, el costo y la complejidad operativa que decides asumir.

La mayoría de las organizaciones no se queda con un solo modelo. Ejecutan multi-tenancy soft para los equipos internos de confianza y reservan el aislamiento hard o físico para el puñado de tenants (un cliente externo, un equipo de ML intensivo en GPU, un workload regulado) que lo necesita. Tratar la "multi-tenancy" como un simple interruptor de encendido/apagado sobredimensiona o subdimensiona muchos de estos proyectos desde el inicio.

Las capas de aislamiento que sostienen la multi-tenancy soft

La mayoría de los equipos comienza con multi-tenancy soft por defecto. Se construye con cuatro capas, y todas deben configurarse; ninguna viene activada de fábrica.

Los namespaces te dan la frontera a la que se adhiere todo lo demás: un lugar donde acotar el RBAC, las cuotas y las políticas de red. Por sí solos aíslan nombres, no comportamientos. Un pod en el namespace A todavía puede comunicarse con un pod en el namespace B, y un workload sin límites de recursos todavía puede comerse un nodo que los pods del namespace B también usan.

El RBAC decide quién puede actuar sobre qué. Comienza con denegación por defecto, otorga los roles mínimos que el equipo de cada tenant realmente necesita y vincúlalo a grupos en lugar de a usuarios individuales, para que el acceso no se degrade a medida que las personas entran y salen de los equipos. La proliferación de RBAC por tenant (decenas de Roles y RoleBindings casi duplicados que se desincronizan) figura entre las principales razones por las que los clústeres multi-tenant se vuelven más difíciles de auditar con el tiempo.

NetworkPolicy impide que los tenants se comuniquen entre sí a través de la red, algo que ni el RBAC ni los namespaces hacen por sí solos:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

La mayoría de los equipos comienza con una política default-deny por namespace y luego agrega reglas de permiso explícitas para lo que realmente necesita comunicarse entre namespaces. Sin ella, cualquier pod del clúster puede conectarse a cualquier otro pod por defecto. Los namespaces no imponen fronteras de red por sí solos.

ResourceQuotas y LimitRanges evitan que un tenant deje sin CPU, memoria o cupo de objetos al resto del clúster. Una ResourceQuota limita lo que un namespace puede consumir en total; un LimitRange establece valores por defecto y máximos razonables por contenedor dentro de él. La multi-tenancy y el problema del noisy neighbor se cruzan justo aquí: una cuota solo protege al clúster cuando los equipos configuran correctamente los requests y limits que la respaldan, ajustados al uso real. Las cuotas demasiado laxas no detienen a los noisy neighbors; las demasiado estrictas solo empujan a los equipos a sobredimensionar sus solicitudes y a perder los ahorros de consolidación que la multi-tenancy prometía.

Los Pod Security Standards completan el cuadro a nivel de workload, restringiendo por namespace los contenedores privilegiados, la red del host y el acceso root, de modo que un atacante que comprometa un pod en un tenant no pueda escalar hacia el nodo ni hacia el resto del clúster.