Kubernetes caduca cada catorze mesos, i no se salten versions

El 27 d'octubre de 2026, la branca 1.34 de Kubernetes deixa de rebre pedaços. No és una notícia ni un ensurt d'última hora: aquesta data estava publicada des que va sortir la versió. I tot i així, a l'octubre hi haurà qui se n'assabenti llegint un avís de seguretat.

La política està escrita en una sola frase de la documentació del projecte: la comunitat manté cada sèrie de pedaços durant «roughly fourteen (14) months». Dotze mesos normals més dos de finals en mode manteniment. El projecte manté «release branches for the most recent three minor releases» —avui la 1.35, la 1.36 i la 1.37—, i pel solapament d'aquests dos mesos finals la 1.34 encara rep pedaços fins al 27 d'octubre.

Les dates de caducitat publicades són aquestes, i convé veure-les juntes perquè juntes diuen una cosa que per separat no es veu: la 1.35 entra en mode manteniment el 28 de desembre de 2026 i mor el 28 de febrer de 2027; la 1.36, el 28 d'abril i el 28 de juny de 2027; la 1.37, el 28 d'agost i el 28 d'octubre de 2027. Resta les tres dates de defunció: febrer, juny, octubre. Cada quatre mesos caduca una versió, mentre el projecte mantingui aquesta cadència. Això és el que signes el dia que adoptes Kubernetes, i ho signes per a tots els anys, no per al primer.

Què vol dir «mode manteniment»

Els dos últims mesos de cada branca no són iguals que els dotze anteriors, i la diferència està escrita. En mode manteniment, els responsables de publicació només treuen versions noves per a tres coses: vulnerabilitats amb identificador CVE assignat, problemes de dependències —inclosa l'actualització de la imatge base— i errades crítiques de components del nucli. Res més.

Traduït a un matí de feina: aquella errada estranya que et vas trobar, la que no és crítica ni té CVE, la que penses reportar amb un cas de reproducció ben fet, ja no s'arregla a la teva branca. S'arregla en una altra, a la qual encara no t'has mogut. És una decisió raonable d'un projecte que va al seu ritme, però és una decisió que prens tu per omissió quan arribes tard.

La regla que converteix el calendari en un projecte

Aquí hi ha la part que la gent descobreix tard. La política de versions del projecte exigeix que «kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters». No se salten versions menors al pla de control. Ni tan sols en un clúster d'una sola màquina, on un pensaria que ningú no se n'assabentarà.

El compte dels salts

Així que el deute no es paga de cop. Si avui corres la 1.33 i vols arribar a la 1.37, són quatre actualitzacions encadenades: 1.34, 1.35, 1.36 i 1.37. Quatre jocs de notes de versió per llegir, quatre tandes d'APIs retirades per comprovar contra els teus manifests, quatre finestres. Una versió endarrerida és una tarda. Quatre versions endarrerides és un projecte amb nom, pressupost i una reunió per decidir quan es fa.

Els nodes, en canvi, tenen marge: el kubelet pot anar fins a tres versions menors per darrere del kube-apiserver —dues si és anterior a la 1.25—, i kubectl és compatible dins d'una versió per sobre o per sota. Aquest marge és útil i està pensat perquè una actualització es pugui fer per fases. També és, segons la nostra experiència, la raó per la qual un clúster sembla sa mentre es va quedant enrere: els nodes continuen funcionant, ningú no veu res trencat, i el marge es consumeix en silenci.

El calendari que no surt en aquell calendari

Les dates de dalt són les del projecte Kubernetes. El teu clúster no és només Kubernetes. A sobre hi ha un controlador d'entrada, un connector de xarxa, un o diversos controladors d'emmagatzematge, un emissor de certificats, la pila de mètriques i, gairebé sempre, algun operador que gestiona una base de dades que a ningú no li ve de gust tocar. Cadascuna d'aquestes peces té cicle propi, matriu de compatibilitat pròpia i un mantenidor que no sap que existeixes, i cap d'aquestes dates no surt a la pàgina de versions de Kubernetes.

Ja vam explicar aquí què va passar amb el controlador d'entrada que era a mitja plataforma Kubernetes i el mantenien dues persones. Aquell avís no va arribar a les notes d'una versió menor de Kubernetes, perquè no era de Kubernetes. Va arribar pel seu costat, amb el seu propi termini. Actualitzar un clúster de debò és resoldre la intersecció de diverses matrius de compatibilitat que van a ritmes diferents; l'ordre és l'últim pas i el més curt. Aquesta intersecció és la que decideix quin dia pots actualitzar i quin dia no.

Això no és un defecte de Kubernetes

Convé dir-ho clar, perquè el text es podria llegir com una pega i no ho és. Publicar tres versions menors l'any és precisament el que permet que el projecte avanci a la velocitat a què avança, i publicar les dates de caducitat amb més d'un any d'antelació és el contrari d'un fabricant que retira un producte per sorpresa. Nosaltres preferim un calendari dur i públic a una promesa tova.

