La lliçó anterior va acabar amb un problema que ni Helm ni Kustomize resolen. Totes dues eines només actuen quan algú executa una ordre. Si un company fa kubectl edit a rutas-norte-pro a les tres de la matinada per sortir d'un compromís, cap se n'assabenta. Si el portàtil de qui desplega s'espatlla, ningú sap desplegar. I si la canalització ci-rutasnorte necessita credencials d'administrador del clúster per executar kubectl apply, hem obert un forat de seguretat que contradiu el RBAC mínim que tant vam cuidar a 08-01.

GitOps és la resposta, i és la conclusió natural de tot el que portem de curs. La idea és senzilla d'enunciar i transformadora a la pràctica: un agent que viu dins del clúster, mira un repositori de Git de forma contínua, i s'encarrega que el clúster s'assembli al que diu aquest repositori. Sempre. Sense que ningú executi res.

En aquesta lliçó muntarem aquest sistema per a Rutas Norte amb Argo CD, veurem el seu equivalent a Flux, resoldrem per fi el conflicte entre l'HPA i el camp replicas anunciat a 09-01, i tancarem el problema dels secrets al repositori que va quedar pendent des de 03-02.

1. Què és GitOps i els seus quatre principis
2. Model d'enviament davant de model d'extracció
3. Deriva de configuració i autocorrecció
4. Argo CD: arquitectura i instal·lació
5. El recurs Application camp a camp
6. App of apps i ApplicationSet
7. Onades de sincronització i hooks
8. Estats de salut i sincronització
9. Flux: els controladors i els seus recursos
10. Argo CD davant de Flux
11. El problema dels secrets
12. Camps que canvien sols: ignoreDifferences
13. Estructura de repositoris i promoció entre entorns
14. Errors comuns i consells
15. Exercicis
16. Conclusió

GitOps és un model operatiu en què l'estat desitjat del sistema viu a Git i un agent automatitzat el fa realitat de forma contínua. El grup de treball OpenGitOps el va formalitzar en quatre principis:

1. Declaratiu: tot el sistema es descriu pel que ha d'existir, no pels passos a executar. Ja ho tenim des de 01-06: Kubernetes és declaratiu per disseny.
2. Versionat i immutable: l'estat desitjat s'emmagatzema de manera que l'historial no es pugui alterar. Git és la implementació òbvia. La pregunta "què va canviar en producció el dimarts?" passa de ser una investigació forense a git log.
3. Aplicat automàticament: els canvis aprovats s'apliquen sense intervenció manual. Ningú executa kubectl apply ni helm upgrade: es fusiona una petició de canvi i el sistema convergeix.
4. Reconciliat de forma contínua: i aquest és el que ho canvia tot. L'agent no es limita a aplicar quan hi ha un commit nou: comprova contínuament que l'estat real coincideix amb el desitjat i corregeix les diferències.

Aquest bucle no para mai. Cada tres minuts (configurable), l'agent es pregunta: "el clúster és com diu Git?". Si no ho és, actua.

Aquesta és la diferència arquitectònica clau, i té implicacions de seguretat serioses.

Al model d'enviament, la canalització executa kubectl apply contra el clúster i per a això necessita un kubeconfig amb permisos. El problema, en detall:

1. Aquest kubeconfig és un secret emmagatzemat fora del clúster, sovint gestionat per un altre equip o per un proveïdor extern.
2. Per poder desplegar qualsevol cosa en qualsevol namespace, sol acabar tenint cluster-admin. És el més fàcil, i per això és el que hi ha a la majoria de les empreses.
3. Qualsevol que pugui modificar la definició de la canalització —un fitxer YAML del repositori de codi— pot executar ordres arbitràries amb aquestes credencials. Una petició de canvi maliciosa a un fitxer de CI equival a accés d'administrador a producció.
4. L'apiserver ha de ser abastable des de l'exterior.
5. Les credencials cal rotar-les, auditar-les i revocar-les, i amb tres clústers, tres jocs.

El RBAC mínim que vam definir per a ci-rutasnorte a 08-01 mitiga el problema, però no l'elimina: la canalització continua tenint una credencial permanent cap a dins del clúster.

El canvi és profund: la credencial més perillosa desapareix. Si algú roba el token d'escriptura a Git, pot fer un commit... que quedarà registrat, serà revisable i es podrà revertir.

La deriva de configuració és la diferència entre el que diuen els teus fitxers i el que hi ha realment al sistema. S'acumula sense que ningú se n'adoni. Casos reals de Rutas Norte:

