A 05-04 vam deixar obert el canary amb pes exacte entre serveis interns: el Service de Kubernetes reparteix per connexió i per nombre de rèpliques, i per enviar exactament el 10 % de les crides del gateway a servei-comandes v2 cal alguna cosa que entengui HTTP entre pods. Aquesta "cosa" és la mateixa peça que resoldria altres problemes que cada servei de TechCorp està repetint al seu codi: timeouts, reintents, xifratge entre serveis, mètriques de trànsit. Un service mesh treu tot això de les aplicacions i ho posa a la infraestructura, amb un proxy al costat de cada pod i un pla de control que els configura. Aquesta lliçó explica com funciona (amb Istio com a referència i Linkerd com a alternativa), mostra els recursos YAML que tanquen el canary de 05-04 i declaren timeouts i reintents per a Comandes→Catàleg, enumera amb honestedat el que costa, i acaba amb la decisió de TechCorp: si adoptar-lo ja, i què fer si no. El que el mesh toca de seguretat (mTLS, 07-02), de resiliència en codi (06-03) i de traces (06-02) aquí només s'anomena com a capacitat.

1. Els problemes transversals que es repeteixen a cada servei
2. Què és un service mesh: pla de dades i pla de control
3. Instal·lar Istio al clúster de TechCorp i què canvia als pods
4. Encaminament per pes: VirtualService i DestinationRule (el canary 90/10 de Comandes)
5. Timeouts i reintents declaratius: Comandes → Catàleg
6. Circuit breaking amb outlierDetection
7. Seguretat com a capacitat: PeerAuthentication i AuthorizationPolicy
8. L'observabilitat que regala el mesh (i la que no)
9. Linkerd com a alternativa més lleugera
10. El que costa un mesh
11. Necessita TechCorp un mesh? La decisió
12. Què fer mentrestant

Repassa el que hem anat demanant a cada servei al llarg del curs:

Tot això té tres característiques: és idèntic per a tots els serveis, no és lògica de negoci, i depèn del llenguatge (la llibreria @techcorp/comu-http només serveix per a Node; si el segon servei en Go de 04-01 arriba, caldrà reescriure-la). La idea del mesh: si són problemes de xarxa, que els resolgui la xarxa.

Un service mesh té dues parts:

• Pla de dades: un proxy lleuger desplegat al costat de cada pod (sidecar: Envoy a Istio, linkerd2-proxy a Linkerd) que intercepta tot el trànsit entrant i sortint del contenidor de l'aplicació. L'aplicació es pensa que crida http://servei-cataleg:3001; en realitat parla amb el seu sidecar a localhost, que aplica regles (timeout, reintent, mTLS, mètriques) i reenvia al sidecar del destí. Istio ofereix a més el mode ambient (sense sidecar: un proxy per node, ztunnel, per a capa 4 i waypoints opcionals per a capa 7).
• Pla de control: un component central (istiod a Istio; el control plane de Linkerd) que llegeix els recursos de Kubernetes i els del mesh (VirtualService, DestinationRule...), i empeny la configuració a tots els proxies, a més d'emetre els certificats per a mTLS.

L'important del dibuix: cap línia no toca el codi dels serveis. Comandes continua fent fetch(CATALEG_URL + '/v1/productes?ids=...') amb el seu TIMEOUT_HTTP_MS; el sidecar hi afegeix la resta.

Conceptualment (els detalls varien per versió), tres passos:

Què canvia a cada pod, sense tocar cap manifest de 05-02: un contenidor istio-proxy (Envoy) al costat del de l'aplicació, un init container (o el CNI d'Istio) que redirigeix amb iptables tot el trànsit del pod a través del proxy, i unes desenes de MB de memòria més per pod. La readinessProbe continua apuntant al contenidor de l'aplicació (Istio la reescriu perquè passi pel proxy, de manera transparent). I amb Kustomize/GitOps (05-02, 05-03), l'etiqueta del namespace és un canvi a namespace.yaml, revisat i aplicat com tota la resta.

Reprenem 05-04: Deployment servei-comandes (etiqueta version: v1) i servei-comandes-canary (version: v2), tots dos seleccionats pel Service servei-comandes. Amb Istio, el nombre de rèpliques deixa d'importar per al repartiment: es declara el pes.

