Container Service for Kubernetes:Prefill OSS data on demand to high-performance volumes

Implementación de la función

Esta función utiliza Volume Populators de Kubernetes, gestionados por storage-operator de ACK. Cuando crea un PVC que hace referencia al recurso personalizado OSSVolumePopulator (OSSVP), storage-operator intercepta la solicitud y pobla los datos.

El modo de poblado depende del tipo de volumen de destino:

Modo	Tipos de almacenamiento compatibles	Descripción
bmcpfs-dataflow Modo de flujo de datos nativo	CPFS for Lingjun	storage-operator aprovecha el flujo de datos nativo de CPFS para poblar los datos. Este modo no consume recursos de cómputo del clúster y ofrece mayor eficiencia.
generic Modo de poblado genérico mediante pod	Otros tipos de almacenamiento, como discos en la nube o CPFS general-purpose edition	storage-operator crea un pod temporal en el namespace ack-volume-populator para montar el nuevo volumen y descargar los datos especificados de OSS. El pod se elimina una vez completado el poblado. Este modo consume recursos de cómputo del clúster.

Una vez completado el poblado correctamente, el estado del PVC cambia de Pending a Bound. Los pods de la aplicación pueden entonces montar el PVC y acceder a los datos precargados.

Escenarios típicos

Esta función admite dos casos de uso principales.

Flujo de trabajo

Los pasos principales de VolumePopulator son similares en ambos modos.

Habilite el Feature Gate VolumePopulator en storage-operator. Al habilitar VolumePopulator, se crea de forma predeterminada el namespace ack-volume-populator para alojar PVCs y pods temporales durante la precarga de datos. Otorgue permisos de acceso a OSS para la tarea de poblado. El modo bmcpfs-dataflow requiere etiquetas específicas en el bucket de OSS. El modo generic requiere configuración de RRSA o AccessKey. Cree un objeto OSSVolumePopulator donde especifique la ruta del bucket de OSS y el modo de poblado. Cree un PVC, especifique una StorageClass y haga referencia al OSSVP mediante dataSourceRef para iniciar la precarga de datos (el momento depende del parámetro volumeBindingMode de la StorageClass). Una vez que el PVC esté en estado Bound, cree las cargas de trabajo (pods, deployments, etc.) que lo montarán para acceder a los datos a alta velocidad. La precarga de datos se realiza una sola vez durante la creación del volumen. Los cambios posteriores en los datos de origen de OSS no se sincronizan con el volumen creado. Al finalizar la tarea, elimine el PVC. Si el parámetro reclaimPolicy de la StorageClass es Delete, el almacenamiento de alto rendimiento asociado (como FileSets de CPFS o discos en la nube) se elimina automáticamente y se detiene la facturación. Los datos de origen en OSS no se ven afectados.

Escenario 1: Precarga de datos en volúmenes compartidos de CPFS for Lingjun

Para entrenamiento de modelos e inference de solo lectura y alto throughput, utilice el flujo de datos de CPFS for Lingjun para precargar modelos desde OSS bajo demanda. Esto permite que múltiples tareas de GPU lean los datos a alta velocidad.

apiVersion: storage.alibabacloud.com/v1beta1
kind: OSSVolumePopulator
metadata:
  name: qwen3-32b
  # Must be in the same namespace as the application and PVC
  namespace: bmcpfs-dataflow-demo 
spec:
  bucket: <your-bucket-name>
  region: cn-hangzhou
  endpoint: oss-cn-hangzhou-internal.aliyuncs.com
  path: /Qwen3-32B/
  # Dedicated for CPFS for Lingjun volumes, leveraging its data flow capability
  mode: bmcpfs-dataflow
  
  # Optional advanced configurations for bmcpfs-dataflow mode
  # This example recommends default settings. Ignore if no special requirements.
  # bmcpfsDataflow:
    # Maximum data flow throughput (MB/s). Options: 600, 1200, 1500. Default: 600
    # throughput: 1200
    # Enable encrypted transfer. Default: empty (disabled)
    # sourceSecurityType: SSL
    # Data prefill mode. Default: metadataAndData for full prefill.
    # Set to metadata for metadata-only prefill.
    # dataType: metadataAndData

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: bmcpfs-dataflow-demo
parameters:
  bmcpfsId: bmcpfs-29000z8xz3xxxxxxxxxxx
  vpcMountTarget: cpfs-29000z8xz3xxxxxxxxxxx-vpc-xxxxxx.cn-wulanchabu.cpfs.aliyuncs.com
  mountpointAutoSwitch: "true"