• Durant un incident del pont de maig, algú va fer kubectl scale deploy/api-reserves --replicas=12. Va funcionar. Ningú ho va portar al manifest. Tres setmanes després, un desplegament rutinari va tornar el Deployment a 4 rèpliques i el servei es va saturar.
• Es va canviar un límit de memòria amb kubectl edit per provar una hipòtesi. Va quedar així sis mesos.
• Es va afegir una anotació a l'Ingress per ajustar un temps d'espera. Quan es va recrear el clúster de pre, va desaparèixer i ningú va saber per què el comportament va canviar.

Amb GitOps, kubectl scale deploy/api-reserves --replicas=12 en producció té un altre desenllaç. Tres minuts després:

Ha tornat a 4. I això és exactament el que volem. No és que la màquina sigui tossuda: és que si 12 rèpliques era la decisió correcta, ha d'estar a Git, on queda revisada, documentada i present la propera vegada que es recreï l'entorn.

El canvi cultural que això provoca és més important que la tecnologia: l'única forma de canviar producció és a través d'una petició de canvi. Al principi genera fricció; al cap de dos mesos, ningú vol tornar enrere.

L'autocorrecció és una decisió, no una obligació. Argo CD permet activar selfHeal per aplicació. A rutas-norte-dev pot convenir deixar-lo desactivat perquè la gent experimenti; a rutas-norte-pro ha d'estar activat.

Detall clau: el controlador d'aplicacions és l'únic que necessita permisos sobre els objectes del clúster. El servidor d'API només gestiona recursos d'Argo CD. Aquesta separació importa per al RBAC.

La instal·lació coherent amb el que hem après és per Helm (10-03), amb valors versionats:

En producció, l'usuari admin es desactiva i es fa servir un proveïdor d'identitat (OIDC, SSO corporatiu). El RBAC d'Argo CD es configura a part del de Kubernetes, al ConfigMap argocd-rbac-cm:

I es registra el repositori amb una credencial de només lectura: Argo CD mai escriu al repositori de manifestos. És el privilegi mínim de 08-01 aplicat aquí.

Application és un CRD (06-06). Cada instància diu: "d'aquest repositori, aquesta ruta, a aquest clúster i namespace, amb aquesta política".

Un AppProject restringeix què pot fer un grup d'aplicacions. És una capa de seguretat essencial quan diversos equips comparteixen Argo CD.

Aquest clusterResourceWhitelist: [] és important: significa que ni un error en un manifest pot crear un ClusterRole o una StorageClass. Sense ell, qui pugui escriure al repositori pot escalar privilegis al clúster.

Argo CD executa internament helm template, així que no crea releases de Helm: no veuràs res a helm list. L'estat el porta Argo CD, no Helm. És coherent amb GitOps (l'estat és a Git), però sorprèn la primera vegada.

Un patró molt útil és el de múltiples orígens: el chart ve d'un repositori públic i els valors del repositori de l'empresa, referenciat amb ref: valors i valueFiles: [$valors/plataforma/.../valors-pro.yaml].

Amb vint aplicacions, crear cada Application a mà i aplicar-la amb kubectl ens torna al problema original. La solució: una Application que gestiona un directori ple d'Applications.

Aquesta és l'última vegada que algú executa kubectl apply a Rutas Norte. A partir d'aquí, afegir una aplicació nova és afegir un fitxer al directori aplicacions/ i fusionar la petició de canvi.

Una definició, tres aplicacions. Hi ha més generadors, i alguns obren possibilitats notables:

Aquest últim és espectacular a la pràctica: obres una PR amb l'etiqueta vista-previa i apareix un entorn complet desplegat; la tanques i desapareix sola.

Argo CD aplica els objectes en un ordre per tipus (Namespace, CRDs, ConfigMaps, Secrets i al final les càrregues). Quan necessites un ordre propi, fas servir onades: argocd.argoproj.io/sync-wave: "-5". Van de menor a major, i Argo CD espera que tots els objectes d'una onada estiguin sans abans de passar a la següent.

Els hooks són l'equivalent dels de Helm (10-03): PreSync, Sync, PostSync, SyncFail i Skip.

Les polítiques d'esborrat són HookSucceeded, HookFailed (no la facis servir: perds els logs) i BeforeHookCreation (recomanada). I un PostSync amb un curl --fail a /salut/preparat és una prova de fum excel·lent: si falla, l'aplicació queda Degraded i Argo CD t'avisa encara que els pods estiguin arrencats.

Argo CD maneja dos estats independents. Confondre'ls és l'error conceptual més comú.

• Estat de sincronització — el clúster coincideix amb Git?: Synced, OutOfSync, Unknown.
• Estat de salut — l'aplicació funciona?: Healthy, Progressing, Degraded, Suspended, Missing, Unknown.

