En l’ecosistema actual d’intel·ligència artificial i machine learning, l’eficiència computacional no és un luxe: és una necessitat. No obstant això, moltes empreses descobreixen que les seves costoses inversions en infraestructura cloud no es tradueixen en rendiment real. Un escenari recurrent a Kubernetes amb Kubeflow i Cilium il·lustra a la perfecció com dos sistemes configurats correctament poden generar un error silenciós i costós. A Q2BSTUDIO, com a empresa especialitzada en aplicacions a mida, hem vist aquest patró en múltiples clients que despleguen clústers per a entrenament distribuït. El problema és senzill de descriure: més de la meitat de les GPUs romanen ocioses, l’entrenament mai no comença, però tots els indicadors de salut apareixen en verd. No hi ha errors als logs, no hi ha caigudes, no hi ha OOMKills. Només silenci. I una factura que continua creixent.
Per entendre-ho, imaginem una sala de concerts amb totes les butaques ocupades. Els músics són als seus llocs, instruments afinats, llums enceses. Però el director ha estat portat a una ala equivocada de l’edifici, i les portes tallafocs, complint perfectament la seva funció de seguretat, han segellat aquesta zona. El resultat és una sala plena i un silenci absolut. Això és exactament el que passa en un clúster de GPUs quan el coordinador de l’entrenament (el director) es col·loca en una zona de disponibilitat i els treballadors (els músics) en una altra, i les polítiques de xarxa de Cilium bloquegen la comunicació entre elles. L’error no és de cap component individual, sinó de l’absència d’un mapa únic que mostri tant la ubicació dels pods com les portes tancades.
L’arrel del problema rau en el fet que el scheduler de Kubernetes, per disseny, és agnòstic a la topologia. Col·loca els pods basant-se en recursos disponibles (CPU, memòria, GPUs) sense considerar en quina zona de disponibilitat cauen. Kubeflow hereta aquesta suposició. D’altra banda, Cilium sí que és conscient de la topologia: els operadors utilitzen CiliumNetworkPolicy per traçar límits de zona, amb l’objectiu d’aïllar el radi d’explosió o protegir un pool dedicat de GPUs. Aquesta és una bona pràctica de seguretat, però Cilium no pot reubicar un pod que ja ha estat col·locat. Quan el coordinador acaba en una zona i els treballadors en una altra, la xarxa bloqueja silenciosament la connexió. Ningú té el mapa complet de col·locació i regles de xarxa alhora.
Aquest mateix error es manifesta de tres formes diferents en entorns productius. La primera és un bloqueig dur: la política de xarxa denega la connexió directament. Els treballadors no poden arribar al coordinador i l’entrenament mai no comença. Es detecta en segons. La segona és més subtil: no hi ha bloqueig explícit, però la sincronització de gradients (NCCL AllReduce) ha de travessar la latència entre zones, reduint el rendiment entre un 30% i un 60% sense cap error visible. Això es nota en hores. La tercera és econòmica: el trànsit creua zones de disponibilitat i apareix a la factura com a transferència de dades inter-AZ. Només es descobreix dies després, en revisar la factura. A Q2BSTUDIO, hem ajudat clients a detectar aquests casos utilitzant eines de BI i Power BI per monitoritzar mètriques d’utilització de GPU i costos per zona, proporcionant una visió consolidada que d’altra manera passaria desapercebuda.
La solució sorprèn per la seva simplicitat. No cal tocar Cilium (les portes romanen tancades perquè la política de seguretat no era el problema), ni parchejar Kubernetes o Kubeflow. Només cal proporcionar al scheduler la informació que li falta: mantenir tot el grup d’entrenament junts, en una zona la ruta de xarxa de la qual estigui oberta. A la pràctica, això s’aconsegueix amb unes línies de YAML natives de Kubernetes al spec de la càrrega de treball: nodeAffinity per fixar el grup a la zona amb GPUs, topologySpreadConstraints per col·localitzar coordinador i treballadors, i un toleration perquè el coordinador pugui aterrar en nodes amb taint de GPU. Un cop tots els pods que es comuniquen comparteixen la mateixa zona, el trànsit passa a ser intra-zona: desapareixen el bloqueig dur, la latència i el cost inter-AZ. Un sol canvi, tres símptomes eliminats.
Si no es vol codificar un nom de zona explícit, es pot utilitzar podAffinity amb una clau de topologia de zona, perquè els treballadors es col·loquin a la mateixa zona on aterri el coordinador. És la mateixa idea, però portable entre clústers. En les nostres proves de laboratori, la utilització de GPU va passar d’aproximadament un 40% a un 85% en el moment de col·localitzar el grup. Aquest tipus d’optimitzacions forma part dels serveis que oferim a Q2BSTUDIO, tant en l’àmbit de cloud AWS/Azure com en la integració d’agents IA i ciberseguretat, on entendre la topologia de xarxa és crític per no comprometre el rendiment ni la seguretat.
La conclusió és clara: la teva interfície de xarxa de contenidors (CNI) té opinions sobre la topologia que el teu scheduler no pot veure. Les polítiques de xarxa conscients de la topologia són silencioses per al scheduler de Kubernetes, i aquest silenci és on habita l’error. La solució és nativa de Kubernetes: sense canvis al CNI, sense parxes al framework, només restriccions de dispersió topològica i afinitat al spec de la càrrega de treball. La instrumentació prèvia és clau: mètriques d’utilització de GPU i de zona de pods a Prometheus i Grafana exposen aquest problema en segons; sense elles poden passar dies. Aquest patró es generalitza a qualsevol combinació de CNI conscient de topologia i framework de ML distribuït, no només a Cilium i Kubeflow.
Per a qui vulgui experimentar directament, existeix un laboratori reproduïble que inclou un clúster kind amb zones GPU i CPU, la política de Cilium, regles de gravació de Prometheus, un dashboard de Grafana i scripts de demostració abans/després. Es pot trobar al repositori https://github.com/ram2valar/kubeflow-cilium-lab i una gravació de la xerrada a KubeCon + CloudNativeCon India 2026 a https://www.youtube.com/watch?v=BG9XGouyM9c . A Q2BSTUDIO, estem convençuts que la prevenció d’aquests errors silenciosos és una de les inversions més rendibles en qualsevol infraestructura cloud moderna.
