Az Azure AKS biztonsági másolat Velero használatával

szavazat
28

Észrevettem, hogy a Velero csak az AKS PVC-kről tud biztonsági másolatot készíteni, ha ezek a PVC lemezek, és nem az Azure fájlmegosztók. Ennek kezelésére megkíséreltem magam a fájlmegosztó fájlok biztonsági mentését, de furcsa naplót adok nekem:

Így néz ki a valódi hüvelyem

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

És a biztonsági mentésem naplója:

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

Mint valahogy láthatja, nem mentte a fájlt upload kötet, mivel azt mondja, hogy már van a biztonsági másolatban (ahol valójában nincs).

Az én azurefile a kötet tartalmazza ezeket a tartalmakat:

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

Mint láthatja, valójában javítottam a tárolási osztályt a nouser_xattr felszerelési opció, amelyet korábban javasoltak

Amikor megvizsgálom a Restic pod naplókat, a következő információt látom:

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

A legjobb, Pim

A kérdést 20/05/2020 16:21
a forrás felhasználó
Más nyelveken...                            


1 válasz

szavazat
0

Hozzátette? nouser_xattr a StorageClass mountOptions listájához?

Ezt a követelményt a GitHub 1800 kiadás dokumentálja.

Ugyancsak megemlítik a resztikus integrációs oldalon (ellenőrizze az Azure szakasz alatt), ahol a következő kivonatot nyújtják a StorageClass erőforrás javításához:

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

Ha még nem létezik mountOptions listán kipróbálhatja:

kubectl patch storageclass azurefile \
  --type merge \
  --patch '{"mountOptions": ["nouser_xattr"]}'
Válaszolt 20/05/2020 21:52
a forrás felhasználó

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