A 10-02 vam muntar un clúster amb kubeadm i vam descobrir tot el que implica: preparar màquines, configurar containerd, generar certificats que caduquen a l'any, mantenir el quòrum d'etcd, assajar restauracions i actualitzar node a node. Vam acabar amb un advertiment clar: operar això en producció exigeix un equip dedicat amb guàrdia.

A 10-05 vam muntar GitOps, i ara tot l'estat de la plataforma Rutas Norte viu a Git. Això planteja una pregunta natural: si el clúster és reemplaçable i es reconstrueix sol, per què l'hauríem de mantenir nosaltres?

Aquesta lliçó respon a aquesta pregunta. Veurem què gestiona el proveïdor i què continua sent teu, compararem EKS, AKS i GKE en els criteris que de debò decideixen, tancarem la federació d'identitat que vam deixar pendent a 03-06, aprofitarem les instàncies interrompibles per a les càrregues tolerants de Rutas Norte, i acabarem amb una recomanació raonada.

1. El model de responsabilitat compartida
2. Comparació d'EKS, AKS i GKE
3. Identitat: IRSA i Workload Identity
4. Nodes: grups gestionats, plantilles i instàncies interrompibles
5. Què canvia en el que ja saps
6. Actualització de versió d'un clúster gestionat
7. Cost real i palanques d'estalvi
8. Portabilitat i dependència del proveïdor
9. La decisió per a Rutas Norte
10. Errors comuns i consells
11. Exercicis
12. Conclusió

Un clúster gestionat no és "Kubernetes sense feina". És una frontera diferent entre el que fa el proveïdor i el que fas tu.

El pla de control desapareix de les teves preocupacions. Els certificats que caduquen a l'any, el quòrum d'etcd, els snapshots, l'HAProxy davant dels tres nodes de control: tot això se'n va. És aproximadament la meitat de la lliçó 10-02.

Tota la resta continua igual. Els nodes continuen sent teus, amb el seu sistema operatiu que cal pedaçar. El RBAC continua sent teu. Les NetworkPolicies continuen sent teves. I si postgres-reserves perd dades, és el teu problema, no el del proveïdor.

Un error molt freqüent: "està gestionat, així que les còpies estan fetes". Fals. El proveïdor fa còpia d'etcd (la definició dels objectes), no dels volums de les teves aplicacions. De les dades de clients de postgres-reserves en fas la còpia tu, amb Velero o amb els snapshots del proveïdor. Ho vam veure a 05-06 i continua sent així.

La regla d'or: un clúster gestionat et treu la meitat de la feina d'operació de Kubernetes. L'altra meitat, la que has estudiat als mòduls 2 a 9, continua sent íntegrament teva.

Amb tres entorns separats en clústers diferents, això són uns 220 $/mes només per existir. És una de les raons per les quals moltes empreses separen entorns per namespace dins d'un clúster (com fa Rutas Norte) en comptes de per clúster.

Avís: el nivell gratuït d'AKS no té SLA financer. Per a rutas-norte-pro això pot ser inacceptable, i llavors el cost s'iguala.

El sistema de canals de GKE és una diferència real d'operació: tries "estable" i Google manté el clúster en una versió provada, actualitzant-lo a la finestra de manteniment que li indiquis. És el més a prop que s'està de no pensar en versions.

A EKS i AKS, el cicle és més manual. I si deixes caducar la versió, tots dos acaben forçant l'actualització, cosa que és pitjor que planificar-la.

Aquesta és la diferència tècnica més important i menys coneguda, i la que provoca sorpreses serioses en producció.

El problema que això causa a la pràctica: a EKS, cada pod consumeix una IP real de la teva VPC. Una instància t3.medium admet 3 interfícies de xarxa amb 6 IP cadascuna: 17 pods màxim, independentment que tingui CPU i memòria lliures. Si la teva subxarxa és un /24 (254 adreces), et quedes sense IP per a pods molt abans de quedar-te sense CPU.

I el símptoma quan s'esgota:

Un pod Pending sense que falti CPU ni memòria. Desconcertant si no coneixes el model.

Mitigacions a EKS: activar el mode de prefixos delegats (ENABLE_PREFIX_DELEGATION), que multiplica per 16 les IP disponibles per interfície; fer servir instàncies més grans; o planificar rangs de VPC generosos des del principi (un /16, no un /24).