provisioner: bmcpfsplugin.csi.alibabacloud.com
# Critical: Ensure CPFS FileSet and data are automatically cleaned up after PVC deletion
reclaimPolicy: Delete
# Recommended: Set to Immediate to start data prefill immediately after PVC creation
volumeBindingMode: Immediate

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: qwen3-32b
  namespace: bmcpfs-dataflow-demo
spec:
  accessModes:
    - ReadOnlyMany
  dataSourceRef:
    apiGroup: storage.alibabacloud.com
    kind: OSSVolumePopulator
    # Reference the OSSVP name created above
    name: qwen3-32b
  resources:
    requests:
      # Must be at least the size of the OSS data source referenced by OSSVP
      storage: 80Gi
  storageClassName: bmcpfs-dataflow-demo
  volumeMode: Filesystem

kubectl -n bmcpfs-dataflow-demo describe ossvp qwen3-32b

5. Crear la carga de trabajo y utilizar los datos

Una vez que el PVC esté en estado Bound, cree una carga de trabajo que lo monte.

Este ejemplo utiliza recursos de GPU. Solo para fines de verificación, cree un pod de CPU y utilice kubectl exec para inspeccionar los datos.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: demo-apply-qwen3-32b
  namespace: bmcpfs-dataflow-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-apply-qwen3-32b
  template:
    metadata:
      labels:
        app: demo-apply-qwen3-32b
      # Use ACS HPN instance type to mount CPFS volume
      # alibabacloud.com/compute-class: "gpu-hpn"
    spec:
      # Use ACS HPN instance type to mount CPFS volume
      # nodeSelector: 
      #   alibabacloud.com/node-type: reserved
      # tolerations:
      # - key: "virtual-kubelet.io/provider" 
      #   operator: "Exists"
      #   effect: "NoSchedule"
      volumes:
        - name: model-storage
          persistentVolumeClaim:
            # Specify the created PVC
            claimName: qwen3-32b
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
      containers:
        - command: ["sh", "-c", "python3 -m sglang.launch_server --model-path /models/Qwen3-32B --tp 2"]
          image: registry.cn-beijing.aliyuncs.com/tool-sys/ossfs-public:demo-env-python3.12.7-sglang0.5.5
          name: sglang
          ports:
            - containerPort: 8000
              name: http
          resources:
            limits:
              nvidia.com/gpu: "2"
            requests:
              nvidia.com/gpu: "2"
          volumeMounts:
            - mountPath: /models/Qwen3-32B
              name: model-storage
            - mountPath: /dev/shm
              name: dshm

Guía de limpieza de recursos

Una vez finalizadas las tareas de entrenamiento de IA o inference, libere los volúmenes compartidos de CPFS for Lingjun y las cargas de trabajo asociadas.

Recursos por liberar:

• Cargas de trabajo que utilizan el volumen compartido (en este ejemplo, un StatefulSet)

• PVC utilizado para la precarga de datos

• Recursos de almacenamiento backend (FileSet de CPFS for Lingjun) creados automáticamente por el PVC

Pasos de limpieza:

1. Eliminar la carga de trabajo

   Elimine el StatefulSet que usa el volumen para liberar el PVC.

   kubectl delete statefulset demo-apply-qwen3-32b -n bmcpfs-dataflow-demo

2. Eliminar el PVC

   Si la StorageClass tiene configurado reclaimPolicy: Delete, al eliminar el PVC también se elimina el FileSet de CPFS en el backend, se libera el almacenamiento y se detiene la facturación.

   kubectl delete pvc qwen3-32b -n bmcpfs-dataflow-demo

3. Verificar la limpieza de recursos:

   • En la consola de NAS, elija File System > File System List y confirme que el FileSet correspondiente a este PVC se haya eliminado y que la capacidad utilizada haya disminuido.

   • Los datos de origen en OSS no se ven afectados. En la consola de OSS, confirme que el conjunto de datos permanece intacto.

Requisitos previos

• Habilite VolumePopulatorPodHandler en storage-operator.

  Al habilitarlo, el sistema otorga los permisos RBAC necesarios a los componentes relacionados y a los pods temporales. Evalúe los riesgos de seguridad antes de proceder.

  Permisos RBAC configurados automáticamente

  • Otorga permisos de operación de pods a storage-operator en el namespace ack-volume-populator

    - apiGroups: [""]
      resources: [pods]
      verbs: [get, list, watch, create, delete]

  • Otorga permisos de acceso a nivel de clúster a los pods temporales de tareas

    - apiGroups: [""]
      resources: [events]
      verbs: [create, patch, get, list]
    - apiGroups: [volumepopulators.storage.alibabacloud.com]
      resources: [ossvolumepopulators]
      verbs: [get, list, watch]

