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

Requisitos previos

• Un clúster ACK Edge de la versión 1.18 o posterior está created.

• Un node pool perimetral está created y los nodos perimetrales están added.

• El conjunto de herramientas nativas de la nube para IA está instalado y el complemento ack-fluid se encuentra desplegado.

  Importante

  Si tiene instalado Fluid de código abierto, desinstálelo antes de desplegar ack-fluid.

  • Si el conjunto de herramientas nativas de la nube para IA no está instalado: habilite Fluid data acceleration cuando install the suite.

  • Si el conjunto de herramientas nativas de la nube para IA ya está instalado: despliegue ack-fluid en la página Cloud-native AI Suite de la consola de ACK.

• El clúster está connected with kubectl.

• OSS está activated.

Paso 1: Preparar los datos de OSS

1. Descargue los datos de prueba en una instancia ECS.

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

2. Cargue los datos de prueba descargados en un bucket de OSS.

   Importante

   Estos pasos utilizan Alibaba Cloud Linux 3.2104 LTS de 64 bits. Para otros sistemas, consulte ossutil quick start y ossutil command reference 1.0.

   1. Install ossutil.

   2. Cree un bucket llamado examplebucket.

      • Cree examplebucket.

        ossutil mb oss://examplebucket

      • Mensaje que indica que examplebucket se creó correctamente:

        0.668238(s) elapsed

   3. Cargue los datos de prueba en examplebucket.

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

Paso 2: Crear un Dataset y un JindoRuntime

1. Cree un archivo llamado mySecret.yaml con a continuación contenido. Reemplace xxx por el AccessKey ID y el AccessKey secret que tengan permisos de lectura sobre el bucket de OSS creado en el paso 1.

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

2. Aplique el Secret. Kubernetes cifra los valores almacenados para evitar que se expongan como texto sin formato.

   kubectl create -f mySecret.yaml

3. Cree un archivo resource.yaml con a continuación contenido:

   • Defina un Dataset que describa el almacenamiento remoto y el sistema de archivos subyacente (UFS).

   • Cree un JindoRuntime para iniciar un clúster JindoFS que almacene datos en caché.

   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

   • En un clúster ACK Edge, utilice nodeAffinity y nodeSelector para desplegar el Dataset y el JindoRuntime en el mismo node pool. De esta manera, los nodos del pool pueden comunicarse entre sí.

   • La gestión de nodos perimetrales y el acceso a OSS requieren comunicación entre la nube y el perímetro. Mantenga un ancho de banda de red suficiente para no desestabilizar el canal de control.

   Parámetros:

   Parámetro	Descripción
   mountPoint	oss://<oss_bucket>/<bucket_dir>. Ruta de montaje del UFS. Debe apuntar a un directorio; no es posible montar un solo archivo. No incluya el endpoint.
   fs.oss.endpoint	Endpoint público o interno del bucket de OSS. Consulte Regions and endpoints.
   replicas	Número de workers en el clúster de caché de JindoFS.
   mediumtype	Medio de almacenamiento de la caché. Valores válidos: HDD, SSD, MEM.
   path	Ruta de almacenamiento local en el nodo worker. Solo se permite una ruta. Es obligatoria cuando mediumtype es MEM para almacenar datos como registros.
   quota	Tamaño máximo de caché por worker. No es posible ampliar la capacidad de la caché si modifica quota. Después de modificar el valor, JindoRuntime reporta el cambio como correcto, pero la nueva capacidad no surte efecto en el Dataset. Para cambiar la capacidad de la caché, elimine el CR de JindoRuntime y vuelva a crearlo.
   high	Umbral de expulsión de la caché (marca de agua alta). Cuando el uso supera esta proporción, comienza la expulsión.
   low	Umbral de retención de la caché (marca de agua baja). La expulsión se detiene cuando el uso desciende hasta esta proporción.

4. Cree el Dataset y el JindoRuntime.

   kubectl create -f resource.yaml

5. Compruebe que el Dataset esté vinculado.

   kubectl get dataset hadoop

   Salida esperada:

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

6. Compruebe que el JindoRuntime esté listo.

   kubectl get jindoruntime hadoop

   Salida esperada:

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

7. Compruebe que se hayan creado el volumen persistente (PV) y la solicitud de volumen persistente (PVC).

   kubectl get pv,pvc

   Salida 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

El Dataset y el JindoRuntime están listos cuando todas las fases muestran Ready y el estado de la PVC es Bound.

Paso 3: Probar la aceleración del acceso a los datos

Despliegue un pod que monte la PVC del Dataset y compare los tiempos de lectura del archivo antes y después de almacenar los datos en caché.

1. Cree un archivo 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

   En un clúster ACK Edge, utilice nodeSelector para desplegar el pod de prueba en el node pool indicado en Step 2.

2. Despliegue el pod.

   kubectl create -f app.yaml

3. Abra un shell en el pod y compruebe el tamaño del archivo.

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

   Salida esperada:

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

4. Mida el tiempo inicial de lectura. Este acceso proviene directamente de OSS, sin caché.

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

   Salida esperada:

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

   La lectura del archivo tarda aproximadamente 18 segundos.

5. Compruebe los datos almacenados en caché después de la lectura.

   kubectl get dataset hadoop

   Salida esperada:

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

   Los 210 MiB completos ahora están almacenados en la caché del almacenamiento local.

6. Elimine y vuelva a crear el pod para borrar la caché de páginas del sistema operativo. Así, la siguiente lectura provendrá de la caché de JindoFS y no de la memoria.

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

7. Vuelva a medir el tiempo de lectura con los datos servidos desde la caché.

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

   Salida esperada:

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

   Con la caché de JindoFS, la lectura del mismo archivo se completa en 48 milisegundos. Esto es más de 300 veces más rápido que el acceso directo a OSS.

(Opcional) Limpieza

Cuando ya no necesite la aceleración de datos, elimine el pod, el Dataset y el JindoRuntime.

Elimine el pod:

kubectl delete pod demo-app

Elimine el Dataset y el JindoRuntime:

kubectl delete dataset hadoop