A AKS amb Azure CNI clàssic, cal reservar per endavant maxPods × nombre de nodes adreces. Si planifiques malament, no pots escalar. La variant "superposició" (Azure CNI Overlay) resol això i és la recomanada avui.

A GKE amb natiu de VPC, es fan servir rangs secundaris d'IP àlies, cosa que separa l'adreçament de pods del de nodes. És el model més net dels tres.

Els tres han convergit en el mateix mecanisme: OIDC. El detallem a l'apartat 3.

GKE Autopilot mereix menció a part: és un mode en què no hi ha nodes en absolut des del teu punt de vista. Declares pods amb les seves requests i pagues exactament per això. No hi ha nodes per pedaçar ni per dimensionar, no hi ha DaemonSets propis, no hi ha hostPath ni privilegis. És Kubernetes reduït a la seva interfície de càrregues de treball.

• A favor: zero operació de nodes, facturació exacta pel sol·licitat, seguretat reforçada per defecte.
• En contra: restriccions fortes (no pots executar Falco de 08-06 tal com és, ni certs DaemonSets), cost per unitat més gran si els teus pods estan mal dimensionats, menys control.

AWS Fargate és similar però més limitat: no admet DaemonSets en absolut, no admet emmagatzematge persistent en bloc, ni privileged. Per a worker-notificacions pot encaixar; per a postgres-reserves, no.

Recordant 09-03: Karpenter no treballa amb grups de nodes predefinits, sinó que tria el tipus d'instància òptim per als pods pendents. Si informes-ocupacio necessita 8 CPU un cop per nit, Karpenter aixeca la instància justa, la fa servir i la retira. És una diferència notable de cost i de velocitat.

Conclusió honesta: la millor elecció gairebé sempre és el núvol on ja hi ha la resta de la teva infraestructura. La diferència tècnica entre els tres és menor que el cost d'operar en dos núvols alhora. Si comences de zero i només mires Kubernetes, GKE és el més polit; si la teva empresa ja viu a AWS, EKS amb Karpenter és excel·lent; si la teva empresa és un entorn Microsoft, AKS s'integra sense fricció.

Tanquem aquí el que va quedar anunciat a 03-06.

api-reserves necessita llegir un fitxer de tarifes d'un bucket d'emmagatzematge i publicar missatges en una cua. La forma tradicional:

Problemes: la credencial és permanent, cal rotar-la a mà, està en un Secret (base64, no xifrat, 03-02), i si es filtra serveix des de qualsevol lloc del món.

Els tres proveïdors convergeixen en el mateix mecanisme. El clúster exposa un emissor OIDC; el kubelet projecta al pod un token signat de curta durada amb la identitat de la ServiceAccount; el proveïdor de núvol confia en aquest emissor i bescanvia el token per credencials temporals.

Cap credencial permanent. Res a rotar. El token es renova sol i només serveix per a aquella ServiceAccount en aquell clúster.

La màgia és a la política de confiança del rol, la condició de la qual limita qui el pot assumir:

Fixa't en sub: només la ServiceAccount api-reserves del namespace rutas-norte-pro pot assumir aquest rol. Ni una altra SA, ni la mateixa SA en un altre namespace.

Al Deployment n'hi ha prou amb serviceAccountName: api-reserves: sense variables de credencials, perquè l'SDK del proveïdor detecta el token projectat automàticament. Pots verificar-ho amb kubectl exec ... -- ls /var/run/secrets/eks.amazonaws.com/serviceaccount/.

Nota: AWS ha introduït EKS Pod Identity, més senzill (una associació a l'API d'EKS, sense proveïdor OIDC ni anotació). És l'opció recomanada per a clústers nous; IRSA continua sent necessària si la càrrega corre fora d'EKS.

El mecanisme és el mateix; canvien les ordres i l'anotació.

L'important per a tu: en els tres casos, el manifest que va a Git conté una anotació amb un identificador, mai un secret. És exactament el model que buscàvem a 03-06 i que encaixa perfectament amb GitOps (10-05).

Un grup de nodes gestionat és un conjunt de màquines homogènies que el proveïdor manté: les crea, les uneix al clúster, les actualitza de forma gradual i les substitueix si fallen.

Fixa't en instanceTypes amb quatre tipus al grup interrompible: com més tipus acceptes, menor és la probabilitat que el proveïdor no tingui capacitat i t'ho interrompi tot alhora.

