Xenit Kubernetes Framework

Posted in : Azure, Kubernetes By xenit Translate with Google ⟶

3 years ago

Bakgrund 

För ungefär tre år sedan började Xenit leverera Kubernetes till kunder och stötte snabbt på en utmaning. Det finns väldigt många sätt att utföra en grunduppsättning, hur olika kringprodukter skall kombineras och hur drift och ansvar för plattformen skall se ut.  

Frågor som följande kom upp snabbt efter att några kunder satts upp: 

• Hur skall kluster sättas upp? 
• Vilket Service Meshskall användas?  
• Vilken ingress är bäst?
• Hur skall kluster uppgraderas? 
• Vilka verktyg skall man använda för att övervaka plattformen?
• Hur rullar man ut en applikation till ett kluster? 
• Hur många kluster skall man ha?

Vi hade idéer om vad som fungerade bra, men märkte också snabbt att efter varje uppsättning, uppdatering och förvaltning ändrades våra åsikter. I början kändes det som ett givet val att sätta upp ett kluster på egen hand, men så fort Azure Kubernetes Service blev GA gjorde den livet och förvaltning betydligt enklare. I början kändes det som att Helm charts var det bästa sedan skivat bröd, men vi insåg snabbt att de som konsumerade dem aldrig lärde sig grunderna då vi abstraherade bort komplexitet från dem med det.

Allt eftersom vårt DevOps-team växte började vi märka att alla skapade förbättringar hos olika kunder som de andra kunderna skulle kunna dra nytta av – men inget sätt att standardisera mellan kunder och mellan personer i teamet. 

Vi insåg att vi behövde påbörja en resa för att säga vad vår gemensamma rekommendation är och försöka göra det på ett sätt som fungerar för så många som möjligt. 

Resa 

När vi insåg att vi hade ett större antal miljöer som vi förvaltade och de var ganska lika, men ändå inte helt. Varje gång en tekniker gick från en miljö till en annan fanns det alltid differenser som var tidskrävande och tog tid från vad kunderna och vi själva behövde. Vi ville att har en tekniker lärt sig en miljö skall teknikern kunna alla. 

Vi satt i ett läge med många olika verktyg och många olika kringkomponenter och att testa allt ihop på olika sätt för varje miljö var utmanande. Vi behövde se till att standardisera på något som vi alla i teamet ansåg var rätt väg just nu men även på ett sätt som gör det enkelt att förbättra allt tillsammans utan att skapa fler varianter som behöver läras ut. 

Med detta som grundtanke valde vi att påbörja jobbet som vi idag kallar Xenit Kubernetes Framework (XKF). XKF är en samling terraform-moduler, verktyg och dokumentation som vi har gjort open source och byggt två tjänster på: Xenit Kubernetes Platform och Xenit Kubernetes Service.

Vårt ramverk gör det möjligt för oss att sätta upp alla miljöer på samma sätt – oavsett tekniker. Det ger oss möjligheten att implementera förbättringar som alla drar nytta av, samtidigt som vi har en plats att i det öppna dela med oss av våra kunskaper till ett bredare community. 

Vi har över de senaste nio månaderna tagit all vår kunskap och destillerat ned den till vad vi anser, just nu, vara rätt sätt att hantera frågorna som ställdes i början. 

Frågor som följande kom upp snabbt efter att några kunder satts upp: 

• Hur skall kluster sättas upp? 
  • Med Terraformi Azure 
• Vilket Service Meshskall användas?  
  • Håll det så enkelt som möjligt, finns behovet kör Linkerd
• Vilken ingress är bäst?
  • Ingress-nginxfungerar väldigt bra 
• Hur skall kluster uppdateras? 
  • Blue/green med hjälp av external-dns
• Vilka verktyg skall man använda för att övervaka plattformen?
  • Prometheus/ Thanos 
• Hur rullar man ut en applikation till ett kluster?
  • Med hjälp av GitOps(Flux) 
• Hur många kluster skall man ha?
  • Minst tre (DEV/QA/PROD)

Detta är våra svar idag och vi har 100-tals andra frågeställningar som inte alltid finns nedskrivna men finns som moduler och verktyg runt omkring. 

Nuläge 

Vi har idag ett ramverk vi fristående från annat kan sätta upp kluster för ett eller flera utvecklingsteam hos kunder där de kan arbeta isolerat om de vill, eller tillsammans om det behöver. För vissa betyder det att Xenit är den enda leverantören i Azure åt dem och tar hand om allt, medans andra inkluderar Xenit Kubernetes Framework som en del av Cloud Adoption Framework, där Xenit Kubernetes Service blir sin egen enterprise-scale landing zone och levererar ”namespace som tjänst” till de olika team i bolaget som konsumerar tjänsten. 

Vi har i vårt arbete byggt ett antal mindre verktyg för att enklare kunna möjliggöra en smidig plattform för utvecklare att fokusera på vad som är viktigt för dem.

Några av dessa verktyg är: 

• XenitAB/terraform-modules: Samling av Terraform-moduler för att sätta upp Azureoch Kubernetes 
• XenitAB/azad-kube-proxy: Reverseproxy för Kubernetes API som möjliggör Azure AD-autentisering för alla kluster 
• XenitAB/gatekeeper-library: Samling av OpenPolicy Agent-regler för OPA-Gatekeeper som vi paketerar och testar med Helm/Kustomize 
• XenitAB/azure-devops-templates: Samling av AzurePipelines templates som används för terraform, packer och GitOps 
• XenitAB/azdo-proxy: AzureDevOps reverse proxy för att möjliggöra multi tenancy med ett Personal Access Token (PAT) med höga rättigheter 
• XenitAB/packer-templates: Packertemplates för att exempelvis sätta upp Azure Pipelines Agent med Azure Virtual Machine Scale Set (VMSS) 

Alla olika verktyg är märkta med taggen xenit-kubernetes-framework på GitHub. 

Framtid 

Vi ser en ljus framtid för tjänsten där vi lockar allt fler och fler tekniker som vill jobba med Cloud Native och Kubernetes, som vill jobba med open source och vill dela med sig av sina kunskaper till resten av Göteborg, Sverige och världen. 

Vi jobbar stenhårt med att hela tiden lägga till nya funktioner i vårt ramverk och håller regelbundet meetups där vi pratar om de olika open source-projekt vi är involverade i. 

Det senaste jobbet vi gjorde var att ta allt det fantastiska vi gjort kring teknik och paketerat det till attraktiva tjänster som är enkla att förstå och beställa. 

Kontakta oss ifall ni vill ha mer information! 

Tags : Azure Kubernetes Service, Kubernetes, Xenit Kubernetes Framework, Xenit Kubernetes Service