A la lliçó anterior vam aixecar clústers llencables al portàtil i vam descobrir, gairebé de passada, que kind fa servir kubeadm per dins: aquell camp kubeadmConfigPatches del fitxer de configuració no era casualitat. Ara anem a l'eina directament.

kubeadm és l'eina oficial del projecte Kubernetes per arrencar un clúster conforme sobre màquines que tu controles. És la base sobre la qual estan construïdes gairebé totes les distribucions, i entendre-la et dona una cosa que cap altra via et dona: veure amb els teus propis ulls on són els certificats, on viuen els pods estàtics del pla de control i què passa exactament quan un node s'uneix al clúster. Encara que Rutas Norte S.L. acabi triant un clúster gestionat (10-06), aquest coneixement és el que et permetrà depurar un pla de control trencat i aprovar la certificació CKA (12-01).

1. Què és kubeadm i què no és
2. Autogestionat davant de gestionat: quan té sentit
3. Preparació de les màquines
4. Instal·lació de containerd
5. Instal·lació de kubeadm, kubelet i kubectl
6. kubeadm init amb fitxer de configuració
7. Què crea exactament kubeadm al node
8. Instal·lar el CNI i per què els nodes estan NotReady
9. Unir nodes de treball
10. Pla de control en alta disponibilitat
11. Gestió de certificats
12. Actualització de versió
13. Còpia de seguretat i restauració d'etcd
14. kubeadm reset i neteja
15. Errors comuns i consells
16. Exercicis
17. Conclusió

kubeadm fa una sola cosa bé: donades unes màquines ja preparades, hi arrenca un pla de control i uneix nodes de treball, produint un clúster que passa les proves de conformitat de Kubernetes.

Aquesta llista de la dreta és la clau. Molta gent executa kubeadm init, veu el missatge d'èxit, i després se sorprèn que kubectl get nodes digui NotReady. No hi ha cap error: falta el CNI, i aquesta feina no és de kubeadm.

Abans d'escriure una sola ordre, la pregunta honesta: hauria Rutas Norte S.L. d'operar el seu propi clúster?

Advertiment seriós: operar un clúster propi en producció exigeix un equip dedicat. No és una tasca que es pugui afegir a la llista d'un altre lloc de treball. Necessites cobertura per a incidents fora d'horari, un procediment provat de restauració d'etcd, una política de pedaços del sistema operatiu, i algú que entengui els certificats quan caduquin. Si la teva organització no pot sostenir això, un clúster gestionat no és una comoditat: és una decisió de gestió de risc.

Quan kubeadm sí que és la resposta correcta: centre de dades propi o maquinari específic (GPU, baixa latència, compliment normatiu); necessitat de configuracions del pla de control que cap gestionat permet; estalvi de cost amb molts nodes; i aprenentatge i certificació, perquè el CKA (12-01) avalua exactament això.

Per a Rutas Norte muntarem un clúster amb kubeadm en un laboratori per aprendre i practicar, amb la conclusió raonada de producció reservada per a 10-06.

Partim de tres màquines Ubuntu 24.04 LTS al laboratori de Rutas Norte:

Requisits mínims oficials: 2 CPU i 2 GB de RAM per node de control, nom de host únic, adreça MAC única i product_uuid únic (sudo cat /sys/class/dmi/id/product_uuid). Si dues màquines clonades comparteixen product_uuid, el clúster pot confondre-les: regenera'l des de l'hipervisor.

Tots els passos següents s'executen a les tres màquines.

Per què cal desactivar el swap? Perquè trenca el model de recursos que vam estudiar a 03-04 i 03-05. El planificador decideix on va un pod segons la memòria sol·licitada i disponible; el kubelet expulsa pods quan el node té pressió de memòria, seguint les classes de QoS. Si hi ha swap, un pod que supera el seu límit de memòria no mor: comença a paginar a disc, es torna mil vegades més lent, les seves sondes de liveness comencen a fallar de forma erràtica i el node sencer es degrada sense que cap mètrica ho expliqui. És una fallada molt pitjor que un OOMKilled net.

Kubernetes 1.30 té suport experimental de swap (NodeSwap), però està en beta amb molts advertiments. Per a un clúster de producció, swap desactivat.

Què fa cadascun:

