Hop til hovedindhold

Velero (forhåndsvisning)

lionbackup er ved at blive et lagermål for Velero, backupværktøjet til Kubernetes. Til det findes et plugin, der registrerer lionbackup som BackupStorageLocation-udbyder, og en lille controller i klyngen, der uploader hver afsluttet backup som én krypteret fil til et lionbackup-projekt. Begge dele er tilgængelige som beta 0.2.0-beta.1: til at prøve i en testklynge, endnu ikke som din eneste backup.

Forhåndsvisning: endnu ingen volumendata

Det, der når frem til lionbackup, er spoolen: Kubernetes-manifester, metadata og logs for backuppen. Indholdet af volumener (PVC'er) sikkerhedskopieres endnu ikke; en PVC kommer tilbage som definition, men tom. Stol fortsat på en anden vej til volumendata.

Hvad forhåndsvisningen gør i dag, og hvad den ikke gør​

Virker i dagMangler stadig
Velero kører fuldt ud mod en spool i klyngen: backup og gendannelse af manifester, sync, GC, backup deleteVolumendata: PVC-indhold opsamles ikke (Veleros node-agent kender kun s3, azure, gcs og filsystem)
Signerede URL'er: velero backup logs og describe --details virker, backups ender CompletedGendannelsesimport: bundtet kommer tilbage i spoolen uden for klyngen (klient med læsetoken)
Upload: controlleren bundter backups/<navn>/ til én .lbk, uploader den med et skrivetoken og annoterer backuppen med file_idCapture- og gendannelsesjobs til volumener; gentagelse kun som "igen om 10 minutter"

En Failed backup betyder, at intet blev skrevet; som regel er ejeren af spool-mappen så forkert (se trin 1). PartiallyFailed optræder kun, når controlleren eller den delte URL-hemmelighed mangler (trin 4).

Prøv det​

Du skal bruge en testklynge, kubectl, Velero-CLI'en (testet med Velero 1.18.3), et lionbackup-projekt med et skrivetoken og lionbackup-klienten på din arbejdsstation til nøgleparret. Plugin-imaget kan hentes uden login.

1. Opret spool-mappen​

Velero skriver til en mappe på noden, som monteres i Velero-podden som hostPath (eller som PVC). Det officielle Velero-image kører som bruger-ID 1002; fsGroup gælder ikke for en hostPath, så mappen skal ejes af det ID. Ellers fejler hver backup med permission denied, men melder alligevel alle objekter som sikkerhedskopieret; fejlen står kun i status.failureReason.

mkdir -p /var/lib/lionbackup/spool
chown -R 1002:1002 /var/lib/lionbackup/spool
chmod 775 /var/lib/lionbackup/spool

2. Installér Velero med pluginet​

velero install \
--provider lionbackup.cloud/lionbackup \
--plugins git.prod.lionbackup.cloud/lionbackup/velero-plugin-lionbackup:0.2.0-beta.1 \
--bucket spool \
--no-secret \
--use-volume-snapshots=false \
--backup-location-config spoolPath=/var/lib/lionbackup/spool \
--wait

--no-secret er korrekt: selve pluginet har ikke brug for legitimationsoplysninger. Skrivetokenet hører hjemme i controllerens Secret (trin 4), aldrig på BackupStorageLocation.

3. Montér spoolen i Velero-podden​

kubectl -n velero patch deployment velero --type=json -p '[
{"op":"add","path":"/spec/template/spec/volumes/-","value":{"name":"lionbackup-spool","hostPath":{"path":"/var/lib/lionbackup/spool","type":"DirectoryOrCreate"}}},
{"op":"add","path":"/spec/template/spec/containers/0/volumeMounts/-","value":{"name":"lionbackup-spool","mountPath":"/var/lib/lionbackup/spool"}}
]'
kubectl -n velero rollout status deploy/velero --timeout=180s
kubectl -n velero get backupstoragelocation default

Uden dette trin lever spoolen i poddens filsystem og er væk efter næste genstart. BackupStorageLocation bør derefter melde Available.

4. Controller og Secret​

Controlleren kører i det samme image som bruger 1002, med spoolen monteret skrivebeskyttet og Secret'et under /etc/lionbackup. Den skal bruge tre ting: projektets skrivetoken, en tilfældig URL-hemmelighed, som den deler med Velero-podden, og den offentlige nøgle til krypteringen. Nøgleparret genererer du på din arbejdsstation; den private nøgle kommer aldrig ind i klyngen, og uden den er der ingen gendannelse.

lionbackup --generate-key --key-name ./velero
kubectl -n velero create secret generic lionbackup-velero \
--from-literal=token=<WRITE-TOKEN> \
--from-literal=url-secret="$(head -c 32 /dev/urandom | base64)" \
--from-file=key.pub=./velero.pub

Gem følgende manifest som controller.yaml. Det indeholder ServiceAccount, Role, RoleBinding, Service og Deployment; arbejdsmappen /work skal kunne rumme spoolens største backup-mappe.

