Tancàvem el mòdul 2 amb una llista de deutes i el primer de tots era aquest: la URL de l'API va incrustada dins de la imatge de botiga-web. Cada vegada que volem desplegar la botiga a rutas-norte-pre en lloc de a rutas-norte-pro cal construir una imatge diferent, amb el mateix codi i un sol caràcter canviat en un fitxer de configuració. Això trenca la promesa més bàsica del contenidor: construir una vegada, desplegar a qualsevol lloc. L'objecte que ho arregla és el ConfigMap, un magatzem de configuració no confidencial que viu al clúster, es versiona a Git juntament amb la resta de manifests i s'injecta al contenidor en el moment de l'arrencada. En aquesta lliçó construiràs el ConfigMap de botiga-web amb el seu nginx.conf real i el muntaràs com un fitxer dins del contenidor, que és la forma de consum més potent i la que dona menys sorpreses. La injecció com a variables d'entorn la veuràs a fons a Variables d'Entorn; aquí només l'esmentarem per situar-la.

1. Per què se separa la configuració del codi
2. Anatomia de l'objecte ConfigMap
3. Les quatre formes de crear un ConfigMap
4. Les tres formes de consumir-lo (i quina veurem aquí)
5. Muntar un ConfigMap com a volum
6. Seleccionar claus concretes amb items i defaultMode
7. subPath: l'ús i els seus dos perills
8. El cas central: el nginx.conf de botiga-web
9. Actualitzar un ConfigMap i la propagació als volums
10. ConfigMaps immutables
11. El límit d'1 MiB i què fer si se supera
12. ConfigMaps per entorn a Rutas Norte

La metodologia dels dotze factors (The Twelve-Factor App), escrita el 2011 per a aplicacions al núvol, dedica el seu tercer factor exactament a aquest problema i el seu enunciat és una sola frase:

Desa la configuració a l'entorn. La configuració és tot allò que pot variar entre desplegaments; el codi és el que no varia.

La prova pràctica que proposa és taxativa i val la pena aplicar-la a Rutas Norte: podries fer públic el repositori de codi ara mateix, sense filtrar cap credencial? Avui la resposta és no, perquè la contrasenya de postgres-reserves està escrita en un manifest del repositori. Aquesta part la salda la lliçó de Secrets. Però hi ha una segona prova, més silenciosa: és exactament la mateixa imatge la que corre a rutas-norte-dev, a rutas-norte-pre i a rutas-norte-pro? Avui tampoc.

Això no és purisme. Té conseqüències molt concretes:

Els dos casos concrets que arrossega Rutas Norte:

1. La URL de l'API a botiga-web. La SPA necessita saber a quina adreça ha de trucar: http://api-reserves dins del clúster, https://api.rutasnorte.example des del navegador del client. Avui està incrustada al JavaScript compilat dins de la imatge.
2. El nginx.conf de botiga-web. La configuració del servidor —compressió, capçaleres de seguretat, la regla de fallback a index.html que tota SPA necessita, el proxy cap a api-reserves— està cuita a la imatge. Ajustar la memòria cau dels fitxers estàtics requereix reconstruir-la.

Tots dos es resolen avui, en aquesta lliçó.

Un ConfigMap és un dels objectes més simples de Kubernetes. No té spec ni status: només metadata i dades.

Els punts que defineixen l'objecte:

• apiVersion: v1: pertany al grup core, com Pod, Service o Namespace. No porta grup al davant.
• No té spec. Un ConfigMap no descriu un estat desitjat que un controlador hagi de reconciliar; és un contenidor de dades passiu. Per això tampoc té status.
• data conté text vàlid en UTF-8. Les claus són noms de fitxer potencials, així que s'han de limitar a caràcters alfanumèrics, -, _ i ..
• binaryData conté dades que no són text, codificades en base64 en escriure-les al manifest. Kubernetes les descodifica en muntar-les. Serveix per a un certificat en format DER, un .ico, una font, un petit .tar.gz de plantilles.
• Una mateixa clau no pot aparèixer a data i a binaryData: l'apply falla.
• Té namespace. Un pod només pot muntar ConfigMaps del seu propi namespace. No hi ha cap forma nativa de referenciar-ne un d'un altre namespace, i aquesta restricció és la que fa natural el patró d'"un ConfigMap per entorn" que veurem a l'apartat 12.

