Introductie
Net als bij elke andere setup kan de data in een Kubernetes-cluster het risico lopen verloren te gaan. Om ernstige problemen te voorkomen, is het essentieel om een dataherstelplan bij de hand te hebben. Een eenvoudige en effectieve manier om dit te doen is door back-ups te maken, waardoor uw gegevens veilig zijn in geval van onverwachte gebeurtenissen. Back-ups kunnen eenmalig of gepland worden uitgevoerd. Het is een goed idee om geplande back-ups te hebben om ervoor te zorgen dat u een recente back-up heeft om gemakkelijk op terug te vallen.
Velero – een open-source tool ontworpen om back-up- en herstelbewerkingen voor Kubernetes-clusters te helpen. Het is ideaal voor het geval van rampenherstel, evenals voor het maken van snapshots van de toepassingsstatus voordat systeembewerkingen op uw cluster worden uitgevoerd, zoals upgrades. Voor meer details over dit onderwerp kunt u de officiële pagina Hoe Velero Werkt bezoeken.
In deze tutorial leert u hoe u Velero implementeert naar uw Kubernetes-cluster, back-ups maakt en herstelt van een back-up als er iets misgaat. U kunt uw hele cluster back-uppen of optioneel een namespace of labelselector kiezen om uw cluster te back-uppen.
Inhoudsopgave
- Vereisten
- Stap 1 – Velero installeren met behulp van Helm
- Stap 2 – Voorbeeld van Namespace Backup en Herstel
- Stap 3 – Voorbeeld van Backup en Herstel van hele cluster
- Stap 4 – Geplande Back-ups
- Stap 5 – Back-ups verwijderen
Vereisten
Om deze tutorial te voltooien, heb je het volgende nodig:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm voor het beheren van Velero-releases en upgrades.
- Doctl voor interactie met de DigitalOcean API.
- Kubectl voor interactie met Kubernetes.
- Velero-client om Velero-back-ups te beheren.
Stap 1 – Velero installeren met behulp van Helm
In deze stap zal je Velero en alle benodigde componenten implementeren, zodat het in staat zal zijn om back-ups te maken van de resources van je Kubernetes-cluster (inclusief PV’s). De back-upgegevens worden opgeslagen in de DO Spaces-bucket die eerder is aangemaakt in de Vereisten-sectie.
Eerst kloon je de Starter Kit Git-repository en verander je de directory naar je lokale kopie:
Vervolgens voeg je het Helm-repository toe en toon je de beschikbare charts:
De uitvoer ziet er vergelijkbaar uit met het volgende:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
De chart van interesse is vmware-tanzu/velero, die Velero op het cluster zal installeren. Bezoek alstublieft de pagina van het velero-chart voor meer details over deze chart.
Vervolgens open en inspecteer je het Velero Helm-waardenbestand dat wordt geleverd in de Starter Kit-repository met behulp van een editor naar keuze (bij voorkeur met YAML-lintondersteuning).
Vervolgens vervang je de <> placeholders dienovereenkomstig voor je DO Spaces Velero-bucket (zoals naam, regio en geheimen). Zorg ervoor dat je ook je DigitalOcean API-token verstrekt (DIGITALOCEAN_TOKEN sleutel).
Tenslotte, installeer Velero met behulp van helm:
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
Controleer nu je Velero-implementatie door het volgende uit te voeren:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
De uitvoer ziet er vergelijkbaar uit met het volgende (de STATUS-kolom moet deployed weergeven):
Controleer vervolgens of Velero actief is:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
De uitvoer ziet er vergelijkbaar uit met het volgende (implementatie-pods moeten in de Ready-status zijn):
Als je verder wilt kijken, kun je de server-side componenten van Velero bekijken:
- Verken de Velero CLI help-pagina’s om te zien welke opdrachten en subopdrachten beschikbaar zijn. Je kunt hulp krijgen voor elk door de
--help-vlag te gebruiken: - Lijst alle beschikbare opdrachten voor
Velero:
Lijst de opties voor de backup-opdracht voor Velero:
Velero maakt gebruik van verschillende CRD’s (Custom Resource Definitions) om zijn bronnen zoals back-ups, back-upschema’s, enz. voor te stellen. Je zult elk ontdekken in de volgende stappen van de tutorial, samen met enkele basisvoorbeelden.
Stap 2 – Voorbeeld van Namespace Back-up en Herstel
In deze stap leert u hoe u een eenmalige back-up uitvoert voor een volledige namespace vanuit uw DOKS-cluster en deze vervolgens herstelt, waarbij ervoor wordt gezorgd dat alle resources opnieuw worden aangemaakt. De betreffende namespace is ambassador.
Maak de back-up van de Ambassador Namespace
Eerst, initieer de back-up:
Vervolgens controleert u of de back-up is gemaakt:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
De uitvoer ziet er vergelijkbaar uit als:
Daarna, na een paar momenten, kunt u deze inspecteren:
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- De uitvoer ziet er vergelijkbaar uit als:
- Zoek naar de regel
Fase. Het zou moeten zeggenVoltooid. - Controleer ook of er geen fouten worden gemeld.
Een nieuw Kubernetes back-upobject is aangemaakt:
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
Tenslotte, bekijk de DO Spaces-bucket en controleer of er een nieuwe map genaamd backups is die de assets bevat die zijn gemaakt voor uw ambassador-backup:
Het verwijderen van de Ambassador Namespace en Resources
Eerst simuleer een ramp door opzettelijk de ambassador namespace te verwijderen:
Vervolgens controleer of de namespace is verwijderd (de lijst met namespaces moet geen ambassador afdrukken):
Tenslotte controleer of de echo en quote backend services endpoint DOWN zijn. Raadpleeg Het maken van de Ambassador Edge Stack Backend Services met betrekking tot de backend-applicaties die worden gebruikt in de Starter Kit-handleiding. U kunt curl gebruiken om te testen (of u kunt uw webbrowser gebruiken):
Het herstellen van de Ambassador Namespace Backup
Herstel de ambassador-backup:
Belangrijk: Wanneer u de ambassador namespace verwijdert, wordt de load balancer resource die is gekoppeld aan de ambassador service ook verwijderd. Dus, wanneer u de ambassador service herstelt, zal de load balancer opnieuw worden aangemaakt door DigitalOcean. Het probleem hier is dat u een NIEUW IP-adres krijgt voor uw load balancer, dus u moet de A-records aanpassen om verkeer te krijgen naar uw domeinen die zijn gehost op de cluster.
Het controleren van de Herstel van de Ambassador Namespace
Om de herstel van de ambassador namespace te verifiëren, controleert u de Phase-regel van de uitvoer van het ambassador-backup herstelcommando. Het zou Voltooid moeten zeggen (let ook op de Warnings-sectie – het vertelt of er iets fout is gegaan):
Vervolgens controleert u of alle resources zijn hersteld voor de ambassador namespace. Zoek naar de ambassador pods, services, en deployments.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
De uitvoer ziet er ongeveer als volgt uit:
Krijg ambassador hosts:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
De uitvoer ziet er ongeveer als volgt uit:
STATE zou Klaar moeten zijn en de HOSTNAME-kolom moet verwijzen naar de volledig gekwalificeerde hostnaam.
Krijg ambassador mappings:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
De uitvoer ziet er vergelijkbaar uit met (let op de echo-backend die is gekoppeld aan de host echo.starter-kit.online en de bronvoorvoegsel /echo/, hetzelfde geldt voor quote-backend):
Tenslotte, nadat u uw load balancer en DigitalOcean domeininstellingen opnieuw hebt geconfigureerd, controleer dan of de eindpunten van de echo en quote backend services UP zijn. Raadpleeg Het maken van de Ambassador Edge Stack Backend Services.
In de volgende stap zult u een ramp simuleren door uw DOKS-cluster opzettelijk te verwijderen.
Stap 3 – Voorbeeld van het maken van een back-up en het herstellen van het hele cluster
In deze stap zult u een scenario voor het herstellen na een ramp simuleren. Het hele DOKS-cluster zal worden verwijderd en vervolgens worden hersteld vanuit een eerdere back-up.
Het maken van een back-up van het DOKS-cluster
Maak eerst een back-up van het hele DOKS-cluster:
Volgende, controleer of de back-up is gemaakt en er geen fouten worden gemeld. Het volgende commando geeft een lijst van alle beschikbare back-ups:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
De uitvoer ziet er ongeveer zo uit:
Tenslotte, inspecteer de back-upstatus en logs (controleer of er geen fouten worden gemeld):
Belangrijk: Wanneer u een DOKS-cluster vernietigt zonder de --dangerous-vlag aan de doctl-opdracht op te geven en het vervolgens herstelt, wordt dezelfde load balancer met hetzelfde IP-adres opnieuw aangemaakt. Dit betekent dat u uw DigitalOcean DNS A-records niet hoeft bij te werken.
Maar wanneer de --dangerous-vlag wordt toegepast op de doctl-opdracht, zal de bestaande load balancer worden vernietigd en zal er een nieuwe load balancer met een nieuw extern IP-adres worden gemaakt wanneer Velero uw ingress-controller herstelt. Zorg er dus voor dat u uw DigitalOcean DNS A-records dienovereenkomstig bijwerkt.
Eerst, verwijder de volledige DOKS-cluster (zorg ervoor dat u de <>-placeholders vervangt).
Om het Kubernetes-cluster te verwijderen zonder de bijbehorende load balancer te vernietigen, voer het volgende uit:
Of om het Kubernetes-cluster samen met de bijbehorende load balancer te verwijderen:
Vervolgens, maak de cluster opnieuw aan, zoals beschreven in Stel DigitalOcean Kubernetes in. Het is belangrijk om ervoor te zorgen dat het aantal knooppunten van de nieuwe DOKS-cluster gelijk is aan of groter is dan het oorspronkelijke aantal.
Vervolgens installeer je de Velero CLI en Server, zoals beschreven in de Vereisten-sectie en Stap 1 – Velero installeren met behulp van Helm respectievelijk. Het is belangrijk om dezelfde Helm Chart-versie te gebruiken.
Tenslotte, herstel alles door het volgende commando uit te voeren:
Controleer de staat van DOKS Cluster-applicaties
Eerst, controleer de Fase-regel van de uitvoer van het commando beschrijf herstel all-cluster-backup. (Vervang de placeholders <> dienovereenkomstig). Het zou Voltooid moeten zeggen.
Controleer nu alle clusterresources door het volgende commando uit te voeren:
Nu zouden de backend-applicaties ook moeten reageren op HTTP-verzoeken. Raadpleeg Het maken van de Ambassador Edge Stack Backend-services met betrekking tot de backend-applicaties die worden gebruikt in de Starter Kit-zelfstudie.
In de volgende stap leer je hoe je geplande (of automatische) back-ups kunt uitvoeren voor je DOKS-clusterapplicaties.
Automatisch back-ups maken op basis van een schema is een zeer nuttige functie. Het stelt je in staat om terug te gaan in de tijd en het systeem te herstellen naar een vorig werkende staat als er iets misgaat.
Het maken van een geplande back-up is een zeer eenvoudig proces. Hieronder wordt een voorbeeld gegeven voor een interval van 1 minuut (het kube-system-namespace is gekozen).
Ten eerste, maak het schema aan:
schedule="*/1 * * * *"
Ook wordt het Linux-cronjob-formaat ondersteund:
Vervolgens, controleer of het schema is aangemaakt:
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
De uitvoer ziet er vergelijkbaar uit met:
Vervolgens, inspecteer alle back-ups na ongeveer een minuut:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
De uitvoer ziet er vergelijkbaar uit met:
Verifiëren van de status van de geplande back-up
Controleer eerst de regel Fase van een van de back-ups (vervang de <>-placeholders dienovereenkomstig). Het zou moeten zeggen Voltooid.
Het Herstellen van de Geplande Back-up
Om back-ups van een minuut geleden te herstellen, volg dezelfde stappen als die je hebt geleerd in de vorige stappen van deze tutorial. Dit is een goede manier om je tot nu toe opgebouwde ervaring te oefenen en te testen.
In de volgende stap leer je hoe je specifieke back-ups die je in de loop van de tijd hebt gemaakt, handmatig of automatisch kunt verwijderen.
Als je oudere back-ups niet nodig hebt, kun je wat middelen vrijmaken zowel op de Kubernetes-cluster als op de Velero DO Spaces-bucket.
Handmatig een Back-up Verwijderen
Kies eerst bijvoorbeeld een back-up van één minuut en geef het volgende commando uit (vervang alstublieft de plaatshouders <> dienovereenkomstig):
Nu, controleer dat het weg is uit de uitvoer van het velero backup get commando. Het zou ook verwijderd moeten zijn uit de DO Spaces bucket.
Vervolgens zul je meerdere back-ups tegelijk verwijderen door een selector te gebruiken. De velero backup delete subopdracht biedt een vlag genaamd --selector. Hiermee kun je meerdere back-ups tegelijk verwijderen op basis van Kubernetes-labels. Dezelfde regels gelden als voor Kubernetes Label Selectors.
Eerst, lijst de beschikbare back-ups op:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
De uitvoer ziet er vergelijkbaar uit met:
Vervolgens, zeg dat je alle backend-minute-backup-* assets wilt verwijderen. Kies een back-up uit de lijst en inspecteer de Labels:
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
De uitvoer ziet er vergelijkbaar uit (let op de waarde van het label velero.io/schedule-name):
Vervolgens kun je alle back-ups verwijderen die overeenkomen met de waarde backend-minute-backup van het label velero.io/schedule-name:
Tenslotte, controleer dat alle backend-minute-backup-* assets zijn verdwenen uit de uitvoer van het velero backup get commando, evenals uit de DO Spaces bucket.
Automatische Back-upverwijdering via TTL
- Wanneer u een back-up maakt, kunt u een TTL (Time To Live) specificeren door de
--ttlvlag te gebruiken. Als Velero ziet dat een bestaande back-upbron is verlopen, verwijdert het: - De
Backupbron - De back-up bestand van cloudobject
opslag - Alle
PersistentVolumesnapshots
Alle bijbehorende Herstelpunten
De TTL-vlag stelt de gebruiker in staat de back-upretentieperiode te specificeren met de opgegeven waarde in uren, minuten en seconden in de vorm van --ttl 24u0m0s. Als niet gespecificeerd, wordt een standaard TTL-waarde van 30 dagen toegepast.
Eerst maakt u de ambassador back-up, met een TTL-waarde van 3 minuten:
Vervolgens inspecteert u de ambassador back-up:
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
De uitvoer ziet er ongeveer zo uit (let op de Namespaces -> Inbegrepen sectie – deze moet ambassador weergeven, en het TTL veld is ingesteld op 3ms0):
Tenslotte, na ongeveer drie minuten, worden de back-up en bijbehorende bronnen automatisch verwijderd. U kunt controleren of het back-upobject is vernietigd met: velero backup beschrijving ambassador-backup-3min-ttl. Het zou moeten mislukken met een foutmelding waarin staat dat de back-up niet meer bestaat. De overeenkomstige ambassador-backup-3min-ttl map van de DO Spaces Velero-bucket wordt ook verwijderd.