Són capacitat sobrant del proveïdor a un 60-90 % de descompte, amb una contrapartida: el proveïdor la pot reclamar amb un avís de 2 minuts (AWS), 30 segons (Azure) o 30 segons (GCP).

Els manifestos, amb el que hem après a 06-05 i 09-05 (el detall complet és a la solució de l'exercici 1):

I un PDB amb minAvailable: 1, perquè encara que siguin interrompibles, no volem que caiguin tots alhora (09-05).

Matís important sobre el PDB: un PodDisruptionBudget protegeix davant d'interrupcions voluntàries (drenatge d'un node per actualitzar-lo). Una interrupció d'una instància spot és involuntària: el proveïdor s'emporta la màquina, amb PDB o sense. El PDB ajuda perquè els gestors de terminació (AWS Node Termination Handler, o el maneig natiu de Karpenter) cordonen i drenen el node en rebre l'avís, i aquell drenatge sí que respecta el PDB.

informes-ocupacio, en ser un CronJob nocturn (06-03), és un cas encara més clar: a més de la toleration pot portar un nodeSelector dur sobre rutasnorte.example/interrompible: "true" —si no hi ha capacitat, esperar és acceptable— i un backoffLimit: 6 generós, perquè la interrupció és esperable.

En lloc de definir grups amb tipus fixos, declares restriccions i Karpenter tria:

Diferències amb el Cluster Autoscaler (09-03):

Aquest apartat repassa les lliçons anteriors del curs i assenyala què és diferent al núvol.

A minikube fèiem servir standard, un directori del node. Al núvol:

L'error clàssic: postgres-reserves amb volumeBindingMode: Immediate crea el disc a eu-west-1a; el planificador col·loca el pod a eu-west-1c; el pod es queda Pending per sempre amb volume node affinity conflict. Solució: WaitForFirstConsumer, que és el valor que porten per defecte les StorageClass dels tres proveïdors.

En local es quedava a <pending> i calia minikube tunnel. Al núvol funciona de debò:

Coses per aprendre:

• Cada Service de tipus LoadBalancer costa diners (uns 20-25 $/mes més el trànsit). Per això se'n fa servir un de sol per al controlador d'Ingress i tota la resta va per regles d'Ingress (04-04).
• Les anotacions són específiques de cada proveïdor. Són la part menys portable dels teus manifestos (apartat 8).
• Esborrar el Service esborra el balancejador. I si el balancejador té un registre DNS apuntant-hi, es trenca.
• externalTrafficPolicy: Local conserva la IP del client però requereix que hi hagi un pod a cada node amb endpoints; si no, el trànsit a aquell node es descarta.

Els tres proveïdors ofereixen a més un controlador d'Ingress gestionat (AWS Load Balancer Controller, Application Gateway Ingress Controller, GKE Ingress) que crea un balancejador de capa 7 directament des de l'objecte Ingress. És còmode, però et lliga més al proveïdor que ingress-nginx.

L'avantatge pràctic: desapareix l'imagePullSecrets. El node s'autentica amb la seva identitat de núvol. Un Secret menys per gestionar.

I s'integra amb el de 08-05: la signatura amb Cosign i la política d'admissió funcionen igual, amb l'avantatge que els tres registres ofereixen escaneig automàtic que alimenta el que hem après a 08-06.

Consell pragmàtic: mantenir Prometheus (07-03) per a les mètriques de les aplicacions, perquè les teves alertes i panells són portables, i fer servir el servei del proveïdor per als registres (07-05), perquè operar EFK a escala és car i dolorós, i el cost del servei gestionat sol sortir a compte. És la combinació que tria la majoria d'equips.

Compte amb el cost dels registres: api-reserves amb LOG_LEVEL=debug en producció pot generar centenars de GB al mes. Els tres proveïdors cobren per ingesta.

Comparat amb el procediment de kubeadm (10-02), això és un passeig. Però continua exigint planificació, i qui ho tracta com un botó s'emporta un disgust.

1. Les APIs eliminades continuen sent el teu problema. Si un manifest de k8s/base fa servir una API que desapareix a 1.31, el clúster s'actualitza i la teva aplicació deixa de desplegar-se.

