Llevamos todo el módulo escribiendo rutas-norte-dev en cada manifiesto y en cada comando, sin habernos detenido a explicar qué es exactamente ese namespace ni qué nos da. Y al final de la lección anterior apareció una propiedad muy interesante: la configuración de api-reservas apunta a redis-cache y a postgres-reservas por su nombre corto, sin mencionar el entorno, porque el DNS lo resuelve dentro del namespace donde corre el pod. Esa propiedad es la que permite desplegar el mismo manifiesto tres veces y obtener tres plataformas independientes. En esta lección montamos los tres entornos de Rutas Norte —rutas-norte-dev, rutas-norte-pre y rutas-norte-pro—, veremos qué aísla un namespace y qué no aísla en absoluto (que es la parte que más incidentes provoca), distinguiremos los recursos con y sin namespace, conoceremos los namespaces del sistema y por qué nunca se despliega en default, trabajaremos cómodamente con -n y con el contexto, resolveremos nombres DNS entre namespaces, y terminaremos con una advertencia muy seria sobre lo que se lleva por delante un kubectl delete namespace.

1. Qué es un namespace y qué aísla
2. Recursos con y sin namespace
3. Los namespaces del sistema y por qué no se despliega en default
4. Los tres entornos de Rutas Norte
5. El mismo manifiesto en varios entornos
6. Trabajar con namespaces sin volverse loco
7. DNS entre namespaces
8. Qué NO garantiza un namespace
9. Borrar un namespace: la orden más peligrosa de kubectl
10. Namespaces frente a clústeres separados

Un namespace es una partición lógica del clúster que agrupa recursos. La definición operativa, la que de verdad sirve:

Un namespace es, sobre todo, un espacio de nombres: dentro de él, el nombre de cada objeto debe ser único; fuera, puede repetirse libremente.

Eso permite que existan simultáneamente tres objetos llamados api-reservas, uno en cada entorno, sin colisionar. Y a partir de ahí se derivan sus demás usos.

Lo que un namespace sí aporta:

Y lo que no aporta, que veremos en detalle en el apartado 8: no aísla la red, no limita recursos por sí solo, no impide el acceso y no separa los nodos.

Fíjate en el detalle clave del diagrama: los objetos con el mismo nombre conviven en namespaces distintos, pero los nodos son compartidos. Un pod de rutas-norte-dev y otro de rutas-norte-pre pueden acabar en la misma máquina.

No todos los objetos de Kubernetes viven dentro de un namespace. Los hay que pertenecen al clúster entero, y confundirlos genera errores desconcertantes.

La forma de saberlo con certeza, sin memorizar nada:

La lógica detrás del reparto es coherente: lo que representa infraestructura física o configuración global del clúster no lleva namespace; lo que representa carga de trabajo o configuración de aplicación, sí.

Dos parejas merecen atención porque son fuente constante de confusión:

• PersistentVolume (sin namespace) frente a PersistentVolumeClaim (con namespace). El disco es un recurso del clúster; la reclamación de ese disco pertenece a una aplicación concreta en un namespace. Módulo 5.
• Role/RoleBinding (con namespace) frente a ClusterRole/ClusterRoleBinding (sin namespace). Los primeros conceden permisos dentro de un namespace; los segundos, en todo el clúster. Módulo 8.

Un error práctico derivado de esto:

El -n se ha ignorado en silencio. Los nodos no tienen namespace, así que el flag no filtra nada. No es un error, pero puede hacerte creer que estás viendo algo filtrado cuando no lo estás.

Todo clúster nace con cuatro namespaces:

Echa un vistazo a kube-system para ver el clúster por dentro:

Ahí están, corriendo como pods, todos los componentes que estudiaste en Arquitectura de Kubernetes. El plano de control de tu minikube es visible y palpable.

kube-node-lease explica algo que quizá te preguntaste: cómo sabe el plano de control si un nodo sigue vivo.

El kubelet renueva ese objeto cada pocos segundos. Si deja de hacerlo, el nodo se marca NotReady.

