Azuurblauwe AKS back-up met behulp van Velero

stemmen
28

Het viel me op dat Velero alleen een back-up kan maken van AKS-pvc's als die pvc's op schijf zijn en niet op azuurblauw. Om dit af te handelen heb ik geprobeerd om restic te gebruiken om een back-up te maken met fileshares zelf, maar ik geef me een vreemd logboek:

Dit is hoe mijn eigenlijke pod eruit ziet

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    backup.velero.io/backup-volumes: app-upload
    deployment.kubernetes.io/revision: 17

En het logboek van mijn back-up:

time=2020-05-20T02:01:09Z level=info msg=Adding pvc upload to additionalItems backup=velero/lbkomas-rocmondriaan-production-20200520020055 cmd=/velero logSource=pkg/backup/pod_action.go:67 pluginName=velero
time=2020-05-20T02:01:09Z level=info msg=Backing up item backup=velero/lbkomas-rocmondriaan-production-20200520020055 group=v1 logSource=pkg/backup/item_backupper.go:169 name=upload namespace=lbkompas-prod resource=persistentvolumeclaims
time=2020-05-20T02:01:09Z level=info msg=Executing custom action backup=velero/lbkomas-rocmondriaan-production-20200520020055 group=v1 logSource=pkg/backup/item_backupper.go:330 name=upload namespace=lbkompas-prod resource=persistentvolumeclaims
time=2020-05-20T02:01:20Z level=info msg=Skipping item because it's already been backed up. backup=velero/lbkomas-rocmondriaan-production-20200520020055 group=v1 logSource=pkg/backup/item_backupper.go:163 name=upload namespace=lbkompas-prod resource=persistentvolumeclaims

Zoals u kunt zien is er op de een of andere manier geen back-up gemaakt van het uploadvolume, omdat er staat dat het al in de back-up zit (waar het eigenlijk niet zit).

Mijn azurefilevolume bevat deze inhoud:

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {allowVolumeExpansion:true,apiVersion:storage.k8s.io/v1beta1,kind:StorageClass,metadata:{annotations:{},labels:{kubernetes.io/cluster-service:true},name:azurefile},parameters:{skuName:Standard_LRS},provisioner:kubernetes.io/azure-file}
  creationTimestamp: 2020-05-18T15:18:18Z
  labels:
    kubernetes.io/cluster-service: true
  name: azurefile
  resourceVersion: 1421202
  selfLink: /apis/storage.k8s.io/v1/storageclasses/azurefile
  uid: e3cc4e52-c647-412a-bfad-81ab6eb222b1
mountOptions:
- nouser_xattr
parameters:
  skuName: Standard_LRS
provisioner: kubernetes.io/azure-file
reclaimPolicy: Delete
volumeBindingMode: Immediate

Zoals u kunt zien heb ik de opslagklasse gepatcht om de nouser_xattrmount-optie vast te houden die eerder werd gesuggereerd

Als ik de Restic pod logs controleer zie ik de volgende info:

E0524 10:22:08.908190       1 reflector.go:156] github.com/vmware-tanzu/velero/pkg/generated/informers/externalversions/factory.go:117: Failed to list *v1.PodVolumeBackup: Get https://10.0.0.1:443/apis/velero.io/v1/namespaces/velero/podvolumebackups?limit=500&resourceVersion=1212830: dial tcp 10.0.0.1:443: i/o timeout
I0524 10:22:08.909577       1 trace.go:116] Trace[1946538740]: Reflector ListAndWatch name:github.com/vmware-tanzu/velero/pkg/generated/informers/externalversions/factory.go:117 (started: 2020-05-24 10:21:38.908988405 +0000 UTC m=+487217.942875118) (total time: 30.000554209s):
Trace[1946538740]: [30.000554209s] [30.000554209s] END

Best, Pim

De vraag is gesteld op 20/05/2020 om 16:21
bron van user
In andere talen...                            


1 antwoorden

stemmen
0

Heeft u uw StorageClass mountOptions-lijst uitgebreidnouser_xattr?

Deze eis is gedocumenteerd in GitHub nummer 1800.

Ook vermeld op de Restic Integration pagina (check onder de Azure sectie), waar ze dit snippet aanbieden om uw StorageClass bron te patchen:

kubectl patch storageclass/<YOUR_AZURE_FILE_STORAGE_CLASS_NAME> \
  --type json \
  --patch '[{"op":"add","path":"/mountOptions/-","value":"nouser_xattr"}]'

Als u geen bestaande mountOptionslijst heeft, kunt u het proberen:

kubectl patch storageclass azurefile \
  --type merge \
  --patch '{"mountOptions": ["nouser_xattr"]}'
antwoordde op 20/05/2020 om 21:52
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more