• Argo Workflows está instalado.

  Pasos detallados

  1. Inicie sesión en ACK console. En el panel de navegación izquierdo, haga clic en Clusters.

  2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, elija Operations > Add-ons.

  3. En la página Add-ons, busque Argo Workflows e instálelo siguiendo las indicaciones.

• Este ejemplo utiliza cómputo serverless (ECI) para las tareas de precarga de datos y los flujos de trabajo. Instale ack-virtual-node add-on. Para verificaciones sin serverless, elimine alibabacloud.com/eci: "true" de los recursos.

1. Autorizar tareas de precarga de datos para acceder a OSS

En el modo generic, las tareas de precarga de datos se ejecutan como pods temporales en el namespace ack-volume-populator. Otorgue a estos pods acceso al bucket de OSS que contiene los datos de origen.

• RRSA method: Asigna dinámicamente roles de RAM temporales con rotación automática a los pods, lo que permite un aislamiento detallado de permisos y mayor seguridad.

• AccessKey method: Almacena credenciales estáticas de larga duración en un Secret. Es sencillo de configurar, pero menos seguro.

2. Crear OSSVolumePopulator (OSSVP)

Cree un recurso OSSVolumePopulator en el mismo namespace que su aplicación y PVC. Establezca mode en generic y configure la autorización.

apiVersion: storage.alibabacloud.com/v1beta1
kind: OSSVolumePopulator
metadata:
  name: generic-demo
  # Must be in the same namespace as the application and PVC
  namespace: argo 
spec:
  bucket: my-test-bucket
  region: cn-hangzhou
  endpoint: oss-cn-hangzhou-internal.aliyuncs.com
  path: /many-files/
  # Generic mode for any backend storage volume
  mode: generic
  generic:
    # Add labels to data population task pods for scheduling to ECI pods
    labels:
      alibabacloud.com/eci: "true"
    # Add annotations to data population task pods for configuring ECI specs
    annotations:
      k8s.aliyun.com/eci-use-specs: "2-4Gi"
    # Choose either secretRef or rrsaConfigs
    # secretRef: oss-secret
    rrsaConfigs:
      # ARN of the RAM role used for RRSA authorization
      roleArn: "acs:ram::1234567*****:role/oss-populator"
      # ARN of the cluster's OIDC Provider
      oidcProviderArn: "acs:ram::1234567*****:oidc-provider/my-oidc-provider"
    # Configure affinity for data population task pods to schedule to specific nodes
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: "disktype"
                  operator: NotIn
                  values:
                    - "hdd"
    # Configure tolerations for data population task pods
    tolerations:
      - key: "virtual-kubelet.io/provider"
        operator: Equal
        value: "alibabacloud"
        effect: NoSchedule
    # Maximum throughput (MB/s)
    # throughput: 1000

Parámetros:

3. Preparar StorageClass

Este escenario requiere una StorageClass para aprovisionar discos en la nube dinámicamente. ACK proporciona una default StorageClass y admite manually creating a StorageClass.

• Este ejemplo utiliza alicloud-disk-essd con reclaimPolicy establecido en Delete y volumeBindingMode en Immediate, adecuado para cómputo serverless sin conciencia de zona.

• Para flujos de trabajo que no son serverless, utilice una StorageClass con volumeBindingMode establecido en WaitForFirstConsumer (como alicloud-disk-topology-alltype) para garantizar que los discos en la nube y los pods de la aplicación se creen en la misma zona.

4. Crear Argo Workflow

Este ejemplo de Workflow utiliza un volumeClaimTemplate ephemeral para crear un disco en la nube independiente con datos precargados para cada tarea paralela.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: parallel-data-process-with-ossvp-
  namespace: argo
