Door: Edco Wallet 4-4-2024
Hoe kies je de juiste Kubernetes Operator voor het beheren van PostgreSQL-databases in een Kubernetes-omgeving? Kies je voor de Postgres Kubernetes-operator van Zalando, de Crunchy data-operator of de Cloud Native PostgreSQL-operator van EDB? In deze blog bespreken we deze vraag en verkennen we de uitdagingen van het draaien van databases in Kubernetes.
Nu het belang van schaalbaarheid, efficiëntie en kostenbesparing stijgt, zijn cloud-native technologieën steeds meer in trek bij organisaties. Naast traditionele infrastructuur zoals virtuele machines en bare metal servers, zien we bij veel bedrijven modernere oplossingen zoals Kubernetes. De flexibiliteit en onderhoudsvriendelijkheid die Kubernetes biedt, zorgen ervoor dat je applicaties eenvoudig kunt implementeren en aanpassen, mits je de juiste helm-charts en tooling hebt. Vooral wanneer het gaat om databases zoals Postgres, beschouwen we containerized implementaties op Kubernetes als een geavanceerde en efficiënte benadering. Het heeft een kleine footprint en kan worden uitgebreid met bijvoorbeeld PostGIS en TimescaleDB. Hoewel sommige klanten al bekend zijn met deze aanpak, moeten anderen nog worden overtuigd met solide argumenten en Proof-of-Concepts.
Wij krijgen de vraag of Postgres in Kubernetes geschikt is voor gebruik in een productieomgeving. En of! Wij hebben met succes een dergelijke implementatie uitgevoerd voor een klant van ons in de maritieme sector. Het bedrijf was al operationeel met Crunchy Postgres-containers, maar zocht naar uitgebreide ondersteuning voor Postgres. Dit was nog vóór de ontwikkeling van de Crunchy-operator. De klant vroeg ons om ondersteuning te bieden voor hun Postgres-containers en om een solide back-up- en hersteloplossing neer te zetten. We hebben dit bereikt door logische replicatie toe te passen vanuit de containers in Kubernetes naar twee Postgres-instanties op virtuele machines.
Het aantal Postgres-containers, of applicaties die een Postgres-pod gebruiken, groeide van slechts een paar tot enkele tientallen. De werklast varieert sterk van applicatie tot applicatie, waarbij sommige gericht zijn op analytische taken en andere op online transactieverwerking (OLTP). Bovendien kan de omvang van de pods aanzienlijk verschillen, variërend van enkele gigabytes tot honderden gigabytes. Met deze logische replicatie-opstelling hebben we de volgende uitdagingen moeten overwinnen:
Om deze uitdagingen aan te pakken, adviseerden we onze klant om een Postgres Kubernetes Operator te implementeren om die uitdagingen en het omslachtige onderhoud te tackelen. Voorafgaand aan deze keuze hebben we een grondige analyse uitgevoerd van de drie meest relevante opties: de Postgres Kubernetes-operator van Zalando, de Crunchy data-operator en de Cloud Native PostgreSQL-operator van EDB. Naast deze 3 opties zijn er nog meer Kubernetes operators in opkomst (die ook steeds beter worden) waaronder die van Percona, StackGres en Cybertec maar deze zijn wat betreft technologie nog niet relevant t.o.v. de 3 reeds genoemde en meest bekende. We hebben de kosten, ondersteuning, gebruiksgemak, flexibiliteit, documentatie en – voor zover te bepalen – het marktaandeel in onze overweging meegenomen.
Uiteindelijk hebben we gekozen voor de Cloud Native PostgreSQL Operator van EDB vanwege zijn uitgebreide ondersteuning, gebruiksgemak en toekomstbestendigheid. Laten we daar eens nader naar kijken. Bij het kiezen van een operator is het van groot belang om niet alleen naar de huidige situatie te kijken, maar ook naar de toekomst. Met de meest relevante opties in gedachten, waren we ervan overtuigd dat op de lange termijn de EDB Cloud Native PostgreSQL (CloudNativePG) de meest uitgebreide en toekomstbestendige keuze zou zijn in het algemeen en voor dit project in het bijzonder. Belangrijke factoren die hebben bijgedragen aan deze beslissing waren:
De belangrijkste voordelen van deze operator zijn de snelle implementatie van clusteropstellingen, Ook het uitrollen van een pgbouncer-setup is een wassen neus. De state fullness die zorgt voor (bijna) echte High Availability (de operator zorgt ervoor dat het cluster altijd wordt weergegeven zoals gedefinieerd), en de CloudNative Postgres Plugin (CNP) die het beheer van Postgres-clusters op Kubernetes vereenvoudigt.
Het draaien van databases in Kubernetes bracht in beginsel aanzienlijke uitdagingen met zich mee. Deze veranderingen waren niet eenvoudig en vereisten een nauwe samenwerking met onze klant. Het implementeren van een verklarend model en het overstappen van traditionele scripts naar helm-charts vroegen om een flinke mentaliteitsverandering. Een bijkomende uitdaging was het ontbreken van een EDB-ondersteund image met de nodige PostGIS- en TimescaleDB-extensies op dat moment. PostGIS wordt nu inmiddels standaard meegeleverd. Hoewel configuratieopties zoals nodes, node pools, taint en affinity beschikbaar waren, vereiste het experimenteren om de optimale instellingen te vinden. Ook het opzetten van effectieve monitoring en waarschuwingssystemen en het verkrijgen van de juiste statistieken in de dashboards bleken uitdagingen. Gelukkig boden de dashboards die bij de operator werden geleverd een solide startpunt. Het was tevens belangrijk om resourcelimieten te overwegen op knooppunten waarop resource-intensieve pods werden uitgevoerd.
CloudNativePG is oorspronkelijk gebouwd door EDB en heeft vervolgens besloten het als open-source-software beschikbaar te stellen, onder Apache licentie 2.0. Het openstellen van de software moedigt een grotere betrokkenheid vanuit de community aan, wat de operator alleen maar sterker zal maken. De Cloud Native PostgreSQL-operator is een waardevolle toevoeging aan het open-source-landschap.
Wil je meer weten over hoe je Kubernetes Operators kunt implementeren voor je databases? Met de verbeteringen van ‘persistent storage’ in Kubernetes en de evolutie van ‘orchestrators’ voor allerlei soorten databases zoals MySQL – met of zonder Galera – en Postgres, kunnen wij onze klanten optimaal adviseren. Neem contact met ons op en ontdek welke oplossing het beste past bij jouw behoeften!
Hoe relevant is de DBA in Cloudland?
How to Postgres on Kubernetes?
Database as a Service onder de loep genomen
Database Reliability Engineering - van Gatekeeper naar Accelerator