---
apiVersion: v1
kind: ServiceAccount
metadata:
name: lionbackup-velero-controller
namespace: velero
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: lionbackup-velero-controller
namespace: velero
rules:
- apiGroups: ["velero.io"]
resources: ["backups"]
verbs: ["get", "list", "watch", "patch"]
- apiGroups: ["velero.io"]
resources: ["backupstoragelocations"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: lionbackup-velero-controller
namespace: velero
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: lionbackup-velero-controller
subjects:
- kind: ServiceAccount
name: lionbackup-velero-controller
namespace: velero
---
apiVersion: v1
kind: Service
metadata:
name: lionbackup-velero-controller
namespace: velero
spec:
selector:
app.kubernetes.io/name: lionbackup-velero-controller
ports:
- name: http
port: 8080
targetPort: http
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: lionbackup-velero-controller
namespace: velero
labels:
app.kubernetes.io/name: lionbackup-velero-controller
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: lionbackup-velero-controller
template:
metadata:
labels:
app.kubernetes.io/name: lionbackup-velero-controller
spec:
serviceAccountName: lionbackup-velero-controller
securityContext:
runAsUser: 1002
runAsGroup: 1002
runAsNonRoot: true
containers:
- name: controller
image: git.prod.lionbackup.cloud/lionbackup/velero-plugin-lionbackup:0.2.0-beta.1
command: ["/plugins/velero-plugin-lionbackup"]
args: ["controller"]
ports:
- name: http
containerPort: 8080
env:
- name: VELERO_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: LIONBACKUP_SPOOL_PATH
value: /var/lib/lionbackup/spool
- name: LIONBACKUP_KEYFILE
value: /etc/lionbackup/key.pub
- name: LIONBACKUP_WORKDIR
value: /work
- name: LIONBACKUP_TOKEN
valueFrom:
secretKeyRef:
name: lionbackup-velero
key: token
- name: LIONBACKUP_VELERO_URL_SECRET
valueFrom:
secretKeyRef:
name: lionbackup-velero
key: url-secret
readinessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 3
resources:
requests:
cpu: 50m
memory: 128Mi
limits:
cpu: "2"
memory: 1Gi
volumeMounts:
- name: lionbackup-spool
mountPath: /var/lib/lionbackup/spool
readOnly: true
- name: lionbackup-secret
mountPath: /etc/lionbackup
readOnly: true
- name: work
mountPath: /work
volumes:
- name: lionbackup-spool
hostPath:
path: /var/lib/lionbackup/spool
type: Directory
- name: lionbackup-secret
secret:
secretName: lionbackup-velero
items:
- key: key.pub
path: key.pub
- name: work
emptyDir:
sizeLimit: 10Gi

Anvend det derefter, giv også URL-hemmeligheden til Velero-deploymentet og sæt projekt og zone på BackupStorageLocation:

kubectl apply -f controller.yaml
kubectl -n velero set env deployment/velero \
LIONBACKUP_VELERO_URL_SECRET="$(kubectl -n velero get secret lionbackup-velero -o jsonpath='{.data.url-secret}' | base64 -d)"
kubectl -n velero patch backupstoragelocation default --type=merge -p \
'{"spec":{"config":{"lbProject":"<PROJECT-UUID>","lbZone":"de01-1","lbEnvironment":"prod"}}}'
kubectl -n velero rollout status deploy/velero --timeout=180s
kubectl -n velero rollout status deploy/lionbackup-velero-controller --timeout=180s

Uden token eller nøgle logger controlleren kun, hvad den ville uploade (observe-only). Flere config-nøgler på BackupStorageLocation: lbCompressionMethod (ZSTD), lbCompressionLevel (5), lbChunksizeMb (64), lbUploadRateLimitMbit (0 = ubegrænset).

De signerede URL'er peger på controller-Service'en inde i klyngen, så velero backup logs og describe --details virker der, hvor den Service kan nås. Kører Velero-CLI'en uden for klyngen, så videresend porten (kubectl -n velero port-forward svc/lionbackup-velero-controller 8080:8080) og sæt controllerURL på BackupStorageLocation til http://localhost:8080; signaturen dækker kun sti og udløb, ikke værten.

5. Backup​

velero backup create demo-1 --include-namespaces demo-app --wait
velero backup logs demo-1 | tail -n 3
kubectl -n velero get backup demo-1 \
-o jsonpath='{.status.phase} {.metadata.annotations.lionbackup\.cloud/file-id}{"\n"}'

Forvent Completed, og velero backup logs leverer loggen via controllerens signerede URL. Kort efter bærer Backup-objektet annotationen lionbackup.cloud/file-id: id'et på den uploadede fil i projektet, det samme som klientens --list viser. Fejler uploaden, står årsagen i controllerens log, og den prøver igen efter ti minutter.

6. Gendannelse fra lionbackup​

Vejen tilbage begynder uden for klyngen, med et læsetoken og den private nøgle; begge holdes på den måde væk fra klyngen. Klienten henter bundtet, du kopierer backup-mappen ind i målklyngens spool, og Velero samler den op ved næste sync af BackupStorageLocation:

lionbackup --config read.yaml --list
lionbackup --config read.yaml --restore <FILE-ID> --identity ./velero.key --target ./restored
# ./restored/…/backups/demo-1/ -> <spoolPath>/spool/backups/demo-1/ des Zielclusters
velero restore create demo-restore --from-backup demo-1 --wait

Manifester, deployments, ConfigMaps og PVC-definitioner kommer tilbage. Dataene i volumenerne gør ikke; det er forhåndsvisningens dokumenterede grænse.

Hvad der kommer​

Næste trin sikkerhedskopierer volumenindhold: et job pr. PVC på poddens node streamer volumenet som arkiv ind i spoolen, et tilsvarende gendannelsesjob fylder det tilbage, og en init-container holder applikationen, indtil volumenet er der igen. Dertil kommer et controller-endpoint, der henter et bundt via file_id direkte tilbage i spoolen. Indtil da gælder noten øverst på denne side.