OpenShift

18-mei-2021

ClosedShift: Een containerplatform klaarmaken voor onderhoud

openshift offline closedshift

Vele van jullie kennen OpenShift inmiddels wel. OpenShift is een Kubernetes plus platform dat je in staat stelt om traditionele statefull applicaties in te zetten, naast cutting-edge cloud-native applicaties, door moderne architecturen zoals microservices of serverless te ondersteunen. Een platform dat naast alle development hulpmiddelen ook gebouwd is met een focus op up-time. Men wil natuurlijk dat zijn of haar horizontaal - of sinds OpenShift 4 ook verticaal - geschaalde applicaties wel blijven draaien. Maar wat nou als je zo'n platform als OpenShift uit moet zetten? Wat komt daar dan bij kijken?

Dat was de vraag die ik kreeg vanuit de afdeling infrastructuur. Zij wilden namelijk alle spullen in meerdere datacentra tegelijk uitzetten omdat een groot aantal netwerkapparatuur aan vervanging toe was. Op dat moment draaide de applicatie stack waar wij als DevOps team voor verantwoordelijk zijn in een Hybride situatie, gedeeltelijk nog op OpenShift 3 en OpenShift 4.

Applicaties gecontroleerd aan- en uitzetten

Snel werd duidelijk dat de DevOps teams verantwoordelijk zouden zijn voor het daadwerkelijk uitzetten van onze applicaties en eventuele andere pods die wij beheren in onze OTAP-straat. Dit om te voorkomen dat bij het opstarten van de nodes, die door OpenShift worden gebruikt, alle applicaties tegelijk proberen op te starten. Er is dus gekozen om alle applicaties op een gecontroleerde manier uit en - vervolgens na het vervangen van de netwerkapparatuur - weer aan te zetten. Eerst gaat OTA uit, daarna volgt productie. Na het onderhoud worden de productie nodes weer gestart, gevolgd door de OTA nodes. Maar een platform als OpenShift is in principe niet gemaakt om uit te gaan. Wat komt daar allemaal bij kijken?

Het plan

In eerste instantie dacht ik: “Oh dat wordt een eitje, simpel ‘Bash Scriptje’ om alles uit te zetten toch?”. Nou nee, dat licht toch iets genuanceerder. Alle applicaties die wij als DevOps team draaien binnen OpenShift worden namelijk automatisch geschaald via een “Horizontal Pod Autoscaler”, of in het kort “HPA”. Mocht ik alle applicaties via een commando of script naar 0 pods schalen, zorgt de HPA ervoor dat de applicatie weer naar het opgegeven minimale aantal pods geschaald wordt. Na wat onderzoek kwam ik erachter dat dit in OpenShift 4 te omzeilen is met een workaround. Voor OpenShift 3 was dit echter geen optie. Daarvoor moest ik wat anders verzinnen.

Uiteindelijk hebben wij ervoor gekozen om het volgende te doen in OpenShift 3:
(Mocht je al OpenShift 4 gebruiken, dan kan je door de hiervoor genoemde workaround de HPA stappen 1, 2 en 8 overslaan.)

  1. Verzamel en bewaar alle HPA-configuratie in een hpalist.yaml bestand per Namespace.
  2. Schoon deze op, zodat deze hpalist.yaml overzichtelijk en makkelijk in gebruik te nemen is.
  3. Verwijder vervolgens alle HPA-configuratie in al onze Namespaces.
  4. Schaal alle applicaties en overige Pods naar 0.
  5. Controleer met behulp van metrieken / logs of het schalen naar 0 succesvol doorgevoerd is.
  6. Wacht tot de datacenter werkzaamheden uitgevoerd zijn oftewel: zet je favoriete serie op!
  7. Schaal alle applicaties en overige pods naar 1.
  8. Zet met behulp van de hpalist.yaml per namespace alle HPA-configuratie terug.
  9. Controleer met behulp van metrieken/logs of de schaling en het herplaatsen van de HPA-configuratie succesvol doorgevoerd is.
  10. Voer met behulp van geautomatiseerde regressie testen op de OTA-omgevingen uit en smoketest, of vraag een eindgebruiker om Productie te testen.

Naast deze stappen hebben wij ook overwogen een volledige re-deployment vanuit onze CI/CD pipeline uit te voeren en op deze manier alle applicaties weer uit te rollen. En waarom ook eigenlijk niet? Klinkt goed, maar bij nader inzien is dit geen goed plan. Dit heeft te maken met het feit dat je er niet van uit kunt gaan dat alles wat nodig is om de CI/CD pipeline te draaien wel werkt. Je weet gewoonweg niet of alle randvoorwaardelijke infrastructuur, die in jouw CI/CD pipeline gebruikt worden, aanwezig zijn. Dit aangezien alles binnen de datacentra uitgezet werd. Daarnaast draaien wij veel applicaties door onze gehele OTAP-straat heen en zou het best wat tijd gaan kosten om deze allemaal tegelijk uit te rollen via onze CI/CD pipelines.

Wij hebben gekozen voor Bash om het een en ander te automatiseren. Dit omdat je voor BASH-scripts weinig afhankelijkheden hebt en wij op dat moment geen toegang hadden tot iets als Ansible. Daarnaast weet je niet wat je aan gaat treffen als het datacentra weer aangezet worden. Deze Bash scripts hebben wij van tevoren in onze OTA-omgeving getest zodat wij vrij zeker waren dat deze stappen tijdens het datacentra onderhoud hun werk zouden doen.

Lessons learned

Uiteindelijk is alles succesvol verlopen, alles verliep volgens plan. Wel hadden we een tweetal dingen geleerd voor de volgende keer:

  • Bij het opschalen van de applicaties van de OTA Namespaces werden er per Namespace ongeveer 350 pods gestart. Dit zorgde voor wat uitdagingen binnen OpenShift 3. De volgende keer is het beter om dit per Namespace te doen. Dit geeft het platform wat meer tijd om alle pods te starten zonder dat er zich mogelijk problemen voor doen.
  • OpenShift 3 heeft geen mogelijkheid om op een simpele manier alle applicaties naar 0 pods te schalen. OpenShift 4 heeft dit wel.

Onze voorbereiding als team heeft daar enorm veel aan bijgedragen. Daarnaast hebben we ook geleerd dat OpenShift 4 meer flexibiliteit biedt door meer functionaliteit te bieden m.b.t. de HPA-configuratie. Het is hierdoor simpeler om in OpenShift 4 een applicatie uit te zetten, ook al heeft deze HPA-configuratie.

Aangezien ik hoogstwaarschijnlijk niet de enige ben die ooit applicaties moet gaan uit zetten op OpenShift ter voorbereiding van onderhoud of iets dergelijks, deel ik naast mijn ervaring hierbij ook mijn scripts die wij gebruikt hebben. Voor meer informatie over de scripts, zie mijn git: ClosedShift . Hierin vind je ook een stappenplan en wat meer informatie over deze git repo.

Bedankt voor het lezen! Heb je vragen? Neem gerust contact op =)


 
Laat een reactie achter