Container Service for Kubernetes:Accelerate OSS access from edge nodes with Fluid

Pré-requisitos

• Um ACK Edge cluster da versão 1,18 ou posterior foi criado.

• Um pool de nós de borda foi criado e os nós de borda foram adicionados.

• A suíte de IA cloud-native está instalada com o add-on ack-fluid implantado.

  Importante

  Se o Fluid open source estiver instalado, desinstale-o antes de implantar o ack-fluid.

  • Se a suíte de IA cloud-native não estiver instalada: ative a aceleração de dados do Fluid e instale a suíte ao instalar a suíte.

  • Se a suíte de IA cloud-native já estiver instalada: implante o ack-fluid na página Cloud-native AI Suite do console do ACK.

• O cluster está conectado ao kubectl.

• O OSS está ativado.

Etapa 1: Preparar os dados do OSS

1. Baixe os dados de teste para uma instância ECS.

   wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

2. Carregue os dados de teste baixados em um bucket do OSS.

   Importante

   Estas etapas usam o Alibaba Cloud Linux 3.2104 LTS 64 bits. Para outros sistemas, consulte ossutil quick start e ossutil command reference 1,0.

   1. Instale o ossutil.

   2. Crie um bucket chamado examplebucket.

      • Em seguida, crie o examplebucket.

        ossutil mb oss://examplebucket

      • O examplebucket foi criado com sucesso:

        0.668238(s) elapsed

   3. Carregue os dados de teste no examplebucket.

      ossutil cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

Etapa 2: Criar um Dataset e um JindoRuntime

1. Crie um arquivo chamado mySecret.yaml com o seguinte conteúdo. Substitua xxx pelo AccessKey (AccessKeyID e AccessKeySecret) que têm acesso de leitura ao bucket oss (id do bucket) criado na Etapa 1.

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysecret
   stringData:
     fs.oss.accessKeyId: xxx
     fs.oss.accessKeySecret: xxx

2. Aplique o Secret. O Kubernetes criptografa os valores armazenados para que não sejam expostos como texto simples.

   kubectl create -f mySecret.yaml

