Logotipo de Zephyrnet

Inteligencia de datos generativa

Big Data

Presentamos el controlador ACK para Amazon EMR en EKS

Reeditado por Platón
Reeditado por Platón

Fecha:

Vistas: 201

AWS Controllers for Kubernetes (ACK) se anunció en agosto de 2020 y ahora admite 14 controladores de servicios de AWS como disponibilidad general con 12 adicionales en versión preliminar. La visión detrás de esta iniciativa era simple: permitir que los usuarios de Kubernetes utilicen la API de Kubernetes para administrar el ciclo de vida de los recursos de AWS, como Servicio de almacenamiento simple de Amazon (Amazon S3) baldes o Servicio de base de datos relacional de Amazon (Amazon RDS) Instancias de bases de datos. Por ejemplo, puede definir un depósito de S3 como un recurso personalizado, crear este depósito como parte de la implementación de su aplicación y eliminarlo cuando se retire su aplicación.

Amazon EMR en EKS es una opción de implementación para EMR que permite a las organizaciones ejecutar Apache Spark en Servicio Amazon Elastic Kubernetes (Amazon EKS) clústeres. Con EMR en EKS, los trabajos de Spark se ejecutan con el tiempo de ejecución de Amazon EMR para Apache Spark. Esto aumenta la rendimiento de sus trabajos de Spark para que se ejecuten más rápido y cuesten menos que Apache Spark de código abierto. Además, puede ejecutar aplicaciones Apache Spark basadas en Amazon EMR con otros tipos de aplicaciones en el mismo clúster de EKS para mejorar la utilización de los recursos y simplificar la administración de la infraestructura.

Hoy nos complace anunciar el controlador ACK para Amazon EMR en EKS generalmente está disponible. Los clientes nos han dicho que les gusta la forma declarativa de administrar aplicaciones Apache Spark en clústeres de EKS. Con el controlador ACK para EMR en EKS, ahora puede definir y ejecutar EMR de Amazon trabajos directamente usando la API de Kubernetes. Esto le permite administrar EMR en recursos de EKS directamente mediante herramientas nativas de Kubernetes, como kubectl.

La patrón de controlador ha sido ampliamente adoptado por la comunidad de Kubernetes para administrar el ciclo de vida de los recursos. De hecho, Kubernetes tiene controladores integrados para recursos integrados como Empleo or Despliegue. Estos controladores aseguran continuamente que el estado observado de un recurso coincida con el estado deseado del recurso almacenado en Kubernetes. Por ejemplo, si define una implementación que tiene NGINX usando tres réplicas, el controlador de implementación observa e intenta mantener continuamente tres réplicas de pods de NGINX. Usando el mismo patrón, el controlador ACK para EMR en EKS instala dos definiciones de recursos personalizados (CRD): VirtualCluster y JobRun. Cuando crea clústeres virtuales de EMR, el controlador realiza un seguimiento de estos como recursos personalizados de Kubernetes y llama a la API del servicio de EMR en EKS (también conocida como emr-containers) para crear y administrar estos recursos. Si desea obtener una comprensión más profunda de cómo funciona ACK con las API de servicio de AWS y aprender cómo ACK genera recursos de Kubernetes como CRD, consulte del blog.

Si necesita un sencillo tutorial de introducción, consulte Ejecute trabajos de Spark con ACK EMR en el controlador EKS. Por lo general, los clientes que ejecutan trabajos de Apache Spark en clústeres de EKS usan abstracción de mayor nivel, como Argo Workflows, Apache Airflow o Funciones de paso de AWSy utilizan la orquestación basada en flujos de trabajo para ejecutar sus trabajos de extracción, transformación y carga (ETL). Esto le brinda una experiencia consistente al ejecutar trabajos mientras define canalizaciones de trabajos mediante gráficos acíclicos dirigidos (DAG). Los DAG le permiten organizar los pasos de su trabajo con dependencias y relaciones para decir cómo deben ejecutarse. Flujos de trabajo de Argo es un motor de flujo de trabajo nativo de contenedor para orquestar trabajos paralelos en Kubernetes.

En esta publicación, le mostramos cómo usar Argo Workflows con el controlador ACK para EMR en EKS para ejecutar trabajos de Apache Spark en clústeres de EKS.

Resumen de la solución

En el siguiente diagrama, mostramos los flujos de trabajo de Argo que envían una solicitud a la API de Kubernetes mediante su mecanismo de orquestación.

