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

Implementação do recurso

Este recurso utiliza os Volume Populators do Kubernetes, gerenciados pelo storage-operator do ACK. Ao criar uma PVC que referencia o recurso personalizado OSSVolumePopulator (OSSVP), o storage-operator intercepta a solicitação e preenche os dados.

O modo de preenchimento depende do tipo de volume de destino:

Modo	Tipos de armazenamento suportados	Descrição
bmcpfs-dataflow Modo de fluxo de dados nativo	CPFS for Lingjun	O storage-operator usa o fluxo de dados nativo do CPFS para preencher os dados. Este modo não consome recursos de computação do cluster e oferece maior eficiência.
generic Modo de preenchimento genérico via pod	Outros tipos de armazenamento, como discos cloud ou CPFS general-purpose edition	O storage-operator cria um pod temporário no namespace ack-volume-populator para montar o novo volume e baixar os dados especificados do OSS. O pod é excluído após a conclusão do preenchimento. Este modo consome recursos de computação do cluster.

Após o preenchimento bem-sucedido, o status da PVC muda de Pending para Bound. Os pods da aplicação podem então montar a PVC e acessar os dados pré-carregados.

Cenários típicos

Este resource suporta dois casos de uso principais.

Fluxo de trabalho

As etapas principais do VolumePopulator são semelhantes em ambos os modos.

Ative o Feature Gate VolumePopulator no storage-operator. Ao ativar o VolumePopulator, o namespace ack-volume-populator é criado por padrão para armazenar PVCs e pods temporários durante o pré-carregamento de dados. Conceda permissões de acesso ao OSS para a tarefa de preenchimento. O modo bmcpfs-dataflow exige tags específicas no bucket do OSS. O modo generic requer configuração de RRSA ou AccessKey. Crie um objeto OSSVolumePopulator especificando o caminho do bucket do OSS e o modo de preenchimento. Crie uma PVC, especifique uma StorageClass e referencie o OSSVP com dataSourceRef para iniciar o pré-carregamento de dados (o tempo depende do volumeBindingMode da StorageClass). Depois que a PVC estiver Bound, crie cargas de trabalho (pods, deployments, etc.) que a montem para acesso aos dados em alta velocidade. O pré-carregamento de dados ocorre apenas uma vez durante a criação do volume. Alterações posteriores nos dados de source do OSS não são sincronizadas com o volume criado. Após o término da tarefa, exclua a PVC. Se o reclaimPolicy da StorageClass for Delete, o armazenamento de alto desempenho associado (como FileSets do CPFS ou discos cloud) será excluído automaticamente e o faturamento cessará. Os dados de source no OSS permanecem inalterados.

Cenário 1: Pré-carregar dados para volumes compartilhados do CPFS for Lingjun

Para treinamento e inferência de modelos somente leitura com alto throughput, use o fluxo de dados do CPFS for Lingjun para pré-carregar modelos do OSS sob demanda, permitindo que múltiplas tarefas de GPU leiam dados em alta velocidade.

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. Criar carga de trabalho e usar dados

Depois que a PVC estiver Bound, crie uma carga de trabalho que a monte.

Este exemplo usa resources de GPU. Apenas para verificação, crie um pod de CPU e use kubectl exec para inspecionar os dados.

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

Guia de limpeza de resources

Após a conclusão das tarefas de treinamento ou inferência de IA, libere os volumes compartilhados do CPFS for Lingjun e as cargas de trabalho relacionadas.

Resources a serem liberados:

• Cargas de trabalho usando o volume compartilhado (neste exemplo, um StatefulSet)

• PVC usada para pré-carregamento de dados

• Resources de armazenamento de backend (FileSet do CPFS for Lingjun) criados automaticamente pela PVC

Etapas de limpeza:

1. Exclua a carga de trabalho

   Exclua o StatefulSet que utiliza o volume para liberar a PVC.

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

2. Exclua a PVC

   Com reclaimPolicy: Delete na StorageClass, a exclusão da PVC também exclui o FileSet do CPFS no backend, libera o armazenamento e interrompe o faturamento.

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

3. Verifique a limpeza de resources:

   • No console NAS, escolha File System > File System List e confirme se o FileSet para esta PVC foi excluído e se a capacidade utilizada diminuiu.

   • Os dados de source no OSS permanecem inalterados. No console OSS, confirme se o conjunto de dados permanece intacto.

Pré-requisitos

• Ative o VolumePopulatorPodHandler no storage-operator.

  Após a ativação, o sistema concede as permissões RBAC necessárias aos componentes relacionados e aos pods temporários. Avalie os riscos de segurança antes de ativar.

  Permissões RBAC configuradas automaticamente

  • Concede permissões de operação de pod ao storage-operator no namespace ack-volume-populator

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

  • Concede permissões de acesso no nível do cluster aos pods temporários de tarefas

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