Es el namespace que Kubernetes usa cuando no dices nada, y precisamente por eso es un mal sitio para trabajar:

1. Es el vertedero del clúster. Todo lo que alguien aplique sin -n acaba ahí. En pocos meses es un cajón de sastre donde nadie sabe qué es de quién.
2. No se puede borrar. Los namespaces del sistema son indestructibles, así que no puedes limpiarlo de un golpe como harías con rutas-norte-dev.
3. Los accidentes son fáciles. Un kubectl delete deploy --all sin -n, ejecutado creyendo estar en otro sitio, se lleva por delante lo que haya en default.
4. Imposibilita el aislamiento. Si todo está en default, no puedes aplicar cuotas por equipo, ni RBAC por entorno, ni políticas de red diferenciadas.
5. Impide reutilizar nombres. Con todo en un mismo namespace, api-reservas de desarrollo y de producción no pueden coexistir.

La regla del proyecto es explícita:

En Rutas Norte, default está prohibido. Todo objeto vive en un namespace nombrado, declarado en su propio manifiesto.

Ha llegado el momento de crear la estructura completa. Ya conoces rutas-norte-dev del módulo 1; le añadimos preproducción y producción, de forma declarativa y en un solo fichero.

En YAML, --- separa varios documentos dentro de un mismo fichero. Es la forma habitual de agrupar objetos relacionados:

Fíjate en dos decisiones deliberadas:

• Los namespaces llevan etiquetas. No es decorativo: en el módulo 4, las NetworkPolicies seleccionarán namespaces por la etiqueta entorno, y así una política podrá decir "solo acepto tráfico de pods del mismo entorno".
• Producción lleva anotaciones informativas. Cualquiera que haga kubectl describe ns rutas-norte-pro sabrá a quién avisar y qué reglas rigen.

La estructura del repositorio que ya tenemos definida encaja de forma natural:

Cómo se combinan base y entornos sin duplicar YAML es trabajo de Kustomize o Helm, en 10-04 y 10-03. En este módulo lo haremos de la forma más simple posible.

Aquí está la propiedad que hace valiosos los namespaces. Vamos a desplegar tienda-web y su Service en preproducción usando exactamente los mismos ficheros que en desarrollo.

Nuestros manifiestos llevan namespace: rutas-norte-dev escrito dentro, así que hay dos formas de llevarlos a otro entorno.

Opción A: quitar el namespace del manifiesto y decidirlo al aplicar.

Opción B: mantener el namespace en el manifiesto y sustituirlo al desplegar. Es lo que harán Kustomize o Helm por ti; a mano se vería así:

Hay una regla importante que conviene conocer: si un manifiesto declara metadata.namespace y además pasas -n con otro valor distinto, kubectl da error en lugar de elegir por su cuenta.

Es un comportamiento deseable: evita desplegar en producción por accidente.

Hagámoslo con la opción B, que respeta nuestros manifiestos actuales:

Ahora observa la situación completa del clúster:

Dos plataformas Rutas Norte completas, con los mismos nombres de Deployment y de Service, conviviendo sin la menor colisión. Ese es el valor central del namespace.

Y una comprobación que ilustra el aislamiento de nombres:

Mismo nombre, dos objetos distintos, dos IPs virtuales distintas.

Escribir -n rutas-norte-dev cien veces al día es tedioso y, peor, olvidarlo es la vía rápida a un accidente.

-A es imprescindible cuando buscas algo y no recuerdas dónde está:

Es la opción que más tiempo ahorra. Modifica tu kubeconfig para que todos los comandos usen ese namespace por defecto:

Y la comprobación que deberías hacer un reflejo antes de cualquier comando destructivo:

Consejo muy recomendable: configura el prompt de tu terminal para mostrar contexto y namespace. Herramientas como kube-ps1 lo hacen, y ver (rutas-norte:rutas-norte-pro) en pantalla antes de teclear delete ha salvado muchas tardes.