Són ortogonals. Les quatre combinacions importants:

Argo CD sap avaluar la salut dels tipus estàndard (Deployment, Service, Ingress, StatefulSet, Job, PVC). Per a CRDs s'escriuen avaluadors propis en Lua, al ConfigMap argocd-cm:

Compte amb argocd app rollback: reverteix el clúster, però no reverteix Git. Amb selfHeal actiu, en tres minuts l'agent tornarà el clúster al que diu Git i el teu rollback desapareixerà. El rollback d'Argo CD és una mesura d'emergència; el rollback de veritat a GitOps és git revert seguit d'una petició de canvi, i Argo CD sincronitza sol.

Flux té una filosofia diferent: en comptes d'una aplicació amb interfície web, és un conjunt de controladors especialitzats, cadascun amb el seu CRD.

Aquest bootstrap és una decisió de disseny interessant: Flux s'instal·la a si mateix mitjançant GitOps. Escriu els seus propis manifestos al repositori i després es gestiona des d'allà. Actualitzar Flux és fer un commit.

Per als charts de tercers hi ha HelmRepository i HelmRelease, i a diferència d'Argo CD, Flux sí que crea releases de Helm de veritat (apareixen a helm list), amb install.remediation i upgrade.remediation com a equivalent d'--atomic.

Capacitat que Flux té de sèrie i Argo CD només mitjançant un projecte a part:

I al manifest es marca quin camp cal actualitzar: newTag: 2.4.1 # {"$imagepolicy": "flux-system:api-reserves:tag"}. Flux detecta una etiqueta nova al registre, fa un commit a Git actualitzant-la, i el cicle GitOps normal la desplega. L'estat continua a Git: l'automatització escriu a Git, no al clúster.

Tria Argo CD si vols que desenvolupament i suport puguin veure l'estat del desplegament sense aprendre kubectl (la interfície web és una eina de comunicació, no un caprici), gestiones diversos clústers des d'un punt central, o necessites la flexibilitat d'ApplicationSet.

Tria Flux si prefereixes una eina lleugera operada per CLI i per Git, vols l'automatització d'imatges de sèrie, necessites releases de Helm de veritat, o tens molts clústers petits i autònoms.

Per a Rutas Norte triem Argo CD, per dues raons concretes: l'equip de suport necessita veure l'estat dels desplegaments sense ser expert en Kubernetes, i ApplicationSet genera els tres entorns des d'una definició. Cap elecció és irreversible: totes dues llegeixen els mateixos manifestos de Kustomize i els mateixos charts de Helm, així que canviar afecta els fitxers de k8s-gitops/, no els de k8s/.

Aquí arriba l'objecció que apareix sempre: si tot va a Git, on poso la contrasenya de postgres-reserves?

A 03-02 vam dir que els Secrets estan codificats en base64, no xifrats, i que versionar-los requereix una eina específica. Ha arribat el moment. I recorda: un secret que ha estat a Git està compromès per sempre, encara que facis commit per esborrar-lo. L'historial el conserva, i qualsevol que hagi clonat el repositori el té.

SOPS xifra els valors d'un YAML deixant les claus llegibles, fent servir una clau d'un KMS, age o PGP.

Avantatge enorme: els diffs continuen sent llegibles, veus quina clau ha canviat encara que no el seu valor. Flux porta suport natiu (decryption: { provider: sops, secretRef: ... }); a Argo CD cal un plugin o ksops, cosa que és un punt en contra.

Un controlador al clúster genera un parell de claus. Tu xifres amb la pública; només aquest clúster pot desxifrar.

El SealedSecret resultant, amb el seu encryptedData, és segur en un repositori públic. Contrapartides: el diff no diu res (tot el bloc canvia encara que canviïs una lletra), el secret està lligat a un namespace i nom concrets, i cal fer còpia de la clau mestra del controlador o perdràs la capacitat de desxifrar si recrees el clúster.

La més neta conceptualment: el secret no és a Git de cap manera, ni xifrat. A Git només hi ha una referència.

Recomanació per a Rutas Norte: External Secrets Operator amb Vault. La plataforma maneja dades personals de clients i credencials de la passarel·la de pagaments; la rotació automàtica i l'auditoria d'accessos no són luxes. Sealed Secrets és una alternativa raonable per començar sense infraestructura extra.

Regla que no canvia amb cap de les tres: si un secret ha arribat a Git en clar, cal rotar-lo. Sempre.

I arribem al problema que vam deixar anunciat a 09-01.