2. Els complements de tercers tenen les seves pròpies matrius de compatibilitat. cert-manager, ingress-nginx, KEDA, Prometheus Operator, el controlador CSI: cadascun suporta un rang de versions. Una actualització del clúster sense actualitzar-los els pot trencar.

3. L'actualització dels nodes reinicia tots els pods. El proveïdor drena cada node per torns. Això exercita:

• Els teus PodDisruptionBudgets (09-05): si estan mal configurats, el drenatge es bloqueja o, pitjor, se salta amb --force.
• Les teves sondes de readiness (07-01): si api-reserves triga 45 segons a estar llest i el drenatge va ràpid, hi ha tall.
• El teu terminationGracePeriodSeconds i el teu hook preStop.
• La teva capacitat d'absorbir la pèrdua temporal d'un node: si el clúster està al 95 % d'ocupació, drenar un node deixa pods Pending.

4. El pla de control i els nodes s'actualitzen per separat, i cal respectar el desfasament de versions (10-02): nodes com a molt 3 menors per sota de l'apiserver, i mai per sobre.

Aquest últim punt tanca el cercle amb la primera lliçó del mòdul: l'entorn local ha de seguir producció.

Una sorpresa habitual: el trànsit entre zones de disponibilitat es cobra. Si api-reserves és a la zona A i postgres-reserves a la zona B, cada consulta creua una frontera facturada. Amb volum alt, això són centenars d'euros al mes. És un argument a favor de l'afinitat de zona... que xoca amb l'alta disponibilitat de 09-05. És un compromís real que cal decidir conscientment.

1. Dimensionar bé (el que hem après a 09-02). És la palanca amb millor relació esforç/estalvi, i gairebé ningú la fa servir. El patró típic: algú va posar requests: {cpu: 1, memory: 2Gi} "per si de cas" i el pod fa servir 80m i 200Mi. El planificador reserva el que s'ha demanat, així que estàs pagant 12 vegades el que fas servir.

Ajustar requests a la recomanació a tota la plataforma sol reduir la factura de còmput entre un 30 i un 50 %.

2. Autoescalat real (09-01 i 09-03). Amb l'HPA ajustant pods i Karpenter o el Cluster Autoscaler ajustant nodes, pagues per la càrrega real i no pel pic anual. Rutas Norte té pics als ponts: sense autoescalat, o dimensiones per al pont tot l'any, o caus el dia del pont.

3. Instàncies interrompibles. 60-90 % de descompte a worker-notificacions i informes-ocupacio.

4. Apagar els entorns que no es fan servir de nit. rutas-norte-dev no fa res de les 20:00 a les 8:00 ni els caps de setmana. Això són 128 de 168 hores setmanals: un 76 % d'estalvi en aquell entorn.

Atenció amb GitOps: si Argo CD té selfHeal actiu a rutas-norte-dev, revertirà l'escalat a zero en tres minuts. Per això a la solució de l'exercici 1 de 10-05 vam deixar selfHeal: false a dev. L'alternativa neta és escalar el grup de nodes en comptes dels Deployments, o fer servir una finestra de sincronització de l'AppProject.

5. Compromisos d'ús. Els tres proveïdors descompten un 30-55 % a canvi de comprometre una despesa o una capacitat durant 1 o 3 anys (Savings Plans i Reserved Instances a AWS, Reservations a Azure, Committed Use Discounts a GCP).

Estratègia recomanada: comprometre només la base estable (els nodes que estan encesos sempre), deixar el pic sota demanda i les càrregues tolerants en spot.

6. Visibilitat del cost per equip. Eines com OpenCost o Kubecost reparteixen la despesa per namespace, etiqueta o equip. Sense això, ningú sap que informes-ocupacio costa 400 €/mes i ningú té incentiu per arreglar-ho. Les etiquetes de 02-07 (app.kubernetes.io/part-of, entorn) són la base d'aquell repartiment.

Tot això val de poc si d'aquí a dos anys vols canviar de núvol i no pots. Serem precisos sobre què és portable a Rutas Norte.

El patró evident: el que està dins de Kubernetes és portable; el que està fora no ho és. La dependència del proveïdor no ve d'EKS, AKS o GKE, sinó dels serveis que envolten el clúster.

1. Aïlla el que no és portable a les superposicions de Kustomize. Ja ho tens muntat des de 10-04:

Canviar de núvol és canviar una línia a components:. La base no es toca.

