hemos definido nuestro YAML con
apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine name: mypod volumeMounts: - name: azure mountPath: /mnt/azure volumes: - name: azure azureFile: secretName: azure-secret shareName: aksshare readOnly: false y antes de la implementación, crearemos un secreto con el comando kubectl :
$AKS_PERS_STORAGE_ACCOUNT_NAME $STORAGE_KEY kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=$AKS_PERS_STORAGE_ACCOUNT_NAME \ --from-literal=azurestorageaccountkey=$STORAGE_KEYYa tenemos ese recurso compartido de archivos existente como recurso de Azure File Share y tenemos un archivo almacenado en él.
Estoy confundido si necesitamos administrar y definir también yamls para kind: PersistentVolume y kind: PersistentVolumeClaim
o el YAML anterior es completamente suficiente? ¿Se requieren PV y PVC solo si no tenemos nuestro recurso compartido de archivos ya creado en Azure? He leído los documentoshttps://kubernetes.io/docs/concepts/storage/persistent-volumes/ pero todavía me siento confundido cuando necesitan ser definidos y cuando está bien no usarlos en absoluto durante el proceso de implementación general. .
Tu Pod Yaml está bien.
Losvolúmenes persistentes de Kubernetes son una abstracción más reciente. Si, en cambio, su aplicación usa PersistentVolumeClaim , se desacopla del tipo de almacenamiento que usa (en su caso, Azure File Share) para que su aplicación pueda implementarse, por ejemplo, en AWS, Google Cloud o Minikube en su escritorio sin ningún cambio. Su clúster debe tener alguna compatibilidad con PersistentVolumes y esa parte se puede vincular a un sistema de almacenamiento específico.
Por lo tanto, para desvincular su aplicación yaml de una infraestructura específica, es mejor usar PersistentVolumeClaims .
No sé acerca de Azure File Share, pero hay buena documentación sobre cómo crear y usar dinámicamente un volumen persistente con Azure Files en Azure Kubernetes Service (AKS) .
Reclamación de volumen persistente
Su aplicación, por ejemplo, una Deployment o StatefulSet puede tener este recurso de PVC
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-azurefile spec: accessModes: - ReadWriteMany storageClassName: my-azurefile resources: requests: storage: 5Gi Luego, debe crear un recurso StorageClass que probablemente sea único para cada tipo de entorno, pero debe tener el mismo nombre y admitir los mismos modos de acceso . Si el entorno no es compatible con el aprovisionamiento dinámico de volúmenes, es posible que también deba crear manualmente el recurso PersistentVolume .
Ejemplos en diferentes entornos:
ReadWriteMany en AWS.Pod con reclamación de volumen persistente
Por lo general, implementa aplicaciones mediante Deployment o StatefulSet , pero la parte que declara la plantilla de pod es similar, excepto que probablemente desee usar volumeClaimTemplate en lugar de PersistentVolumeClaim para StatefulSet .
Vea el ejemplo completo en Crear un pod usando un PersistentVolumeClaim
apiVersion: v1 kind: Pod metadata: name: task-pv-pod spec: volumes: - name: file-share persistentVolumeClaim: claimName: my-azurefile # this must match your name of PVC containers: - name: task-pv-container image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/usr/share/nginx/html" name: file-share