Google Cloud heeft aangekondigd dat de GKE-service nu algemeen beschikbare tweestaps-upgrades voor het control plane aanbiedt, waardoor klanten de software-binary-upgrade kunnen scheiden van de dataformaat-migratie en een rollback-venster open kunnen houden tijdens wijzigingen in minor versions.

Waarom GKE een veiliger pad nodig had

Het upgraden van een Kubernetes control plane van de ene naar de volgende minor version heeft altijd risico's met zich meegebracht. Een overstap van 1.33 naar 1.34 vervangt niet alleen de binaries, maar herschrijft ook de onderliggende datastructuren. Als de nieuwe versie een bug bevat, kan het cluster niet eenvoudig worden teruggedraaid; beheerders moeten oude database-snapshots herstellen of het hele cluster opnieuw opbouwen, een tijdrovend en foutgevoelig proces.

Hoe de tweestaps-upgrade werkt

De nieuwe workflow splitst de upgrade in twee afzonderlijke fasen:

  • Stap 1 – Binary-upgrade (emulatiemodus). GKE vervangt de control-plane binaries door de doelversie, terwijl het oude dataformaat behouden blijft. Omdat er geen nieuwe datastructuren worden geschreven, blijft het cluster gedurende deze fase rollback-veilig.
  • Stap 2 – Finalisatie. Na een configureerbare wachttijd converteert GKE de opgeslagen gegevens naar het nieuwe formaat. Zodra deze conversie is voltooid, zou een rollback dezelfde inspanning voor het herstellen van snapshots vereisen die het tweestaps-proces juist probeerde te voorkomen.

De scheiding creëert een "soak window" waarin operators de geüpgradede binaries in productie kunnen observeren zonder zich vast te leggen op de onomkeerbare datamigratie.

Het soak window in de praktijk

GKE monitort automatisch belangrijke gezondheidsstatistieken tijdens de soak-periode: API-latentie, foutpercentages en pod-gezondheid. Als de service afwijkingen detecteert, wordt de uitrol stopgezet, waardoor het cluster in de binary-only staat blijft waarin een rollback nog mogelijk is. Google vermeldt een succespercentage van 99,999% voor upgrades die dit patroon volgen.

Voor clusters die gebruikmaken van de auto-upgrade-functie van GKE, regelt het platform de volledige tweestaps-sequentie zonder handmatige tussenkomst. Gebruikers die de voorkeur geven aan volledige controle, kunnen het proces aanroepen via de Cloud CLI of Terraform.

Het uitvoeren van een handmatige tweestaps-upgrade

Een typische handmatige upgrade met een veiligheidsvenster van 48 uur ziet er als volgt uit:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Om de huidige status te inspecteren:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Als er tijdens de soak een defect optreedt, kan de beheerder een rollback-opdracht geven en terugkeren naar de vorige versie zonder gegevensverlies. Wanneer het cluster stabiel blijkt te zijn, kan de upgrade vervroegd worden voltooid met het commando complete-control-plane-upgrade.

Limieten en vereisten

  • De functie is van toepassing op GKE-clusters met versie 1.33 of later.
  • Er mag slechts één minor version tegelijk worden geüpgraded; het overslaan van versies wordt niet ondersteund.
  • Zowel Autopilot- als regionale clusters blijven beschikbaar gedurende het tweestaps-proces.

Mogelijke nadelen

Het scheiden van binary- en data-upgrades voegt een extra stap toe aan de upgrade-tijdlijn, wat de totale periode kan verlengen voor organisaties die snelle versie-wijzigingen nodig hebben. De soak-periode is ook afhankelijk van geautomatiseerde gezondheidscontroles; teams die zeer aangepaste workloads draaien, moeten de monitoring van GKE mogelijk aanvullen met hun eigen observability-tools om edge-case regressies op te merken.

Waar we op moeten letten

Google heeft nog geen roadmap vrijgegeven voor het uitbreiden van het tweestaps-model naar major version upgrades, die in veel gevallen nog steeds een volledige recreatie van het cluster vereisen. Waarnemers zullen kijken naar aankondigingen over vergelijkbare veiligheidsnetten voor node-pool upgrades en naar eventuele integraties met CI/CD-pipelines van derden die de soak-window-controles kunnen automatiseren.

Kernpunt: Door binary-upgrades los te koppelen van datamigraties, biedt GKE platform engineers een praktisch rollback-venster voor wijzigingen in minor versions, waardoor de operationele kosten van clusteronderhoud worden verlaagd terwijl de downtime tot een minimum wordt beperkt.