Del conjunto kubectx, kubens cambia de namespace de forma interactiva:

Es azúcar sintáctico sobre kubectl config set-context, pero con listado interactivo y salto rápido al anterior. Se instala como binario suelto o mediante krew, el gestor de plugins de kubectl que vimos en La CLI de Kubernetes.

Vuelve a desarrollo antes de continuar:

Ya conoces el nombre completo de un Service: <servicio>.<namespace>.svc.cluster.local. Los namespaces son la razón de que exista esa estructura.

Cuando un pod resuelve un nombre, el DNS del clúster prueba una serie de sufijos de búsqueda en orden. Míralos en un pod real:

La primera línea explica todo el comportamiento: al buscar redis-cache, el pod prueba primero redis-cache.rutas-norte-dev.svc.cluster.local. Como existe, ahí termina. El nombre corto siempre resuelve dentro del propio namespace.

Compruébalo:

Aquí hay dos noticias. La buena: el mismo manifiesto de api-reservas, con DATABASE_HOST: postgres-reservas, funciona en los tres entornos y cada uno habla con su propia base de datos, sin condicionales ni plantillas.

La mala, y es importante: un pod de desarrollo acaba de resolver y podría conectarse a un Service de preproducción. Nada se lo impide. Eso nos lleva directamente al apartado siguiente.

Este es el apartado que evita incidentes. La creencia de que "cada equipo en su namespace y así están aislados" es peligrosamente falsa.

Por defecto, cualquier pod de cualquier namespace puede conectarse a cualquier pod o Service de cualquier otro namespace. El modelo de red plano de Kubernetes es explícito en esto: todos los pods se ven entre sí.

Demostración incómoda: un pod de desarrollo escribiendo en la caché de preproducción.

Acabamos de poner a cero las plazas disponibles en la caché de preproducción desde desarrollo. Si hubiera sido rutas-norte-pro, sería un incidente serio. Y nadie ha necesitado permisos especiales: ha bastado con conocer el nombre.

La solución no es el namespace, son las NetworkPolicies de 04-06, que sí permiten declarar reglas del tipo "postgres-reservas solo acepta conexiones de pods con la etiqueta app=api-reservas del mismo namespace".

Crear un namespace no restringe quién puede hacer qué en él. Si tus credenciales tienen permisos amplios sobre el clúster, los tienes sobre todos los namespaces, existentes y futuros.

Con un usuario de administrador, la respuesta es yes para cualquier namespace. El aislamiento de permisos lo dan los Role y RoleBinding de RBAC. El namespace es solo el ámbito sobre el que esas reglas se aplican: necesario, pero no suficiente.

Un namespace no impone ningún techo. Un Deployment mal configurado en rutas-norte-dev puede consumir toda la CPU y la memoria del clúster y dejar sin recursos a los pods de rutas-norte-pro, porque comparten los mismos nodos.

Esas dos líneas finales lo dicen todo: sin cuota y sin límites. Ponerlos es materia de Cuotas y Límites de Recursos y LimitRanges y QoS.

Los pods de todos los namespaces se reparten por los mismos nodos. Un pod de desarrollo y uno de producción pueden ser vecinos en la misma máquina, compartiendo CPU, memoria y disco.

Separar cargas por nodos requiere taints, tolerations y afinidad (06-05).

La frase que resume el apartado: el namespace es el ámbito sobre el que se aplican los mecanismos de aislamiento, no el mecanismo de aislamiento. Sin cuotas, RBAC y políticas de red encima, un namespace es solo una carpeta.

Ese comando borra todo lo que hay dentro: Deployments, ReplicaSets, Pods, Services, ConfigMaps, Secrets, PersistentVolumeClaims, ServiceAccounts, Roles... Y con los PVC se van, según la política de recuperación, los datos.

Características que lo hacen especialmente peligroso:

• No pide confirmación. Ninguna.
• No hay deshacer. No existe papelera ni kubectl undelete.
• Es asíncrono. El namespace pasa a estado Terminating mientras se borra el contenido, y en ese estado no admite objetos nuevos.
• Un error de tecleo es catastrófico. rutas-norte-pro en lugar de rutas-norte-pre son tres caracteres de diferencia.