Avançar el canary és canviar 90/10 per 50/50 i per 0/100 (tres commits a plataforma, o el que Argo Rollouts/Flagger facin sols amb mètriques, 05-04); retirar-lo és 100/0. Amb una rèplica de v2 i tres de v1, el 10 % és el 10 %, no "una de quatre". Això és el que 05-04 no podia donar sense mesh.

La crida GET /v1/productes?ids= des de Comandes (04-04) amb timeout i reintents al mesh:

Tres advertències que el YAML no diu sol:

• Reintentar només operacions idempotents. Un GET repetit no fa mal; un POST /v1/comandes reintentat pel proxy crearia dues comandes si el primer va arribar i la resposta es va perdre, tret que el servidor apliqui la Idempotency-Key (03-01), i tot i així el proxy no la coneix. Per això el match per mètode, i per això mai no es posa retries en un VirtualService genèric de Comandes.
• El timeout del mesh i el del codi conviuen. TIMEOUT_HTTP_MS=2000 (04-03) continua a Comandes: el sidecar talla als 2 s i l'aplicació també. Han de ser coherents (el de l'aplicació una mica més gran o igual que el del mesh, perquè sigui el mesh qui reintenti dins de la seva finestra); si el de l'app fos 1 s, tallaria abans que el mesh reintentés.
• El mesh no substitueix la lògica de fallada. Què fa Comandes quan Catàleg no respon després dels reintents (degradar amb el preu de l'últim traductorProducte, rebutjar la comanda, encuar) és decisió de negoci i viu al codi: 06-03.

El DestinationRule també pot expulsar temporalment del balanceig els pods que fallen (outlier detection, un circuit breaker passiu per instància) i limitar connexions:

Aquí només ho presentem: protegeix del "pod malalt" sense tocar codi, però no decideix què respondre a l'usuari ni obre el circuit per a una dependència sencera; el circuit breaker d'aplicació (estats tancat/obert/semiobert, resposta alternativa) és de 06-03, i tots dos es complementen.

Amb una línia, tot el trànsit entre sidecars del namespace passa a ser mTLS (xifrat i amb identitat de cada servei, certificats emesos i rotats per istiod):

I una AuthorizationPolicy pot dir "només el gateway pot cridar servei-comandes" o "ningú tret de Comandes i Inventari parla amb Catàleg", per identitat de servei, no per IP. És una capacitat enorme per molt poc esforç, i una de les raons típiques per adoptar un mesh. Com funciona mTLS, quins certificats hi ha a sota i com s'aconsegueix sense mesh és 07-02; aquí n'hi ha prou de saber que el mesh ho regala.

Com que tot el trànsit passa pels proxies, el mesh produeix sense instrumentar res: mètriques RED (peticions, errors, durada) per servei origen/destí, ruta i codi de resposta, en format Prometheus; el graf de crides a Kiali (qui parla amb qui, amb quina taxa d'error, en temps real); i spans de traça per salt. El que no regala: la correlació d'aquests spans en una traça de la petició completa. Envoy no pot saber que la crida sortint Comandes→Catàleg pertany a la petició entrant gateway→Comandes; per a això l'aplicació ha de propagar les capçaleres de traça (traceparent, o les x-b3-*) de la petició entrant a les sortints. Aquesta és exactament la feina d'OpenTelemetry a 06-02, amb mesh o sense.

Linkerd s'instal·la amb linkerd install | kubectl apply -f - i l'anotació linkerd.io/inject: enabled al namespace, i en molts equips petits és "tot el mesh que necessiten": mTLS i mètriques per defecte, reintents i pesos declaratius, sense l'extensió d'Istio.

• Latència: cada salt passa per dos proxies; el cost és de mil·lisegons (menys amb Linkerd), però se suma en cadenes llargues.
• Recursos: un sidecar per pod. Amb 6 serveis × 3 rèpliques més gateway i jobs, uns 25 proxies; amb Envoy, entre 1 i 2 GB de memòria del clúster només en sidecars.
• Complexitat operativa: un altre pla de control que pot caure (si istiod cau, els proxies continuen amb l'última configuració, però no arrenquen pods nous correctament), CRD per aprendre, depuració més difícil ("falla l'app o el sidecar?"), interacció amb jobs (un Job amb sidecar no acaba fins que es mati el proxy: cal anotar-lo o fer servir ambient).
• Actualitzacions: el mesh té el seu propi cicle de versions, acoblat a versions de Kubernetes; actualitzar-lo implica reiniciar tots els pods per renovar sidecars.
• Falsa sensació: "ja tenim reintents" sense haver pensat en la idempotència; "ja tenim mTLS" sense polítiques d'autorització.

Les dades: sis serveis més el gateway, tots en Node amb la mateixa llibreria, un equip de Plataforma de quatre persones que acaba de muntar Kubernetes, CI/CD i GitOps i que encara té per davant observabilitat (mòdul 6) i seguretat (mòdul 7). Els beneficis que TechCorp aprofitaria avui: el pes exacte del canary de Comandes i Pagaments, mTLS intern i mètriques de trànsit gratis. Els costos: complexitat per a un equip que ja va al límit, i una capa més per depurar quan falli la saga a les 3 de la matinada.

Decisió de la Marta i de l'equip de Plataforma: no adoptar un mesh a la primera fase. Es reavaluarà quan es compleixi qualsevol d'aquestes condicions: (a) més de 10 serveis o un segon llenguatge (la llibreria deixa de cobrir-los tots); (b) un requisit de mTLS obligatori entre serveis (per exemple, una auditoria de l'àrea de Pagaments), moment en què el mesh és la manera més barata d'aconseguir-ho; (c) el canary manual per rèpliques de Comandes i Pagaments es converteixi en un coll d'ampolla real. Quan arribi, la primera opció per avaluar serà Linkerd, per cost i corba, amb Istio ambient com a segona si calen les seves capacitats d'encaminament.

L'avantatge d'haver concentrat el que és transversal a @techcorp/comu-http des de 04-01 és que, si un dia arriba el mesh, es treu de la llibreria el que el mesh assumeixi (reintents, mètriques de trànsit) sense tocar els serveis; i si no arriba, la llibreria continua sent el "mesh en procés" de TechCorp.

• Reintents al mesh per a tot (retryOn: 5xx sense match per mètode): comandes duplicades. Només idempotents.
• Adoptar el mesh "perquè el fa servir tothom" amb cinc serveis i dues persones de plataforma. Els problemes que resol han d'existir abans.
• PeerAuthentication STRICT de cop amb serveis encara sense sidecar (o amb Prometheus fent scraping des de fora del mesh): tot deixa de parlar. PERMISSIVE primer, STRICT quan el 100 % té proxy.
• Un Job amb sidecar que no acaba mai: el contenidor de l'app acaba, Envoy continua. Anotació per no injectar en jobs o ambient.
• Creure que el mesh dona traces completes sense tocar l'app: sense propagar traceparent, cada salt és una traça solta.
• Consell: si adoptes un mesh, comença per un namespace i una capacitat (mTLS PERMISSIVE + mètriques), i afegeix encaminament només quan el necessitis; i mesura la latència p99 abans i després.

Exercici 1. Escriu el VirtualService que permetria a l'equip de Comandes, amb Istio, reproduir l'estratègia de l'exercici de 03-04 però per a Comandes: durant una setmana, només les peticions internes amb X-Canary: comandes van a servei-comandes v2; la resta, a v1; i explica en dues frases quin recurs més necessita i per què no cal tocar el Deployment ni el Service.

Exercici 2. Un company proposa declarar al VirtualService de servei-comandes retries: { attempts: 3, retryOn: 5xx } "perquè el gateway no vegi errors als pics". Explica què passaria amb POST /v1/comandes i amb GET /v1/comandes/{id}, i com es pot aconseguir el que vol sense risc.

Exercici 3. La Marta et demana un criteri en una frase per a cadascuna de les tres condicions de reavaluació de l'apartat 11 (més de 10 serveis o segon llenguatge, mTLS obligatori, canary com a coll d'ampolla), i que indiquis per a cadascuna si el primer candidat seria Linkerd o Istio i per què.

Solució 1.

Necessita el DestinationRule de l'apartat 4 que defineix els subsets v1/v2 per l'etiqueta version. No es toca el Deployment ni el Service perquè tots dos ja existeixen tal com els va deixar 05-04 (dos Deployment amb version: v1/v2, un Service que selecciona per app); el mesh encamina per sobre del Service, llegint etiquetes dels pods. Retirar el canary és esborrar la primera regla; cap manifest de 05-02 no canvia.

Solució 2. POST /v1/comandes no és idempotent des del punt de vista del proxy: si Comandes crea la comanda i la resposta es perd (o el pod retorna 500 després d'haver confirmat la transacció, o mor just després d'escriure), el sidecar reintenta i el segon intent arriba amb la mateixa Idempotency-Key; si el servei va implementar bé la clau (03-01, 04-04), respon el mateix resultat i no hi ha duplicat, però s'està depenent que tots els POST del servei siguin idempotents; i en un pic de càrrega, tres intents per petició tripliquen la càrrega que causa el pic (tempesta de reintents). GET /v1/comandes/{id} sí que es pot reintentar. Solució: match per method: GET per a la ruta amb retries, retryOn: connect-failure,reset (no 5xx) com a màxim per a la resta, perTryTimeout curt, i al gateway un timeout clar; el pic es tracta amb rèpliques (05-02, HPA a 06-04) i amb rate limiting al gateway (03-04), no amb reintents.

Solució 3. (a) Més de 10 serveis o segon llenguatge: "quan la llibreria no pugui garantir el mateix comportament a tots els serveis, el comportament passa a la xarxa"; primer candidat Linkerd (cobreix timeouts, reintents, mTLS i mètriques amb poc cost). (b) mTLS obligatori: "quan una auditoria exigeixi xifratge i identitat entre serveis, el mesh és més barat que gestionar certificats a sis serveis"; Linkerd, perquè el mTLS és automàtic i per defecte. (c) Canary com a coll d'ampolla: "quan el percentatge per rèpliques o l'Ingress no n'hi hagi prou per a Comandes i Pagaments i vulguem automatitzar-ho amb Argo Rollouts/Flagger"; aquí Istio (o Linkerd amb Gateway API) per la riquesa d'encaminament, tret que Linkerd cobreixi el que cal, cas en què es manté l'opció lleugera.

Un service mesh mou a la infraestructura el que cada servei repeteix al seu codi: un proxy al costat de cada pod (Envoy amb Istio, linkerd2-proxy amb Linkerd, o el mode ambient sense sidecar) i un pla de control (istiod) que el configura, activat amb istioctl install i l'etiqueta istio-injection=enabled a techcorp. Amb DestinationRule (subsets v1/v2 per etiqueta version) i VirtualService hem tancat el canary de 05-04 amb pes exacte 90/10 i per capçalera X-Canary; hem declarat timeout: 2s i retries només per als GET de Comandes→Catàleg, amb l'advertència de no reintentar POST /v1/comandes; hem presentat outlierDetection com a circuit breaking passiu, PeerAuthentication STRICT i AuthorizationPolicy com a capacitats de seguretat (07-02), i les mètriques i Kiali com a observabilitat regalada que tot i així necessita que l'aplicació propagui les capçaleres de traça (06-02); hem comparat Istio, Linkerd i no tenir mesh, i n'hem explicat els costos. La decisió de TechCorp és no adoptar-lo a la primera fase i reavaluar Linkerd en superar deu serveis, amb mTLS obligatori o quan el canary manual faci nosa; fins llavors, la llibreria @techcorp/comu-http, el gateway i el codi de resiliència fan aquest paper.

Amb això acaba el mòdul de desplegament i orquestració: cada servei és una imatge Docker construïda amb la mateixa plantilla i aixecada en local amb Docker Compose (05-01), s'executa a Kubernetes amb els seus Deployment, Service, ConfigMap, Secret, Job i Ingress gestionats amb Kustomize (05-02), arriba a staging i a producció per un pipeline de GitHub Actions amb pactes, imatges etiquetades i GitOps (05-03), canvia de versió sense talls amb rolling, blue-green o canary (05-04) i sap què li donaria un mesh i per què encara no el té (05-05). El que encara no tenim és visibilitat: quan el sistema sigui en producció, com sabrem que la saga d'una comanda s'ha encallat, quin servei respon lent, o si el canary de Comandes va bé? El mòdul 6 comença per aquí: logging estructurat amb Loki i mètriques amb Prometheus i Grafana (06-01), traces distribuïdes amb OpenTelemetry i Jaeger (06-02), la gestió d'errors i la resiliència en codi que aquest mòdul ha anat remetent (06-03), escalabilitat i rendiment amb l'HPA (06-04) i, finalment, SLO, alertes i gestió d'incidents (06-05). Comença pels logs i les mètriques.