El que sí que canvia és la pregunta que cal fer-se abans d'adoptar-lo. Abans d'adoptar-lo cal contestar una pregunta que no és de tecnologia sinó de plantilla: qui executa tres finestres de manteniment l'any en aquesta casa, durant els propers cinc anys. A everyWAN operem Kubernetes i Docker Swarm, oferim Kubernetes gestionat igual que operem Swarm, i triem segons els mèrits de cada cas, no segons la comissió, perquè no som revenedors de cap plataforma. I per això ho diem sense embuts: un clúster ben dissenyat envelleix malament tan bon punt el calendari es queda sense responsable.

Hi ha a més un detall de mètode que va en la mateixa direcció i que ja vam escriure en un altre lloc: «latest» no és una versió. Si els teus desplegaments no fixen versions, aquest calendari no et serveix de res, perquè no saps què estàs executant i per tant no saps quin dia caduca.

Cinc preguntes que hauries de poder contestar avui

• Quina versió menor fas servir i quin dia caduca? Un kubectl version i la taula de versions de pedaços del projecte. Si la resposta triga més de cinc minuts, ja tens la primera troballa.
• Quants salts et separen de la branca viva més antiga? Cada salt és una finestra, perquè el pla de control no se salta versions. Aquest número és el teu deute.
• Quina versió mínima de Kubernetes demana cada add-on que tens posat? I, la que fa més mal, quin d'ells no suporta encara la versió a la qual vols anar? Aquesta pregunta et durà una tarda i no cinc minuts, i és la que mana en la teva data.
• Qui executa la finestra i amb quin pla de tornada enrere? Amb nom de persona i amb el procediment escrit, no «ho mira qui hi hagi». Sense marxa enrere documentada, la finestra és una aposta.
• Qui mira l'alerta a les tres de la matinada de l'endemà? Les 48 hores següents a la finestra són les que fan mal. Ja vam escriure sobre quina alerta mereix despertar algú i quina és soroll; aquesta distinció es decideix abans, no aquella nit.

El que no estem dient

No estem dient que no facis servir Kubernetes. L'operem, l'oferim gestionat i ens sembla l'eina correcta en força casos. Tampoc no estem dient que aquestes dates siguin inamovibles: són les que el projecte publica avui, 24 de setembre de 2026, i el projecte es reserva variar els calendaris de pedaços segons la gravetat de les errades. I no hem comprovat per a aquest post què ofereix cada proveïdor de Kubernetes gestionat al núvol quan una versió caduca, ni a quin preu; el que sí que surt del calendari oficial és la data del projecte, i aquesta s'aplica a tothom igual.

L'única cosa que defensem aquí és un compte i una conseqüència. El compte: catorze mesos per branca, tres branques vives, una caducitat cada quatre mesos, sense salts al pla de control. La conseqüència: el cost de Kubernetes no és muntar-lo, és sostenir-lo, i aquest cost es paga en finestres de manteniment. Si aquesta feina té un responsable, el calendari és una agenda. Si no en té, el calendari és una data de caducitat que arriba sola, un dimarts, amb un avís de seguretat a sota. Això és exactament el que cobreix el nostre suport IT 24x7, i el que mirem primer quan algú ens demana consultoria sobre una plataforma que ja està en marxa.

Fonts (consultades el 24-set-2026): la frase «roughly fourteen (14) months», el repartiment en dotze mesos més dos en mode manteniment, la llista de motius pels quals es talla una versió durant aquest període (vulnerabilitats amb CVE assignat, problemes de dependències inclosa la imatge base, i errades crítiques de components del nucli) i les dates de mode manteniment i fi de vida de la 1.34 (27-08-2026 i 27-10-2026), la 1.35 (28-12-2026 i 28-02-2027), la 1.36 (28-04-2027 i 28-06-2027) i la 1.37 (28-08-2027 i 28-10-2027) són a Patch Releases. Que es mantenen «release branches for the most recent three minor releases» (1.35, 1.36, 1.37) i que les versions 1.19 i posteriors reben aproximadament un any de suport de pedaços és a Releases. Les regles de desfasament de versions —«kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters», el kubelet fins a tres versions menors per darrere (dues si és anterior a la 1.25), kubectl dins d'una versió, i els apiserver d'un clúster en alta disponibilitat dins d'una versió menor— són a Version Skew Policy. El que aquest post NO afirma: el càlcul d'«una caducitat cada quatre mesos» és nostre, fet restant les tres dates de fi de vida publicades, i depèn que la cadència es mantingui; el projecte es reserva variar els calendaris de pedaços segons la gravetat de les errades. No hem verificat quin suport estès ofereix cada proveïdor de Kubernetes gestionat després del fi de vida upstream, ni el seu cost, i per això no donem cap xifra al respecte. No afirmem que cap altra plataforma de contenidors sigui millor ni pitjor per tenir un altre cicle de vida: són compromisos diferents. I la recomanació de comptar els salts i assignar amo a la finestra és criteri nostre, no una recomanació del projecte.