Kopia zapasowa Azure AKS przy użyciu Velero

głosy
50

Zauważyłem, że Velero może tworzyć kopie zapasowe AKS PVC tylko wtedy, gdy te PVC są dyskowe, a nie lazurowe. Aby sobie z tym poradzić, próbowałem użyć resticu do tworzenia kopii zapasowych przez same współdzielenie plików, ale daję mi dziwny dziennik:

Tak wygląda mój prawdziwy strąk

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

I dziennik mojej kopii zapasowej:

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

Jak widać, w jakiś sposób nie wykonał on kopii zapasowej uploadwolumenu, ponieważ mówi, że jest on już w kopii zapasowej (gdzie tak naprawdę nie jest).

Mój azurefilewolumin przechowuje tę zawartość:

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

Jak widzisz, naprawiłem klasę pamięci masowej, aby utrzymać opcję nouser_xattrmontowania, która została zasugerowana wcześniej

Kiedy sprawdzam logi podręczne, widzę następujące informacje:

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

Najlepsze, Pim

Utwórz 20/05/2020 o 16:21
źródło użytkownik
W innych językach...                            


1 odpowiedzi

głosy
0

Czy dodałeś nouser_xattrdo swojej listy StorageClass mountOptions?

Wymóg ten jest udokumentowany w wydaniu GitHub 1800.

Wspomniano również o tym na stronie integracji restic (sprawdź w sekcji Azure), gdzie podano ten fragment do łatania zasobów StorageClass:

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

Jeśli nie masz istniejącej mountOptionslisty, możesz spróbować:

kubectl patch storageclass azurefile \
  --type merge \
  --patch '{"mountOptions": ["nouser_xattr"]}'
Odpowiedział 20/05/2020 o 21:52
źródło użytkownik

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