2. Fes servir ingress-nginx en comptes del controlador del proveïdor. És una capa d'abstracció que costa una mica de rendiment i estalvia una migració sencera. Les regles d'Ingress i les anotacions de nginx funcionen igual als tres núvols.

3. Fes servir Prometheus per a les mètriques. Les teves alertes i panells són el coneixement operatiu acumulat d'anys. En PromQL són portables; en el llenguatge de consulta del proveïdor, no.

4. Terraform en comptes de l'eina nativa. No fa la infraestructura portable, però sí el model mental i els fluxos de treball.

5. Decideix conscientment sobre les bases de dades. Executar postgres-reserves com a StatefulSet amb un operador (06-01, 06-07) és portable; fer servir el servei gestionat del proveïdor és més còmode i menys portable. Totes dues són decisions defensables; el que no val és prendre-la sense adonar-se'n.

6. Sigues realista. La portabilitat total costa diners i complexitat, i moltes empreses mai canvien de núvol. Un objectiu sensat: "podríem migrar en tres mesos amb esforç, no en tres dies". Això et dona poder de negociació i et protegeix d'un canvi de preus abusiu, sense pagar l'impost de l'abstracció total.

• Empresa petita: dues persones a plataforma, sis a desenvolupament, tres a suport.
• Cap cobertura de guàrdia 24×7.
• Trànsit amb pics forts i previsibles: ponts i vacances, 8-10 vegades la càrrega base.
• Dades personals de clients a postgres-reserves: exigències del RGPD sobre localització i xifratge.
• Pressupost ajustat.
• Ja fa servir emmagatzematge d'objectes i correu transaccional d'AWS per a altres coses.

Amb dues persones a plataforma i sense guàrdia, kubeadm (10-02) queda descartat. La pregunta decisiva és: qui restaura etcd un diumenge a les 4 de la matinada? Si la resposta és "esperem al dilluns", no es pot operar rutas-norte-pro amb un clúster propi. L'estalvi del pla de control (uns 220 €/mes amb tres clústers) no compensa ni de bon tros el risc.

Si Rutas Norte no fes servir ja AWS, la recomanació seria GKE: el model de xarxa més net, Workload Identity més senzilla, canals de versió que redueixen la feina d'actualització, i Autopilot com a opció per als entorns no productius.

Dos clústers, no tres. Separar pro de la resta és una frontera de seguretat real; separar dev de pre no ho justifica: els namespaces amb quotes (03-04) i NetworkPolicies (04-06) són suficients, i estalvien 73 $/mes més l'operació.

Sense les palanques d'estalvi (tot sota demanda, sense spot, sense apagada nocturna, sense compromisos, amb requests sobredimensionades) la mateixa plataforma costaria de l'ordre de 1.400-1.600 $/mes. Les palanques de l'apartat 7 no són teoria: són més de la meitat de la factura.

Un clúster gestionat no és més barat que un de propi en cost d'infraestructura pura. És més barat en cost total, perquè inclou la feina que no has de fer i el risc que no assumeixes. Per a Rutas Norte S.L., amb dues persones a plataforma i sense guàrdia, és l'única opció defensable.

I hi ha una simetria que convé notar: gràcies a GitOps (10-05), la decisió és reversible. Tot l'estat de la plataforma és a Git. Si demà hi ha una raó per canviar de núvol o per muntar un clúster propi, s'aixeca el clúster nou, s'instal·la Argo CD, s'aplica l'Application arrel i en vint minuts la plataforma està dempeus. Les dades es migren a part, que és la part difícil, però la plataforma es reconstrueix sola.

1. Creure que "gestionat" inclou les còpies de les teves dades. El proveïdor fa còpia d'etcd, no dels teus volums. postgres-reserves és la teva responsabilitat: Velero (05-06) i snapshots, amb restauració assajada.

2. No planificar l'adreçament IP. A EKS amb VPC CNI, cada pod consumeix una IP real de la VPC. Un /24 s'esgota de seguida i el símptoma (FailedCreatePodSandBox) no menciona les IP de forma òbvia. Planifica rangs generosos i activa la delegació de prefixos.

3. Un Service de tipus LoadBalancer per aplicació. Cadascun costa 20-25 $/mes. Fes servir-ne un per al controlador d'Ingress i encamina amb regles d'Ingress (04-04).

