Hoe ziet bij ACA de Kubernetes setup eruit?
Bij ACA draait alles om Kubernetes. We zetten nieuwe projecten standaard op met dit populaire
systeem voor containerorkestratie en we zijn ook bestaande klanten naar Kubernetes aan het migreren. Dat betekent dat het aantal Kubernetes-clusters dat het ACA-team beheert snel groeit! We hebben onze opzet meerdere keren moeten veranderen om plaats te maken voor meer klanten, meer clusters, meer belasting, minder onderhoud en ga zo maar door.
Van een Amazon ECS naar een Kubernetes set-up
In 2016 hadden we veel projecten die draaiden in Docker-containers. Op dat moment draaiden onze Docker-containers of in Amazon ECS, of op Amazon EC2 Virtuele Machines die de Docker daemon draaien. Helaas vergde deze opstelling veel onderhoud. We hadden een tool nodig waarmee we op een betrouwbare manier deze containers in productie konden draaien. We hadden behoefte aan een orkestratietool die ons hoge beschikbaarheid, het automatisch opruimen van oude resources, automatische containerplanning, etc.
kon bieden.
→ Enter Kubernetes!
Kubernetes bleek de perfecte kandidaat te zijn voor onze nieuwe containerorkestratietool. Kubernetes was in staat om containers op een betrouwbare manier in productie te nemen en de hoeveelheid onderhoud te verminderen die nodig zou zijn voor onze opzet.
Een op Kubernetes gerichte aanpak creëren
Agile als we zijn, stelden we voor een van onze volgende projecten een opzet met behulp van Kubernetes voor. De klant zag het potentieel van onze nieuwe aanpak en stemde ermee in om deel uit te maken van de revolutie. Begin 2017 hebben we ons eerste eigen Kubernetes-cluster gecreëerd. Op dat moment waren er maar twee zekerheden: we wilden Kubernetes draaien en het moest draaien op AWS. Afgezien daarvan waren er nog een heleboel vragen en uitdagingen.
- Hoe zouden we ons cluster opzetten en beheren?
- Kunnen we onze bestaande Docker-containers binnen het cluster draaien?
- Welk type toegang en informatie kunnen wij de ontwikkelteams bieden?
We hebben uiteindelijk ontdekt dat het opzetten van de clusters niet het moeilijkste aspect was. Integendeel, het creëren van een nieuwe mindset bij ACA Group om deze nieuwe aanpak te accepteren, en het betrekken van de ontwikkelteams bij onze next-gen Kubernetes-opzet, bleek een veel lastigere opgave te zijn. Afgezien van het feit dat we zelf het product moesten leren kennen en er andere teams bij moesten betrekken, vergden ook een paar andere taken onze aandacht:
- we moesten elke applicatie converteren voor Docker-uitvoering,
- we moesten in het Kubernetes-cluster applicaties op kunnen zetten met een hoge
beschikbaarheid die, indien mogelijk, ook zelfherstellend zouden zijn, - en geclusterde applicaties moesten hun status kunnen delen met behulp van de beschikbare methoden binnen de geselecteerde interface van het containernetwerk.
Het wennen aan deze nieuwe manier van werken in combinatie met andere taken, zoals het opzetten van goede monitoring, een gecentraliseerde registratie-opzet, en het inzetten van onze applicaties op een consistente en onderhoudbare manier, bleek een hele uitdaging te zijn. Gelukkig konden we deze uitdagingen overwinnen en ongeveer een half jaar nadat we onze eerste Kubernetes-cluster hadden gecreëerd, is ons eerste productiecluster live gegaan (augustus 2017).
Dit waren de hoofdonderdelen van onze toolset anno 2017:
- Terraform zou de AWS VPC, netwerkcomponenten en andere afhankelijkheden voor het Kubernetes-cluster inzetten
- Kops voor clustercreatie en beheer
- Een EFK-stack voor registratie werd ingezet binnen het Kubernetes-cluster
- Heapster, influxdb en grafana in combinatie met Librato voor monitoring binnen het cluster
- Opsgenie voor waarschuwingen
Mooi! ...maar het kan nog beter, met minder kosten, onderdelen en uitvaltijd
Nadat we dit voor de eerste keer hadden opgezet werd het gemakkelijker om dezelfde topologie te gebruiken en we hebben daarna deze opzet ook voor andere klanten geïmplementeerd. Door onze aanpak van infrastructuur-als-code (Terraform) in combinatie met een Kubernetes-cluster beheertool (Kops), was de inspanning om nieuwe clusters te creëren betrekkelijk gering.
Na een tijdje begonnen we echter te zien dat deze opzet een aantal mogelijke risico's met zich mee brengt. De hoeveelheid werk die nodig is voor het opzetten en de impact van updates of upgrades op onze Kubernetes-stack was te groot. Tegelijkertijd groeide het aantal klanten dat hun eigen Kubernetes-cluster wilde hebben. We moesten dus een paar veranderingen aanbrengen om de onderhoudsinspanning te verminderen voor het Kubernetes-deel van deze opzet om het voor onszelf beheersbaar te houden.
Migratie naar Amazon EKS en Datadog
Op dat moment werd de Kubernetes-dienst van AWS (Amazon EKS) algemeen beschikbaar gesteld. We konden hierdoor alle zaken die door Kops werden beheerd verplaatsen naar onze Terraform-code, wat alles een stuk minder complex maakte. Als extra voordeel worden de hoofdknooppunten van Kubernetes nu beheerd door EKS. Dit betekent dat we nu minder knooppunten hoeven te beheren. EKS geeft ons bovendien cluster-upgrades met een enkele druk op de knop.
Naast het verminderen van de werklast wat betreft het Kubernetes-beheer, hebben we ook het aantal componenten binnen ons cluster verminderd. In de vorige opzet gebruikten we
een EFK-stack (ElasticSearch, Fluentd en Kibana) voor de infrastructuur van onze logboekregistratie. Voor onze monitoring gebruikten we een combinatie van InfluxDB, Grafana, Heapster en Librato. Met deze tools waren we wel heel flexibel, maar de onderhoudsinspanning was hoog, omdat ze allemaal binnen het cluster draaiden. We hebben ze allemaal vervangen door Datadog agent, waarmee onze onderhoudsbelasting drastisch is verminderd.
Upgrades in < 60 minuten
Bovendien stelde de migratie naar Amazon EKS en de vermindering van het aantal componenten dat binnen het Kubernetes-cluster draait ons in staat om de kosten en het beschikbaarheidseffect van onze cluster-upgrades te verlagen. Met de huidige stack, die we draaien met behulp van Datadog en Amazon EKS, kunnen we een Kubernetes-cluster binnen een uur upgraden. Als we dat met de vorige stack wilden doen, kostte ons dat gemiddeld 10 uur.
Dus, waar staan we nu?
We hebben momenteel 16 Kubernetes-clusters draaien, allemaal met de laatst
beschikbare EKS-versie. We willen nu aan iedereen die het wil horen, vertellen hoe geweldig Kubernetes is.
Meerdere projectteams binnen ACA IT-Solutions gebruiken nu Kubernetes, dus we organiseren workshops om hen te helpen snel vertrouwd te raken met de technologie. Tegelijkertijd proberen we ook de meest recente toevoegingen aan dit snel veranderende
platform bij te houden. Daarom hebben we deelgenomen aan de Kubecon-conferentie in Barcelona, waar we onze ideeën hebben gedeeld in ons Kubecon Afterglow evenement.
En wat nu?
Ook al zijn we erg blij met onze huidige opzet met Kubernetes, wij vinden dat er altijd ruimte is voor verbetering. Tijdens ons Kubecon Afterglow evenement, hebben we een paar interessante discussies gevoerd met andere fans van Kubernetes. Deze discussies hebben ons geholpen onze volgende stappen te bepalen om onze Kubernetes-opzet naar een nog hoger niveau te tillen. Enkele verbeteringen in de nabije toekomst:
- service mesh toevoegen aan onze Kubernetes-stack,
- 100% automatische werkknooppunt-upgrades zonder uitvaltijd van de applicatie
Dit zijn natuurlijk slechts een paar van de aandachtspunten. Zodra ze worden vrijgegeven gaan we veel nieuwe functies en verbeteringen implementeren!