• O Argo Workflows deve estar instalado.

  Etapas detalhadas

  1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, escolha Operations > Add-ons.

  3. Na página Add-ons, localize Argo Workflows e instale-o conforme instruído.

• Este exemplo usa computação serverless (ECI) para tarefas de pré-carregamento de dados e workflows. Instale o ack-virtual-node add-on. Para verificação sem serverless, remova alibabacloud.com/eci: "true" dos resources.

1. Autorizar tarefas de pré-carregamento de dados a acessar o OSS

No modo generic, as tarefas de pré-carregamento de dados são executadas como pods temporários no namespace ack-volume-populator. Conceda a esses pods acesso ao bucket do OSS com os dados de source.

• RRSA method: Atribui dinamicamente funções RAM temporárias e com rotação automática aos pods para isolamento granular de permissões com maior segurança.

• AccessKey method: Armazena credenciais estáticas e de longo prazo em um Secret. Simples de configure, mas menos seguro.

2. Criar OSSVolumePopulator (OSSVP)

Crie um OSSVolumePopulator no mesmo namespace da sua aplicação e PVC. Defina mode como generic e configure a autorização.

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 cenário requer uma StorageClass para provisionamento dinâmico de discos cloud. O ACK fornece uma default StorageClass e suporta manually creating a StorageClass.

• Este exemplo usa alicloud-disk-essd com reclaimPolicy definido como Delete e volumeBindingMode definido como Immediate, adequado para computação serverless sem consciência de zona.

• Para fluxos de trabalho não serverless, use uma StorageClass com volumeBindingMode definido como WaitForFirstConsumer (como alicloud-disk-topology-alltype) para que discos cloud e pods da aplicação sejam criados na mesma zona.

4. Criar Argo Workflow

Este exemplo de Workflow usa um ephemeral volumeClaimTemplate para criar um disco cloud independente com dados pré-carregados para cada tarefa 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

Após criar o Workflow, verifique os logs de qualquer pod de tarefa para confirmar se as leituras dos dados pré-carregados foram bem-sucedidas.

Em produção, use o Artifact do Argo Workflows para persistir os resultados finais da computação no OSS.

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

Saída 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álise do resultado:

• 1-logs: Arquivo gravado pela tarefa, confirmando acesso de leitura/gravação e armazenamento isolado entre tarefas paralelas.

• results-2025-04-16T07:48:00Z e arquivos similares: Dados pré-carregados do OSS para o disco cloud.

• lost+found: Diretório criado durante a formatação do sistema de arquivos. Ignore-o.

Guia de limpeza de resources

Após a conclusão das tarefas de processamento em lote, libere os volumes isolados de disco cloud e as instâncias do Argo Workflow.

Resources a serem liberados:

• Instância do Argo Workflow

• PVCs temporárias criadas automaticamente pelo Workflow

• Resources de armazenamento de backend (discos cloud) criados automaticamente pelas PVCs.

Etapas de liberação:

1. Exclua o Argo Workflow:

   Exclua o resource Workflow. Com reivindicações de volume ephemeral, a exclusão se propaga para todas as PVCs. O StorageClass com reclaimPolicy: Delete então exclui os discos cloud de backend, libera resources e interrompe o faturamento.

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

2. Verifique a limpeza de resources:

   • Execute kubectl -n argo get pvc para confirmar se todas as PVCs relacionadas ao workflow foram excluídas.

   • Verifique os resources de disco cloud: Acesse Console ECS - Block Storage - Disks e confirme se não restam resources de disco cloud deste workflow.

   • Os dados de source no OSS permanecem inalterados. No console OSS, confirme se o conjunto de dados permanece intacto.

Após a conclusão do pré-carregamento, se eu atualizar arquivos de source no OSS, os dados no volume serão sincronizados automaticamente?

Não. O pré-carregamento de dados ocorre apenas uma vez durante a criação do volume. Após o preenchimento, o conteúdo do volume é desacoplado dos dados de source do OSS, e alterações posteriores no OSS não são sincronizadas.

Por que minha PVC permanece no status Pending?

O status Pending é normal durante o pré-carregamento de dados. Se persistir, solucione o problema da seguinte forma:

1. kubectl describe pvc <pvc-name> -n <namespace>: Verifique eventos da PVC para erros do populator.

2. kubectl describe ossvp <ossvp-name> -n <namespace>: Verifique o status e eventos do OSSVP para progresso ou falhas no preenchimento.

3. No modo generic, verifique pods com falha no namespace ack-volume-populator e revise os logs. Causas comuns incluem permissões insuficientes no OSS, problemas de rede ou espaço de armazenamento insuficiente.