Uden data kan en klynge genskabes et nyt sted på kort tid, fordi manifesterne beskriver den. Det, der gør flytningen svær, er de vedvarende volumener og databaserne, fordi data skal kopieres, holdes i takt og gendannes i en anden klynge med et andet lager under sig, uden at noget går tabt.
Et vedvarende volumen er den lagerplads, en container skriver til, og som skal overleve, at containeren genstartes eller flyttes til en anden node. Volumenet er bundet til den lagerdriver og den lagerklasse, klyngen bruger, og driveren tilhører udbyderen eller jeres eget lagersystem. Den binding er grunden til, at data kræver mere arbejde end resten.
Tre slags data i en klynge
Data i klyngens volumener. Filer, køer og databaser, der kører som containere i klyngen og skriver til volumener. De flyttes ved at tage backup af volumenet og gendanne det i den nye klynge, eller ved at kopiere data på applikationsniveau.
Databaser uden for klyngen. En administreret database hos udbyderen, som applikationerne i klyngen kalder. Den flyttes for sig, med databasens egne værktøjer, og ofte er det den, der sætter tidsplanen. Se databaserne ved en flytning.
Klyngens egen tilstand. De ressourcer, der beskriver applikationerne, hemmeligheder og konfiguration. De ligger i etcd og i manifesterne og flyttes som beskrivelser, der kan lægges ind i den nye klynge.
Et værktøj, der gør begge dele: Velero
Velero er et open source-værktøj til backup, gendannelse og katastrofegendannelse af Kubernetes-ressourcer og vedvarende volumener, og til at flytte dem mellem klynger. Licensen er Apache 2.0, og projektets side angiver “Velero a Series of LF Projects, LLC”, altså et projekt under Linux Foundation, læst 8. november 2026. Kodelageret ligger under navnet vmware-tanzu. Hvem der i praksis vedligeholder projektet i dag, er ikke undersøgt her, og det bør I selv se på, før I lægger flytningen på værktøjet.
Velero er et eksempel på en fremgangsmåde: tag backup af ressourcer og volumener i den gamle klynge til et objektlager, som begge klynger kan læse, og gendan i den nye. Andre værktøjer og egne scripts kan gøre det samme. Pointen er, at backuppen ligger uden for begge udbydere, så flytningen ikke afhænger af, at den gamle udbyder kan levere den.
Lagerklassen skifter under flytningen
Når et volumen gendannes i den nye klynge, skal det lande i en lagerklasse dér. Klasserne har andre navne og andre egenskaber: ydelse, størrelse, om de kan tage øjebliksbilleder, og om de er bundet til én zone. Lav en tabel med hver klasse i den gamle klynge og den klasse, den skal ende i hos den nye. Er ydelsen lavere, mærker databasen det først.
Bygger I klyngen på egne servere, kan lageret være distribueret på noderne selv. Longhorn er et eksempel på distribueret bloklager til Kubernetes, udgivet under Apache 2.0-licensen. Valget af lager i eget miljø står i Lagring i eget miljø.
Databaser i klyngen kræver konsistens
En backup af et volumen, mens en database skriver til det, kan give en kopi, der ikke kan startes. For databaser er der to veje: stop skrivningen kort, eller brug databasens egen backup eller replikering til at lave en konsistent kopi. Replikering mellem gammel og ny klynge giver den korteste nedetid, fordi omstillingen kan ske, når den nye kopi er i takt. Den kræver til gengæld, at netværket mellem de to steder er på plads i hele perioden.
Store datamængder tager tid at kopiere over nettet. Hvor længe, afhænger af forbindelsen og af, hvad den gamle udbyder tager for udgående data; prismodellen for udgående trafik står i Udgående data. Planlæg en første fuld kopi i god tid og en sidste, mindre kopi ved omstillingen.
Gendannelsen er prøven
Før gendannelsen er prøvet, ved I ikke, om backuppen virker. Prøv gendannelsen i en tom klynge, før flytningen begynder, og mål to ting: hvor lang tid den tager, og om applikationen virker bagefter med de data, den får. Det samme gælder efter flytningen, hvor backuppen nu skal virke i den nye klynge og til et nyt lager. Se Hvor hurtigt kommer data tilbage fra cloud?.
Hvad det kræver, og hvad det koster at lade være
For en klynge med få volumener og én database tager kortlægning, backupopsætning og en prøvegendannelse typisk fra en til to uger. Med mange databaser, store datamængder eller krav om meget kort nedetid skal I regne med flere uger og en periode med replikering, hvor begge miljøer kører. Posterne er arbejdstimer, objektlager til mellemlagring, udgående data hos den gamle udbyder og parallel drift.
Springes prøven over, er det første rigtige forsøg selve flytningen. Viser det sig dér, at en database ikke kan startes fra kopien, er det gamle miljø det eneste, I kan falde tilbage til, og flytningen må tages om.
Det skal I lade være med
- At tage backup af en kørende database som et almindeligt volumen · brug databasens egen metode til en konsistent kopi.
- At lægge backuppen hos den udbyder, I forlader · den skal kunne læses af den nye klynge.
- At flytte uden en prøvegendannelse · mål tiden, og start applikationen på kopien.
Det skal valget kunne vise
- ☐ En liste over volumener og databaser med størrelse og lagerklasse.
- ☐ En tabel over lagerklasser i den gamle og den nye klynge.
- ☐ Metoden til konsistent kopi for hver database.
- ☐ En prøvegendannelse med målt tid og en applikation, der virker.
Kilder
- Velero og Veleros licensfil, læst 8. november 2026.
- Longhorns licensfil, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav listen over volumener og databaser med størrelser i dag. Den viser, hvilken del af flytningen der tager længst tid.
Læs også: Store datamængder over til ny udbyder · Kubernetes på egne servere eller i colocation
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
