La lliçó anterior va acabar amb un CRD RutaProgramada perfectament definit, validat i consultable, sobre el qual no passava absolutament res. I a la lliçó 06-01 vam deixar un altre deute: postgres-reserves és un StatefulSet que dona identitat i disc a les seves rèpliques, però que no sap triar un primari, ni replicar dades, ni commutar per error quan aquell primari mor.

Les dues mancances tenen la mateixa solució, i es resumeix en una frase que convé memoritzar:

Operador = recurs personalitzat + controlador que el reconcilia.

Un operador és el coneixement operatiu d'un expert —com es promou una rèplica de PostgreSQL, com es fa una còpia coherent, com s'actualitza una versió major sense perdre dades— codificat en programari que corre dins del clúster i no dorm mai.

Aquesta és l'última lliçó del mòdul. Tancarem els dos deutes oberts, veurem el bucle de reconciliació per dins, substituirem el nostre StatefulSet artesanal per un operador de PostgreSQL de veritat, esbossarem el controlador de RutaProgramada, i acabarem explicant per què la majoria dels equips no haurien d'escriure operadors.

1. Què és un operador, amb precisió
2. Anatomia real del bucle de reconciliació
3. Idempotència i absència d'estat en memòria
4. El model de capacitats en cinc nivells
5. Operadors que ja has fet servir en aquest curs
6. Cas pràctic: un operador de PostgreSQL per a postgres-reserves
7. On trobar operadors i què mirar abans d'adoptar-ne un
8. Com se n'escriu un: Kubebuilder i controller-runtime
9. ownerReferences i l'esborrat en cascada
10. Quan NO escriure un operador

Un operador té exactament dues peces:

1. Un o diversos CRD que defineixen el vocabulari: Cluster, Certificate, RutaProgramada. És la interfície declarativa amb què l'usuari expressa què vol.
2. Un controlador —normalment un Deployment corrent al mateix clúster— que observa aquests objectes i fa la feina.

El terme el va encunyar CoreOS el 2016 amb aquesta idea: quan un equip d'operacions porta anys administrant PostgreSQL, ha acumulat un conjunt de procediments —què fer si el primari deixa de respondre, com afegir una rèplica de lectura, en quin ordre actualitzar— que viuen en runbooks, en scripts solts i al cap de dues persones. Un operador converteix tot això en un programa que s'executa contínuament.

La diferència amb les eines que ja coneixes:

Un operador no instal·la: manté. Si algú esborra un pod, el recrea. Si el primari cau a les tres de la matinada, promou una rèplica sense despertar ningú. Si el disc s'omple, l'amplia. Aquesta vigilància permanent és el seu valor.

A la lliçó 01-02 vam descriure el bucle de reconciliació com la idea central de Kubernetes: observar l'estat desitjat, observar el real, actuar per acostar-los. Ara el veiem per dins, tal com l'implementa qualsevol controlador seriós.

El controlador no consulta l'API en bucle: obre una connexió watch i rep notificacions de cada canvi. La biblioteca estàndard (client-go) ho embolcalla en un informer, que manté a més una memòria cau local de tots els objectes observats.

La memòria cau importa per dos motius:

• Les lectures del controlador no colpegen l'apiserver: en un clúster amb centenars d'objectes, la diferència és substancial.
• La memòria cau pot estar lleugerament desactualitzada. Un controlador ha de tolerar llegir un objecte amb un parell de segons de retard, cosa que reforça la necessitat d'idempotència.

Els esdeveniments no es processen directament: es tradueix cadascun a una clau (namespace/nom) i es fica en una cua amb tres propietats:

• Deduplicació: si un objecte canvia cinc vegades mentre es processa, la clau apareix una sola vegada. Es reconciliarà una vegada amb l'estat final, no cinc vegades amb estats intermedis.
• Retard: es pot demanar "torna a mirar això d'aquí a 30 segons", útil per esperar que alguna cosa externa progressi.
• Límit de taxa amb retrocés exponencial: un objecte que falla es reintenta als 5 ms, 10 ms, 20 ms… fins a un màxim. Un objecte permanentment trencat no consumeix el controlador sencer.

És el cor, i la seva signatura diu molt:

Rep només una clau, no l'objecte ni l'esdeveniment. Aquesta decisió de disseny és deliberada: Reconcile no sap què va canviar ni per què ha estat cridada. El seu contracte és sempre el mateix: donat aquest nom, llegeix l'estat desitjat, mira el real, i fes que s'assemblin.

Retorna dues coses:

L'últim pas de cada reconciliació és escriure l'observat a .status, a través del subrecurs que vam estudiar a 06-06. Aquí apareix un camp convencional que mereix explicació:

metadata.generation l'incrementa l'apiserver cada vegada que canvia el spec (no quan canvien etiquetes o anotacions). El controlador desa a status.observedGeneration la generació que ja va processar. Comparant-los, qualsevol pot saber si el controlador està al dia:

Si difereixen, hi ha un canvi del spec que el controlador encara no ha atès.

Dues propietats no negociables de qualsevol Reconcile.

Reconcile es pot executar moltes més vegades de les que esperes: per un canvi real, per un reintent després d'un error, per una resincronització periòdica de l'informer (cada 10 hores per defecte), o simplement perquè el controlador es va reiniciar i reconcilia tot el que existeix.

Per això Reconcile mai no ha de pensar en termes de "crear" sinó d'"assegurar que existeix":

Corol·lari pràctic: una reconciliació que no canvia res és el cas normal i ha de ser barata. Si el teu Reconcile escriu a l'API a cada passada encara que res no hagi canviat, provocaràs un bucle infinit: l'escriptura genera un esdeveniment, l'esdeveniment provoca una altra reconciliació, i així indefinidament. És l'error clàssic del primer operador que escriu qualsevol, i es detecta perquè l'apiserver registra milers d'update per minut sobre el mateix objecte.

El controlador no pot recordar res entre reconciliacions. Ni en variables globals, ni en mapes, ni en fitxers locals.

Motius:

• Es pot reiniciar en qualsevol moment (actualització, desallotjament, fallada del node) i ho perdria tot.
• Hi pot haver diverses rèpliques per a alta disponibilitat; només una està activa gràcies a l'elecció de líder, però el relleu pot passar en qualsevol moment.
• L'estat en memòria es dessincronitza del món real sense que ningú se n'adoni.

Tot l'estat que el controlador necessiti recordar ha de viure a l'API de Kubernetes: a .status, en anotacions, en etiquetes o en els mateixos objectes que gestiona. Si el teu operador necessita saber "ja he llançat la còpia de seguretat d'avui", això va a status.ultimaCopia, no en una variable.

La conseqüència positiva és que un operador ben escrit es pot matar i arrencar en qualsevol moment sense efectes secundaris. És una propietat que convé provar deliberadament: esborra el pod del controlador enmig d'una operació i comprova que ho reprèn correctament.

El projecte Operator Framework va definir una escala per mesurar quant sap fer un operador. És la millor eina per avaluar-ne un abans d'adoptar-lo. Aplicada a una base de dades com postgres-reserves:

Detall del que aporta cada salt:

Nivell 1 → 2: l'actualització deixa de ser un procediment manual. L'operador sap que cal actualitzar primer les rèpliques i promoure després, i que cal esperar que cadascuna se sincronitzi.

Nivell 2 → 3: aquí hi ha el gruix del valor. Còpies programades amb verificació, restauració a un instant concret, afegir una rèplica de lectura amb un sol canvi al spec, canviar shared_buffers sense perdre connexions.

Nivell 3 → 4: l'operador deixa de ser una caixa negra. Publica mètriques del retard de replicació, de la mida de la base i de l'estat de les còpies, i el seu status diu la veritat sobre el que està passant.

Nivell 4 → 5: la commutació per error automàtica. És el nivell que separa "m'estalvia feina" de "puc dormir tranquil". També el més difícil i el que més cura requereix: un operador que commuta malament pot provocar un split brain amb dos primaris acceptant escriptures.

En avaluar un operador, pregunta pel nivell. Molts projectes vistosos es queden al 2, i per al nivell 2 no compensa la complexitat afegida: això ja ho fa un chart de Helm.

Sense anomenar-los així, portem diversos mòduls fent servir operadors.