Estamos usando Argo para mostrar las posibilidades con la orquestación de flujo de trabajo en esta publicación, pero también puede enviar trabajos directamente usando kubectl (la herramienta de línea de comandos de Kubernetes). Cuando Argo Workflows envía estas solicitudes a la API de Kubernetes, el controlador ACK para EMR en EKS reconcilia VirtualCluster recursos personalizados invocando el EMR en las API de EKS.

Realicemos un ejercicio de creación de recursos personalizados mediante el controlador ACK para EMR en EKS y Argo Workflows.

Requisitos previos

Su entorno necesita las siguientes herramientas instaladas:

Instale el controlador ACK para EMR en EKS

Puede crear un clúster de EKS o reutilizar uno existente. Nos remitimos a las instrucciones de Ejecute trabajos de Spark con ACK EMR en el controlador EKS configurar nuestro entorno. Complete los siguientes pasos:

  1. Instalar el clúster de EKS.
  2. Crear asignación de identidad de IAM.
  3. Instalar emrcontainers-controller.
  4. Configure IRSA para el EMR en el controlador EKS.
  5. Cree un rol de ejecución de trabajos de EMR y configure IRSA.

En esta etapa, debe tener un clúster de EKS con los permisos adecuados de control de acceso basado en roles (RBAC) para que Amazon EMR pueda ejecutar sus trabajos. También debe tener instalado el controlador ACK para EMR en EKS y la función de ejecución del trabajo EMR con Funciones de IAM para la cuenta de servicio (IRSA) para que tengan los permisos correctos para llamar a las API de EMR.

Tenga en cuenta que nos estamos saltando el paso para crear un clúster virtual de EMR porque queremos crear un recurso personalizado usando Argo Workflows. Si creó este recurso con el tutorial de introducción, puede eliminar el clúster virtual o crear una nueva asignación de identidad de IAM con un espacio de nombres diferente.

Validemos la anotación para el EMR en la cuenta de servicio del controlador EKS antes de continuar:

# validate annotation
kubectl get pods -n $ACK_SYSTEM_NAMESPACE
CONTROLLER_POD_NAME=$(kubectl get pods -n $ACK_SYSTEM_NAMESPACE --selector=app.kubernetes.io/name=emrcontainers-chart -o jsonpath='{.items..metadata.name}')
kubectl describe pod -n $ACK_SYSTEM_NAMESPACE $CONTROLLER_POD_NAME | grep "^s*AWS_"

El siguiente código muestra los resultados esperados:

