Я заметил, что Velero может создавать резервные копии AKS PVC только в том случае, если эти PVC являются дисковыми, а не Azure файлообменниками. Чтобы справиться с этим, я попытался использовать restic для резервного копирования с помощью filehares, но у меня появился странный журнал:
Вот как выглядит мой настоящий стручок
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
backup.velero.io/backup-volumes: app-upload
deployment.kubernetes.io/revision: 17
и журнал моей резервной копии:
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
Как вы видите, он каким-то образом не создал резервную копию upload
тома, так как говорит, что он уже находится в резервной копии (где на самом деле его нет).
В моем azurefile
томе хранится это содержимое:
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
Как вы видите, я на самом деле исправил класс хранилища, чтобы удерживать опцию nouser_xattr
монтирования, которая была предложена ранее
Когда я проверяю журналы Restic pod, я вижу следующую информацию:
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
Лучшая, Pim