4. StorageClass amb volumeBindingMode: Immediate en un clúster multizona. El disc es crea en una zona, el pod es planifica en una altra, i el pod no arrenca mai. Fes servir WaitForFirstConsumer.

5. Posar càrregues amb estat en instàncies interrompibles. postgres-reserves en spot és una recepta per perdre dades. Només càrregues que tolerin morir sense avís, amb terminationGracePeriodSeconds i hook preStop adequats.

6. Un sol tipus d'instància al grup interrompible. Si el proveïdor es queda sense aquell tipus, s'emporta tots els teus nodes alhora. Declara 4-6 tipus equivalents.

7. Continuar fent servir credencials estàtiques a Secrets. IRSA, Workload Identity i el seu equivalent a Azure eliminen les credencials permanents. És de les millores de seguretat amb millor relació cost/benefici que existeixen.

8. Actualitzar la versió sense comprovar les APIs eliminades ni els complements. El clúster s'actualitza sense problema i la teva aplicació deixa de desplegar-se, o ingress-nginx deixa d'arrencar. kubent i les matrius de compatibilitat, abans de tocar res.

9. requests sobredimensionades "per si de cas". És la principal causa de sobrecost a Kubernetes. El VPA en mode Off (09-02) et dona els números reals en una setmana.

10. Ignorar el trànsit entre zones. En aplicacions molt xerraires pot ser una partida important. Mesura-ho abans de decidir; és un compromís real amb l'alta disponibilitat de 09-05.

11. No etiquetar per al repartiment de costos. Sense entorn, app.kubernetes.io/part-of i una etiqueta d'equip, la factura és un número global que ningú pot reduir. Les etiquetes de 02-07 són la base d'OpenCost o Kubecost.

12. Adoptar Autopilot o Fargate sense comprovar les restriccions. Falco (08-06), alguns DaemonSets de xarxa i tot el que necessiti privilegis poden no funcionar. Prova primer en un entorn no productiu.

13. Confondre "menys operació" amb "sense operació". Continues sent responsable dels nodes, del RBAC, de les polítiques, dels secrets, de l'observabilitat i del cost. Els mòduls 2 a 9 d'aquest curs continuen sent enterament aplicables.

Escriu el conjunt complet de manifestos que permet executar worker-notificacions en un grup de nodes interrompibles marcat amb el taint rutasnorte.example/interrompible=true:NoSchedule, sense deixar de funcionar si no hi ha capacitat spot. Ha d'incloure: tolerations, afinitat de node preferent, distribució topològica, terminationGracePeriodSeconds amb hook preStop, un PDB i un ScaledObject de KEDA. Explica per què fas servir afinitat preferent i no nodeSelector, i què protegeix realment el PDB davant d'una interrupció de spot.

Dissenya el component k8s/components/proveidor-aws/ que contingui tot l'específic d'AWS que Rutas Norte necessita: la StorageClass rutas-norte-ssd amb EBS gp3 xifrat, un pedaç que afegeixi l'anotació d'IRSA a les ServiceAccounts d'api-reserves i worker-notificacions, i un pedaç que afegeixi les anotacions de balancejador de xarxa al Service del controlador d'Ingress. Explica com s'activaria des de la superposició de pro i què caldria canviar per migrar a Azure.

La factura de rutas-norte-pro és de 1.450 $/mes: 980 $ de còmput, 180 $ d'emmagatzematge, 120 $ de balancejadors (5 Services de tipus LoadBalancer), 90 $ de trànsit i 80 $ de registres. Tots els pods tenen requests: {cpu: 500m, memory: 1Gi} i kubectl top mostra un ús mitjà de 90m i 220Mi. No hi ha instàncies interrompibles ni compromisos. Proposa un pla prioritzat amb les ordres de diagnòstic, l'estalvi estimat de cada mesura i el risc associat.

Solució 1

Afinitat preferent i no nodeSelector: nodeSelector és una restricció dura. Si no hi ha capacitat spot a la regió —cosa que passa precisament als pics, quan més falta fa— els pods es quedarien Pending indefinidament. Amb preferredDuringScheduling, el planificador intenta el node interrompible i, si no n'hi ha, en fa servir un de sota demanda: es paga més, però el servei no s'atura.