AWS_REGION: us-west-2
AWS_ENDPOINT_URL:
AWS_ROLE_ARN: arn:aws:iam::012345678910:role/ack-emrcontainers-controller
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token (http://eks.amazonaws.com/serviceaccount/token)

Compruebe los registros del controlador:

kubectl logs ${CONTROLLER_POD_NAME} -n ${ACK_SYSTEM_NAMESPACE}

El siguiente código es el resultado esperado:

2022-11-02T18:52:33.588Z INFO controller.virtualcluster Starting Controller {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "VirtualCluster"}
2022-11-02T18:52:33.588Z INFO controller.virtualcluster Starting EventSource {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "VirtualCluster", "source": "kind source: *v1alpha1.VirtualCluster"}
2022-11-02T18:52:33.589Z INFO controller.virtualcluster Starting Controller {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "VirtualCluster"}
2022-11-02T18:52:33.589Z INFO controller.jobrun Starting EventSource {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "JobRun", "source": "kind source: *v1alpha1.JobRun"}
2022-11-02T18:52:33.589Z INFO controller.jobrun Starting Controller {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "JobRun"}
...
2022-11-02T18:52:33.689Z INFO controller.jobrun Starting workers {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "JobRun", "worker count": 1}
2022-11-02T18:52:33.689Z INFO controller.virtualcluster Starting workers {"reconciler group": "emrcontainers.services.k8s.aws", "reconciler kind": "VirtualCluster", "worker count": 1}

Ahora estamos listos para instalar Argo Workflows y usar la orquestación de flujos de trabajo para crear EMR en clústeres virtuales de EKS y enviar trabajos.

Instalar flujos de trabajo de Argo

Los siguientes pasos están destinados a una instalación rápida con una prueba de concepto en mente. Esto no está diseñado para una instalación de producción. Recomendamos revisar la documentación de Argo, EN LINEA directrices, y Otras Consideraciones para una instalación de producción.

Instalamos el argo CLI primero. Hemos proporcionado instrucciones para instalar el argo CLI utilizando brew, que es compatible con el sistema operativo Mac. Si usa Linux u otro sistema operativo, consulte Empieza para los pasos de instalación.

brew install argo

Vamos a crear un espacio de nombres e instalar Argo Workflows en su clúster EMR en EKS:

kubectl create namespace argo
kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.4.3/install.yaml

Puede acceder a la interfaz de usuario de Argo localmente reenviando el puerto argo-server despliegue:

kubectl -n argo port-forward deploy/argo-server 2746:2746

Puede acceder a la interfaz de usuario web en https://localhost:2746. Recibirá un aviso de que "Su conexión no es privada" porque Argo está utilizando un certificado autofirmado. Está bien elegir Avanzado y luego Continuar con el host local.

Tenga en cuenta que recibe un error de acceso denegado porque aún no hemos configurado los permisos. Configuremos RBAC para que Argo Workflows tenga permisos para comunicarse con la API de Kubernetes. Damos permisos de administrador para argo serviceaccount existentes argo y emr-ns espacios de nombres.

Abra otra ventana de terminal y ejecute estos comandos:

# setup rbac kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default --namespace=argo
kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default --namespace=emr-ns # extract bearer token to login into UI
SECRET=$(kubectl get sa default -n argo -o=jsonpath='{.secrets[0].name}')
ARGO_TOKEN="Bearer $(kubectl get secret $SECRET -n argo -o=jsonpath='{.data.token}' | base64 --decode)"
echo $ARGO_TOKEN

Ahora tiene un token de portador que debemos ingresar para la autenticación del cliente.

Ahora puede navegar a la Procesos pestaña y cambie el espacio de nombres a emr-ns para ver los flujos de trabajo en este espacio de nombres.

Configuremos los permisos de RBAC y creemos un flujo de trabajo que cree un EMR en el clúster virtual de EKS:

cat << EOF > argo-emrcontainers-vc-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: name: argo-emrcontainers-virtualcluster
rules: - apiGroups: - emrcontainers.services.k8s.aws resources: - virtualclusters verbs: - '*'
EOF cat << EOF > argo-emrcontainers-jr-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: name: argo-emrcontainers-jobrun
rules: - apiGroups: - emrcontainers.services.k8s.aws resources: - jobruns verbs: - '*'
EOF

Vamos a crear estos roles y un enlace de roles:

# create argo clusterrole with permissions to emrcontainers.services.k8s.aws
kubectl apply -f argo-emrcontainers-vc-role.yaml
kubectl apply -f argo-emrcontainers-jr-role.yaml # Give permissions for argo to use emr-containers clusterrole
kubectl create rolebinding argo-emrcontainers-virtualcluster --clusterrole=argo-emrcontainers-virtualcluster --serviceaccount=emr-ns:default -n emr-ns
kubectl create rolebinding argo-emrcontainers-jobrun --clusterrole=argo-emrcontainers-jobrun --serviceaccount=emr-ns:default -n emr-ns

Recapitulemos lo que hemos hecho hasta ahora. Creamos un clúster de EMR en EKS, instalamos el controlador ACK para EMR en EKS mediante Helm, instalamos Argo CLI, instalamos Argo Workflows, obtuvimos acceso a la interfaz de usuario de Argo y configuramos los permisos de RBAC para Argo. Se requieren permisos RBAC para que la cuenta de servicio predeterminada en el espacio de nombres Argo pueda usar VirtualCluster y JobRun recursos personalizados a través de emrcontainers.services.k8s.aws API.

Es hora de crear el clúster virtual de EMR. Las variables de entorno que se utilizan en el siguiente código proceden de la guía de introducción, pero puede cambiarlas para adaptarlas a su entorno:

export EKS_CLUSTER_NAME=ack-emr-eks
export EMR_NAMESPACE=emr-ns cat << EOF > argo-emr-virtualcluster.yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata: name: emr-virtualcluster
spec: arguments: {} entrypoint: emr-virtualcluster templates: - name: emr-virtualcluster resource: action: create manifest: | apiVersion: emrcontainers.services.k8s.aws/v1alpha1 kind: VirtualCluster metadata: name: my-ack-vc spec: name: my-ack-vc containerProvider: id: ${EKS_CLUSTER_NAME} type_: EKS info: eksInfo: namespace: ${EMR_NAMESPACE}
EOF

Utilice el siguiente comando para crear un flujo de trabajo de Argo para la creación de un clúster virtual:

kubectl apply -f argo-emr-virtualcluster.yaml -n emr-ns
argo list -n emr-ns

El siguiente código es el resultado esperado de Argo CLI:

NAME STATUS AGE DURATION PRIORITY MESSAGE
emr-virtualcluster Succeeded 12m 11s 0

Verifique el estado de virtualcluster:

kubectl describe virtualcluster/my-ack-vc -n emr-ns

El siguiente código es el resultado esperado del comando anterior:

Name: my-ack-vc
Namespace: default
Labels: <none>
Annotations: <none>
API Version: emrcontainers.services.k8s.aws/v1alpha1
Kind: VirtualCluster
...
Status: Ack Resource Metadata: Arn: arn:aws:emr-containers:us-west-2:012345678910:/virtualclusters/dxnqujbxexzri28ph1wspbxo0 Owner Account ID: 012345678910 Region: us-west-2 Conditions: Last Transition Time: 2022-11-03T15:34:10Z Message: Resource synced successfully Reason: Status: True Type: ACK.ResourceSynced Id: dxnqujbxexzri28ph1wspbxo0
Events: <none>

Si tiene problemas, puede verificar los registros de Argo usando el siguiente comando o a través de la consola:

argo logs emr-virtualcluster -n emr-ns

También puede verificar los registros del controlador como se menciona en el guía para resolver problemas.

Debido a que tenemos un clúster virtual de EMR listo para aceptar trabajos, podemos comenzar a trabajar en los requisitos previos para el envío de trabajos.

Cree un depósito S3 y Registros de Amazon CloudWatch grupo que se necesitan para el trabajo (consulte el siguiente código). Si ya creó estos recursos desde el tutorial de iniciación, puedes omitir este paso.

export RANDOM_ID1=$(LC_ALL=C tr -dc a-z0-9 </dev/urandom | head -c 8) aws logs create-log-group --log-group-name=/emr-on-eks-logs/$EKS_CLUSTER_NAME
aws s3 mb s3://$EKS_CLUSTER_NAME-$RANDOM_ID1

Usamos la Conjunto de datos de bicicletas Citi de Nueva York, que tiene datos demográficos del pasajero e información de datos de viaje. Ejecute el siguiente comando para copiar el conjunto de datos en su depósito S3:

export S3BUCKET=$EKS_CLUSTER_NAME-$RANDOM_ID1
aws s3 sync s3://tripdata/ s3://${S3BUCKET}/citibike/csv/

Copie el código de la aplicación Spark de muestra en su depósito S3:

aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-2782/citibike-convert-csv-to-parquet.py s3://${S3BUCKET}/application/
aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-2782/citibike-ridership.py s3://${S3BUCKET}/application/
aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-2782/citibike-popular-stations.py s3://${S3BUCKET}/application/
aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-2782/citibike-trips-by-age.py s3://${S3BUCKET}/application/

Ahora es el momento de ejecutar un trabajo de muestra de Spark. Ejecute lo siguiente para generar una plantilla de envío de flujo de trabajo de Argo:

export RANDOM_ID2=$(LC_ALL=C tr -dc a-z0-9 </dev/urandom | head -c 8) cat << EOF > argo-citibike-steps-jobrun.yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata: name: emr-citibike-${RANDOM_ID2}
spec: entrypoint: emr-citibike templates: - name: emr-citibike steps: - - name: emr-citibike-csv-parquet template: emr-citibike-csv-parquet - - name: emr-citibike-ridership template: emr-citibike-ridership - name: emr-citibike-popular-stations template: emr-citibike-popular-stations - name: emr-citibike-trips-by-age template: emr-citibike-trips-by-age # This is parent job that converts csv data to parquet - name: emr-citibike-csv-parquet resource: action: create successCondition: status.state == COMPLETED failureCondition: status.state == FAILED manifest: | apiVersion: emrcontainers.services.k8s.aws/v1alpha1 kind: JobRun metadata: name: my-ack-jobrun-csv-parquet-${RANDOM_ID2} spec: name: my-ack-jobrun-csv-parquet-${RANDOM_ID2} virtualClusterRef: from: name: my-ack-vc executionRoleARN: "${ACK_JOB_EXECUTION_ROLE_ARN}" releaseLabel: "emr-6.7.0-latest" jobDriver: sparkSubmitJobDriver: entryPoint: "s3://${S3BUCKET}/application/citibike-convert-csv-to-parquet.py" entryPointArguments: [${S3BUCKET}] sparkSubmitParameters: "--conf spark.executor.instances=2 --conf spark.executor.memory=1G --conf spark.executor.cores=1 --conf spark.driver.cores=1 --conf spark.sql.shuffle.partitions=60 --conf spark.dynamicAllocation.enabled=false" configurationOverrides: | ApplicationConfiguration: null MonitoringConfiguration: CloudWatchMonitoringConfiguration: LogGroupName: /emr-on-eks-logs/${EKS_CLUSTER_NAME} LogStreamNamePrefix: citibike S3MonitoringConfiguration: LogUri: s3://${S3BUCKET}/logs # This is a child job which runs after csv-parquet jobs is complete - name: emr-citibike-ridership resource: action: create manifest: | apiVersion: emrcontainers.services.k8s.aws/v1alpha1 kind: JobRun metadata: name: my-ack-jobrun-ridership-${RANDOM_ID2} spec: name: my-ack-jobrun-ridership-${RANDOM_ID2} virtualClusterRef: from: name: my-ack-vc executionRoleARN: "${ACK_JOB_EXECUTION_ROLE_ARN}" releaseLabel: "emr-6.7.0-latest" jobDriver: sparkSubmitJobDriver: entryPoint: "s3://${S3BUCKET}/application/citibike-ridership.py" entryPointArguments: [${S3BUCKET}] sparkSubmitParameters: "--conf spark.executor.instances=2 --conf spark.executor.memory=1G --conf spark.executor.cores=1 --conf spark.driver.cores=1 --conf spark.sql.shuffle.partitions=60 --conf spark.dynamicAllocation.enabled=false" configurationOverrides: | ApplicationConfiguration: null MonitoringConfiguration: CloudWatchMonitoringConfiguration: LogGroupName: /emr-on-eks-logs/${EKS_CLUSTER_NAME} LogStreamNamePrefix: citibike S3MonitoringConfiguration: LogUri: s3://${S3BUCKET}/logs # This is a child job which runs after csv-parquet jobs is complete - name: emr-citibike-popular-stations resource: action: create manifest: | apiVersion: emrcontainers.services.k8s.aws/v1alpha1 kind: JobRun metadata: name: my-ack-jobrun-popular-stations-${RANDOM_ID2} spec: name: my-ack-jobrun-popular-stations-${RANDOM_ID2} virtualClusterRef: from: name: my-ack-vc executionRoleARN: "${ACK_JOB_EXECUTION_ROLE_ARN}" releaseLabel: "emr-6.7.0-latest" jobDriver: sparkSubmitJobDriver: entryPoint: "s3://${S3BUCKET}/application/citibike-popular-stations.py" entryPointArguments: [${S3BUCKET}] sparkSubmitParameters: "--conf spark.executor.instances=2 --conf spark.executor.memory=1G --conf spark.executor.cores=1 --conf spark.driver.cores=1 --conf spark.sql.shuffle.partitions=60 --conf spark.dynamicAllocation.enabled=false" configurationOverrides: | ApplicationConfiguration: null MonitoringConfiguration: CloudWatchMonitoringConfiguration: LogGroupName: /emr-on-eks-logs/${EKS_CLUSTER_NAME} LogStreamNamePrefix: citibike S3MonitoringConfiguration: LogUri: s3://${S3BUCKET}/logs # This is a child job which runs after csv-parquet jobs is complete - name: emr-citibike-trips-by-age resource: action: create manifest: | apiVersion: emrcontainers.services.k8s.aws/v1alpha1 kind: JobRun metadata: name: my-ack-jobrun-trips-by-age-${RANDOM_ID2} spec: name: my-ack-jobrun-trips-by-age-${RANDOM_ID2} virtualClusterRef: from: name: my-ack-vc executionRoleARN: "${ACK_JOB_EXECUTION_ROLE_ARN}" releaseLabel: "emr-6.7.0-latest" jobDriver: sparkSubmitJobDriver: entryPoint: "s3://${S3BUCKET}/application/citibike-trips-by-age.py" entryPointArguments: [${S3BUCKET}] sparkSubmitParameters: "--conf spark.executor.instances=2 --conf spark.executor.memory=1G --conf spark.executor.cores=1 --conf spark.driver.cores=1 --conf spark.sql.shuffle.partitions=60 --conf spark.dynamicAllocation.enabled=false" configurationOverrides: | ApplicationConfiguration: null MonitoringConfiguration: CloudWatchMonitoringConfiguration: LogGroupName: /emr-on-eks-logs/${EKS_CLUSTER_NAME} LogStreamNamePrefix: citibike S3MonitoringConfiguration: LogUri: s3://${S3BUCKET}/logs EOF

Ejecutemos este trabajo:

argo -n emr-ns submit --watch argo-citibike-steps-jobrun.yaml

El siguiente código es el resultado esperado:

Name: emr-citibike-tp8dlo6c
Namespace: emr-ns
ServiceAccount: unset (will run with the default ServiceAccount)
Status: Succeeded
Conditions: PodRunning False Completed True
Created: Mon Nov 07 15:29:34 -0500 (20 seconds ago)
Started: Mon Nov 07 15:29:34 -0500 (20 seconds ago)
Finished: Mon Nov 07 15:29:54 -0500 (now)
Duration: 20 seconds
Progress: 4/4
ResourcesDuration: 4s*(1 cpu),4s*(100Mi memory)
STEP TEMPLATE PODNAME DURATION MESSAGE ✔ emr-citibike-if32fvjd emr-citibike ├───✔ emr-citibike-csv-parquet emr-citibike-csv-parquet emr-citibike-if32fvjd-emr-citibike-csv-parquet-140307921 2m └─┬─✔ emr-citibike-popular-stations emr-citibike-popular-stations emr-citibike-if32fvjd-emr-citibike-popular-stations-1670101609 4s ├─✔ emr-citibike-ridership emr-citibike-ridership emr-citibike-if32fvjd-emr-citibike-ridership-2463339702 4s └─✔ emr-citibike-trips-by-age emr-citibike-trips-by-age emr-citibike-if32fvjd-emr-citibike-trips-by-age-3778285872 4s

Puede abrir otra terminal y ejecutar el siguiente comando para verificar también el estado del trabajo:

kubectl -n emr-ns get jobruns -w

También puede consultar la interfaz de usuario y ver los registros de Argo, como se muestra en la siguiente captura de pantalla.

Limpiar

Siga las Instrucciones del tutorial de introducción para limpiar el controlador ACK para EMR en EKS y sus recursos. Para eliminar recursos de Argo, utilice el siguiente código:

kubectl delete -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.4.3/install.yaml
kubectl delete -f argo-emrcontainers-vc-role.yaml
kubectl delete -f argo-emrcontainers-jr-role.yaml
kubectl delete rolebinding argo-emrcontainers-virtualcluster -n emr-ns
kubectl delete rolebinding argo-emrcontainers-jobrun -n emr-ns
kubectl delete ns argo

Conclusión

En esta publicación, analizamos cómo administrar sus trabajos de Spark en clústeres de EKS mediante el controlador ACK para EMR en EKS. Puede definir trabajos de Spark de manera declarativa y administrar estos recursos mediante recursos personalizados de Kubernetes. También revisamos cómo usar Argo Workflows para orquestar estos trabajos y obtener una experiencia de envío de trabajos uniforme. Puedes aprovecharte de los ricos Características de Argo Workflows, como el uso de DAG para definir flujos de trabajo de varios pasos y especificar dependencias dentro de los pasos del trabajo, usar la interfaz de usuario para visualizar y administrar los trabajos y definir reintentos y tiempos de espera en el nivel de flujo de trabajo o tarea.

Puede comenzar hoy instalando el Controlador ACK para EMR en EKS y comience a administrar sus recursos de Amazon EMR utilizando métodos nativos de Kubernetes.

Sobre los autores

pedro dalbhanjan es un arquitecto de soluciones para AWS con sede en Herndon, VA. Peter es un apasionado de evangelizar y resolver problemas comerciales complejos mediante una combinación de servicios de AWS y soluciones de código abierto. En AWS, Peter ayuda con el diseño y la arquitectura de una variedad de cargas de trabajo de los clientes.

amina hilaly es un ingeniero de desarrollo de software en Amazon Web Services que trabaja en proyectos relacionados con Kubernetes y código abierto durante aproximadamente dos años. Amine es un fanático de Go, código abierto y Kubernetes.

punto_img

Información más reciente

punto_img

Derechos de autor @ 2024 Plato Technologies Inc.