Míralo en acción, con un namespace de usar y tirar:

El pod se fue con él, sin preguntar nada.

Un problema que encontrarás tarde o temprano: un namespace que se queda en Terminating indefinidamente. La causa casi siempre es un finalizer —esos ganchos que estudiamos en Objetos y Manifiestos— que no puede completarse, típicamente el de una API extendida cuyo servidor ya no existe.

Antes de forzar nada, averigua qué recurso está bloqueando, porque quitar el finalizer a lo bruto deja objetos huérfanos en etcd. La forma correcta es eliminar el recurso conflictivo o restaurar el servicio que debe procesarlo.

1. Etiquetar y anotar producción, como hicimos en namespaces.yaml: al describir el namespace se lee el aviso.
2. RBAC restrictivo: nadie tiene permiso de delete namespaces en rutas-norte-pro salvo un par de personas (08-01).
3. Verificar el contexto antes de cualquier borrado, con el reflejo del apartado 6.
4. Copias de seguridad: la única red real. Herramientas como Velero permiten restaurar un namespace entero, y es materia de Copias de Seguridad y Restauración.
5. Comprobar antes de disparar, siempre:

Un buen hábito adicional: usar --dry-run=client mentalmente. Antes de borrar, pregúntate en voz alta qué namespace estás mirando.

Deja preproducción montada, la seguiremos usando:

La pregunta estratégica: ¿deben los tres entornos de Rutas Norte vivir en un clúster con tres namespaces, o en tres clústeres separados?

Criterios prácticos de decisión:

Namespaces en un clúster cuando:

• Los entornos son de confianza equivalente (dev y pre del mismo equipo).
• El equipo es pequeño y el presupuesto limitado.
• Se domina RBAC, cuotas y políticas de red.

Clústeres separados cuando:

• Hay datos regulados: personales, sanitarios, financieros.
• Se ofrece servicio a clientes que no confían entre sí (multi-tenant real).
• Se necesitan versiones distintas de Kubernetes o de componentes del clúster.
• Un fallo de producción no puede depender de la salud de un entorno de pruebas.

La empresa tiene datos personales de clientes —nombre, DNI, teléfono y correo— en postgres-reservas. La decisión, y su porqué:

Es decir: dos clústeres, tres namespaces. El namespace rutas-norte-pro existe también en el clúster de no producción para que los manifiestos sean idénticos y se pueda ensayar el despliegue, pero la producción real vive aparte.

Durante el curso trabajaremos con un solo minikube y los tres namespaces, que es lo práctico para aprender. La gestión de varios clústeres a la vez, con sus contextos y sus herramientas, se trata en Gestión Multi-Clúster.

Un último apunte sobre cómo organizar namespaces: por entorno (lo que hacemos), por equipo (equipo-pagos, equipo-rutas) o por aplicación (rutas-norte, intranet). Lo habitual es combinar dos ejes: rutas-norte-pro, intranet-pro. Lo que nunca funciona es un namespace por microservicio: multiplica la burocracia sin aportar aislamiento útil.