3. Crie um arquivo resource.yaml com o seguinte conteúdo:

   • Defina um Dataset que descreva o armazenamento remoto e o sistema de arquivos subjacente (UFS).

   • Crie um JindoRuntime para iniciar um cluster JindoFS para cache de dados.

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: hadoop
   spec:
     nodeAffinity:
       required:
         nodeSelectorTerms:
           - matchExpressions:
             - key: alibabacloud.com/nodepool-id
               operator: In
               values:
                 - npxxxxxxxxxxxxxx
     mounts:
       - mountPoint: oss://<oss_bucket>/<bucket_dir>
         options:
           fs.oss.endpoint: <oss_endpoint>
         name: hadoop
         path: "/"
         encryptOptions:
           - name: fs.oss.accessKeyId
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeyId
           - name: fs.oss.accessKeySecret
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeySecret
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: hadoop
   spec:
     nodeSelector:
       alibabacloud.com/nodepool-id: npxxxxxxxxxxxxxx
     replicas: 2
     tieredstore:
       levels:
         - mediumtype: MEM
           path: /dev/shm
           volumeType: emptyDir
           quota: 2Gi
           high: "0.99"
           low: "0.95"

   Nota

   • Em um ACK Edge cluster, use nodeAffinity e nodeSelector para implantar o Dataset e o JindoRuntime no mesmo pool de nós e permitir a comunicação entre eles.

   • O gerenciamento de nós de borda e o acesso ao OSS exigem comunicação da cloud para a borda. Mantenha uma largura de banda de rede suficiente para evitar a desestabilização do canal de controle.

   Parâmetros:

   Parâmetro	Descrição
   mountPoint	oss://<oss_bucket>/<bucket_dir>. Caminho de montagem do UFS. Deve apontar para um diretório. Um único arquivo não pode ser montado. Não inclua o endpoint.
   fs.oss.endpoint	Endpoint público ou interno do bucket do OSS. Consulte Regions and endpoints.
   replicas	Número de workers no cluster de cache do JindoFS.
   mediumtype	Meio de armazenamento de cache. Valores válidos: HDD, SSD, MEM.
   path	Caminho de armazenamento local no nó worker. Apenas um caminho é permitido. Obrigatório quando mediumtype é MEM para armazenar dados como logs.
   quota	Tamanho máximo de cache por worker. Não é possível expandir a capacidade do cache ao modificar quota. Após modificar o valor, o JindoRuntime relata a alteração como bem-sucedida, mas a nova capacidade de cache não entra em vigor no Dataset. Para alterar a capacidade do cache, exclua o CR do JindoRuntime e crie-o novamente.
   high	Limiar de evicção de cache (marca d'água alta). Quando o uso excede essa proporção, a evicção começa.
   low	Limiar de retenção de cache (marca d'água baixa). A evicção para quando o uso cai para essa proporção.

4. Crie o Dataset e o JindoRuntime.

   kubectl create -f resource.yaml

5. Agora, verifique se o Dataset está vinculado.

   kubectl get dataset hadoop

   Saída esperada:

   NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop        210MiB       0.00B    4.00GiB              0.0%          Bound   1h

6. Confirme se o JindoRuntime está pronto.

   kubectl get jindoruntime hadoop

   Saída esperada:

   NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
   hadoop   Ready          Ready          Ready        4m45s

7. Certifique-se de que o volume persistente (PV) e a solicitação de volume persistente (PVC) foram criados.

   kubectl get pv,pvc

   Saída esperada:

   NAME                              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
   persistentvolume/default-hadoop   100Pi      ROX            Retain           Bound    default/hadoop                           52m
   
   NAME                           STATUS   VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   persistentvolumeclaim/hadoop   Bound    default-hadoop    100Pi      ROX                           52m

O Dataset e o JindoRuntime estão prontos quando todas as fases mostram Ready e o status do PVC é Bound.

Etapa 3: Testar a aceleração de acesso a dados

Implante um pod para montar o PVC do Dataset e compare os tempos de leitura de arquivos antes e depois do armazenamento em cache.

1. Crie um arquivo app.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: demo-app
   spec:
     nodeSelector:
       alibabacloud.com/nodepool-id: npxxxxxxxxxxxxx
     containers:
       - name: demo
         image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         volumeMounts:
           - mountPath: /data
             name: hadoop
     volumes:
       - name: hadoop
         persistentVolumeClaim:
           claimName: hadoop

   Nota

   Em um ACK Edge cluster, use nodeSelector para implantar o pod de teste no pool de nós na Etapa 2.

2. Implante o pod.

   kubectl create -f app.yaml

3. Abra um shell no pod e verifique o tamanho do arquivo.

   kubectl exec -it demo-app -- bash
   du -sh /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz

   Saída esperada:

   210M    /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz

4. Meça o tempo inicial de leitura. Esse acesso é feito diretamente do OSS, sem cache.

   time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   Saída esperada:

   real    0m18.386s
   user    0m0.002s
   sys    0m0.105s

   A leitura do arquivo leva cerca de 18 segundos.

5. Verifique os dados em cache após a leitura.

   kubectl get dataset hadoop

   Saída esperada:

   NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop   210.00MiB       210.00MiB    4.00GiB        100.0%           Bound   1h

   Os 210 MiB completos agora estão em cache no armazenamento local.

6. Exclua e recrie o pod para limpar o cache de página do SO. Assim, a próxima leitura virá do cache do JindoFS em vez da memória.

   kubectl delete -f app.yaml && kubectl create -f app.yaml

7. Meça novamente o tempo de leitura com os dados servidos pelo cache.

   kubectl exec -it demo-app -- bash
   time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   Saída esperada:

   real    0m0.048s
   user    0m0.001s
   sys     0m0.046s

   Com o cache do JindoFS, a leitura do mesmo arquivo é concluída em 48 milissegundos, mais de 300 vezes mais rápido que o acesso direto ao OSS.

(Opcional) Limpeza

Quando a aceleração de dados não for mais necessária, exclua o pod, o Dataset e o JindoRuntime.

Para limpar, exclua o pod:

kubectl delete pod demo-app

Em seguida, exclua o Dataset e o JindoRuntime:

kubectl delete dataset hadoop