I takt med att användningen av Kubernetes fortsätter att öka har dess avgörande roll för att säkerställa kontinuitet i verksamheten blivit väldigt tydlig, inte minst på grund av att det är den teknik som driver en så stor del av våra digitala liv.
Kubernetes är en komplex teknik som är utformad för att lösa komplexa problem, och fel kan uppstå på alla nivåer, från sk. noder och pods till hela kluster. Regelbundna brandövningar i din Kubernetes-miljö är avgörande för att maximera dina chanser att stå emot driftstörningar och förbättra dina chanser att komma ut oskadd på andra sidan.
I den här artikeln berättar vi kortfattat hur vi resonerar och tänker i och kring brandövningar med Kubernetes. Vi tillämpar dessa metoder med vissa av våra kunder som prenumererar på våra supportpaket för att hjälpa dem att uppnå sina affärsmål med containers i Cleura Cloud. Vi baserar den här artikeln och vissa av våra metoder och tekniska möjligheter på vår vår tjänst Cleura Container Orchestration Engine som drivs av Gardener. De allmänna principer som vi beskriver beskrivs här gäller dock för alla mikrotjänstmiljöer, inte bara Kubernetes-baserade sådana.
Innehåll
Vad är en Kubernetes brandövning?
Brandövningar på Kubernetes-miljöer är övningar som simulerar olika fel för att testa miljöns motståndskraft och för att validera en katastrofplan.
När vi hjälper våra kunder med brandövningar går vi i allmänhet igenom fem huvudfaser, där vi regelbundet lär oss nya saker och drar nytta av mer och mer kunskap om:
- Förberedelser.
- Definiering av omfattning.
- Simulering av misslyckanden.
- Aktivering av katastrofplaner.
- Validering av återställning.
- Dokumentation.
Container Orchestration i Cleura Cloud
Cleura Container Orchestration Engine, vår tjänst för containerorkestrering i Cleura Cloud, är en Kubernetes-baserad plattform som gör det möjligt för våra användare att hantera flera Kubernetes-kluster. Gardener har flera funktioner som gör det enklare att genomföra brandövningar i en Kubernetes-miljö, bland annat möjligheten att utföra underhåll, som att stänga av en nod eller ett kluster på ett smidigt sätt. Dessa funktioner gör det möjligt för användare att simulera ett fel utan att påverka produktionsmiljön.
Utföra en brandövning med Kubernetes
1. Förberedelser – involvera alla intressenter
Det låter enkelt, men genom att involvera alla potentiella intressenter kan ni se till att ni täcker in så många kritiska områden som möjligt i katastrofplanen. Varje intressent har ett unikt perspektiv och kunskap om de affärsprocesser som de ansvarar för, och de kan hjälpa till att identifiera potentiella sårbarheter och föreslå ytterligare steg i återställningen.
Om teamet till exempel utvecklar en katastrofplan för en webbshop kan intressenter från marknadsföringsteamet hjälpa till att säkerställa att kunddata och marknadsföringskampanjer är helt skyddade i händelse av en katastrof. I det här exemplet är det också marknadsföringsteamet som är mest kvalificerat att svara på om katastrofplanen fungerade eller inte.
2. Definiera omfattningen
Innan vi gör något annat är det viktigt att tydligt definiera brandövningens omfattning. Det bör inkludera vilken typ av fel vi ska simulera, vilka tjänster som kommer att påverkas och vilken katastrofplan vi ska använda för att lösa problemet. Både utvecklare, driftpersonal och affärsområdesansvariga måste vara med och definiera omfattningen för att säkerställa att den täcker in alla viktiga områden.
Här är ett exempel på en verklig omfattning, på hög nivå, från en brandövning som vi genomförde med en av våra kunder.
Exempel på omfattning
- Simulera en plötslig ökning av trafiken till Kubernetes-klustret genom att skicka många förfrågningar till de applikationer som körs i klustret.
- Övervaka hur klustret reagerar på den ökade trafiken och identifiera prestandaproblem eller flaskhalsar.
- Testa klustrets förmåga att hantera ett nodfel genom att simulera förlust av en eller flera noder i klustret.
- Observera hur klustret reagerar på nodfelet och se till att applikationerna körs smidigt.
- Verifiera att Kubernetes inbyggda mekanismer för autoskalning fungerar korrekt genom att lägga till ytterligare noder och observera klustrets förmåga att hantera den ökade belastningen.
- Dokumentera resultaten av brandövningen och identifiera eventuella områden som behöver förbättras eller optimeras.
3. Simulera felet eller felen
Nästa steg är att simulera felet i enlighet med övningens omfattning. Det kan vara så enkelt som att simulera en hög belastning eller ett nodfel, som illustreras i vårt exempel på omfattning, eller så komplicerat som ditt team vill att scenariot ska vara.
Att välja vilka typer av fel som ska övas beror helt på hur väl du vill att ditt team och system ska hantera olika scenarier. Vi tycker att det är viktigt att hålla en sund balans mellan att genomföra brandövningar och förbättra systemen, och vårt bästa tips är att begränsa dina feltyper till centrala backend-komponenter och utöka när ditt team är mer vana med att genomföra brandövningar.
4. Aktivera katastrofplanen
När ert simulerade scenario har aktiverats är det dags att påbörja den katastrofplan som ni redan har planerat i steg 1. Katastrofplanen bör vara väldefinierad och dokumenterad för att täcka alla kritiska områden.
Vissa av funktionerna i Gardener, vår tjänst för containerorkestrering, t.ex. möjligheten att återställa från säkerhetskopior eller utföra en rullande uppgradering, kan användas för att återställa felet. Andra scenarier kan kräva att man återställer nätverksanslutningen och förlitar sig på Kubernetes självläkande egenskaper.
5. Validera återställningen
Det sista steget är att validera att katastrofplanen återställde systemet till dess ursprungliga tillstånd.
Förutom att kontrollera klustrets övergripande status, inklusive dess noder och systemkomponenter, måste du verifiera hälsa och prestanda för de program som körs i klustret. Datakonsistens bör också vara en viktig del av er katastrofplan, särskilt för sk. stateful-applikationer. Andra praktiska tester är att se till att övervaknings- och loggningstjänsterna fungerar korrekt och att klustret återigen kan hantera automatisk skalning som svar på ökade arbetsbelastningar efter återställningen.
Vi återkommer hela tiden till intressenterna, men glöm inte att involvera dem alla i valideringsprocessen för att säkerställa att så många områden som möjligt täcks in.
6. Dokumentera
Efter brandövningen är det dags att dokumentera hela processen för att utvärdera hur effektiv katastrofplanen var och identifiera eventuella förbättringsområden. Använd resultaten från er dokumentation för att uppdatera katastrofplanen och förbättra systemets motståndskraft.
Att regelbundet genomföra brandövningar i en Kubernetes-miljö, kanske med hjälp av vår tjänst för containerorkestrering, är viktigt för att säkerställa att ditt system och din personal är bättre förberedda på att hantera fel som kan uppstå.
De steg som beskrivs i den här artikeln är ett grovt ramverk för att genomföra effektiva brandövningar i en Kubernetes-miljö. Genom att följa dessa steg kan du också identifiera och åtgärda eventuella större problem innan en verklig katastrof inträffar.
Martin Dahl
Customer Solutions Architect Karlskrona, SverigeMed över ett decennium i branschen är Martin Dahl en skicklig lösningsarkitekt som specialiserat sig på containers, Kubernetes och OpenStack. Han är känd för att driva effektivitet och integrerar effektivt CI/CD- och DevOps-metoder i sitt arbete och tar fram innovativa lösningar som optimerar utvecklingsprocesser. Hans gedigna tekniska expertis, analytiska förmåga och förmåga att kommunicera komplexa idéer kompletteras av hans engagemang för att hålla jämna steg med de senaste trenderna inom molnteknik.
Molnguiden
Svara på ett antal frågor om din verksamhet och din IT-organisation så ger vi dig en indikation om vilken av våra molntjänster vi tror passar er samt hur vi kan hjälpa er vidare.