• Desplegar en default por olvido. El síntoma es kubectl get pods sin resultados donde esperabas verlos. Comprueba con kubectl get pods -A -l app=<componente>.
• Creer que un namespace aísla la red. No lo hace. Cualquier pod puede conectarse a cualquier Service de otro namespace conociendo su nombre.
• Creer que un namespace aísla permisos o recursos. Hacen falta RBAC y ResourceQuota. El namespace es el ámbito, no el mecanismo.
• Poner -n a un recurso sin namespace. kubectl get nodes -n loquesea ignora el flag en silencio y puede confundirte.
• Discrepancia entre metadata.namespace y -n. kubectl da error en lugar de decidir por ti. Es una protección, no un fastidio.
• Buscar en el namespace equivocado y concluir que algo no existe. Ante la duda, -A.
• Borrar un namespace sin mirar qué contiene. No hay confirmación ni deshacer. kubectl get all -n <ns> antes, siempre.
• Forzar el borrado de un namespace atascado quitándole los finalizers. Deja objetos huérfanos en etcd. Investiga primero qué recurso bloquea.
• Un namespace por microservicio. Multiplica la carga administrativa sin aportar aislamiento real. Organiza por entorno, equipo o aplicación.
• Consejo: configura el prompt para mostrar contexto y namespace (kube-ps1). Ver (rutas-norte:rutas-norte-pro) antes de teclear delete evita accidentes.
• Consejo: declara metadata.namespace en los manifiestos que sean específicos de un entorno y omítelo en los que sean genéricos. La ambigüedad es lo que provoca despliegues en el sitio equivocado.
• Consejo: etiqueta siempre tus namespaces. Las NetworkPolicies del módulo 4 seleccionarán namespaces por etiqueta, y sin ellas tendrás que volver atrás a ponerlas.

1. Con un solo comando, cuenta cuántos tipos de recursos tienen namespace y cuántos no.
2. Determina, sin consultar tablas, si estos recursos llevan namespace: PersistentVolume, PersistentVolumeClaim, Role, ClusterRole, Ingress, StorageClass.
3. Lista los pods de kube-system e identifica cuáles son los cinco componentes del plano de control que estudiaste en el módulo 1.
4. Averigua qué hay dentro de kube-public y explica qué tiene de particular ese namespace.

1. Despliega tienda-web (Deployment y Service) en rutas-norte-pro, con la etiqueta entorno: pro en lugar de dev.
2. Demuestra con un solo comando que existen tres Deployments llamados tienda-web en el clúster, en namespaces distintos.
3. Comprueba que las ClusterIP de los tres Services tienda-web son diferentes.
4. Desde un pod efímero en rutas-norte-dev, haz una petición HTTP al tienda-web de rutas-norte-pro usando el nombre DNS completo. ¿Funciona? Explica qué implica esto y qué objeto habría que crear para impedirlo.

Te incorporas al equipo de plataforma de Rutas Norte y te encargan una auditoría rápida del clúster. Responde con comandos y su salida:

1. ¿Qué namespaces existen y cuáles pertenecen a la plataforma Rutas Norte?
2. ¿Hay algún objeto desplegado en default? Si lo hay, muévelo al namespace correcto.
3. ¿Qué namespaces tienen ResourceQuota definida? ¿Qué implica que no la tengan?
4. ¿Puedes borrar el namespace de producción con tus credenciales actuales? ¿Qué mecanismo debería impedirlo y en qué lección se estudia?
5. Elabora una tabla con los tres entornos indicando: número de pods, número de Services y si tienen cuota.

Solución 1

Los números varían según los CRDs y addons instalados en tu clúster.

2. El razonamiento, antes de comprobarlo: lleva namespace lo que pertenece a una aplicación concreta; no lo lleva lo que es infraestructura o configuración global.

Los cinco: kube-apiserver (la única puerta a la API), etcd (el almacén de estado), kube-scheduler (asigna pods a nodos), kube-controller-manager (donde viven los controladores de ReplicaSet, Deployment, endpoints...) y CoreDNS (que resuelve los nombres de Service que usamos en la lección anterior).

kube-public es el único namespace legible sin autenticarse: cualquiera que alcance el apiserver puede leer su contenido. Contiene cluster-info, con los datos que un nodo necesita para unirse al clúster durante el proceso de kubeadm join. Por eso nunca debe guardarse nada sensible ahí.

Solución 2

Funciona. Un pod de desarrollo ha accedido sin ningún obstáculo a un servicio de producción. Implicación directa: el namespace no es una frontera de red. En el modelo por defecto de Kubernetes, todos los pods se ven entre sí, y basta conocer el nombre DNS para conectarse.

