Portem tot el mòdul escrivint rutas-norte-dev a cada manifest i a cada ordre, sense haver-nos aturat a explicar què és exactament aquell namespace ni què ens dona. I al final de la lliçó anterior va aparèixer una propietat molt interessant: la configuració d'api-reserves apunta a redis-cache i a postgres-reserves pel seu nom curt, sense esmentar l'entorn, perquè el DNS ho resol dins del namespace on corre el pod. Aquella propietat és la que permet desplegar el mateix manifest tres vegades i obtenir tres plataformes independents. En aquesta lliçó muntem els tres entorns de Rutas Norte —rutas-norte-dev, rutas-norte-pre i rutas-norte-pro—, veurem què aïlla un namespace i què no aïlla en absolut (que és la part que més incidents provoca), distingirem els recursos amb i sense namespace, coneixerem els namespaces del sistema i per què mai no es desplega a default, treballarem còmodament amb -n i amb el context, resoldrem noms DNS entre namespaces, i acabarem amb un advertiment molt seriós sobre el que s'endú per davant un kubectl delete namespace.

1. Què és un namespace i què aïlla
2. Recursos amb i sense namespace
3. Els namespaces del sistema i per què no es desplega a default
4. Els tres entorns de Rutas Norte
5. El mateix manifest en diversos entorns
6. Treballar amb namespaces sense tornar-se boig
7. DNS entre namespaces
8. Què NO garanteix un namespace
9. Esborrar un namespace: l'ordre més perillosa de kubectl
10. Namespaces enfront de clústers separats

Un namespace és una partició lògica del clúster que agrupa recursos. La definició operativa, la que de debò serveix:

Un namespace és, sobretot, un espai de noms: dins d'ell, el nom de cada objecte ha de ser únic; fora, es pot repetir lliurement.

Això permet que existeixin simultàniament tres objectes anomenats api-reserves, un a cada entorn, sense col·lidir. I a partir d'aquí se'n deriven la resta d'usos.

El que un namespace sí que aporta:

I el que no aporta, que veurem en detall a l'apartat 8: no aïlla la xarxa, no limita recursos per si sol, no impedeix l'accés i no separa els nodes.

Fixa't en el detall clau del diagrama: els objectes amb el mateix nom conviuen en namespaces diferents, però els nodes són compartits. Un pod de rutas-norte-dev i un altre de rutas-norte-pre poden acabar a la mateixa màquina.

No tots els objectes de Kubernetes viuen dins d'un namespace. N'hi ha que pertanyen al clúster sencer, i confondre'ls genera errors desconcertants.

La manera de saber-ho amb certesa, sense memoritzar res:

La lògica del repartiment és coherent: allò que representa infraestructura física o configuració global del clúster no porta namespace; allò que representa càrrega de treball o configuració d'aplicació, sí.

Dues parelles mereixen atenció perquè són font constant de confusió:

• PersistentVolume (sense namespace) enfront de PersistentVolumeClaim (amb namespace). El disc és un recurs del clúster; la reclamació d'aquell disc pertany a una aplicació concreta en un namespace. Mòdul 5.
• Role/RoleBinding (amb namespace) enfront de ClusterRole/ClusterRoleBinding (sense namespace). Els primers concedeixen permisos dins d'un namespace; els segons, a tot el clúster. Mòdul 8.

Un error pràctic derivat d'això:

El -n s'ha ignorat en silenci. Els nodes no tenen namespace, així que el flag no filtra res. No és un error, però pot fer-te creure que estàs veient alguna cosa filtrada quan no ho està.

Tot clúster neix amb quatre namespaces:

Fes una ullada a kube-system per veure el clúster per dins:

Aquí els tens, corrent com a pods, tots els components que vas estudiar a Arquitectura de Kubernetes. El pla de control del teu minikube és visible i palpable.

kube-node-lease explica una cosa que potser et vas preguntar: com sap el pla de control si un node continua viu.

El kubelet renova aquell objecte cada pocs segons. Si deixa de fer-ho, el node es marca NotReady.