api-reserves té un HPA que ajusta spec.replicas entre 4 i 20 segons la càrrega. El manifest a Git diu replicas: 4. Quan arriba el pont de maig, l'HPA puja a 15. Sense res més:

Argo CD ha baixat a 4 rèpliques en plena hora punta. Trenta segons després, l'HPA les torna a pujar. I al cap de tres minuts, Argo CD les baixa una altra vegada. És un bucle de guerra entre dos controladors, i qui pateix és el client que intenta comprar un bitllet.

La solució té dues parts. Primera: no declarar replicas al manifest, com ja vam fer a 10-04. Segona: ignoreDifferences, perquè encara que el camp no sigui a Git, Argo CD compara l'objecte viu amb el generat i el detecta igualment.

Flux ho resol d'una altra manera: traient el camp de l'objecte desitjat abans d'aplicar, amb un patch d'op: remove sobre /spec/replicas, de manera que server-side apply no en reclama la propietat i l'HPA queda lliure.

Consell d'operació: quan una aplicació apareix OutOfSync de forma persistent i no entens per què, argocd app diff t'ho diu en dos segons. Gairebé sempre és un camp d'aquesta llista.

Cinc raons per separar codi i manifestos:

L'últim pas de la canalització, que només toca dev:

Es promociona el digest, no l'etiqueta. És la garantia que el que es va provar a pre és bit a bit el que va a pro. La petició de canvi que promociona a producció és literalment copiar tres línies de pre/ a pro/: un diff revisable en deu segons.

Aquesta última fila és important: revertir ha de ser ràpid. Si el procediment de marxa enrere és tan pesat com el de desplegament, la gent evitarà revertir i arreglarà a mà, que és el que volíem eliminar.

Les comprovacions obligatòries a tota PR són les de 10-04: kustomize build de les tres superposicions, kubeconform contra l'esquema, kyverno apply de les polítiques (08-03) i argocd app diff comentat automàticament a la PR.

Aquesta és l'anècdota que convenç els escèptics, i passa a totes les empreses que adopten GitOps. Una persona de suport, depurant un problema, executa kubectl delete deployment api-reserves -n rutas-norte-pro. Se li gela la sang.

Trenta-set segons. Els pods tornen, la configuració és exactament la correcta, i hi ha un registre del que va passar.

Aquell dia l'equip entén que el repositori no és una còpia de la documentació del clúster: és el clúster. El clúster és només la projecció actual, i és reemplaçable. La prova definitiva, que convé assajar un cop l'any: destruir rutas-norte-pre, crear un clúster nou, instal·lar Argo CD i aplicar una Application, l'arrel. En vint minuts està reconstruït sencer: namespaces, aplicacions, polítiques, monitoratge, certificats. Les dades es restauren a part amb Velero (05-06), però la plataforma es reconstrueix sola.

1. Oblidar el finalitzador resources-finalizer.argocd.argoproj.io. Sense ell, esborrar una Application deixa tots els seus objectes orfes al clúster, sense ningú que els gestioni.

2. Activar prune: true sense entendre l'abast. Si t'equivoques a path i apunta a un directori buit, Argo CD esborrarà tot el que gestionava. Protegeix-te amb allowEmpty: false i prova sempre a dev primer.

3. selfHeal barallant-se amb l'HPA. El bucle de l'apartat 12. Treu replicas del manifest i afegeix ignoreDifferences. Totes dues coses.

4. targetRevision: HEAD o main en producció. Qualsevol commit a main es desplega immediatament a rutas-norte-pro. Fes servir una etiqueta o un commit fix, i promociona conscientment.

5. Posar secrets al repositori "de moment, ja ho arreglarem". No s'arregla, i el secret queda a l'historial per sempre. Munta SOPS, Sealed Secrets o External Secrets abans del primer desplegament.

6. Donar a la credencial d'Argo CD permisos d'escriptura a Git. Només necessita llegir.

7. No configurar AppProject i deixar-ho tot a default. El projecte default permet desplegar qualsevol cosa en qualsevol namespace des de qualsevol repositori: qui pugui escriure al repositori de manifestos pot escalar a administrador del clúster.

8. Confondre Synced amb Healthy. Synced + Degraded significa que el desplegament va funcionar i l'aplicació està trencada: mira els pods, no el repositori.

9. Fer servir argocd app rollback creient que resol el problema. Reverteix el clúster, no Git. Amb selfHeal, en tres minuts torna l'estat dolent. El rollback real és git revert.

10. Tot en una sola Application gegant. Quan alguna cosa falla, tota l'aplicació queda Degraded i no saps què. Divideix per component o per capa, amb onades per a l'ordre.