spec:
  # Define input parameters
  arguments:
    parameters:
      - name: number
        value: 2

  entrypoint: main
  # Define volume claim template for each concurrent replica in the Workflow
  volumes:
    - name: scratch-volume
      # Declare as ephemeral volume, automatically deleted after Workflow completion
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              diskType: scratch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            # For non-serverless compute, replace with alicloud-disk-topology-alltype
            storageClassName: "alicloud-disk-essd"
            resources:
              requests:
                # Must be at least the size of the OSS data source referenced by OSSVP
                storage: 20Gi
            # Reference OSSVP as data source
            dataSourceRef:
              apiGroup: storage.alibabacloud.com
              kind: OSSVolumePopulator
              name: generic-demo

  templates:
    - name: main
      dag:
        tasks:
          # Execute multiple echo tasks in parallel
          - name: echo-task
            template: echo-template
            arguments:
              parameters:
                - name: index
                  value: "{{item}}"
            withSequence:
              count: "{{workflow.parameters.number}}"

    - name: echo-template
      metadata:
        labels:
          # Run tasks on ECI
          alibabacloud.com/eci: "true" 
      container:
        image: mirrors-ssl.aliyuncs.com/busybox:latest
        command:
          - sh
          - -c
        args:
          - |
            echo "Subtask started, ID: {{inputs.parameters.index}}"
            echo "Creating a new log file..."
            touch /scratch-volume/"{{inputs.parameters.index}}-logs"
            echo "Listing contents from the disk populated by OSSVP:"
            ls /scratch-volume
            echo "Subtask completed, ID: {{inputs.parameters.index}}"
        volumeMounts:
        - name: scratch-volume
          mountPath: /scratch-volume
        resources:
          limits:
            cpu: '4'
            memory: 16Gi
          requests:
            cpu: '4'
            memory: 16Gi
      inputs:
        parameters:
          - name: index

Después de crear el Workflow, revise los registros de cualquier pod de tarea para confirmar que la lectura de los datos precargados se realiza correctamente.

En producción, utilice Argo Workflows Artifact para conservar los resultados finales del cálculo en OSS.

# Replace <your-workflow-pod-name> with the actual pod name
kubectl -n argo logs <your-workflow-pod-name>

Salida esperada:

Subtask started, ID: 1
Creating a new log file...
Listing contents from the disk populated by OSSVP:
1-logs
lost+found
results-2025-04-16T07:48:00Z
...
Subtask completed, ID: 1

Análisis de resultados:

• 1-logs: Archivo escrito por la tarea, que confirma el acceso de lectura y escritura, así como el almacenamiento aislado entre tareas paralelas.

• results-2025-04-16T07:48:00Z y archivos similares: Datos precargados desde OSS hacia el disco en la nube.

• lost+found: Directorio creado durante el formateo del sistema de archivos. Puede ignorarlo.

Guía de limpieza de recursos

Una vez completadas las tareas de procesamiento por lotes, libere los volúmenes de disco en la nube aislados y las instancias de Argo Workflow.

Recursos por liberar:

• Instancia de Argo Workflow

• PVC temporales creadas automáticamente por el Workflow

• Recursos de almacenamiento backend (discos en la nube) creados automáticamente por las PVC.

Pasos para la liberación:

1. Elimine el Argo Workflow:

   Elimine el recurso Workflow. Con las solicitudes de volumen ephemeral, la eliminación se propaga a todas las PVC. La configuración reclaimPolicy: Delete de la StorageClass elimina posteriormente los discos en la nube del backend, libera los recursos y detiene la facturación.

   # Replace <workflow-name> with the actual Workflow name
   kubectl -n argo delete workflow <workflow-name>

2. Verifique la limpieza de recursos:

   • Ejecute kubectl -n argo get pvc para confirmar que se eliminaron todas las PVC relacionadas con el workflow.

   • Verifique los recursos de disco en la nube: Vaya a Consola de ECS - Block Storage - Disks y confirme que no quedan recursos de disco en la nube provenientes de este workflow.

   • Los datos de origen en OSS no se ven afectados. En la consola de OSS, confirme que el conjunto de datos permanece intacto.

¿Si actualizo los archivos de origen en OSS después de completar la precarga, los datos del volumen se sincronizan automáticamente?

No. La precarga de datos ocurre una sola vez durante la creación del volumen. Después del llenado, el contenido del volumen se desacopla de los datos de origen en OSS, por lo que los cambios posteriores en OSS no se sincronizan.

¿Por qué mi PVC permanece en estado Pending?

El estado Pending es normal durante la precarga de datos. Si persiste, resuelva el problema de la siguiente manera:

1. kubectl describe pvc <pvc-name> -n <namespace>: Revise los eventos de la PVC para detectar errores del populator.

2. kubectl describe ossvp <ossvp-name> -n <namespace>: Consulte el estado y los eventos de OSSVP para verificar el progreso del llenado o posibles fallos.

3. En el modo generic, revise los pods con errores en el namespace ack-volume-populator y consulte sus registros. Las causas comunes incluyen permisos insuficientes en OSS, problemas de red o espacio de almacenamiento insuficiente.