Configuración de volúmenes perimetrales de ingesta en la nube
En este artículo se describe la configuración de volúmenes perimetrales de ingesta en la nube (carga de blobs con purga local).
¿Qué son los volúmenes perimetrales de ingesta en la nube?
Los volúmenes perimetrales de ingesta en la nube facilitan la ingesta ilimitada de datos desde el perímetro al blob, incluido ADLSgen2. Los archivos escritos en este tipo de almacenamiento se transfieren sin problemas al almacenamiento de blobs y, una vez confirmada la carga, se purgan luego localmente. Esta eliminación garantiza la disponibilidad del espacio para los nuevos datos. Además, esta opción de almacenamiento admite la integridad de los datos en entornos desconectados, lo que permite el almacenamiento local y la sincronización tras la reconexión a la red.
Por ejemplo, puede escribir un archivo en la PVC de ingesta en la nube y un proceso ejecuta un examen para comprobar si hay nuevos archivos cada minuto. Una vez identificado, el archivo se envía para cargarlo en el destino de blob designado. Tras la confirmación de una carga correcta, el volumen perimetral de ingesta en la nube espera cinco minutos y, a continuación, elimina la versión local del archivo.
Requisitos previos
Cree una cuenta de almacenamiento siguiendo las instrucciones que se indican aquí.
Nota:
Al crear la cuenta de almacenamiento, se recomienda crearla en el mismo grupo de recursos y región o ubicación que el clúster de Kubernetes.
Cree un contenedor en la cuenta de almacenamiento que ha creado previamente siguiendo las instrucciones que se indican aquí.
Configuración de la identidad de extensión
Los volúmenes perimetrales permiten el uso de una identidad de extensión asignada por el sistema para el acceso al almacenamiento de blobs. En esta sección se describe cómo usar la identidad de extensión asignada por el sistema para conceder acceso a la cuenta de almacenamiento, lo que le permite cargar volúmenes de ingesta en la nube en estos sistemas de almacenamiento.
Se recomienda usar la identidad de extensión. Si el destino final es Blob Storage o ADLSgen2, consulte las instrucciones siguientes. Si el destino final es OneLake, siga las instrucciones de Configuración de OneLake para la identidad de extensión.
Aunque no se recomienda, si prefiere usar la autenticación basada en claves, siga las instrucciones en Autenticación basada en claves.
Obtención de la identidad de extensión
Azure Portal
- Vaya al clúster conectado a Arc.
- Seleccione Extensiones.
- Seleccione la extensión de Azure Container Storage habilitado por Azure Arc
- Anote el identificador de entidad de seguridad en Detalles de la extensión de clúster.
Configuración de la cuenta de Blob Storage para la identidad de extensión
Agregar permisos de identidad de extensión a una cuenta de almacenamiento
- Vaya a la cuenta de almacenamiento en Azure Portal.
- Seleccione Control de acceso (IAM).
- Seleccione Agregar+ -> Agregar asignación de roles.
- Seleccione Propietario de datos de blobs de almacenamiento y, a continuación, seleccione Siguiente.
- Elija + Seleccionar miembros.
- Para agregar el identificador de entidad de seguridad a la lista de Miembros seleccionados:, pegue el identificador y seleccione + junto a la identidad.
- Haga clic en Seleccionar.
- Para revisar y asignar permisos, seleccione Siguiente y, a continuación, seleccione Revisar y asignar.
Creación de una notificación de volumen persistente de ingesta en la nube (PVC)
Cree un nuevo archivo denominado
cloudIngestPVC.yaml
con el contenido siguiente. Edite la líneametadata.name
y cree un nombre para la notificación de volumen persistente. Se hace referencia a este nombre en la última línea dedeploymentExample.yaml
en el paso siguiente. Además, actualice el valormetadata.namespace
con el pod de consumo previsto. Si no tiene un pod de consumo previsto, el valormetadata.namespace
esdefault
. El parámetrospec.resources.requests.storage
determina el tamaño del volumen persistente. En este ejemplo es de 2 GB, pero se puede modificar para adaptarlo a las necesidades:Nota:
Use solo letras minúsculas y guiones. Para más información, consulte la documentación de nomenclatura de objetos de Kubernetes.
kind: PersistentVolumeClaim apiVersion: v1 metadata: ### Create a name for your PVC ### name: <create-persistent-volume-claim-name-here> ### Use a namespace that matched your intended consuming pod, or "default" ### namespace: <intended-consuming-pod-or-default-here> spec: accessModes: - ReadWriteMany resources: requests: storage: 2Gi storageClassName: cloud-backed-sc
Para aplicar
cloudIngestPVC.yaml
, ejecute:kubectl apply -f "cloudIngestPVC.yaml"
Adjuntar subvolumen al volumen perimetral
Para crear un subvolumen mediante la identidad de extensión para conectarse al contenedor de la cuenta de almacenamiento, use el siguiente proceso:
Obtenga el nombre del volumen de ingesta perimetral con este comando:
kubectl get edgevolumes
Cree un archivo llamado
edgeSubvolume.yaml
y copie el contenido siguiente. Estas variables deben actualizarse con su información:Nota:
Use solo letras minúsculas y guiones. Para más información, consulte la documentación de nomenclatura de objetos de Kubernetes.
metadata.name
: cree un nombre para el subvolumen.spec.edgevolume
: este nombre se recuperó del paso anterior mediantekubectl get edgevolumes
.spec.path
: cree su propio nombre de subdirectorio en la ruta de acceso de montaje. El siguiente ejemplo ya contiene un nombre de ejemplo (exampleSubDir
). Si cambia este nombre de ruta de acceso, la línea 33 dedeploymentExample.yaml
debe actualizarse con el nuevo nombre de ruta de acceso. Si decide cambiar el nombre de la ruta de acceso, no use una barra diagonal precedente.spec.container
: el nombre del contenedor en la cuenta de almacenamiento.spec.storageaccountendpoint
: vaya a la cuenta de almacenamiento en Azure Portal. En la página Información general, cerca de la parte superior derecha de la pantalla, seleccione Vista JSON. Puede encontrar el vínculostorageaccountendpoint
en properties::primaryEndpoints::blob. Copie todo el vínculo (por ejemplo,https://mytest.blob.core.windows.net/
).
apiVersion: "arccontainerstorage.azure.net/v1" kind: EdgeSubvolume metadata: name: <create-a-subvolume-name-here> spec: edgevolume: <your-edge-volume-name-here> path: exampleSubDir # If you change this path, line 33 in deploymentExample.yaml must be updated. Don't use a preceding slash. auth: authType: MANAGED_IDENTITY storageaccountendpoint: "https://<STORAGE ACCOUNT NAME>.blob.core.windows.net/" container: <your-blob-storage-account-container-name> ingestPolicy: edgeingestpolicy-default # Optional: See the following instructions if you want to update the ingestPolicy with your own configuration
Para aplicar
edgeSubvolume.yaml
, ejecute:kubectl apply -f "edgeSubvolume.yaml"
Opcional: modifique ingestPolicy
a partir del valor predeterminado
Si desea cambiar
ingestPolicy
del valor predeterminadoedgeingestpolicy-default
, cree un archivo denominadomyedgeingest-policy.yaml
con el siguiente contenido. Las siguientes variables deben actualizarse con sus preferencias:Nota:
Use solo letras minúsculas y guiones. Para más información, consulte la documentación de nomenclatura de objetos de Kubernetes.
metadata.name
: cree un nombre para ingestPolicy. Este nombre debe actualizarse y hacer referencia a este en la secciónspec.ingestPolicy
deedgeSubvolume.yaml
.spec.ingest.order
: el orden en el que se cargan los archivos con modificaciones. Este es el mejor esfuerzo, no una garantía (el valor predeterminado es primero el más antiguo). Las opciones para el orden son: primero el más antiguo o primero el más reciente.spec.ingest.minDelaySec
: el número mínimo de segundos antes de que un archivo con modificaciones sea apto para la ingesta (el valor predeterminado es 60). Este número puede oscilar entre 0 y 31 536 000.spec.eviction.order
: cómo se expulsan los archivos (el valor predeterminado es desordenado). Las opciones para el orden de expulsión son: desordenado o nunca.spec.eviction.minDelaySec
: el número de segundos antes de que un archivo limpio sea apto para la expulsión (el valor predeterminado es 300). Este número puede oscilar entre 0 y 31 536 000.
apiVersion: arccontainerstorage.azure.net/v1 kind: EdgeIngestPolicy metadata: name: <create-a-policy-name-here> # This must be updated and referenced in the spec.ingestPolicy section of the edgeSubvolume.yaml spec: ingest: order: <your-ingest-order> minDelaySec: <your-min-delay-sec> eviction: order: <your-eviction-order> minDelaySec: <your-min-delay-sec>
Para obtener más información sobre estas especificaciones, consulte Establecer directiva de ingesta.
Para aplicar
myedgeingest-policy.yaml
, ejecute:kubectl apply -f "myedgeingest-policy.yaml"
Asociación de la aplicación (aplicación nativa de Kubernetes)
Para configurar un único pod genérico (aplicación nativa de Kubernetes) en la notificación de volumen persistente (PVC), cree un archivo denominado
deploymentExample.yaml
con el siguiente contenido. Modifique los valorescontainers.name
yvolumes.persistentVolumeClaim.claimName
. Si ha actualizado el nombre de la ruta de acceso deedgeSubvolume.yaml
,exampleSubDir
en la línea 33 debe actualizarse con el nuevo nombre de ruta de acceso. El parámetrospec.replicas
determina el número de pods de réplica que se van a crear. En este ejemplo son 2, pero se puede modificar para adaptarlo a las necesidades:Nota:
Use solo letras minúsculas y guiones. Para más información, consulte la documentación de nomenclatura de objetos de Kubernetes.
apiVersion: apps/v1 kind: Deployment metadata: name: cloudingestedgevol-deployment ### This must be unique for each deployment you choose to create. spec: replicas: 2 selector: matchLabels: name: wyvern-testclientdeployment template: metadata: name: wyvern-testclientdeployment labels: name: wyvern-testclientdeployment spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - wyvern-testclientdeployment topologyKey: kubernetes.io/hostname containers: ### Specify the container in which to launch the busy box. ### - name: <create-a-container-name-here> image: mcr.microsoft.com/azure-cli:2.57.0@sha256:c7c8a97f2dec87539983f9ded34cd40397986dcbed23ddbb5964a18edae9cd09 command: - "/bin/sh" - "-c" - "dd if=/dev/urandom of=/data/exampleSubDir/acsaingesttestfile count=16 bs=1M && while true; do ls /data &>/dev/null || break; sleep 1; done" volumeMounts: ### This name must match the volumes.name attribute below ### - name: wyvern-volume ### This mountPath is where the PVC is attached to the pod's filesystem ### mountPath: "/data" volumes: ### User-defined 'name' that's used to link the volumeMounts. This name must match volumeMounts.name as previously specified. ### - name: wyvern-volume persistentVolumeClaim: ### This claimName must refer to your PVC metadata.name (Line 5) claimName: <your-pvc-metadata-name-from-line-5-of-pvc-yaml>
Para aplicar
deploymentExample.yaml
, ejecute:kubectl apply -f "deploymentExample.yaml"
Use
kubectl get pods
para buscar el nombre del pod. Copie este nombre para usarlo en el paso siguiente.Nota:
Dado que
spec.replicas
dedeploymentExample.yaml
se especificó como2
, aparecen dos pods mediantekubectl get pods
. Puede elegir cualquiera de los nombres de pod para usar en el paso siguiente.Ejecute el siguiente comando y reemplace
POD_NAME_HERE
por el valor copiado del último paso:kubectl exec -it POD_NAME_HERE -- sh
Cambie los directorios a la
/data
ruta de acceso de montaje tal como se especifica en eldeploymentExample.yaml
.Debería ver un directorio con el nombre que especificó como
path
en el Paso 2 de la sección Adjuntar subvolumen a un volumen perimetral. Cambie los directorios a/YOUR_PATH_NAME_HERE
, reemplazando el valorYOUR_PATH_NAME_HERE
por sus detalles.Por ejemplo, cree un archivo denominado
file1.txt
y escriba en él medianteecho "Hello World" > file1.txt
.En Azure Portal, vaya a la cuenta de almacenamiento y busque el contenedor especificado en el paso 2 de Adjuntar subvolumen a un volumen perimetral. Al seleccionar el contenedor, debería ver
file1.txt
rellenado dentro del contenedor. Si el archivo no ha aparecido aún, espere aproximadamente 1 minuto; los volúmenes perimetrales esperan un minuto antes de cargarse.
Pasos siguientes
Después de completar estos pasos, puede comenzar a supervisar la implementación mediante Azure Monitor y la supervisión de Kubernetes o la supervisión de terceros con Prometheus y Grafana.