És el namespace que Kubernetes fa servir quan no dius res, i precisament per això és un mal lloc per treballar:

1. És l'abocador del clúster. Tot el que algú apliqui sense -n hi acaba. En pocs mesos és un calaix de sastre on ningú no sap què és de qui.
2. No es pot esborrar. Els namespaces del sistema són indestructibles, així que no el pots netejar d'un cop com faries amb rutas-norte-dev.
3. Els accidents són fàcils. Un kubectl delete deploy --all sense -n, executat creient ser en un altre lloc, s'endú per davant el que hi hagi a default.
4. Impossibilita l'aïllament. Si tot és a default, no pots aplicar quotes per equip, ni RBAC per entorn, ni polítiques de xarxa diferenciades.
5. Impedeix reutilitzar noms. Amb tot en un mateix namespace, api-reserves de desenvolupament i de producció no poden coexistir.

La regla del projecte és explícita:

A Rutas Norte, default està prohibit. Tot objecte viu en un namespace anomenat, declarat al seu propi manifest.

Ha arribat el moment de crear l'estructura completa. Ja coneixes rutas-norte-dev del mòdul 1; hi afegim preproducció i producció, de forma declarativa i en un sol fitxer.

En YAML, --- separa diversos documents dins d'un mateix fitxer. És la manera habitual d'agrupar objectes relacionats:

Fixa't en dues decisions deliberades:

• Els namespaces porten etiquetes. No és decoratiu: al mòdul 4, les NetworkPolicies seleccionaran namespaces per l'etiqueta entorn, i així una política podrà dir "només accepto trànsit de pods del mateix entorn".
• Producció porta anotacions informatives. Qualsevol que faci kubectl describe ns rutas-norte-pro sabrà a qui avisar i quines regles hi regeixen.

L'estructura del repositori que ja tenim definida hi encaixa de manera natural:

Com es combinen base i entorns sense duplicar YAML és feina de Kustomize o Helm, a 10-04 i 10-03. En aquest mòdul ho farem de la manera més simple possible.

Aquí hi ha la propietat que fa valuosos els namespaces. Desplegarem botiga-web i el seu Service a preproducció fent servir exactament els mateixos fitxers que a desenvolupament.

Els nostres manifests porten namespace: rutas-norte-dev escrit a dins, així que hi ha dues maneres de portar-los a un altre entorn.

Opció A: treure el namespace del manifest i decidir-lo en aplicar.

Opció B: mantenir el namespace al manifest i substituir-lo en desplegar. És el que faran Kustomize o Helm per tu; a mà es veuria així:

Hi ha una regla important que convé conèixer: si un manifest declara metadata.namespace i a més hi passes -n amb un valor diferent, kubectl dona error en lloc de triar pel seu compte.

És un comportament desitjable: evita desplegar a producció per accident.

Fem-ho amb l'opció B, que respecta els nostres manifests actuals:

Ara observa la situació completa del clúster:

Dues plataformes Rutas Norte completes, amb els mateixos noms de Deployment i de Service, convivint sense la menor col·lisió. Aquest és el valor central del namespace.

I una comprovació que il·lustra l'aïllament de noms:

Mateix nom, dos objectes diferents, dues IPs virtuals diferents.

Escriure -n rutas-norte-dev cent vegades al dia és tediós i, pitjor, oblidar-ho és la via ràpida a un accident.

-A és imprescindible quan busques alguna cosa i no recordes on és:

És l'opció que més temps estalvia. Modifica el teu kubeconfig perquè totes les ordres facin servir aquell namespace per defecte:

I la comprovació que hauries de convertir en un reflex abans de qualsevol ordre destructiva:

Consell molt recomanable: configura el prompt de la teva terminal perquè mostri context i namespace. Eines com kube-ps1 ho fan, i veure (rutas-norte:rutas-norte-pro) a la pantalla abans de teclejar delete ha salvat moltes tardes.

Del conjunt kubectx, kubens canvia de namespace de forma interactiva:

És sucre sintàctic sobre kubectl config set-context, però amb llistat interactiu i salt ràpid a l'anterior. S'instal·la com a binari solt o mitjançant krew, el gestor de connectors de kubectl que vam veure a La CLI de Kubernetes.

Torna a desenvolupament abans de continuar:

Ja coneixes el nom complet d'un Service: <servei>.<namespace>.svc.cluster.local. Els namespaces són la raó que existeixi aquella estructura.

Quan un pod resol un nom, el DNS del clúster prova una sèrie de sufixos de cerca en ordre. Mira'ls en un pod real:

La primera línia explica tot el comportament: en buscar redis-cache, el pod prova primer redis-cache.rutas-norte-dev.svc.cluster.local. Com que existeix, allà s'acaba. El nom curt sempre resol dins del propi namespace.

Comprova-ho:

Aquí hi ha dues notícies. La bona: el mateix manifest d'api-reserves, amb DATABASE_HOST: postgres-reserves, funciona als tres entorns i cadascun parla amb la seva pròpia base de dades, sense condicionals ni plantilles.

La dolenta, i és important: un pod de desenvolupament acaba de resoldre i es podria connectar a un Service de preproducció. No hi ha res que ho impedeixi. Això ens porta directament a l'apartat següent.

Aquest és l'apartat que evita incidents. La creença que "cada equip al seu namespace i així estan aïllats" és perillosament falsa.

Per defecte, qualsevol pod de qualsevol namespace es pot connectar a qualsevol pod o Service de qualsevol altre namespace. El model de xarxa pla de Kubernetes és explícit en això: tots els pods es veuen entre ells.

Demostració incòmoda: un pod de desenvolupament escrivint a la memòria cau de preproducció.

Acabem de posar a zero les places disponibles a la memòria cau de preproducció des de desenvolupament. Si hagués estat rutas-norte-pro, seria un incident seriós. I ningú no ha necessitat permisos especials: n'hi ha hagut prou amb conèixer el nom.

La solució no és el namespace, són les NetworkPolicies de 04-06, que sí que permeten declarar regles del tipus "postgres-reserves només accepta connexions de pods amb l'etiqueta app=api-reserves del mateix namespace".

Crear un namespace no restringeix qui pot fer què dins d'ell. Si les teves credencials tenen permisos amplis sobre el clúster, els tens sobre tots els namespaces, existents i futurs.

Amb un usuari d'administrador, la resposta és yes per a qualsevol namespace. L'aïllament de permisos el donen els Role i RoleBinding de RBAC. El namespace és només l'àmbit sobre el qual aquelles regles s'apliquen: necessari, però no suficient.

Un namespace no imposa cap sostre. Un Deployment mal configurat a rutas-norte-dev pot consumir tota la CPU i la memòria del clúster i deixar sense recursos els pods de rutas-norte-pro, perquè comparteixen els mateixos nodes.

Aquelles dues línies finals ho diuen tot: sense quota i sense límits. Posar-los és matèria de Quotes i Límits de Recursos i LimitRanges i QoS.

Els pods de tots els namespaces es reparteixen pels mateixos nodes. Un pod de desenvolupament i un de producció poden ser veïns a la mateixa màquina, compartint CPU, memòria i disc.

Separar càrregues per nodes requereix taints, toleracions i afinitat (06-05).

La frase que resumeix l'apartat: el namespace és l'àmbit sobre el qual s'apliquen els mecanismes d'aïllament, no el mecanisme d'aïllament. Sense quotes, RBAC i polítiques de xarxa a sobre, un namespace és només una carpeta.

Aquella ordre esborra tot el que hi ha a dins: Deployments, ReplicaSets, Pods, Services, ConfigMaps, Secrets, PersistentVolumeClaims, ServiceAccounts, Roles... I amb els PVC se'n van, segons la política de recuperació, les dades.

Característiques que la fan especialment perillosa:

• No demana confirmació. Cap.
• No hi ha desfer. No existeix paperera ni kubectl undelete.
• És asíncrona. El namespace passa a estat Terminating mentre s'esborra el contingut, i en aquell estat no admet objectes nous.
• Un error de teclat és catastròfic. rutas-norte-pro en lloc de rutas-norte-pre són tres caràcters de diferència.