Quan vam aplicar un Certificate per a www.rutasnorte.example, va passar el següent sense que fes falta res més:

1. El controlador de cert-manager va observar el nou objecte Certificate.
2. Va crear un CertificateRequest, va generar una clau privada i la va desar en un Secret.
3. Va crear un Order i un Challenge per al protocol ACME.
4. Va publicar un Ingress temporal amb el token del desafiament HTTP-01.
5. Va esperar que Let's Encrypt validés, va obtenir el certificat i el va escriure al Secret.
6. I des de llavors vigila la data de caducitat i repeteix el procés 30 dies abans que expiri.

El pas 6 és la definició d'operador. Un script hauria fet els passos 1 a 5; només un controlador que corre sempre fa el 6. En capacitats, cert-manager és al nivell 5 per al seu domini: renova sense intervenció humana.

Tres Deployments: el controlador, un injector de certificats de CA i el webhook de validació dels seus CRD. És l'anatomia típica d'un operador madur.

Quan vam crear un VolumeSnapshot de les dades de reserves, un controlador el va observar, va parlar amb el driver CSI, va crear el VolumeSnapshotContent corresponent i va actualitzar status.readyToUse. Mateix patró: CRD més controlador.

Els seus Backup, Restore i Schedule són CRD, i el seu controlador és qui executa les còpies, aplica els hooks abans i després, i respecta la retenció. Un Schedule de Velero és un operador creant Jobs, conceptualment igual al que fa el controlador de CronJob amb el nostre informes-ocupacio.

El que ve. Els seus CRD Prometheus, ServiceMonitor, PodMonitor i PrometheusRule permeten declarar "recull mètriques de tots els Services amb aquesta etiqueta" i l'operador genera i recarrega la configuració de Prometheus. Sense ell, afegir un objectiu nou significa editar a mà un fitxer de configuració de centenars de línies.

Convé tancar el cercle: el controlador de Deployments, el de ReplicaSets i el de Jobs funcionen exactament igual. Observen objectes, comparen desitjat amb observat i actuen. L'única diferència és que els seus tipus vénen de fàbrica i el seu codi va dins del kube-controller-manager en comptes d'en un Deployment a part. El patró és idèntic; els operadors només l'estenen a dominis que Kubernetes no coneix.

Arribem al deute de 06-01. El nostre StatefulSet artesanal té una rèplica i no sap fer res més. El substituirem per CloudNativePG, un operador de PostgreSQL madur i de codi obert.

Un Deployment (el controlador) i quatre CRD (el vocabulari). Exactament les dues peces de la definició.

Ara postgres-reserves es descriu així:

Els tres Services són la peça que un StatefulSet no pot donar:

I el més essencial: quan el primari canvia, l'operador reescriu el Service -rw perquè apunti al nou. L'aplicació no se n'assabenta. Això és exactament el que un StatefulSet no sap fer, perquè el seu Service headless dona noms estables però no sap quin d'aquests noms és el primari.

En qüestió de segons: es detecta la caiguda, es promou postgres-reserves-2, es reescriu el Service -rw, i la instància caiguda torna reincorporada com a rèplica. Sense intervenció humana, sense runbook, sense trucada a les tres de la matinada.

Aquest és l'argument sencer a favor dels operadors per a programari amb estat: la columna de l'esquerra són setmanes de feina, procediments fràgils i guàrdies nocturnes; la de la dreta són camps d'un YAML.

Amb el que hem après a 05-06 i 06-01, la migració des del nostre StatefulSet es fa per restauració lògica, no movent volums:

L'operador arrenca, es connecta al StatefulSet antic, importa la base i munta el clúster nou. Després es verifica el nombre de reserves, s'apunta api-reserves al Service -rw i es retira el StatefulSet.

Adoptar un operador és adoptar una dependència que tindrà permisos amplis sobre el teu clúster i de la qual dependran les teves dades. Abans d'instal·lar-lo:

1. Manteniment. Quan va ser l'últim commit? Quantes persones hi contribueixen? Hi ha releases regulars? Quantes incidències obertes sense resposta? Un operador abandonat que gestiona la teva base de dades és un problema seriós, perquè desinstal·lar-lo sense perdre dades poques vegades és trivial.