11. Editar en producció "només aquesta vegada, és una urgència". Es revertirà sol. Si el canvi és correcte, la via ràpida és una PR amb una aprovació, que triga dos minuts. Prepara aquest procediment abans de necessitar-lo.

12. No monitorar el mateix Argo CD. Si el controlador està caigut, res no se sincronitza i no te n'assabentes. Alerta sobre argocd_app_info{sync_status="OutOfSync"} sostingut i sobre la salut dels pods d'argocd (07-04).

13. Onades de sincronització sense comprovacions de salut. Argo CD passa a l'onada següent quan l'anterior està sana; si l'objecte no té avaluador de salut (un CRD sense resource.customizations), passa immediatament i l'ordre no serveix de res.

Escriu un ApplicationSet que generi les tres aplicacions de Rutas Norte amb aquestes diferències: dev sincronitza automàticament des de main sense selfHeal; pre des de main amb selfHeal i poda; pro des de l'etiqueta release-2.4 amb selfHeal, poda i server-side apply. Tots tres han d'ignorar spec.replicas dels Deployments. Afegeix l'AppProject que restringeixi el desplegament als tres namespaces i prohibeixi crear recursos d'àmbit de clúster.

rutas-norte-pro porta dos dies a OutOfSync encara que ningú ha tocat res. Descriu el procediment complet de diagnòstic amb les ordres exactes, identifica almenys tres causes possibles amb el que s'ha estudiat al curs, i escriu l'ignoreDifferences que les resoldria.

Dissenya les anotacions necessàries perquè un desplegament passi en aquest ordre: (1) namespace i quotes, (2) ExternalSecrets i ConfigMaps, (3) migració d'esquema abans que res més, (4) postgres-reserves i redis-cache, (5) api-reserves, (6) botiga-web, (7) Ingress, (8) HPA i PDB, i una prova de fum final que marqui l'aplicació com a degradada si falla. Explica què passa si la migració falla.

Solució 1

Solució 2

Solució 3

Si la migració falla: el hook PreSync no completa, així que Argo CD avorta la sincronització sense aplicar cap manifest. El clúster queda exactament com estava, servint la versió anterior. L'aplicació apareix Sync Failed i el Job continua existint (per BeforeHookCreation), de manera que kubectl logs job/migracio-esquema -n rutas-norte-pro en dona el motiu. És el mateix comportament protector que els hooks de Helm de 10-03.

GitOps tanca el cercle que vam obrir al principi del mòdul. Rutas Norte ha passat de 120 fitxers aplicats a mà des d'un portàtil a un sistema on el repositori és la font de veritat i el clúster hi convergeix contínuament.

• Els quatre principis —declaratiu, versionat i immutable, aplicat automàticament, reconciliat de forma contínua— són el contracte. El quart és el que ho canvia tot.
• El model d'extracció elimina la credencial més perillosa: ci-rutasnorte ja no necessita accés al clúster, només escriure en un repositori Git, i l'apiserver deixa d'haver de ser accessible des de fora.
• La deriva de configuració es detecta i es corregeix sola. El canvi cultural que provoca —"l'única forma de canviar producció és una petició de canvi"— val més que la tecnologia.
• Argo CD amb la seva Application, els seus AppProject que limiten l'abast, el patró app of apps que redueix la feina manual a un únic kubectl apply en tota la vida del clúster, i els ApplicationSet que generen els tres entorns des d'una definició. Les onades i els hooks ordenen el desplegament i protegeixen la migració d'esquema.
• Flux ofereix el mateix amb controladors especialitzats, releases de Helm reals i automatització d'imatges integrada. L'elecció no és irreversible: llegeixen els mateixos manifestos.
• Els secrets tenen tres solucions pràctiques: SOPS (diffs llegibles), Sealed Secrets (sense infraestructura extra) i External Secrets Operator (el secret no arriba mai a Git, amb rotació automàtica). Per a Rutas Norte, la tercera.
• I el conflicte entre l'HPA i replicas que arrossegàvem des de 09-01 queda resolt: fora del manifest i ignoreDifferences a l'Application, juntament amb tota la família de camps que altres controladors modifiquen.

Ens queda una peça de l'ecosistema. Tot el que hem muntat ha de córrer en algun lloc, i a 10-02 vam veure el que costa operar un clúster propi. A la lliçó següent, Kubernetes Gestionat: EKS, AKS i GKE, veurem què t'estalvia un proveïdor de núvol i què continua sent teu: el model de responsabilitat compartida, la comparació honesta dels tres grans, la federació d'identitat que vam deixar pendent a 03-06, l'ús d'instàncies interrompibles per a worker-notificacions i informes-ocupacio, i el criteri de decisió final per a Rutas Norte.