Para impedirlo hace falta una NetworkPolicy en rutas-norte-pro que rechace todo el tráfico entrante salvo el que proceda de namespaces con la etiqueta entorno: pro (por eso etiquetamos los namespaces al crearlos). Es el contenido de Políticas de Red y Seguridad de Red.

Solución 3

La etiqueta común permite distinguir de un vistazo los namespaces de la plataforma de los del sistema.

Solo aparece service/kubernetes, que es el Service del propio apiserver y debe estar ahí: es el que permite a los pods hablar con la API. Si hubiera cualquier otra cosa, el procedimiento sería exportarla, corregir su namespace y volver a aplicarla:

Ningún namespace tiene cuota. Implicación: cualquier Deployment de rutas-norte-dev puede consumir toda la CPU y la memoria del clúster y dejar sin recursos a los pods de rutas-norte-pro, porque comparten nodos. Un bucle mal escrito en desarrollo puede tumbar la producción. Se corrige con ResourceQuota y LimitRange en 03-04 y 03-05.

Sí puedo borrarlo, y con él toda la producción, sin confirmación y sin deshacer. Lo que debería impedirlo es RBAC: un Role/ClusterRole que no incluya el verbo delete sobre namespaces para las credenciales habituales, dejando ese permiso a un rol de emergencia usado por dos personas. Se estudia en Control de Acceso Basado en Roles. Como red de seguridad complementaria, copias de seguridad con Velero (05-06).

Los namespaces han dejado de ser esa palabra que repetíamos en cada comando. Sabes que su función nativa es la unicidad de nombres, y que de ella se derivan el ámbito de las consultas, de los selectores, del DNS corto, de las cuotas, del RBAC y de las políticas de red. Distingues los recursos que llevan namespace —pods, Deployments, Services, ConfigMaps, Secrets, PVCs— de los que pertenecen al clúster entero —nodos, PersistentVolumes, StorageClasses, ClusterRoles—, y sabes averiguarlo en cualquier momento con kubectl api-resources --namespaced. Conoces los cuatro namespaces del sistema, has visto el plano de control corriendo como pods en kube-system, y tienes claro por qué default es un vertedero en el que Rutas Norte no despliega nada.

Has montado los tres entornos del proyecto de forma declarativa y con etiquetas que las NetworkPolicies aprovecharán después, y has desplegado los mismos manifiestos en varios de ellos comprobando que tienda-web y api-reservas conviven con idéntico nombre en namespaces distintos, cada uno con su propia ClusterIP y hablando con su propia base de datos gracias al DNS corto. Trabajas con -n, con -A y fijando el namespace del contexto, con el reflejo de verificar dónde estás antes de cualquier comando destructivo.

Y te llevas las dos advertencias que más incidentes evitan. La primera: un namespace no aísla nada por sí solo. No es frontera de red —lo has demostrado escribiendo en la caché de preproducción desde desarrollo y llamando a producción desde un pod de dev—, no es frontera de permisos, no limita recursos y no separa nodos. Es el ámbito sobre el que se aplican cuotas, RBAC y políticas de red, que llegarán en los módulos 3, 4 y 8. La segunda: kubectl delete namespace se lo lleva todo sin confirmación y sin marcha atrás, motivo por el cual producción real de Rutas Norte vive en un clúster aparte.

Queda un hilo suelto que ha recorrido todo el módulo. Los selectores de los ReplicaSets, los selectores de los Services, la etiqueta entorno de los namespaces, la anotación kubernetes.io/change-cause del historial de revisiones, el pod-template-hash que el Deployment añade solo, las consultas con -l que llevamos usando desde la primera lección... Todo eso son etiquetas y anotaciones, y hasta ahora las hemos ido usando sin sistematizar. En Etiquetas, Selectores y Anotaciones, la lección que cierra el módulo, pondremos orden: sintaxis y restricciones, etiquetas recomendadas por Kubernetes, el esquema de etiquetado definitivo de los seis componentes de Rutas Norte en sus tres entornos, selectores de igualdad y de conjunto, y las consultas del día a día que convierten un clúster grande en algo navegable.