• overlay: el sistema de fitxers per capes que fa servir containerd per muntar les imatges de contenidor. Sense ell, el runtime no pot crear contenidors.
• br_netfilter: permet que el trànsit que travessa un pont de xarxa de Linux (el que connecta els contenidors del node) sigui visible per a iptables. Sense ell, kube-proxy escriu regles que mai s'apliquen al trànsit entre pods, i els Services simplement no funcionen.

• ip_forward = 1: el node ha de reenviar paquets entre interfícies. Sense això, un pod de rn-worker-1 no pot parlar amb un de rn-worker-2.
• bridge-nf-call-iptables = 1: activa el que br_netfilter fa possible.

Si sysctl et diu que el paràmetre no existeix, és que br_netfilter no està carregat. L'ordre importa.

Sobre l'últim: cada CNI fa servir el seu. Calico amb VXLAN necessita UDP 4789; amb IP-in-IP necessita el protocol IP 4; Cilium amb VXLAN, UDP 8472. Consulta la documentació del CNI que triïs.

Per al laboratori n'hi ha prou amb obrir aquests ports amb ufw i permetre tot el trànsit de la xarxa interna: sudo ufw allow from 10.10.0.0/24. Verifica des d'un altre node amb nc -zv 10.10.0.11 6443.

Consell de laboratori: si estàs aprenent i alguna cosa no connecta, desactiva temporalment el tallafocs (sudo ufw disable) per descartar que sigui el culpable. En producció, mai; allà es documenta cada regla.

Kubernetes no executa contenidors directament: parla amb un runtime a través de la interfície CRI. Des de 1.24, Docker no és un runtime vàlid de forma directa; containerd és l'opció estàndard.

Aquí hi ha la fallada número u dels clústers amb kubeadm. containerd porta per defecte una configuració amb SystemdCgroup = false, mentre que el kubelet de Kubernetes 1.30 fa servir el controlador de cgroups systemd. Si no coincideixen, el clúster arrenca aparentment bé i després els pods es reinicien de forma aleatòria sota pressió de memòria, perquè hi ha dos gestors de cgroups barallant-se pel mateix node.

Si el grep no retorna res o retorna false, la ruta de l'opció ha canviat a la teva versió. Edita el fitxer a mà i busca la secció [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options].

Si això respon, el runtime està llest. crictl és la teva eina de depuració a nivell de node: crictl ps, crictl images, crictl logs. Quan l'apiserver està caigut, kubectl no serveix de res i crictl és l'únic que tens.

Tots tres s'instal·len des del repositori oficial de Kubernetes, que des de 1.28 està segmentat per versió menor. Això és important: el repositori de v1.30 només conté pedaços de 1.30, cosa que evita salts accidentals de versió menor.

Per què el hold és imprescindible: sense ell, un apt upgrade rutinari de manteniment del sistema actualitzaria el kubelet en un node qualsevol. Aquell kubelet nou podria ser incompatible amb el pla de control, o simplement reiniciar-se enmig del dia i expulsar tots els pods d'aquell node. Les actualitzacions de Kubernetes són un procediment planificat (apartat 12), mai un efecte secundari.

Podries arrencar el clúster amb una tirallonga de banderes (kubeadm init --pod-network-cidr=... --control-plane-endpoint=... --apiserver-cert-extra-sans=...), i funcionaria. Però el problema és evident després de tot el que portem de curs: no està versionat, ningú recorda quines banderes es van fer servir fa un any, i en afegir un node de control cal repetir-les exactament. La forma professional és un fitxer de configuració, desat al costat dels manifestos.

Executem:

--upload-certs puja els certificats del pla de control a un Secret temporal del clúster, xifrat, perquè altres nodes de control s'hi puguin unir sense copiar-los a mà. Caduca a les 2 hores.

Sortida (molt abreujada):

Desa aquesta sortida. Les dues ordres join del final són les que necessites als apartats 9 i 10.

NotReady. És correcte, i ho expliquem a l'apartat 8.

Sobre controlPlaneEndpoint: encara que avui només tinguis un node de control i no un balancejador, declara'l amb un nom DNS des del principi. Pots fer que aquest nom apunti avui a 10.10.0.11 i demà a la IP virtual del balancejador. Si no ho fas, el certificat i tots els kubeconfig apuntaran a la IP del node, i muntar HA més tard exigeix regenerar certificats a tot el clúster.