Mira-ho en acció, amb un namespace d'usar i llençar:

El pod se'n va anar amb ell, sense preguntar res.

Un problema que trobaràs tard o d'hora: un namespace que es queda en Terminating indefinidament. La causa és gairebé sempre un finalizer —aquells ganxos que vam estudiar a Objectes i Manifests— que no es pot completar, típicament el d'una API estesa el servidor de la qual ja no existeix.

Abans de forçar res, esbrina quin recurs està bloquejant, perquè treure el finalizer a la brava deixa objectes orfes a etcd. La manera correcta és eliminar el recurs conflictiu o restaurar el servei que l'ha de processar.

1. Etiquetar i anotar producció, com vam fer a namespaces.yaml: en descriure el namespace es llegeix l'avís.
2. RBAC restrictiu: ningú no té permís de delete namespaces a rutas-norte-pro tret d'un parell de persones (08-01).
3. Verificar el context abans de qualsevol esborrat, amb el reflex de l'apartat 6.
4. Còpies de seguretat: l'única xarxa real. Eines com Velero permeten restaurar un namespace sencer, i és matèria de Còpies de Seguretat i Restauració.
5. Comprovar abans de disparar, sempre:

Un bon hàbit addicional: fer servir --dry-run=client mentalment. Abans d'esborrar, pregunta't en veu alta quin namespace estàs mirant.

Deixa preproducció muntada, la continuarem fent servir:

La pregunta estratègica: han de viure els tres entorns de Rutas Norte en un clúster amb tres namespaces, o en tres clústers separats?

Criteris pràctics de decisió:

Namespaces en un clúster quan:

• Els entorns són de confiança equivalent (dev i pre del mateix equip).
• L'equip és petit i el pressupost limitat.
• Es domina RBAC, quotes i polítiques de xarxa.

Clústers separats quan:

• Hi ha dades regulades: personals, sanitàries, financeres.
• S'ofereix servei a clients que no es fien entre ells (multi-tenant real).
• Calen versions diferents de Kubernetes o de components del clúster.
• Una fallada de producció no pot dependre de la salut d'un entorn de proves.

L'empresa té dades personals de clients —nom, DNI, telèfon i correu— a postgres-reserves. La decisió, i el seu perquè:

És a dir: dos clústers, tres namespaces. El namespace rutas-norte-pro existeix també al clúster de no producció perquè els manifests siguin idèntics i es pugui assajar el desplegament, però la producció real viu a part.

Durant el curs treballarem amb un sol minikube i els tres namespaces, que és el pràctic per aprendre. La gestió de diversos clústers alhora, amb els seus contextos i les seves eines, es tracta a Gestió Multi-Clúster.

Un últim apunt sobre com organitzar namespaces: per entorn (el que fem), per equip (equip-pagaments, equip-rutes) o per aplicació (rutas-norte, intranet). L'habitual és combinar dos eixos: rutas-norte-pro, intranet-pro. El que mai no funciona és un namespace per microservei: multiplica la burocràcia sense aportar aïllament útil.

• Desplegar a default per oblit. El símptoma és kubectl get pods sense resultats on esperaves veure'ls. Comprova-ho amb kubectl get pods -A -l app=<component>.
• Creure que un namespace aïlla la xarxa. No ho fa. Qualsevol pod es pot connectar a qualsevol Service d'un altre namespace coneixent-ne el nom.
• Creure que un namespace aïlla permisos o recursos. Calen RBAC i ResourceQuota. El namespace és l'àmbit, no el mecanisme.
• Posar -n a un recurs sense namespace. kubectl get nodes -n elquesigui ignora el flag en silenci i et pot confondre.
• Discrepància entre metadata.namespace i -n. kubectl dona error en lloc de decidir per tu. És una protecció, no una molèstia.
• Buscar al namespace equivocat i concloure que alguna cosa no existeix. Davant del dubte, -A.
• Esborrar un namespace sense mirar què conté. No hi ha confirmació ni desfer. kubectl get all -n <ns> abans, sempre.
• Forçar l'esborrat d'un namespace encallat traient-li els finalizers. Deixa objectes orfes a etcd. Investiga primer quin recurs el bloqueja.
• Un namespace per microservei. Multiplica la càrrega administrativa sense aportar aïllament real. Organitza per entorn, equip o aplicació.
• Consell: configura el prompt perquè mostri context i namespace (kube-ps1). Veure (rutas-norte:rutas-norte-pro) abans de teclejar delete evita accidents.
• Consell: declara metadata.namespace als manifests que siguin específics d'un entorn i omet-lo als que siguin genèrics. L'ambigüitat és el que provoca desplegaments al lloc equivocat.
• Consell: etiqueta sempre els teus namespaces. Les NetworkPolicies del mòdul 4 seleccionaran namespaces per etiqueta, i sense elles hauràs de tornar enrere a posar-les.