Un detall important sobre les claus multilínia. El | de YAML és un bloc literal: conserva els salts de línia tal qual. És el que vols per a un fitxer de configuració. El seu cosí > (bloc plegat) converteix els salts de línia simples en espais, i arruïnaria un nginx.conf. Per a fitxers, fes servir sempre |.

És la forma canònica i l'única que es versiona bé a Git. Ja l'has vista a dalt. S'aplica com qualsevol altre objecte:

Per a valors curts, sobretot quan estàs explorant o generant el YAML amb --dry-run.

Comprovem què ha creat exactament:

Fixa't que no porta cap etiqueta. Els objectes creats amb kubectl create no segueixen l'esquema d'etiquetatge de Rutas Norte, i això els deixa fora de totes les consultes amb -l app.kubernetes.io/part-of=rutas-norte. Per això l'ús recomanat de l'ordre imperativa és com a generador de YAML, no com a forma de crear objectes:

Després s'editen les etiquetes a mà i s'aplica el fitxer. És el mateix flux --dry-run=client -o yaml del mòdul 1, ara aplicat a la configuració.

Aquí hi ha el cas interessant. Tens el nginx.conf real al teu repositori i el vols ficar dins d'un ConfigMap sense copiar-lo a mà dins d'un YAML (amb el risc d'espatllar la indentació).

La clau és el nom base del fitxer (nginx.conf), no la ruta completa. Si vols que la clau s'anomeni d'una altra manera, s'anteposa amb un =:

La clau serà default.conf encara que el fitxer del disc s'anomeni nginx-produccio.conf. Aquest truc és imprescindible quan el nom que espera l'aplicació no coincideix amb el que et resulta còmode al repositori.

Si apuntes a un directori, cada fitxer de dins es converteix en una clau. No és recursiu: els subdirectoris s'ignoren.

Tres fitxers, tres claus. Quan muntem aquest ConfigMap a /etc/nginx/conf.d apareixeran els tres fitxers amb aquests mateixos noms, que és just el que nginx espera.

Aquesta és la que més confon. Pren un fitxer amb format CLAU=valor i crea una clau per línia, no una clau amb el fitxer sencer.

Compara-ho amb el que hauria fet --from-file sobre el mateix fitxer: una sola clau anomenada botiga-web.env el valor de la qual seria el text complet. La diferència és enorme i és la font d'un error clàssic.

Regles del format de --from-env-file: les línies buides i les que comencen per # s'ignoren; no s'admeten cometes al voltant del valor (es desarien com a part del valor) ni continuacions de línia; i les claus han de ser noms vàlids de variable d'entorn.

Aquesta lliçó se centra en la segona perquè és la que resol el cas del nginx.conf —un fitxer de 40 línies no cap còmodament en una variable d'entorn— i perquè és l'única que permet canviar la configuració sense recrear pods.

El mecanisme té sempre dues meitats que han de quadrar: un volum a nivell de pod que declara d'on surten les dades, i un volumeMount a nivell de contenidor que declara on apareixen. El pont entre tots dos és el camp name.

Què passa exactament quan arrenca aquest pod:

1. El kubelet llegeix el pod i veu un volum de tipus configMap.
2. Demana a l'API el ConfigMap botiga-web-nginx del namespace rutas-norte-dev. Si no existeix, el pod es queda en ContainerCreating fins que aparegui, amb un esdeveniment FailedMount. No falla per sempre: tan bon punt creïs el ConfigMap, el pod arrenca.
3. Crea al node un directori i hi escriu a dins un fitxer per cada clau del ConfigMap.
4. Munta aquest directori a /etc/nginx/conf.d dins del contenidor.

I aquí hi ha el punt que sorprèn tothom la primera vegada: el muntatge substitueix el contingut del directori del contenidor. El que la imatge nginx portava a /etc/nginx/conf.d (el fitxer default.conf per defecte) deixa de veure's. No s'esborra de la imatge; simplement queda ocult sota el punt de muntatge, igual que a Linux en muntar un disc sobre un directori que ja tenia fitxers.

Anem a veure-ho:

Aquesta sortida conté tota la màgia del mecanisme, així que convé llegir-la amb calma:

• Els fitxers que veu l'aplicació (compressio.conf, etc.) són enllaços simbòlics a ..data/.
• ..data és al seu torn un enllaç simbòlic a un directori amb marca de temps.
• El directori real conté els fitxers de veritat.

Per què tanta indirecció? Perquè permet una actualització atòmica. Quan el ConfigMap canvia, el kubelet escriu un directori nou amb marca de temps nova i després mou l'enllaç ..data de cop. L'aplicació no veu mai un estat a mitges amb la meitat dels fitxers vells i la meitat nous. És un detall d'implementació, però explica dos comportaments que veuràs més endavant: per què l'actualització funciona i per què amb subPath no funciona.

Per defecte es projecten totes les claus. Sovint no és el que vols: un mateix ConfigMap pot tenir claus destinades a variables d'entorn (API_URL) i claus que són fitxers (nginx.conf), i muntar-les totes juntes ompliria /etc/nginx/conf.d de brossa que nginx intentaria interpretar.

Amb items tries quines claus es projecten i amb quin nom de fitxer:

Detalls que importen:

• path és relatiu al mountPath. Amb mountPath: /etc/nginx/conf.d i path: default.conf, el fitxer acaba a /etc/nginx/conf.d/default.conf.
• path admet subdirectoris: path: extra/capceleres.conf crea el subdirectori. El que no admet és començar per / ni contenir ...
• Si fas servir items, només es projecta el que llistis. Les claus no esmentades desapareixen del volum.
• Si una clau llistada a items no existeix al ConfigMap, el pod no arrenca. És un comportament desitjable: falla aviat i amb un missatge clar en lloc d'arrencar nginx sense configuració.
• defaultMode s'escriu en octal i s'ha de posar amb el 0 al davant (0444). Si escrius 444 en decimal, YAML ho interpreta com el número 444, que en octal és 0674: permisos absurds. És un error real i freqüent.
• El mode d'un item concret preval sobre defaultMode.

Un advertiment sobre els permisos: si el contenidor corre amb un usuari no root (l'habitual i el recomanable, com veuràs a Contextos de Seguretat), un defaultMode: 0400 significa "només lectura per al propietari", i el propietari del fitxer és root. El procés no el podria llegir. Per a aquest cas, 0444 és l'elecció segura.

Torna al problema de l'apartat 5: muntar un volum sobre un directori amaga el que ja hi havia. I si només vols afegir o substituir un únic fitxer dins d'un directori que ha de conservar la resta del seu contingut?

El cas canònic a Rutas Norte és /etc/nginx/nginx.conf. Aquest fitxer és a /etc/nginx/, un directori que també conté mime.types, fastcgi_params, el directori conf.d... Si muntem el volum a /etc/nginx/, nginx es queda sense tota la resta i no arrenca.

La solució és subPath:

Amb això, només el fitxer /etc/nginx/nginx.conf queda substituït; la resta de /etc/nginx/ continua intacta.

Tot al seu lloc. Ara els dos perills, que cal conèixer abans de fer-lo servir:

Perill 1: amb subPath l'actualització NO es propaga. Quan muntes amb subPath, el kubelet copia el fitxer directament en lloc de crear la cadena d'enllaços simbòlics de l'apartat 5. En no haver-hi enllaç ..data per moure, el fitxer queda congelat en el valor que tenia en arrencar el pod. Pots editar el ConfigMap cent vegades: el contenidor continuarà veient l'original fins que el recreïs. És, de bon tros, la causa número u de "he canviat la configuració i no passa res".

Perill 2: és fàcil equivocar-se de sentit. mountPath ha d'apuntar al fitxer de destinació i subPath a la clau d'origen. Si els intercanvies, o si mountPath apunta a un directori existent, obtindràs un directori on esperaves un fitxer i l'aplicació fallarà amb un missatge confús.

La recomanació pràctica: evita subPath si pots. En el cas de nginx tens una alternativa millor, que és la que farem servir: muntar a /etc/nginx/conf.d/, el directori que la mateixa imatge reserva per a configuració afegida, sense tocar /etc/nginx/nginx.conf. Aquest directori està pensat per ser substituït sencer.

Anem a resoldre el deute del mòdul 2 amb tot l'anterior. Creem el fitxer k8s/base/botiga-web/configmap-nginx.yaml:

I modifiquem el Deployment de botiga-web que ja teníem:

Apliquem i comprovem:

Verifiquem que nginx està llegint la nostra configuració i no la de la imatge:

nginx -T bolca la configuració efectiva després de resoldre tots els include. Que aparegui el nostre try_files confirma que la regla de la SPA està activa. I la prova definitiva, des d'un pod efímer:

Les tres capçaleres de seguretat hi són. La configuració de nginx ja no viu a la imatge: viu en un YAML revisable en una pull request.

Ara el pagament de l'esforç. Afegim una capçalera més sense reconstruir la imatge i sense reiniciar res.

Esperem i mirem dins del contenidor:

El fitxer ha canviat dins d'un contenidor que no s'ha reiniciat. Els tres pods continuen tenint RESTARTS 0.

Sobre els temps i les condicions:

• La propagació no és instantània. El kubelet refresca els volums al seu cicle de sincronització, governat per --sync-frequency (per defecte 1 minut), més el temps de memòria cau del seu client de l'API (configMapAndSecretChangeDetectionStrategy, per defecte Watch). A la pràctica compta amb fins a un parell de minuts, no amb segons.
• Es propaga només si el volum no fa servir subPath (apartat 7).
• Es propaga només si el ConfigMap no és immutable (apartat 10).
• I, sobretot: que el fitxer canviï no vol dir que l'aplicació se n'assabenti. nginx va llegir la seva configuració en arrencar i la té a memòria.

Aquest darrer punt és fonamental. Hi ha tres tipus d'aplicació:

Per a nginx podem enviar-li el senyal de recàrrega, que no talla cap connexió en curs:

Per al cas general, la solució neta és forçar un desplegament nou:

Això substitueix els pods amb l'estratègia RollingUpdate del mòdul 2, sense tall de servei. Existeix una tècnica més elegant i automàtica —desar un hash del ConfigMap en una anotació del template, de manera que canviar la configuració dispari el desplegament tot sol— que veuràs a Variables d'Entorn, on encara és més necessària.

Des de Kubernetes 1.21, un ConfigMap es pot declarar immutable:

Què hi guanya:

1. Rendiment i escala. Aquest és el motiu principal. Cada kubelet manté un watch obert contra l'apiserver per cada ConfigMap que munta. En un clúster gran això són milers de connexions vigilant canvis. Si l'objecte és immutable, el kubelet tanca el watch: no hi ha res a vigilar. La càrrega sobre l'apiserver baixa de manera notable.
2. Protecció contra el canvi accidental. Ningú no pot modificar per error la configuració de producció d'una tirada.
3. Determinisme. Un pod que arrenqui avui i un altre que arrenqui d'aquí a un mes amb el mateix ConfigMap tindran exactament la mateixa configuració. Amb un ConfigMap mutable, dues rèpliques del mateix Deployment podrien tenir continguts diferents si el ConfigMap va canviar entre les seves arrencades.

Què s'hi perd: l'actualització en calent de l'apartat 9. I hi ha dues regles dures:

• La immutabilitat no es pot revertir. Un cop immutable: true, no es pot tornar a false. Només queda esborrar l'objecte i recrear-lo.
• metadata sí que es pot canviar (etiquetes, anotacions). El que queda congelat és data i binaryData.

Intentar modificar-lo produeix un error molt clar:

El patró que acompanya la immutabilitat és versionar el nom: botiga-web-nginx-v3, -v4, etc. El Deployment apunta a la versió concreta, i canviar de configuració significa crear un ConfigMap nou i actualitzar la referència al Deployment, cosa que dispara un desplegament amb historial i rollback. És exactament el que fan els generadors de Kustomize afegint un sufix amb el hash del contingut.

Recomanació per a Rutas Norte: mutable a dev (iterar ràpid amb nginx -s reload), immutable amb nom versionat a pro (determinisme i rollback).

Un ConfigMap no pot superar 1 MiB, comptant la suma de data i binaryData més les metadades. El límit no és capriciós: els ConfigMaps es desen a etcd, que imposa per defecte una mida màxima d'1,5 MiB per valor, i etcd és el cor del clúster.

En passar-te'n, l'error és immediat:

O bé, quan la validació la fa el mateix objecte:

Tingues present a més que base64 infla un 33 %: un .ico de 800 KiB ocupa uns 1,07 MiB a binaryData i no hi cap.

Què fer si t'acostes al límit:

La regla d'olfacte: si t'acostes al megabyte, gairebé segur que estàs ficant en un ConfigMap alguna cosa que no és configuració. A Rutas Norte això aplicaria al catàleg complet de rutes i parades, que són dades de negoci i viuen a postgres-reserves, no en un ConfigMap.

Recorda la restricció de l'apartat 2: un ConfigMap té namespace i un pod només pot muntar els del seu propi namespace. Com que els entorns de Rutas Norte són namespaces, això encaixa de manera natural: un ConfigMap per entorn, amb el mateix nom a cadascun.

El nom del ConfigMap és idèntic als tres namespaces. Això permet que el Deployment sigui literalment el mateix fitxer a k8s/base/, i que l'única cosa que canviï entre entorns sigui el ConfigMap de k8s/entorns/<entorn>/. L'estructura del repositori queda així:

I aquest és el contingut concret de la configuració de Rutas Norte per entorn. Pren aquesta taula com a referència; a 03-03 l'ampliarem al catàleg complet de tots els components.

Observa dues decisions de disseny:

• REDIS_TTL_SEGONS puja en acostar-se a producció. En desenvolupament interessa una memòria cau curta per veure els canvis; en producció, amb els pics de trànsit de ponts i vacances, interessa una memòria cau llarga que descarregui postgres-reserves.
• MODE_MANTENIMENT és un interruptor operatiu. Posar-lo a true i recarregar nginx mostra la pàgina d'"estem actualitzant" sense desplegar res. És exactament el tipus de palanca que justifica separar configuració de codi.

I una cosa que no hi ha en aquesta taula i mai no hi ha de ser: la contrasenya de postgres-reserves. Un ConfigMap no ofereix cap protecció: qualsevol que pugui llistar ConfigMaps al namespace en llegeix el contingut en clar. Aquest deute el salda la lliçó següent.

Cinc consells que estalvien hores:

1. Etiqueta els ConfigMaps amb el mateix esquema que la resta. kubectl get cm -l app=botiga-web -A ha de funcionar.
2. Comprova sempre des de dins del contenidor, no des del YAML: kubectl exec ... -- cat <ruta>. És l'única veritat.
3. Documenta cada clau amb un comentari al YAML. El manifest és la documentació de la configuració.
4. Un ConfigMap per propòsit, no un de gegant per aplicació. Separa el que es munta com a fitxer del que alimenta variables d'entorn.
5. En producció, immutable i versionat. El determinisme compensa la comoditat.

api-reserves necessita un fitxer /app/config/regles-tarifes.json amb les regles de descompte, que avui és dins de la seva imatge.

1. Crea a la teva màquina el fitxer regles-tarifes.json amb aquest contingut:

2. Genera amb kubectl (sense escriure YAML a mà) el manifest d'un ConfigMap anomenat api-reserves-tarifes a rutas-norte-dev a partir d'aquest fitxer, i desa'l a k8s/entorns/dev/.
3. Afegeix-li les etiquetes de l'esquema de Rutas Norte i aplica'l.
4. Escriu el fragment de volumes i volumeMounts que el munta a /app/config de manera que només es pugui llegir.
5. Verifica des de dins del pod que el fitxer existeix i té el contingut correcte.

1. Desplega un pod de botiga-web que munti la seva configuració amb subPath sobre /etc/nginx/nginx.conf.
2. Comprova que /etc/nginx/ conserva mime.types i el directori conf.d.
3. Modifica el ConfigMap i espera tres minuts. Comprova si el fitxer ha canviat dins del contenidor.
4. Repeteix l'experiment muntant el mateix ConfigMap sense subPath a /etc/nginx/conf.d/. Es propaga ara?
5. Explica en dues línies la diferència i què es veu amb ls -la en cada cas.

1. Crea el ConfigMap botiga-web-config als tres namespaces amb els valors de la taula de l'apartat 12.
2. Demostra amb una sola ordre que existeixen tres objectes amb aquest nom i que els seus valors de NIVELL_LOG són diferents.
3. Fes immutable únicament el de rutas-norte-pro i intenta modificar-lo. Copia l'error.
4. Actualitza el REDIS_TTL_SEGONS de producció sabent que el ConfigMap és immutable. Descriu la seqüència completa de passos.
5. Respon: si demà cal activar el mode manteniment a producció a les 3 de la matinada, quina ordre exacta executaries?

Solució 1

El YAML generat, ja amb les etiquetes afegides a mà:

El fragment del Deployment:

I la verificació:

Un apunt: la clau del ConfigMap és regles-tarifes.json perquè --from-file pren el nom base del fitxer, i el mountPath és el directori /app/config. El resultat és /app/config/regles-tarifes.json, la ruta demanada.

Solució 2

Amb subPath:

El directori ho conserva tot. Després de modificar el ConfigMap i esperar:

No ha canviat. El fitxer continua amb el valor de l'arrencada.

Sense subPath, muntant a /etc/nginx/conf.d/:

Ara sí. La diferència es veu amb ls -la:

Sense subPath, el kubelet actualitza escrivint un directori nou i movent l'enllaç ..data. Amb subPath no hi ha enllaç: el fitxer es va copiar una vegada i allà es queda fins que es recreï el pod.

Solució 3

La comprovació en una ordre:

Tres objectes amb el mateix nom i continguts diferents, exactament el que permet que el Deployment sigui idèntic.

Ara la immutabilitat de producció:

Per actualitzar REDIS_TTL_SEGONS a producció essent immutable, la seqüència correcta és:

1. Crear un ConfigMap nou amb nom versionat, botiga-web-config-v2, amb el valor nou i immutable: true.
2. Aplicar-lo.
3. Editar el Deployment de rutas-norte-pro perquè apunti a botiga-web-config-v2, amb kubernetes.io/change-cause documentant el motiu.
4. kubectl rollout status per seguir el desplegament progressiu del mòdul 2.
5. Verificar i conservar el -v1 uns dies: si cal fer kubectl rollout undo, el Deployment el tornarà a referenciar i ha d'existir.
6. Esborrar el -v1 passada la finestra de rollback.

Fixa't en l'avantatge: la configuració de producció ara té historial i rollback, igual que el codi.

Per al mode manteniment a les 3 de la matinada, amb el ConfigMap mutable d'nginx:

Sense reconstruir imatge, sense desplegar, sense tallar connexions. Aquest és exactament el valor de tenir la configuració fora del codi.

Has saldat el primer dels deutes del mòdul 2. Saps per què el tercer factor dels dotze factors exigeix que la configuració visqui fora del codi, i has vist el cost concret de no fer-ho: una imatge per entorn, el provat a pre diferent del desplegat a pro, i un canvi de temps d'espera convertit en un pipeline complet. Coneixes l'anatomia del ConfigMap —sense spec ni status, amb data per a text i binaryData per a la resta, amb namespace i amb les claus com a noms de fitxer potencials— i les seves quatre formes de creació, sabent distingir el parany entre --from-file i --from-env-file.

Domines el consum com a volum, que és el que dona més joc: la parella volumes/volumeMounts, el fet que el muntatge amaga el contingut previ del directori, la cadena d'enllaços simbòlics cap a ..data que fa atòmica l'actualització, la selecció de claus amb items, els permisos amb defaultMode en octal i les seves interaccions amb els usuaris no root, i els dos perills de subPath, començant pel més car: amb subPath la configuració no es propaga mai. Saps que la propagació triga fins a un parell de minuts i que canviar el fitxer no equival que l'aplicació se n'assabenti, amb les tres estratègies segons el tipus d'aplicació. I coneixes els ConfigMaps immutables, el que guanyen en càrrega sobre l'apiserver i determinisme, el patró de nom versionat que els acompanya, i el límit d'1 MiB amb el senyal que emet: si t'hi acostes, no és configuració.

Sobre el terreny, botiga-web ja serveix el seu nginx.conf des d'un ConfigMap muntat a /etc/nginx/conf.d, amb capçaleres de seguretat, compressió, memòria cau d'estàtics, la regla try_files de la SPA i un endpoint /healthz que la lliçó de sondes aprofitarà. Els tres entorns tenen el seu propi ConfigMap amb el mateix nom, cosa que ha permès que el Deployment sigui un únic fitxer a k8s/base/.

Queda el deute gros. Tot el que hem desat avui és públic: qualsevol amb permís de lectura al namespace veu el contingut íntegre d'un ConfigMap. La contrasenya de postgres-reserves —la base de dades que desa el nom, el DNI, el telèfon i el correu de cada client de Rutas Norte— continua en clar en un manifest de Git. La lliçó següent, Secrets, la treu d'allà: veuràs en què es diferencia realment un Secret d'un ConfigMap, per què base64 no és xifratge i ho demostraràs descodificant-ne un en tres segons, els tipus de Secret i els seus usos, el xifratge en repòs a etcd que per defecte no està activat, com es descarreguen imatges privades de registry.rutasnorte.example i quines solucions reals fa servir l'ecosistema quan el Secret natiu no n'hi ha prou.