Què protegeix el PDB: res davant de la interrupció en si (el proveïdor s'emporta la màquina). Protegeix durant el drenatge que el manejador de terminació (o Karpenter) executa en rebre l'avís de 2 minuts: aquell drenatge respecta el PDB, així que no es buiden dos nodes simultàniament deixant la cua sense consumidors.

Solució 2

storageclass.yaml és el de l'apartat 5 (provisioner ebs.csi.aws.com, gp3 xifrat, WaitForFirstConsumer). Els dos pedaços són fusions estratègiques mínimes; el target s'encarrega de a qui s'apliquen, així que el metadata.name del pedaç és irrellevant:

Migrar a Azure: crear k8s/components/proveidor-azure/ amb provisioner: disk.csi.azure.com, l'anotació azure.workload.identity/client-id (més l'etiqueta azure.workload.identity/use: "true" als pods) i les anotacions de balancejador d'Azure. Després, canviar aquella única línia. k8s/base/ no es toca en absolut.

Solució 3

Ordre i risc: es comença per l'ajust de requests perquè és el de més estalvi i menys risc, aplicant-lo primer a pre, verificant amb k6 (09-06) i després a pro component a component. El compromís d'ús va l'últim a propòsit: només té sentit comprometre's a una capacitat després d'haver-la reduït, o estaries pagant per endavant el sobredimensionament.

Es tanca aquí el mòdul 10. L'essencial d'aquesta lliçó:

• El model de responsabilitat compartida et treu el pla de control sencer —etcd, certificats, quòrum, actualitzacions, alta disponibilitat—, és a dir, aproximadament la meitat de la feina de 10-02. Tota la resta, inclosos els nodes, el RBAC, les polítiques, els secrets, l'observabilitat, les còpies de les teves dades i el cost, continua sent teu.
• EKS, AKS i GKE s'assemblen més que no pas es diferencien. Les diferències que de debò decideixen són el model de xarxa i l'assignació d'IP als pods, el cicle de versions, l'autoescalat (Karpenter destaca) i els modes automàtics (Autopilot destaca). I per damunt de tot: el núvol on ja és la teva infraestructura.
• La federació d'identitat —IRSA, Workload Identity i el seu equivalent a Azure— elimina les credencials permanents dels Secrets. El manifest que va a Git porta una anotació, no un secret. Tanca el que es va prometre a 03-06.
• Les instàncies interrompibles són estalvi real per a worker-notificacions i informes-ocupacio, si s'acompanyen de tolerations, afinitat preferent, distribució topològica, preStop i PDB.
• El que ja sabies canvia de forma concreta: la StorageClass és del proveïdor i necessita WaitForFirstConsumer, el LoadBalancer per fi obté IP (i factura), el registre s'autentica amb la identitat del node, i les mètriques i registres es poden delegar.
• L'actualització continua exigint planificació: APIs eliminades, matrius de compatibilitat dels complements, PDB que permetin drenar i sondes que aguantin el reinici.
• El cost es domina amb sis palanques, i les dues primeres —ajustar requests amb el VPA i apagar el que no es fa servir— són les de millor relació esforç/benefici.
• I la portabilitat depèn del que posis fora de Kubernetes, no de quin gestionat triïs. Aïllar l'específic del proveïdor en un component de Kustomize deixa la base 100 % portable.

Per a Rutas Norte S.L., la recomanació és EKS a eu-west-1, amb dos clústers, Karpenter, instàncies interrompibles per a les càrregues tolerants i les palanques d'estalvi aplicades des del primer dia. I gràcies a GitOps, aquesta decisió és reversible.

Amb això acaba el recorregut per l'ecosistema. Ja tens totes les peces: clústers locals i propis, empaquetat amb Helm, superposicions amb Kustomize, desplegament continu amb GitOps i una plataforma gestionada on recolzar-ho tot. Sumades als nou mòduls anteriors —pods, serveis, configuració, xarxa, emmagatzematge, patrons avançats, observabilitat, seguretat i escalat—, ja coneixes totes les peces per separat.

El que falta és veure-les funcionar juntes. Al Mòdul 11: Estudis de Cas i Aplicacions del Món Real recorrerem escenaris complets de principi a fi: el desplegament d'una aplicació web des de zero, l'execució d'aplicacions amb estat, una canalització de CI/CD completa, les estratègies de desplegament blue-green i canary, la gestió multi-clúster i, per tancar, l'operació en producció de debò: incidències, runbooks i control de costos. Aquí és on el coneixement es converteix en criteri.