2. Permisos RBAC que demana. Aquest és el punt que més es passa per alt. Mira'l abans d'aplicar el manifest:

Preguntes: demana cluster-admin? (senyal d'alarma immediata) Demana accés a tots els Secrets del clúster? Pot crear ClusterRoleBindings, és a dir, ampliar-se els seus propis permisos? Un operador compromès amb permisos amplis equival a un clúster compromès. Hi tornarem a 08-01.

3. Maduresa. Quin nivell de capacitats declara i quin compleix de veritat? Hi ha casos d'ús en producció documentats? Existeix una guia d'actualització entre versions del mateix operador?

4. Què passa si el desinstal·les. La pregunta decisiva:

• Els objectes que gestionava continuen funcionant o s'aturen?
• Els seus CRD tenen finalitzadors que deixarien objectes penjats en Terminating?
• Pots exportar les dades a un format estàndard?
• Hi ha un procediment documentat de sortida?

Un operador del qual no es pot sortir és un segrest tecnològic. Amb CloudNativePG, per exemple, les còpies en format Barman són restaurables amb eines estàndard de PostgreSQL: hi ha porta de sortida.

5. Recursos i abast. Quanta CPU i memòria consumeix el controlador? Vigila tot el clúster o es pot limitar a namespaces concrets? Un operador que observa tots els objectes d'un clúster gran pot consumir força memòria.

6. Model d'actualització. Com s'actualitza l'operador sense afectar el que gestiona? És compatible cap enrere amb els CRD ja desplegats?

Ningú no escriu un operador des de zero. Les eines estàndard:

Amb Operator SDK es pot construir un operador sense escriure Go, fent servir un chart de Helm o un playbook d'Ansible com a lògica de reconciliació. És una via raonable per a operadors senzills, encara que limita les capacitats als nivells 1 i 2.

Estructura generada:

El CRD de la lliçó 06-06 no s'escriu a mà en un projecte real: es genera a partir d'structs de Go anotats.

Els comentaris // +kubebuilder:... són marcadors que el generador tradueix a l'esquema OpenAPI del CRD. make manifests produeix exactament el YAML que vam escriure a mà a 06-06, i els comentaris normals es converteixen en les description que alimenten kubectl explain.

Aquest és el cor de l'operador de RutaProgramada: cada ruta activa ha de tenir el seu propi CronJob que generi l'informe d'ocupació d'aquella ruta.

Els set passos són l'esquelet de qualsevol operador, sigui de rutes d'autobús o de PostgreSQL: llegir el desitjat, contemplar el cas d'esborrat, construir el que hauria d'existir, marcar la propietat, crear o actualitzar només si cal, observar la realitat i escriure el status, i decidir quan tornar a mirar.

L'Owns(&batchv1.CronJob{}) de SetupWithManager mereix un comentari: fa que el controlador rebi esdeveniments dels CronJobs que ell va crear, i els tradueixi a reconciliacions de la RutaProgramada propietària. És el que fa que esborrar el CronJob a mà provoqui la seva recreació en segons. Sense aquesta línia, l'operador només reaccionaria a canvis en els seus propis recursos personalitzats.

Els marcadors +kubebuilder:rbac: de dalt generen aquest ClusterRole:

Observa el principi de mínim privilegi: l'operador només pot tocar CronJobs i els seus propis recursos. No pot llegir Secrets, ni crear Deployments, ni tocar res més. Quan avaluïs un operador aliè (apartat 7), això és exactament el que has de mirar i comparar amb el que l'operador diu que fa. RBAC en detall és la lliçó 08-01.

make run és l'avantatge pràctic d'aquest model: el controlador corre al teu portàtil, amb depurador si cal, parlant amb el clúster real. No cal construir imatges per a cada iteració.

A la lliçó 02-02 vam veure que un ReplicaSet posa ownerReferences als seus pods, i que per això esborrar un Deployment esborra tot el que hi ha a sota. Els operadors fan servir el mateix mecanisme, i és imprescindible entendre'l.

Aquesta línia escriu al CronJob generat:

Conseqüències:

1. Esborrat en cascada automàtic. En esborrar la RutaProgramada, el recol·lector d'escombraries de Kubernetes esborra el CronJob. L'operador no ha d'escriure codi de neteja: el mateix clúster se n'ocupa.
2. La propietat és visible. kubectl describe cronjob mostra Controlled By: RutaProgramada/rn-041-bilbao-santander, cosa que fa traçable d'on va sortir cada objecte.
3. Esdeveniments cap al propietari. Gràcies a Owns(), canvis al CronJob provoquen reconciliacions de la ruta.

Dues restriccions importants:

• El propietari i l'objecte posseït han d'estar al mateix namespace. Un objecte de namespace no pot ser propietat d'un altre d'un namespace diferent.
• Un objecte de clúster no pot ser propietat d'un de namespace. Si el teu operador crea ClusterRoles o PersistentVolumes, els hauràs de netejar tu.

Quan l'operador crea recursos externs —un bucket, un registre DNS, una base de dades en un proveïdor— les ownerReferences no serveixen: el recol·lector d'escombraries de Kubernetes no sap res d'aquests recursos.

Per a això hi ha els finalitzadors, el mateix mecanisme que vam veure protegint els PVC a 05-03:

Advertiment operatiu de primer ordre: si l'operador deixa de funcionar i hi ha objectes amb el seu finalitzador, aquests objectes es queden en Terminating per sempre. kubectl delete es queda penjat i no hi ha manera neta de sortir-ne llevat d'editar l'objecte i treure el finalitzador a mà:

Això deixa els recursos externs orfes, que caldrà netejar per una altra via. És una de les raons de la pregunta "què passa si el desinstal·lo?" de l'apartat 7: desinstal·la sempre l'operador després d'esborrar els seus objectes, mai abans.

Escriure un operador és divertit i gairebé sempre innecessari. Abans de començar, passa aquest filtre.

Un Deployment, un Service, un HorizontalPodAutoscaler i un ConfigMap cobreixen api-reserves, botiga-web i worker-notificacions completament. Un operador no hi afegiria res: el controlador de Deployments ja fa la reconciliació.

Els operadors brillen amb programari amb estat i amb procediments operatius complexos: bases de dades, cues de missatges, sistemes de consens, magatzems distribuïts. Si la teva aplicació es reinicia sense conseqüències, no en necessites cap.

La pregunta discriminant: "què ha de passar quan alguna cosa es trenca a les tres de la matinada?" Si la resposta és "res, el Deployment ho recrea", no necessites operador. Si és "cal promoure una rèplica, reconfigurar l'encaminament i avisar", allà sí que hi ha un operador.

Per a PostgreSQL, MySQL, Redis, Kafka, MongoDB, Elasticsearch, RabbitMQ i pràcticament qualsevol programari conegut ja existeixen operadors madurs, mantinguts per equips que hi porten anys. Escriure el teu significa reimplementar pitjor el que altres ja van resoldre, i mantenir-lo tu sol.

El que la gent subestima:

• És un servei de producció amb permisos privilegiats. Necessita desplegament, actualitzacions, monitoratge, alertes i guàrdies.
• Una fallada a l'operador afecta tot el que gestiona. Un Reconcile amb un error pot esborrar objectes en cascada a tot el clúster. Hi ha incidents públics famosos per això.
• Els CRD són una API pública amb les obligacions de compatibilitat que vam veure a 06-06. Canviar l'esquema després és car.
• Provar un operador és difícil. Calen proves amb envtest o un clúster efímer, i la lògica de reconciliació té molts camins possibles.
• Requereix Go i coneixement profund de Kubernetes a l'equip, a perpetuïtat, no només mentre s'escriu.

Una regla d'or assenyada:

Escriu un operador quan tinguis un procediment operatiu documentat, repetitiu, que s'executa sovint i que s'executa malament quan el fa una persona cansada. Si no pots escriure aquell runbook amb precisió, tampoc no el podràs codificar.

El bucle infinit de reconciliació. L'error número u: Reconcile escriu a l'API a cada passada encara que res no hagi canviat, l'escriptura genera un esdeveniment, l'esdeveniment dispara una altra reconciliació. Símptoma: milers d'update per minut sobre el mateix objecte. Solució: comparar abans d'escriure, amb DeepDerivative o similar.

Desar estat en memòria. Variables globals, mapes de "ja ho he fet". Es perden en reiniciar i es dessincronitzen del món real. Tot l'estat va a .status, en anotacions o als objectes gestionats.

Escriure .status sense el subrecurs. Un Update de l'objecte complet pot sobreescriure un canvi de spec que l'usuari acaba de fer. Fes servir sempre r.Status().Update() amb el subrecurs activat.

Oblidar ownerReferences. Els objectes creats per l'operador queden orfes en esborrar el recurs principal. Amb el temps el clúster s'omple de CronJobs, Services i Secrets que ningú no sap d'on van sortir.

Desinstal·lar l'operador abans d'esborrar els seus objectes. Si fa servir finalitzadors, els objectes es queden en Terminating per sempre. Ordre correcte: esborrar els objectes, comprovar que desapareixen, i només llavors desinstal·lar l'operador.

Adoptar un operador que demana cluster-admin. És una porta oberta a tot el clúster. Revisa sempre el ClusterRole abans d'aplicar el manifest, i desconfia de qualsevol que demani accés a tots els Secrets sense justificar-ho.

Confondre "té CRD" amb "és un operador". Un CRD sense controlador és una base de dades amb formulari, com vam veure a 06-06. Comprova que hi ha un Deployment corrent i que escriu al status dels objectes.

No llegir el nivell de capacitats. Un operador de nivell 2 no et salvarà d'una commutació per error nocturna. Si l'adoptes creient que arriba al 5, la sorpresa arribarà en el pitjor moment.

Consell: fes servir make run en desenvolupament. El controlador corre al teu portàtil contra el clúster real, amb depurador. El cicle d'iteració passa de minuts a segons.

Consell: emet esdeveniments. r.Recorder.Eventf(...) fa que les accions de l'operador apareguin al kubectl describe de l'objecte. És la diferència entre un operador que es pot diagnosticar i un que és una caixa negra.

Consell: registra observedGeneration. Permet a qualsevol saber si el controlador ha processat l'últim canvi del spec, i és la base perquè kubectl wait funcioni de manera fiable sobre els teus recursos.

Consell: prova matant el controlador. Esborra'l enmig d'una operació i comprova que en tornar ho reprèn correctament. Si no ho fa, tens estat en memòria o falta idempotència.

Al teu minikube (perfil rutas-norte), identifica quins operadors hi ha instal·lats. Per a cadascun, determina: quin CRD aporta, on corre el seu controlador, i quins permisos de ClusterRole té. Després raona per què cert-manager és un operador i el controlador de Deployments, sent el mateix patró, no se'n diu així.

Demostra experimentalment que un controlador reconcilia contínuament i un desplegament no:

1. Crea un Deployment demo-reconciliacio amb 3 rèpliques a rutas-norte-dev.
2. Esborra un pod i observa què passa i en quant de temps.
3. Canvia manualment la imatge d'un pod amb kubectl edit pod i observa el resultat.
4. Explica quin controlador va actuar en cada cas i amb quina informació.

Rutas Norte vol un recurs EntornProves que, en crear-se, provoqui automàticament: un namespace propi, una restauració de postgres-reserves des de l'últim snapshot, un desplegament d'api-reserves apuntant a aquella base de dades, i l'esborrat complet als 7 dies.

Sense escriure codi, dissenya:

1. El spec i el status del CRD (camps i tipus).
2. Els passos de la funció Reconcile, en ordre.
3. Els permisos RBAC mínims que necessitaria.
4. Què faries servir per a l'esborrat als 7 dies i per què.
5. Si caldria un finalitzador, i per a què.

Solució 1

Permisos acotats: els seus propis CRD, més Secrets (necessaris: hi desa claus i certificats) i esdeveniments. No demana cluster-admin.

Per què cert-manager se'n diu operador i el controlador de Deployments no, sent el mateix patró:

La diferència no és tècnica, és d'origen. Tots dos són bucles de reconciliació sobre tipus de l'API. El controlador de Deployments gestiona un tipus natiu i el seu codi viu dins del kube-controller-manager, un binari del pla de control. cert-manager gestiona tipus afegits mitjançant CRD i corre com una càrrega de treball més del clúster.

El terme "operador" designa aquesta segona situació: el patró controlador aplicat a un domini que Kubernetes no coneix de fàbrica, empaquetat com a aplicació desplegable. Conceptualment, el controlador de Deployments és un operador de Deployments; simplement ningú no en diu així perquè ve inclòs.

Solució 2

2. Esborrar un pod:

En menys d'un segon hi ha un substitut. Ningú no va executar cap ordre: el ReplicaSet va observar que hi havia 2 pods on n'hi havia d'haver 3 i en va crear un.

3. Canviar la imatge d'un pod a mà:

El canvi persisteix. Això sorprèn, però és correcte i molt instructiu.

4. Quin controlador va actuar i amb quina informació:

La clau és a què reconcilia cada controlador:

• El controlador de ReplicaSets reconcilia el nombre de pods que casen amb el seu selector. En compta 2, en vol 3, en crea un. Tant li fa quina imatge tinguin.
• El controlador de Deployments reconcilia quins ReplicaSets han d'existir segons la plantilla del Deployment. Com que la plantilla no va canviar, no fa res.
• Ningú no reconcilia el contingut d'un pod individual contra la plantilla del Deployment. La plantilla es fa servir en crear el pod, no per vigilar-lo després.

Lliçó pràctica: la reconciliació és d'objectes gestionats, no de camps arbitraris. Si esborres el pod modificat, el seu substitut naixerà de la plantilla i tornarà a nginx:1.27.2-alpine. I un kubectl rollout restart deployment/demo-reconciliacio recrearia tots els pods des de la plantilla, corregint la desviació.

Solució 3

1. Disseny del CRD:

Subrecurs status activat. additionalPrinterColumns: Solicitant, Fase, Caducitat, Antiguitat.

2. Passos de Reconcile:

1. Llegir l'EntornProves. Si no existeix, acabar (IgnoreNotFound).
2. Si té DeletionTimestamp, executar la lògica del finalitzador (pas 10) i acabar.
3. Assegurar el finalitzador si no el té.
4. Comprovar la caducitat: si now() > status.dataCaducitat, esborrar el mateix objecte i acabar. La cascada farà la resta.
5. Assegurar el namespace proves-<nom> amb etiquetes de propietat. (És un objecte de clúster: no admet ownerReferences d'un objecte de namespace; es neteja al finalitzador.)
6. Assegurar el PVC restaurat des del snapshot, amb dataSource (05-05). Si encara no està Bound, actualitzar status.fase = "Restaurant" i retornar RequeueAfter: 30s.
7. Assegurar el StatefulSet/Cluster de PostgreSQL i el seu Secret de credencials generat.
8. Assegurar els Deployments i Services dels components marcats a spec.components, i l'Ingress si escau.
9. Observar la realitat: estan tots els pods Ready? Escriure status.fase, urlAcces, condicions i observedGeneration mitjançant el subrecurs.
10. Retornar RequeueAfter calculat: fins a la caducitat si falta molt, o 1 minut si és a prop, perquè el pas 4 es dispari a temps.

3. RBAC mínim:

Fixa't en el que no hi és: res de cluster-admin, ni permisos sobre nodes, ni sobre RBAC. Els Secrets són inevitables (genera credencials), i això ja és motiu suficient per revisar el codi abans de donar-li aquests permisos.

4. L'esborrat als 7 dies:

L'opció correcta és el mateix bucle de reconciliació amb RequeueAfter, no un CronJob de neteja:

• L'operador ja està observant l'objecte: comprovar una data a cada reconciliació és gratis.
• RequeueAfter garanteix que es desperta a temps encara que no hi hagi cap altre esdeveniment.
• Un CronJob extern seria un segon component amb la seva pròpia lògica, els seus propis permisos i la seva pròpia possibilitat de fallar, i podria estar dessincronitzat amb el que l'operador creu.
• A més, ttlSecondsAfterFinished (06-03) no hi aplica: això és per a Jobs, no per a recursos personalitzats.

Detall d'implementació: l'operador esborra el seu propi objecte (r.Delete(ctx, &entorn)), i l'esborrat en cascada més el finalitzador s'ocupen de tota la resta. És més net que anar esborrant recursos un per un.

5. Finalitzador: sí, i és imprescindible.

Motius concrets:

• El namespace és un objecte de clúster des del punt de vista de les ownerReferences d'un objecte que viu en un altre namespace: no es pot establir la propietat, així que cal esborrar-lo explícitament.
• Cal verificar que el PVC s'allibera abans de donar l'esborrat per acabat, evitant volums orfes amb la classe Retain.
• Hi pot haver recursos externs: un registre DNS proves-xyz.rutasnorte.example, una entrada al sistema de facturació interna. Res d'això no ho coneix el recol·lector d'escombraries de Kubernetes.
• Convé notificar el sol·licitant que el seu entorn ha caducat abans de completar l'esborrat.

Amb l'advertiment de l'apartat 9 ben present: si l'operador cau amb objectes pendents de finalitzar, aquests objectes queden en Terminating per sempre. Per això el finalitzador ha de ser ràpid, tolerant a fallades i amb un camí d'escapament documentat.

Un operador és un recurs personalitzat més un controlador que el reconcilia: el coneixement operatiu d'un expert codificat en programari que corre dins del clúster i no dorm mai. A diferència d'un script o de Helm, que actuen quan algú els invoca, un operador manté l'estat desitjat contínuament.

El seu motor és el bucle de reconciliació de 01-02, ara vist per dins: un watch amb memòria cau local, una cua de treball amb deduplicació i retrocés exponencial, i una funció Reconcile que rep només un nom i el contracte de la qual és sempre el mateix —llegeix el desitjat, mira el real, acosta'ls— i que acaba escrivint el status pel seu subrecurs. Dues propietats no negociables: idempotència, perquè Reconcile s'executarà moltes més vegades de les que esperes, i absència d'estat en memòria, perquè el controlador es pot reiniciar en qualsevol moment.

El model de cinc nivells —instal·lació, actualitzacions, cicle de vida, observabilitat i pilot automàtic— és l'eina per avaluar un operador abans d'adoptar-lo, juntament amb el manteniment del projecte, els permisos RBAC que demana i la pregunta decisiva de què passa si el desinstal·les.

Hem tancat el deute que vam obrir a 06-01: un operador de PostgreSQL substitueix el nostre StatefulSet artesanal i aporta el que un StatefulSet no podrà donar mai per si sol —elecció de primari, commutació per error automàtica en segons, rèpliques de lectura, Services -rw i -ro que es reescriuen sols, còpies programades i recuperació a un instant concret— amb un YAML en comptes de setmanes de feina i guàrdies nocturnes. I hem esbossat el controlador de RutaProgramada amb Kubebuilder: els marcadors que generen el CRD i l'RBAC, els set passos de Reconcile, ownerReferences per a l'esborrat en cascada i finalitzadors per al que viu fora del clúster.

I hem acabat on calia acabar: la majoria dels equips no haurien d'escriure operadors. Per a aplicacions sense estat no aporten res, per a programari conegut ja existeixen i són millors que el que escriuries, i mantenir-ne un significa operar un servei privilegiat a perpetuïtat. Escriu-lo només quan tinguis un procediment repetitiu, documentat i que s'executa malament a les tres de la matinada.

Amb aquesta lliçó es tanca el mòdul de conceptes avançats. La plataforma de Rutas Norte ha canviat molt:

És una plataforma potent. I és, en aquest moment, completament opaca.

No hi ha manera de saber si api-reserves està sana, més enllà que el seu pod digui Running —que només significa que el procés va arrencar, no que funcioni—. No sabem quanta memòria consumeix realment postgres-reserves ni si els 2 GiB que li vam reservar a 03-05 sobren o falten. Si el CronJob d'informes va fallar ahir a la nit a les tres de la matinada, l'única pista són uns logs que s'esborraran amb l'historial. Si botiga-web comença a respondre en tres segons en comptes d'en cent mil·lisegons, ens n'assabentarem per una queixa d'un client que no va poder comprar el seu bitllet.

Tot el que hem construït està a cegues. Això s'acaba al mòdul 7: Monitoratge i Registre. Començarem pel més bàsic i el més important —ensenyar Kubernetes a distingir un contenidor que va arrencar d'un que funciona— amb les verificacions de salut i sondes de la lliçó 07-01.