1. Amb una sola ordre, compta quants tipus de recursos tenen namespace i quants no.
2. Determina, sense consultar taules, si aquests recursos porten namespace: PersistentVolume, PersistentVolumeClaim, Role, ClusterRole, Ingress, StorageClass.
3. Llista els pods de kube-system i identifica quins són els cinc components del pla de control que vas estudiar al mòdul 1.
4. Esbrina què hi ha dins de kube-public i explica què té de particular aquell namespace.

1. Desplega botiga-web (Deployment i Service) a rutas-norte-pro, amb l'etiqueta entorn: pro en lloc de dev.
2. Demostra amb una sola ordre que existeixen tres Deployments anomenats botiga-web al clúster, en namespaces diferents.
3. Comprova que les ClusterIP dels tres Services botiga-web són diferents.
4. Des d'un pod efímer a rutas-norte-dev, fes una petició HTTP al botiga-web de rutas-norte-pro fent servir el nom DNS complet. Funciona? Explica què implica això i quin objecte caldria crear per impedir-ho.

T'incorpores a l'equip de plataforma de Rutas Norte i t'encarreguen una auditoria ràpida del clúster. Respon amb ordres i la seva sortida:

1. Quins namespaces existeixen i quins pertanyen a la plataforma Rutas Norte?
2. Hi ha algun objecte desplegat a default? Si n'hi ha, mou-lo al namespace correcte.
3. Quins namespaces tenen ResourceQuota definida? Què implica que no en tinguin?
4. Pots esborrar el namespace de producció amb les teves credencials actuals? Quin mecanisme ho hauria d'impedir i en quina lliçó s'estudia?
5. Elabora una taula amb els tres entorns indicant: nombre de pods, nombre de Services i si tenen quota.

Solució 1

Els números varien segons els CRDs i els addons instal·lats al teu clúster.

2. El raonament, abans de comprovar-ho: porta namespace allò que pertany a una aplicació concreta; no en porta allò que és infraestructura o configuració global.