Aquest apartat connecta directament amb l'arquitectura que vam veure a 01-02. Ara la veurem al disc.

Això és un pod estàtic: el kubelet vigila aquest directori i arrenca qualsevol pod que hi trobi, sense passar per l'apiserver. És la solució al problema de l'ou i la gallina: com arrenca l'apiserver, si per crear un pod cal un apiserver? Resposta: no es crea com un pod normal, el llegeix el kubelet directament del disc.

Conseqüències pràctiques molt importants:

• Si edites /etc/kubernetes/manifests/kube-apiserver.yaml, el kubelet detecta el canvi i reinicia l'apiserver automàticament en segons. És la manera d'afegir una bandera a mà.
• Si esborres aquest fitxer, l'apiserver desapareix i perds el clúster. Còpia de seguretat abans de tocar res.
• kubectl delete pod kube-apiserver-rn-control-1 -n kube-system no l'elimina de debò: el kubelet el recrea, perquè la font de veritat és el fitxer.
• Si l'apiserver no arrenca, kubectl no funciona. Depura'l amb crictl ps -a i crictl logs, o amb journalctl -u kubelet.

Per inspeccionar els noms vàlids d'un certificat: sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 'Subject Alternative Name'.

A /etc/kubernetes/*.conf n'hi ha un per component: controller-manager.conf, scheduler.conf, kubelet.conf (credencials d'aquest node, amb rotació automàtica) i dos d'administració:

• admin.conf: el que vas copiar a ~/.kube/config. Des de 1.29 pertany al grup kubeadm:cluster-admins, subjecte a RBAC (08-01).
• super-admin.conf: salta el RBAC completament (system:masters). És el trenca-vidres quan has trencat el RBAC i no el pots ni arreglar. No el reparteixis.

A /var/lib/etcd/member/ (amb els seus directoris snap i wal) viu l'estat complet del teu clúster: tots els objectes, tots els Secrets, tot. És el que cal copiar (apartat 13).

El missatge és explícit. El kubelet es nega a declarar-se Ready mentre no existeixi un complement de xarxa que sàpiga assignar IP als pods. Recorda de 04-01: Kubernetes defineix el contracte (tot pod té una IP, tots els pods es veuen sense NAT) però no l'implementa. Això és feina del CNI.

També veuràs CoreDNS a Pending, i és normal: CoreDNS és un pod i necessita xarxa per arrencar.

Instal·lem Calico (el detall dels CNI és a 04-01; aquí només el necessari):

I CoreDNS arrenca sol. La seqüència completa és:

A rn-worker-1 i rn-worker-2, ja preparats amb els apartats 3, 4 i 5:

Què signifiquen els dos paràmetres:

• --token: una credencial temporal (caduca a les 24 hores) que autoritza el node a demanar el seu certificat. És un Secret de tipus bootstrap.kubernetes.io/token a kube-system.
• --discovery-token-ca-cert-hash: el hash SHA-256 de la clau pública de la CA del clúster. Serveix perquè el node verifiqui l'apiserver, no a l'inrevés. Sense ell, un atacant podria suplantar el pla de control i capturar el token. No facis servir mai --discovery-token-unsafe-skip-ca-verification fora d'un laboratori.

És la situació més habitual: vols afegir un node tres setmanes després i el token original ja no val.

Ordres relacionades:

kubeadm no posa l'etiqueta de rol als nodes de treball per seguretat (un kubelet no pot autoassignar-se etiquetes de rol). Es fa des del pla de control:

Amb un sol node de control, si rn-control-1 cau, el clúster continua servint trànsit (els pods continuen corrent, kube-proxy continua encaminant) però perds tota capacitat de gestió: no hi ha reprogramació de pods, ni escalat, ni desplegaments, ni HPA. I si el disc d'etcd es perd, perds el clúster sencer.

Tots els nodes de control publiquen el mateix port 6443. Necessites alguna cosa al davant que reparteixi:

Opcions: HAProxy + keepalived amb una IP virtual flotant (el més comú en centre de dades propi), el balancejador de capa 4 del núvol si estàs en màquines virtuals, o kube-vip com a pod estàtic si no vols infraestructura externa. El que no val és un DNS amb diversos registres A: el client fa memòria cau i no detecta caigudes.

Configuració mínima d'HAProxy:

És TCP pur (mode tcp), no HTTP: la connexió a l'apiserver és TLS d'extrem a extrem i el balancejador no l'ha de terminar. Amb check, si un node deixa de respondre al 6443, HAProxy deixa d'enviar-li trànsit automàticament.

etcd necessita quòrum: 1 membre tolera 0 fallades, 2 membres també en toleren 0 (pitjor que 1!), 3 en toleren 1, 4 en toleren 1, i 5 en toleren 2. Per això el nombre de nodes de control és sempre senar: 1 (laboratori), 3 (producció normal) o 5 (clústers grans).

Per a etcd extern, es declara al fitxer de kubeadm:

La --certificate-key ve de --upload-certs. Si han passat més de 2 hores, es regenera:

Per verificar la salut del clúster d'etcd, kubectl -n kube-system exec etcd-rn-control-1 -- etcdctl ... endpoint status --cluster -w table ha de mostrar els tres membres, amb la mateixa versió, mida de base de dades semblant i exactament un amb IS LEADER = true.

Aquí hi ha el parany que sorprèn més equips: els certificats que genera kubeadm caduquen a l'any. Un clúster muntat al març deixa de funcionar al març de l'any següent, sense previ avís, amb un missatge així:

Kubernetes renova automàticament els certificats durant kubeadm upgrade. Com que molts equips actualitzen almenys un cop l'any, mai ho veuen. Qui no actualitza, s'emporta el sobresalt.

Les CA duren 10 anys; els certificats que signen, 1 any.

Recomanació d'operació: no ho deixis al calendari humà. L'apiserver exposa apiserver_client_certificate_expiration_seconds_bucket, sobre la qual es pot muntar una alerta a Alertmanager (07-04). Més simple i més fiable encara: un CronJob (06-03) o una tasca del sistema que executi kubeadm certs check-expiration setmanalment i avisi si queda menys d'un mes.

Nota sobre el kubelet: el seu certificat es rota sol, automàticament, si rotateCertificates: true (per defecte). Els certificats que cal renovar a mà són els del pla de control.

Només pots saltar una versió menor cada vegada. De 1.28 a 1.30 no es pot anar directe: cal fer 1.28 → 1.29 → 1.30. Cada salt és un procediment complet.

A més, la política de desfasament (version skew) exigeix:

D'aquí l'ordre obligatori: primer el pla de control, després els nodes de treball. Mai a l'inrevés.

Tres coses, per aquest ordre: còpia de seguretat d'etcd (apartat 13, no negociable), llegir les notes de la versió, i comprovar que res faci servir APIs que desapareixen.

Qualsevol línia aquí és feina que cal fer abans d'actualitzar. Eines com kubent (kube-no-trouble) o pluto escanegen els teus manifestos buscant el mateix.

Per als altres nodes de control i per als de treball, el procediment és el mateix de l'apartat anterior amb una sola diferència: es fa servir sudo kubeadm upgrade node en comptes d'upgrade apply.

Un a un, verificant pel mig. Si drain es bloqueja, és un PodDisruptionBudget fent la seva feina: postgres-reserves no es pot quedar sense rèpliques. Investiga amb kubectl get pdb -A abans de forçar res.

A 05-06 vam fer còpies de les dades de les aplicacions amb Velero. Això és una altra cosa: és la còpia de la definició del clúster. Tots els Deployments, Secrets, ConfigMaps, RBAC, CRDs... tot viu a etcd.

Sense còpia d'etcd, una fallada del disc del node de control t'obliga a recrear el clúster des de zero i tornar a aplicar tots els manifestos. Amb GitOps (10-05) això seria recuperable, però perdries tot el que no sigui a Git.

Aquesta mateixa ordre a /etc/cron.d/copia-etcd, a les 03:15 diàries i encadenada amb un find /var/copies -name 'etcd-*.db' -mtime +14 -delete, cobreix l'automatització amb retenció de dues setmanes.

Tres coses imprescindibles: copia també /etc/kubernetes/pki/ (el snapshot sense la CA és inútil), treu-les del node (una còpia al disc que s'espatllarà no és una còpia) i xifra-les, perquè contenen tots els Secrets de rutas-norte-pro, incloses les credencials de postgres-reserves i les de la passarel·la de pagaments: recorda de 03-02 que els Secrets estan en base64, no xifrats.

Procediment d'emergència, per quan el pla de control és irrecuperable:

Punts crítics:

• En un clúster HA, cal restaurar als tres nodes de control, amb el snapshot idèntic i cadascun amb el seu --name i les seves URL. Si les dades difereixen, etcd no formarà quòrum.
• L'estat torna al moment de la còpia. Tot el creat després es perd.
• Els pods que estaven corrent continuen corrent (el kubelet no se n'ha assabentat), però poden aparèixer objectes "fantasma": pods que existeixen al node però no a etcd, o a l'inrevés. Després de restaurar, revisa kubectl get pods -A contra crictl ps a cada node.

Assaja la restauració. Una còpia de seguretat que mai s'ha restaurat no és una còpia de seguretat: és un fitxer. Fes-ho al laboratori, cronometra't, i escriu el procediment en un runbook (11-06).

Quan alguna cosa surt malament i vols tornar a començar, o retirar un node:

reset és honest sobre el que no neteja. Cal rematar-ho a mà:

Si et saltes els passos 3, 4 i 5, el següent kubeadm init o join en aquella màquina pot semblar que funciona i després donar fallades de xarxa inexplicables: regles velles d'iptables encaminant a IP de pods que ja no existeixen. És una de les causes més freqüents de «vaig reinstal·lar i continua fallant».

1. SystemdCgroup = false a containerd. És l'error número u. El clúster arrenca, tot sembla bé, i dies després els pods es reinicien sota pressió de memòria sense explicació. Verifica sempre amb grep SystemdCgroup /etc/containerd/config.toml i reinicia containerd després de canviar-ho.

2. Oblidar swapoff -a a /etc/fstab. El desactives, funciona, reinicies la màquina un mes després i el kubelet no arrenca. Comenta la línia a /etc/fstab sempre.

3. podSubnet que se solapa amb la xarxa física. Si el teu laboratori fa servir 10.10.0.0/24 i declares podSubnet: 10.0.0.0/8, l'encaminament es trenca de formes que semblen màgia negra. Tria rangs que no col·lisionin amb res: ni amb la xarxa de nodes, ni amb serviceSubnet, ni amb la xarxa corporativa.

4. El rang del CNI diferent de podSubnet. Declares 10.244.0.0/16 a kubeadm i instal·les Calico amb el seu valor per defecte 192.168.0.0/16. Els pods obtenen IP del rang del CNI, però el controller-manager assigna blocs de l'altre. Han de coincidir.

5. No declarar controlPlaneEndpoint des del principi. Afegir alta disponibilitat després obliga a regenerar certificats a tot el clúster. Declara un nom DNS des del primer dia, encara que apunti a una sola IP.

6. Certificats caducats a l'any. Real i molt comú. Alerta al calendari, o millor, al monitoratge.

7. Saltar dues versions menors, o actualitzar els nodes abans que el pla de control. kubeadm upgrade apply v1.32.0 des de 1.30 és rebutjat; i un kubelet 1.31 contra un apiserver 1.30 està fora de la política de desfasament. Una menor cada vegada, pla de control primer.

8. kubectl drain bloquejat i forçar-lo amb --force. El que et bloqueja sol ser un PDB (09-05) protegint postgres-reserves o redis-cache. Forçar-ho pot provocar pèrdua de dades. Investiga abans amb kubectl get pdb -A.

9. Còpies d'etcd sense /etc/kubernetes/pki. El snapshot sense la CA no et torna un clúster funcional. Copia tots dos, junts, xifrats i fora del node.

10. kubeadm reset sense netejar iptables i CNI. Restes que provoquen fallades de xarxa a la reinstal·lació. Executa la neteja completa de l'apartat 14.

11. No fixar apt-mark hold. Un apt upgrade rutinari que actualitzi el kubelet en producció és un incident esperant a passar.

Escriu un script preparar-node.sh idempotent (que es pugui executar dues vegades sense trencar res) que deixi una màquina Ubuntu llesta per a kubeadm join: swap desactivat de forma permanent, mòduls i sysctl, containerd amb SystemdCgroup=true verificat, i kubeadm/kubelet/kubectl 1.30.4 fixats. L'script ha de fallar amb un missatge clar si alguna verificació no passa.

Escriu el fitxer de configuració de kubeadm per al clúster rutas-norte-lab amb aquests requisits: tres nodes de control darrere d'api-k8s.rutasnorte.example (IP virtual 10.10.0.10), podSubnet 172.16.0.0/16, etcd apilat, auditoria activada, i el kubelet reservant 500m de CPU i 512Mi de memòria per al sistema. Explica per què vas triar 172.16.0.0/16 i què comprovaries abans.

Redacta el procediment complet, en ordre i amb les ordres exactes, per actualitzar el clúster de 1.30.4 a 1.31.1 amb un node de control i dos de treball, incloent-hi la còpia de seguretat prèvia. Afegeix el criteri de "punt sense retorn" i què faries si l'apiserver no arrenca després d'upgrade apply.

Solució 1

Claus d'idempotència: el sed que no recomenta línies ja comentades, el [[ -s ]] abans de regenerar la configuració de containerd, i l'unhold abans d'instal·lar.

Solució 2

Per què 172.16.0.0/16: és un rang privat (RFC 1918) que no col·lisiona amb la xarxa del laboratori (10.10.0.0/24) ni amb serviceSubnet (10.96.0.0/12), i dona 65 536 IP, suficients. Comprovacions prèvies: que 172.16/16 no es faci servir a la xarxa corporativa ni a la VPN, i configurar el CNI amb aquest mateix CIDR.

Solució 3

Punt sense retorn: kubeadm upgrade apply, perquè migra l'esquema d'etcd. Abans, n'hi ha prou amb revertir els paquets; després, la marxa enrere exigeix restaurar el snapshot.

Si l'apiserver no arrenca: sudo crictl ps -a | grep apiserver, sudo crictl logs <id> i journalctl -u kubelet -f. Causes típiques: una bandera nova no suportada o un certificat mal generat. Si no es resol dins la finestra de manteniment, restaurar pre-131.db i pki-pre-131.tgz amb el procediment de l'apartat 13.2 i revertir els paquets a 1.30.4.

Ja saps muntar un clúster de Kubernetes des de zero sobre màquines pròpies. L'essencial:

• kubeadm arrenca un clúster conforme; no aprovisiona màquines ni instal·la el CNI. Aquesta frontera explica el 90 % dels dubtes inicials, inclòs el node NotReady.
• La preparació de les màquines —swap, overlay i br_netfilter, ip_forward, ports, i sobretot SystemdCgroup = true a containerd— és on neixen les fallades més difícils de diagnosticar.
• Un fitxer de configuració versionat (ClusterConfiguration, InitConfiguration, KubeletConfiguration) és infinitament millor que una tirallonga de banderes; controlPlaneEndpoint i certSANs ben posats des del primer dia t'estalvien regenerar certificats més tard.
• kubeadm deixa al node pods estàtics a /etc/kubernetes/manifests, els certificats a /etc/kubernetes/pki i els kubeconfig: l'arquitectura de 01-02, feta fitxers.
• Els nodes s'uneixen amb token i hash de la CA; el token caduca a les 24 hores i es regenera amb kubeadm token create --print-join-command. L'alta disponibilitat exigeix un punt d'entrada estable i un nombre senar de membres d'etcd, normalment 3 apilats.
• Els certificats caduquen a l'any, les actualitzacions van una versió menor cada vegada amb el pla de control abans que els nodes de treball, i les còpies d'etcd (snapshot + pki, xifrades, fora del node, amb restauració assajada) són la diferència entre un mal dia i la fi de l'empresa.

I l'advertiment que cal repetir: operar això en producció exigeix un equip dedicat amb guàrdia. A 10-06 veurem què t'estalvia un clúster gestionat i a quin preu.

Però abans hem de resoldre el problema amb què va començar aquest mòdul. Ja sabem crear clústers, locals i propis; el que continua sense resoldre's són els 120 fitxers YAML duplicats de Rutas Norte. A la lliçó següent, Helm, coneixerem el gestor de paquets de Kubernetes: charts, valors, plantilles i releases. És l'eina amb què ja vam instal·lar cert-manager (04-05) i kube-prometheus-stack (07-03) sense explicar-la; toca entendre-la de debò i fer-la servir per empaquetar la plataforma Rutas Norte en un únic chart amb un fitxer de valors per entorn.