Van een Amazon ECS naar een Kubernetes setup

In 2016 hadden we veel projecten die in Docker-containers draaiden. Op dat moment draaiden onze Docker-containers in Amazon ECS of op virtuele machines van Amazon EC2 waarop de Docker-daemon draaide. Helaas vergde deze opstelling veel onderhoud. We hadden een tool nodig die ons een betrouwbare manier zou bieden om deze containers in productie te draaien. We verlangden naar een orchestrator die ons hoge beschikbaarheid, automatische opschoning van oude resources, automatische containerplanning en nog veel meer zou bieden.

→ Enter Kubernetes!

Kubernetes bleek de perfecte kandidaat te zijn voor een container orkestratietool. Het kon containers betrouwbaar in productie draaien en de hoeveelheid onderhoud die nodig was voor onze opstelling verminderen.

Een Kubernetes-gerichte aanpak creëren

Behendig als we zijn, stelden we het idee voor een Kubernetes-opstelling voor een van onze volgende projecten voor. De klant zag het potentieel van onze nieuwe aanpak en stemde ermee in om deel uit te maken van de revolutie. Begin 2017 creëerden we ons eerste Kubernetes-cluster. In dit stadium waren er slechts twee zekerheden: we wilden Kubernetes draaien en het zou op AWS draaien. Daarnaast waren er nog veel vragen en uitdagingen.

• Hoe zouden we ons cluster opzetten en beheren?
• Kunnen we onze bestaande docker-containers in het cluster draaien?
• Wat voor toegang en informatie kunnen we de ontwikkelteams geven?

We hebben geleerd dat de moeilijkste taak uiteindelijk niet het opzetten van het cluster was. In plaats daarvan bleek het creëren van een nieuwe mindset binnen ACA Group om deze nieuwe aanpak te accepteren en het betrekken van de ontwikkelteams bij onze next-gen Kubernetes setup de moeilijkste taak te zijn. Naast het zelf leren kennen van het product en het betrekken van andere teams, hadden we nog een aantal andere taken die onze aandacht vroegen:

• we moesten elke applicatie dockeriseren,
• we moesten in staat zijn om applicaties in het Kubernetes-cluster op te zetten die hoog beschikbaar en indien mogelijk ook zelfhelend waren,
• en geclusterde applicaties moesten hun status kunnen delen met behulp van de beschikbare methoden binnen de geselecteerde container netwerkinterface.

Het bleek een hele uitdaging om te wennen aan deze nieuwe manier van werken in combinatie met andere taken, zoals het opzetten van goede monitoring, een gecentraliseerde logging setup en het implementeren van onze applicaties op een consistente en onderhoudbare manier. Gelukkig konden we deze uitdagingen overwinnen en ongeveer een half jaar nadat we ons eerste Kubernetes-cluster hadden gemaakt, ging ons eerste productiecluster live (augustus 2017).

Dit waren de kernonderdelen van onze toolset anno 2017:

• Terraform zou de AWS VPC, netwerkcomponenten en andere afhankelijkheden voor het Kubernetes-cluster implementeren
• Kops voor clustercreatie en -beheer
• Een EFK-stack voor logging werd ingezet binnen het Kubernetes-cluster
• Heapster, influxdb en grafana in combinatie met Librato voor monitoring binnen het cluster
• Opsgenie voor waarschuwingen

Leuk! ... maar het kan beter: kosten, componenten en downtime verlagen

Nadat we onze eerste opstelling hadden voltooid, werd het eenvoudiger om dezelfde topologie te gebruiken en zijn we doorgegaan met het implementeren van deze opstelling voor andere klanten. Door onze infrastructure-as-code aanpak (Terraform) in combinatie met een Kubernetes cluster management tool (Kops) was de inspanning om nieuwe clusters aan te maken relatief laag.

Na een tijdje begonnen we echter een aantal mogelijke risico's op te merken met betrekking tot deze setup. De hoeveelheid werk die nodig was voor de setup 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. We moesten dus een aantal veranderingen doorvoeren om de onderhoudsinspanning op het Kubernetes-gedeelte van deze setup te verminderen en de zaken beheersbaar te houden voor onszelf.

Migratie naar Amazon EKS en Datadog

Op dit punt werd de Kubernetes-service van AWS (Amazon EKS) algemeen beschikbaar. We waren in staat om alle dingen die door Kops worden beheerd te verplaatsen naar onze Terraform-code, waardoor de dingen een stuk minder complex werden. Als extra voordeel worden de Kubernetes masternodes nu beheerd door EKS. Dit betekent dat we nu minder nodes hoeven te beheren en EKS biedt ons ook clusterupgrades met één druk op de knop.

Naast het verminderen van de werklast op ons Kubernetes-beheervlak, hebben we ook het aantal componenten binnen ons cluster verminderd. In de vorige opstelling gebruikten we een EFK-stack (ElasticSearch, Fluentd en Kibana) voor onze loginfrastructuur. Voor onze monitoring gebruikten we een combinatie van InfluxDB, Grafana, Heapster en Librato. Deze tools gaven ons veel flexibiliteit, maar vergden veel onderhoud, omdat ze allemaal binnen het cluster draaiden. We hebben ze allemaal vervangen door Datadog agent, waardoor onze onderhoudswerkzaamheden drastisch zijn verminderd.

Upgrades in < 60 minuten

Bovendien waren we door de migratie naar Amazon EKS en de vermindering van het aantal componenten die binnen het Kubernetes-cluster draaien, in staat om de kosten en de impact op de beschikbaarheid van onze clusterupgrades te verminderen. Met de huidige stack, die Datadog en Amazon EKS gebruikt, kunnen we een Kubernetes-cluster binnen een uur upgraden. Als we de vorige stack zouden gebruiken, zouden we daar gemiddeld 10 uur over doen.

Waar staan we nu?

Op dit moment hebben we 16 Kubernetes-clusters draaien, allemaal met de laatst beschikbare EKS-versie. Op dit moment willen we onze liefde voor Kubernetes verspreiden waar we maar kunnen.

Meerdere projectteams binnen ACA Group maken nu gebruik van Kubernetes, dus we organiseren workshops om ze te helpen snel met de technologie overweg te kunnen. Tegelijkertijd proberen we ook op de hoogte te blijven van de nieuwste toevoegingen aan dit snel veranderende platform. Daarom hebben we de Kubecon conferentie in Barcelona bijgewoond en onze meningen gedeeld in ons Kubecon Afterglow evenement.

Wat is de volgende stap?

Hoewel we erg blij zijn met onze huidige Kubernetes setup, geloven we dat er altijd ruimte is voor verbetering. Tijdens ons Kubecon Afterglow evenement hebben we een aantal interessante discussies gehad met andere Kubernetes enthousiastelingen. Deze discussies hebben ons geholpen om onze volgende stappen te definiëren en onze Kubernetes setup naar een nog hoger niveau te brengen. Enkele dingen die we in de nabije toekomst willen verbeteren:

1. service mesh toevoegen aan onze Kubernetes stack,
2. 100% automatische worker node upgrades zonder applicatie downtime.

Natuurlijk zijn dit maar een paar aandachtspunten. We zullen veel nieuwe functies en verbeteringen implementeren zodra ze worden vrijgegeven!

Hoe zit het met jou? Ben je geïnteresseerd in je eigen Kubernetes-cluster? Welke verbeteringen ben je van plan aan te brengen in je stack of Kubernetes setup? Of heb je een onbeantwoorde Kubernetes-vraag waarmee we je misschien kunnen helpen?

Neem contact met ons op via cloud@aca-it.be en we helpen je verder!