Els cinc: kube-apiserver (l'única porta a l'API), etcd (el magatzem d'estat), kube-scheduler (assigna pods a nodes), kube-controller-manager (on viuen els controladors de ReplicaSet, Deployment, endpoints...) i CoreDNS (que resol els noms de Service que vam fer servir a la lliçó anterior).

kube-public és l'únic namespace llegible sense autenticar-se: qualsevol que arribi a l'apiserver pot llegir-ne el contingut. Conté cluster-info, amb les dades que un node necessita per unir-se al clúster durant el procés de kubeadm join. Per això mai no s'hi ha de guardar res sensible.

Solució 2

Funciona. Un pod de desenvolupament ha accedit sense cap obstacle a un servei de producció. Implicació directa: el namespace no és una frontera de xarxa. En el model per defecte de Kubernetes, tots els pods es veuen entre ells, i n'hi ha prou amb conèixer el nom DNS per connectar-s'hi.

Per impedir-ho cal una NetworkPolicy a rutas-norte-pro que rebutgi tot el trànsit entrant tret del que provingui de namespaces amb l'etiqueta entorn: pro (per això vam etiquetar els namespaces en crear-los). És el contingut de Polítiques de Xarxa i Seguretat de Xarxa.

Solució 3

L'etiqueta comuna permet distingir d'un cop d'ull els namespaces de la plataforma dels del sistema.

Només apareix service/kubernetes, que és el Service del mateix apiserver i ha de ser-hi: és el que permet als pods parlar amb l'API. Si hi hagués qualsevol altra cosa, el procediment seria exportar-la, corregir-ne el namespace i tornar-la a aplicar:

Cap namespace no té quota. Implicació: qualsevol Deployment de rutas-norte-dev pot consumir tota la CPU i la memòria del clúster i deixar sense recursos els pods de rutas-norte-pro, perquè comparteixen nodes. Un bucle mal escrit a desenvolupament pot tombar la producció. Es corregeix amb ResourceQuota i LimitRange a 03-04 i 03-05.

Sí que el puc esborrar, i amb ell tota la producció, sense confirmació i sense desfer. El que ho hauria d'impedir és RBAC: un Role/ClusterRole que no inclogui el verb delete sobre namespaces per a les credencials habituals, deixant aquell permís a un rol d'emergència fet servir per dues persones. S'estudia a Control d'Accés Basat en Rols. Com a xarxa de seguretat complementària, còpies de seguretat amb Velero (05-06).

Els namespaces han deixat de ser aquella paraula que repetíem a cada ordre. Saps que la seva funció nativa és la unicitat de noms, i que d'ella se'n deriven l'àmbit de les consultes, dels selectors, del DNS curt, de les quotes, del RBAC i de les polítiques de xarxa. Distingeixes els recursos que porten namespace —pods, Deployments, Services, ConfigMaps, Secrets, PVCs— dels que pertanyen al clúster sencer —nodes, PersistentVolumes, StorageClasses, ClusterRoles—, i saps esbrinar-ho en qualsevol moment amb kubectl api-resources --namespaced. Coneixes els quatre namespaces del sistema, has vist el pla de control corrent com a pods a kube-system, i tens clar per què default és un abocador on Rutas Norte no desplega res.

Has muntat els tres entorns del projecte de forma declarativa i amb etiquetes que les NetworkPolicies aprofitaran després, i has desplegat els mateixos manifests en diversos d'ells comprovant que botiga-web i api-reserves conviuen amb idèntic nom en namespaces diferents, cadascun amb la seva pròpia ClusterIP i parlant amb la seva pròpia base de dades gràcies al DNS curt. Treballes amb -n, amb -A i fixant el namespace del context, amb el reflex de verificar on ets abans de qualsevol ordre destructiva.

I t'emportes els dos advertiments que més incidents eviten. El primer: un namespace no aïlla res per si sol. No és frontera de xarxa —ho has demostrat escrivint a la memòria cau de preproducció des de desenvolupament i cridant producció des d'un pod de dev—, no és frontera de permisos, no limita recursos i no separa nodes. És l'àmbit sobre el qual s'apliquen quotes, RBAC i polítiques de xarxa, que arribaran als mòduls 3, 4 i 8. El segon: kubectl delete namespace s'ho endú tot sense confirmació i sense marxa enrere, motiu pel qual la producció real de Rutas Norte viu en un clúster a part.

Queda un fil solt que ha recorregut tot el mòdul. Els selectors dels ReplicaSets, els selectors dels Services, l'etiqueta entorn dels namespaces, l'anotació kubernetes.io/change-cause de l'historial de revisions, el pod-template-hash que el Deployment afegeix sol, les consultes amb -l que fem servir des de la primera lliçó... Tot això són etiquetes i anotacions, i fins ara les hem anat fent servir sense sistematitzar. A Etiquetes, Selectors i Anotacions, la lliçó que tanca el mòdul, hi posarem ordre: sintaxi i restriccions, etiquetes recomanades per Kubernetes, l'esquema d'etiquetatge definitiu dels sis components de Rutas Norte als seus tres entorns, selectors d'igualtat i de conjunt, i les consultes del dia a dia que converteixen un clúster gran en una cosa navegable.