Versies, onderhoud en levenscyclus

De beheerfunctie is CloudNativePG 1.30.1 met de Barman Cloud-plug-in 0.15.0. De ondersteuning van 1.30 loopt rond december 2026 af; de overgang naar 1.31 start daarom tijdens de bouw van de dienst, en de acceptatie omvat 1.31. De leverancier bevestigt dat hij de stapel en de opslagkoppeling ondersteunt, ook de tussenliggende combinaties naar 1.31.

Het platform biedt PostgreSQL 17 en 18 aan; ‘standaard’ is 18, en 14 wordt niet aangeboden. De beelden komen per hoofdversie uit een ClusterImageCatalog via beleid; kleine versies volgen via de beeldcatalogus, en extensies komen alleen uit het vrijgegeven beeld.

Ondersteunt de leverancier de stapel niet, dan is EDB Postgres for Kubernetes, de uitgave van de leverancier, de terugvaloptie, in de versie die hij bij OpenShift 4.22 ondersteunt en met dezelfde instellingen; tot die overgang alleen voor ontwikkelen en beproeven. Er draait geen productie op een niet-ondersteunde stapel.

Voor functies die nog niet vastliggen, gelden acceptatiecriteria, ieder met een eigen terugvaloptie.

Alleen door de leverancier ondersteunde combinaties draaien. De overgang naar een nieuwe versie van de beheerfunctie start ten minste 3 maanden vóór het einde van de ondersteuning. Ondersteunt de beheerfunctie een nieuwe clusterversie niet, dan gaat zij eerst over.

Beheerfunctie, plug-in en databasebeelden zijn software van derden, geen platformsoftware van de platformleverancier. Zij komen via de toelatingsroute uit de containerregistry van de cel, opgehaald met de leesrobot van het cluster, en staan in het register van toegelaten software met eigenaar en einddatum.

Nieuwe versies van beheerfunctie, plug-in en databasebeeld gaan via de leeromgeving en daarna per cel via de proefgroep, golf 1 en golf 2, zoals de gehoste clusters, zodat een fout eerst een kleine groep treft.

Kwetsbaarheden in beheerfunctie en databasebeelden worden opgelost binnen de termijnen die het platform voor kwetsbaarheden hanteert, in het onderhoudsvenster of via de spoedroute.

Het onderhoudsvenster van de database is dat van haar applicatiecluster: één venster per cluster. Kleine updates voert het platform daarin automatisch uit; in reguliere productie via overschakeling naar een bijgewerkt exemplaar (primaryUpdateMethod switchover), waarbij verbindingen opnieuw worden opgebouwd, en bij ontwikkelen en beproeven met een korte onderbreking bij de herstart.

Een nieuwe hoofdversie volgt een plan met het team en komt in een nieuw databasecluster, via import of logische replicatie; daarna verhuizen adres en naam. Zij gaat pas in gebruik na een volledige back-up, een schrijfstop en een geslaagde proef op een herstelde kopie. Het oude databasecluster blijft terugvalpad tot het akkoord.

De draaiboeken voor de beheerde database staan in de opslagplaats Draaiboeken, lopen via Ansible Automation Platform of als wijzigingsvoorstel, en zijn vóór productie beproefd. Vóór de overdracht voeren de beheerders ze zelf uit.