Nu OpenShift 4 alweer een tijdje uit is en ook steeds meer geschikt is geworden voor on-premise implementaties (naast de verschillende public clouds), komt steeds vaker de vraag hoe je van je bestaande OpenShift 3 installatie kunt overstappen naar 4. In dit blog nemen we de benodigde stappen met je door.
Laten we beginnen met het slechte nieuws: je kunt niet in-place een OpenShift 3 cluster upgraden naar OpenShift 4 met bijvoorbeeld yum upgrade of het vervangen van alle OpenShift containerimages door de nieuwste versies. Je moet dus eerst een nieuw cluster inrichten met de nieuwe openshift-installer en de CoreOS onderlaag.
In een ideale wereld heb je vervolgens voor al je applicaties een geheel geautomatiseerde CI/CD pipeline draaien, waar je nu alleen maar hoeft aan te geven dat de output en assets richting je nieuwe platform gestuurd moeten worden. En klaar is Kees. Maar de ervaring leert dat de wereld niet overal zo ideaal is als je zou willen.
Dan nu het goede nieuws: Red Hat heeft twee migratietools uitgebracht om je te helpen met je migratie: de Cluster Application Migration tool (CAM) en de Control Plane Migration Assistant (CPMA). Omdat de meeste migratievraagstukken liggen bij applicatieworkloads, focus ik nu vooral op de eerste: CAM. De CPMA tool kan echter alsnog handig zijn als je je OpenShift cluster niet hebt ingericht volgens het Infrastructure-as-Code (IaC) principe, en je dus heel veel handwerk zou moeten verrichten om alle configuratie opties mee te nemen (let er echter op dat de CPMA tool vanwege de grote verschillen tussen OCP 3 en 4 zeker niet alle parameters mee zal kunnen nemen).
De Cluster Application Migration tool kun je gewoon installeren met behulp van een (daar is het magische woord weer) Operator. Natuurlijk op je OCP 4 cluster via de GUI, maar ook met behulp van podman op OCP 3. De tool moet op zowel het bron- als doelcluster geïnstalleerd zijn, en er moet object storage (AWS S3, Azure Blob, etc.) zijn waar een repository voor je applicaties kan worden aangemaakt.
De Cluster Application Migration tool is opgebouwd uit de open-source tools Velero (voor sommige ook nog bekend als Heptio Ark) en Restic. Eigenlijk is het dus een schil om een Kubernetes backup- en restore script, aangevuld met functionaliteit om al je back-ups in een objectstore op te kunnen slaan.
Op het doelcluster (dus de OCP 4 kant) kun je nu met de migration-controller in je openshift-migration namespace de Migration UI aan laten maken, compleet met service en route. Je kunt hier vervolgens op inloggen via oAuth. Nu het is het nog zaak om de uiteindelijke hostname van deze instantie toe te voegen in CORS configuratie van het broncluster (de OCP 3 kant), en vervolgens kun je allebei de clusters en de storage repository toevoegen aan je migratietool.
Nu kun je migratieplannen gaan opstellen. Op dit moment is het nog nodig dat je cluster-admin bent op de projecten die je wilt migreren (anders kan het zijn dat de tool niet genoeg toegang heeft tot de verschillende resources van het project). Let erop dat migratie per namespace verloopt, en dat er dus niet afhankelijkheden zijn van objecten in een andere namespace. Kies het project dat je wilt migreren, eventuele bijbehorende Persistent Volumes, de repository waarin je tijdelijk wilt repliceren en als alle settings goed staan, kun je kiezen voor Stage.
Mocht de Stage geheel zijn gelukt dan kunnen je kiezen voor de daadwerkelijke ‘Migrate’. Let erop dat in de default settings de deployment op het broncluster naar 0 pods wordt gezet en op dat moment dus niet meer beschikbaar is. Zeker als je ook Persistent Volumes mee kopieert weet je zeker dat er geen dataverlies en/of synchronisatieproblemen plaats gaan vinden (je kunt hiervoor kiezen tussen Copy en Move, maar let er dus op dat als je bijvoorbeeld een Move doet van NFS storage, deze dus meteen wordt geunmount op het broncluster en gemount op het doelcluster).
Je kunt bij het uitvoeren van je migratieplan kiezen of je de pods in het broncluster door wilt laten draaien. Voor stateless applicaties kan dit makkelijk, maar als je de onderliggende volumes verplaatst (dus niet kopieert), of als de applicatie allerlei belangrijke unieke data naar een database schrijft (zij het in OpenShift, zij het extern), dan zul je hier toch downtime voor in moeten plannen, al is het maar voor heel even. Mocht je migratie in een volgend stadium alsnog mislukken, dan kun je de data weer oppakken en de pods weer opbrengen alsof er niets is gebeurd, en het op een later moment opnieuw proberen.
Als de migratie is gelukt krijg je de melding ‘Migration Successful’ en is het Plan vervolgens ‘Closed’. Er is nu een gelijknamig project op de doelcluster met nieuwe pods van dezelfde applicatie. Je kunt nu dus je loadbalancer wijzen naar deze nieuwe deployment (dus naar de nieuwe router in je OCP 4 cluster) of, als nodig, DNS records omzetten. Zorg er dus voor dat je goed in kaart hebt hoe alle gebruikers de applicatie benaderen, want al deze entrypoints moeten worden omgezet naar het nieuwe cluster. Test dit ook meteen, want een technisch succesvol gemigreerde applicatie waar vervolgens niemand op kan inloggen, daar heeft niemand wat aan.
Je hebt nu, als het goed is, je OpenShift 3 omgeving succesvol overgezet naar OpenShift 4! Laat de tool gerust staan, want hij komt ook van pas als je binnen minor versions van OpenShift 4 (bijvoorbeeld van 4.1 naar 4.2) of tussen meerdere clusters van dezelfde versie wilt gaan migreren.
Kwam je er toch niet helemaal uit? Stel gerust je vraag hieronder!
De meeste workloads kunnen zonder problemen worden gemigreerd, mits aan een aantal voorwaarden worden voldaan:
Riemer Palstra