As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciamento de execuções de trabalhos do Amazon EMR no EKS
As seções a seguir abordam tópicos que ajudam você a gerenciar suas execuções de trabalhos do Amazon EMR no EKS. Isso inclui configurar os parâmetros de execução do trabalho ao usar o AWS CLI, configurar como seus dados de registro são armazenados, executar scripts do Spark SQL para executar consultas, entender os estados de execução do trabalho e saber como monitorar trabalhos. Você pode trabalhar com esses tópicos, geralmente em ordem, se quiser configurar e concluir uma execução de trabalho para processar dados.
**Topics**
+ [Gerenciando execuções de trabalhos com o AWS CLI](emr-eks-jobs-CLI.md)
+ [Executando scripts do Spark SQL por meio da API StartJobRun](emr-eks-jobs-spark-sql-parameters.md)
+ [Estados de execução de trabalho](emr-eks-jobs-states.md)
+ [Visualização de trabalhos no console do Amazon EMR](emr-eks-jobs-console.md)
+ [Erros comuns ao executar trabalhos](emr-eks-jobs-error.md)
# Gerenciando execuções de trabalhos com o AWS CLI
Este tópico aborda como gerenciar execuções de trabalhos com o AWS Command Line Interface (AWS CLI). São detalhadas as propriedades, como parâmetros de segurança, o driver e várias configurações de substituição. Também inclui subtópicos que abrangem várias maneiras de configurar o registro em log.
**Topics**
+ [Opções para a configuração de uma execução de trabalho](#emr-eks-jobs-parameters)
+ [Configuração de uma execução de trabalho para usar logs do Amazon S3](emr-eks-jobs-s3.md)
+ [Configurar uma execução de trabalho para usar o Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md)
+ [Listagem de execuções de trabalhos](#emr-eks-jobs-list)
+ [Descrição de uma execução de trabalho](#emr-eks-jobs-describe)
+ [Cancelamento de uma execução de trabalho](#emr-eks-jobs-cancel)
## Opções para a configuração de uma execução de trabalho
Use as seguintes opções para configurar os parâmetros de execução de trabalho:
+ `--execution-role-arn`: você deve fornecer um perfil do IAM que é usado para a execução de trabalhos. Para obter mais informações, consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md).
+ `--release-label`: você pode implantar o Amazon EMR no EKS com as versões 5.32.0 e 6.2.0 e posteriores do Amazon EMR. O Amazon EMR no EKS não é compatível com as versões anteriores do Amazon EMR. Para obter mais informações, consulte [Versões do Amazon EMR no EKS](emr-eks-releases.md).
+ `--job-driver`: o driver de trabalho usado para fornecer entradas sobre o trabalho principal. Este é um campo do tipo união no qual você só pode transferir um dos valores para o tipo de trabalho que deseja executar. Os tipos de trabalho com suporte incluem:
+ Trabalhos do Spark-submit: usados para executar um comando por meio do spark-submit. Você pode usar esse tipo de tarefa para executar Scala, SparkR PySpark, SparkSQL e qualquer outra tarefa compatível por meio do Spark Submit. Esse tipo de trabalho tem os seguintes parâmetros:
+ Ponto de entrada - Essa é a referência HCFS (sistema de arquivos compatível com Hadoop) ao jar/py arquivo principal que você deseja executar.
+ EntryPointArguments - Essa é uma matriz de argumentos que você deseja passar para o jar/py arquivo principal. Você deve realizar a leitura desses parâmetros usando seu código de Entrypoint. Cada argumento na matriz deve ser separado por uma vírgula. EntryPointArguments não pode conter colchetes ou parênteses, como (), \$1\$1 ou [].
+ SparkSubmitParameters - Esses são os parâmetros adicionais do Spark que você deseja enviar para o trabalho. Use este parâmetro para substituir as propriedades padrão do Spark, como a memória do driver ou o número de executores, como —conf ou —class. Para obter informações adicionais, consulte [Launching Applications with spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
+ Trabalhos do Spark SQL: usados para executar um arquivo de consulta SQL por meio do Spark SQL. Você pode usar esse tipo de trabalho para executar trabalhos do Spark SQL. Esse tipo de trabalho tem os seguintes parâmetros:
+ Entrypoint: esta é a referência do HCFS (sistema de arquivos compatível com Hadoop) para o arquivo de consulta SQL que você deseja executar.
Para obter uma lista de parâmetros adicionais do Spark que você pode usar para um trabalho do Spark SQL, consulte [Executando scripts do Spark SQL por meio da API StartJobRun](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides`: você pode substituir as configurações padrão para as aplicações ao fornecer um objeto de configuração. Você pode usar uma sintaxe abreviada para fornecer a configuração ou fazer referência ao objeto de configuração em um arquivo JSON. Os objetos de configuração consistem em uma classificação, propriedades e configurações opcionais aninhadas As propriedades consistem nas configurações que você deseja substituir neste arquivo. Você pode especificar várias classificações para diversas aplicações em um único objeto JSON. As classificações de configuração disponíveis variam de acordo com a versão do Amazon EMR. Para obter uma lista das classificações de configuração disponíveis para cada versão de liberação do Amazon EMR, consulte [Versões do Amazon EMR no EKS](emr-eks-releases.md).
Se você transferir a mesma configuração em uma substituição de aplicação e nos parâmetros do spark-submit, os parâmetros do spark-submit terão precedência. A lista completa de prioridades de configuração é apresentada a seguir, na ordem da prioridade mais alta para a prioridade mais baixa.
+ Configuração fornecida ao criar `SparkSession`.
+ Configuração fornecida como parte do `sparkSubmitParameters` usando `—conf`.
+ Configuração fornecida como parte das substituições de aplicações.
+ Configurações otimizadas escolhidas pelo Amazon EMR para a versão.
+ Configurações padrão de código aberto para a aplicação.
Para monitorar a execução de trabalhos usando o Amazon CloudWatch ou o Amazon S3, você deve fornecer os detalhes da configuração do. CloudWatch Para obter mais informações, consulte [Configuração de uma execução de trabalho para usar logs do Amazon S3](emr-eks-jobs-s3.md) e [Configurar uma execução de trabalho para usar o Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md). Se o bucket ou grupo de CloudWatch logs do S3 não existir, o Amazon EMR o criará antes de fazer o upload dos registros para o bucket.
+ Para obter uma lista adicional de opções de configuração do Kubernetes, consulte [Spark Properties on Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration).
As configurações do Spark apresentadas a seguir não têm suporte.
+ `spark.kubernetes.authenticate.driver.serviceAccountName`
+ `spark.kubernetes.authenticate.executor.serviceAccountName`
+ `spark.kubernetes.namespace`
+ `spark.kubernetes.driver.pod.name`
+ `spark.kubernetes.container.image.pullPolicy`
+ `spark.kubernetes.container.image`
**nota**
Você pode usar `spark.kubernetes.container.image` para imagens do Docker personalizadas. Para obter mais informações, consulte [Personalização de imagens do Docker para o Amazon EMR no EKS](docker-custom-images.md).
# Configuração de uma execução de trabalho para usar logs do Amazon S3
Para poder monitorar o progresso do trabalho e solucionar falhas, você deve configurar seus trabalhos para enviar informações de log para o Amazon S3, CloudWatch Amazon Logs ou ambos. Este tópico ajuda você a começar a publicar logs de aplicações no Amazon S3 em trabalhos iniciados com o Amazon EMR no EKS.
**Política do IAM para logs do S3**
Antes que os trabalhos possam enviar dados de log ao Amazon S3, as permissões apresentadas a seguir devem ser inclusas na política de permissões para o perfil de execução do trabalho. Substitua *amzn-s3-demo-logging-bucket* pelo nome do bucket de registro em log.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
**nota**
O Amazon EMR no EKS também pode criar um bucket do Amazon S3. Se um bucket do Amazon S3 não estiver disponível, inclua a permissão `“s3:CreateBucket”` na política do IAM.
Depois de conceder ao perfil de execução as permissões adequadas para enviar logs ao Amazon S3, os dados de log serão enviados para os locais do Amazon S3 apresentados a seguir quando `s3MonitoringConfiguration` for transmitida na seção `monitoringConfiguration` de uma solicitação `start-job-run`, conforme mostrado em [Gerenciando execuções de trabalhos com o AWS CLI](emr-eks-jobs-CLI.md).
+ Registros do remetente -//*virtual-cluster-id*/jobs/ /containers/*logUri*/(stderr.gz/stdout.gz) *job-id* *pod-name*
+ Registros de drivers -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers/ /spark- -driver/ (*spark-application-id*stderr.gz/stdout.gz) *job-id*
+ Registros do executor -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers///(*spark-application-id*stderr.gz/stdout.gz) *executor-pod-name*
# Configurar uma execução de trabalho para usar o Amazon CloudWatch Logs
Para monitorar o progresso do trabalho e solucionar falhas, você deve configurar seus trabalhos para enviar informações de log para o Amazon S3, CloudWatch Amazon Logs ou ambos. Este tópico ajuda você a começar a usar CloudWatch registros em seus trabalhos que são lançados com o Amazon EMR no EKS. Para obter mais informações sobre CloudWatch registros, consulte [Monitoramento de arquivos de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) no Guia CloudWatch do usuário da Amazon.
**CloudWatch Política de IAM de registros**
Para que seus trabalhos enviem dados de registro para o CloudWatch Logs, as seguintes permissões devem ser incluídas na política de permissões da função de execução do trabalho. Substitua *my\$1log\$1group\$1name* e *my\$1log\$1stream\$1prefix* por nomes de seu grupo de CloudWatch registros e nomes de fluxo de registros, respectivamente. O Amazon EMR no EKS cria o grupo de logs e o fluxo de logs se eles não existirem, desde que o ARN do perfil de execução tenha as permissões apropriadas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
],
"Sid": "AllowLOGSCreatelogstream"
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:log-group:my_log_group_name:log-stream:my_log_stream_prefix/*"
],
"Sid": "AllowLOGSPutlogevents"
}
]
}
```
------
**nota**
O Amazon EMR no EKS também pode criar um fluxo de logs. Se um fluxo de logs não existir, a política do IAM deverá incluir a permissão `"logs:CreateLogGroup"`.
Depois de conceder à sua função de execução as permissões adequadas, seu aplicativo envia os dados de registro para o CloudWatch `cloudWatchMonitoringConfiguration` Logs quando são passados na `monitoringConfiguration` seção de uma `start-job-run` solicitação, conforme mostrado em[Gerenciando execuções de trabalhos com o AWS CLI](emr-eks-jobs-CLI.md).
Na `StartJobRun` API, *log\$1group\$1name * é o nome do grupo de registros para CloudWatch e *log\$1stream\$1prefix* é o prefixo do nome do fluxo de registros para CloudWatch. Você pode visualizar e pesquisar esses logs no Console de gerenciamento da AWS.
+ Registros do remetente -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* /containers//(stderr/stdout*job-id*) *pod-name*
+ Registros de drivers -*logGroup*//*logStreamPrefix**virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- -driver/ (*spark-application-id*stderrstdout) *job-id*
+ Registros do executor -*logGroup*//*logStreamPrefix**virtual-cluster-id*/jobs/ *job-id* /containers///(*spark-application-id*stderr/stdout) *executor-pod-name*
## Listagem de execuções de trabalhos
Você pode executar `list-job-run` para mostrar os estados das execuções de trabalhos, como demonstra o exemplo a seguir.
```
aws emr-containers list-job-runs --virtual-cluster-id
```
## Descrição de uma execução de trabalho
Você pode executar `describe-job-run` para obter mais detalhes sobre o trabalho, como o estado do trabalho, os detalhes do estado e o nome do trabalho, como demonstra o exemplo a seguir.
```
aws emr-containers describe-job-run --virtual-cluster-id cluster-id --id job-run-id
```
## Cancelamento de uma execução de trabalho
Você pode executar `cancel-job-run` para cancelar trabalhos em execução, como demonstra o exemplo a seguir.
```
aws emr-containers cancel-job-run --virtual-cluster-id cluster-id --id job-run-id
```
# Executando scripts do Spark SQL por meio da API StartJobRun
As versões 6.7.0 e posteriores do Amazon EMR no EKS incluem um driver de trabalho do Spark SQL para que você possa executar scripts do Spark SQL por meio da API `StartJobRun`. Você pode fornecer arquivos de ponto de entrada SQL para executar consultas do Spark SQL diretamente no Amazon EMR no EKS com a API `StartJobRun`, sem a necessidade de realizar modificações nos scripts do Spark SQL existentes. A tabela a seguir lista os parâmetros do Spark que são compatíveis com as tarefas do Spark SQL por meio da StartJobRun API.
Você pode escolher entre os parâmetros do Spark apresentados a seguir para enviar para um trabalho do Spark SQL. Use esses parâmetros para substituir as propriedades padrão do Spark.
| Opção | Description |
| --- | --- |
| --name NAME | Nome da aplicação |
| --jars JARS | Lista separada por vírgulas de arquivos em JARs a serem inclusos no driver e no caminho de classe de execução. |
| --packages | Lista separada por vírgulas de coordenadas do Maven de arquivos em JARs a serem inclusas nos caminhos de classe do driver e do executor. |
| --exclude-packages | Lista separada por vírgulas de groupId:artifactId, para excluir ao resolver as dependências fornecidas em --packages para evitar conflitos de dependência. |
| --repositories | Lista separada por vírgulas de repositórios remotos adicionais para pesquisar as coordenadas do Maven fornecidas com --packages. |
| --files FILES | Lista separada por vírgulas de arquivos a serem colocados no diretório de trabalho de cada executor. |
| --conf PROP=VALUE | Propriedade de configuração do Spark. |
| --properties-file FILE | Caminho para um arquivo do qual as propriedades extras serão carregadas. |
| --driver-memory MEM | Memória para o driver. O padrão é de 1.024 MB. |
| --driver-java-options | Opções extras do Java a serem transferidas para o driver. |
| --driver-library-path | Entradas extras de caminhos da biblioteca a serem transferidas para o driver. |
| --driver-class-path | Entradas extras de caminhos de classe a serem transferidas para o driver. |
| --executor-memory MEM | Memória por executor. O padrão é de 1 GB. |
| --driver-cores NUM | Número de núcleos usados pelo driver. |
| -- total-executor-cores NÚMERO | Total de núcleos para todos os executores. |
| --executor-cores NUM | Número de núcleos usados por cada executor. |
| --num-executors NUM | Número de executores para iniciar. |
| -hivevar | Substituição de variável para a aplicação dos comandos do Hive, por exemplo, -hivevar A=B. |
| -hiveconf | Valor a ser usado para a propriedade em questão. |
Para uma tarefa do Spark SQL, crie um start-job-run-request arquivo.json e especifique os parâmetros necessários para a execução da tarefa, como no exemplo a seguir:
```
{
"name": "myjob",
"virtualClusterId": "123456",
"executionRoleArn": "iam_role_name_for_job_execution",
"releaseLabel": "emr-6.7.0-latest",
"jobDriver": {
"sparkSqlJobDriver": {
"entryPoint": "entryPoint_location",
"sparkSqlParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
}
},
"configurationOverrides": {
"applicationConfiguration": [
{
"classification": "spark-defaults",
"properties": {
"spark.driver.memory":"2G"
}
}
],
"monitoringConfiguration": {
"persistentAppUI": "ENABLED",
"cloudWatchMonitoringConfiguration": {
"logGroupName": "my_log_group",
"logStreamNamePrefix": "log_stream_prefix"
},
"s3MonitoringConfiguration": {
"logUri": "s3://my_s3_log_location"
}
}
}
}
```
# Estados de execução de trabalho
Quando você envia uma execução de trabalho para uma fila de trabalhos do Amazon EMR no EKS, a execução de trabalho entra no estado `PENDING`. Em seguida, ela passa pelos estados apresentados a seguir até obter êxito (sair com o código `0`) ou falhar (sair com um código diferente de zero).
As execuções de trabalhos podem ter os seguintes estados:
+ `PENDING`: o estado inicial do trabalho quando a execução de trabalho é enviada ao Amazon EMR no EKS. O trabalho está aguardando para ser enviado ao cluster virtual, e o Amazon EMR no EKS está trabalhando no envio desse trabalho.
+ `SUBMITTED`: uma execução de trabalho que foi enviada com êxito ao cluster virtual. O programador do cluster tenta executar esse trabalho no cluster.
+ `RUNNING`: uma execução de trabalho em execução no cluster virtual. Em aplicações do Spark, isso significa que o processo do driver do Spark está no estado `running`.
+ `FAILED`: uma execução de trabalho que falhou ao ser enviada ao cluster virtual ou que foi concluída sem êxito. Examine StateDetails e FailureReason encontre informações adicionais sobre essa falha no trabalho.
+ `COMPLETED`: uma execução de trabalho que foi concluída com êxito.
+ `CANCEL_PENDING`: uma execução de trabalho foi solicitada para cancelamento. O Amazon EMR no EKS está tentando cancelar o trabalho no cluster virtual.
+ `CANCELLED`: uma execução de trabalho que foi cancelada com êxito.
# Visualização de trabalhos no console do Amazon EMR
Os dados de execução do trabalho estão disponíveis para exibição, para que você possa monitorar cada trabalho à medida que ele passa pelos estados. Para visualizar trabalhos no console do Amazon EMR, execute as etapas a seguir.
1. No menu à esquerda do console do Amazon EMR, em Amazon EMR no EKS, escolha **Clusters virtuais**.
1. Na lista de clusters virtuais, selecione o cluster virtual do qual deseja visualizar os trabalhos.
1. Na tabela **Execuções de trabalhos**, selecione **Visualizar logs** para visualizar os detalhes de uma execução de trabalho.
**nota**
O suporte para a experiência de um clique está habilitado por padrão. Ele pode ser desativado ao configurar `persistentAppUI` para `DISABLED` na `monitoringConfiguration` durante o envio do trabalho. Para obter mais informações, consulte [View Persistent Application User Interfaces](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html).
# Erros comuns ao executar trabalhos
Os erros a seguir podem ocorrer ao executar a API `StartJobRun`. A tabela lista cada erro e fornece etapas de mitigação para que você possa resolver os problemas rapidamente.
| Mensagem de erro | Condição de erro | Próxima etapa recomendada |
| --- | --- | --- |
| erro: argumento -- *argument* é obrigatório | Os parâmetros obrigatórios estão ausentes. | Adicione os argumentos ausentes à solicitação de API. |
| Ocorreu um erro (AccessDeniedException) ao chamar a StartJobRun operação: Usuário: não ARN está autorizado a realizar: emr-containers: StartJobRun | O perfil de execução está ausente. | Consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md). |
| Ocorreu um erro (AccessDeniedException) ao chamar a StartJobRun operação: Usuário: não *ARN* está autorizado a realizar: emr-containers: StartJobRun | O chamador não tem permissão para acessar o perfil de execução [formato válido ou inválido] por meio de chaves de condição. | Consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md). |
| Ocorreu um erro (AccessDeniedException) ao chamar a StartJobRun operação: Usuário: não *ARN* está autorizado a realizar: emr-containers: StartJobRun | O emissor de trabalho e o ARN do perfil de execução são de contas diferentes. | Certifique-se de que o ARN do emissor de trabalho e do perfil de execução sejam da mesma conta da AWS . |
| 1 erro de validação detectado: o valor *Role* em 'executionRoleArn' falhou em satisfazer o padrão de expressão regular do ARN: ^arn :( aws [a-zA-z0-9-] \$1) :iam: :(\$1 d \$112\$1)? : (papel ((\$1 u002F) \$1 (\$1 u002F [\$1 u0021-\$1 u007F] \$1\$1 u002F)) [\$1 w\$1=, .@-] \$1) | O chamador tem permissões para acessar o perfil de execução por meio de chaves de condição, mas o perfil não atende às restrições do formato de ARN. | Forneça o perfil de execução seguindo o formato de ARN. Consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md). |
| Ocorreu um erro (ResourceNotFoundException) ao chamar a StartJobRun operação: O cluster virtual *Virtual Cluster ID* não existe. | O ID do cluster virtual não foi encontrado. | Forneça um ID do cluster virtual registrado no Amazon EMR no EKS. |
| Ocorreu um erro (ValidationException) ao chamar a StartJobRun operação: O estado do cluster virtual não *state* é válido para criar recursos JobRun. | O cluster virtual não está pronto para executar o trabalho. | Consulte [Estados de um cluster virtual](virtual-cluster.md#virtual-cluster-states). |
| Ocorreu um erro (ResourceNotFoundException) ao chamar a StartJobRun operação: A liberação *RELEASE* não existe. | A versão especificada no envio do trabalho está incorreta. | Consulte [Versões do Amazon EMR no EKS](emr-eks-releases.md). |
| Ocorreu um erro (AccessDeniedException) ao chamar a StartJobRun operação: Usuário: não *ARN* está autorizado a realizar: emr-containers: StartJobRun on resource: *ARN* com uma negação explícita. Ocorreu um erro (AccessDeniedException) ao chamar a StartJobRun operação: Usuário: não *ARN* está autorizado a executar: emr-containers: StartJobRun on resource: *ARN* | O usuário não está autorizado a ligar StartJobRun. | Consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md). |
| Ocorreu um erro (ValidationException) ao chamar a StartJobRun operação: configurationOverrides.monitoringConfiguration.s3 MonitoringConfiguration .logURI falhou em satisfazer a restrição: %s | A sintaxe do URI do caminho do S3 não é válida. | O logUri deve estar no formato s3://... |
Os erros a seguir podem ocorrer ao executar a API `DescribeJobRun` antes da execução de trabalho.
| Mensagem de erro | Condição de erro | Próxima etapa recomendada |
| --- | --- | --- |
| StateDetails: falha no JobRun envio. Classificação *classification* não suportada. failureReason: VALIDATION\$1ERROR state: FAILED. | Os parâmetros em não StartJobRun são válidos. | Consulte [Versões do Amazon EMR no EKS](emr-eks-releases.md). |
| StateDetails: *EKS Cluster ID* O cluster não existe. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O cluster do EKS não está disponível. | Verifique se o cluster do EKS existe e tem as permissões corretas. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: *EKS Cluster ID* O cluster não tem permissões suficientes. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O Amazon EMR não tem permissões para acessar o cluster do EKS. | Verifique se as permissões estão configuradas para o Amazon EMR no namespace registrado. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: O cluster não *EKS Cluster ID* está acessível no momento. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O cluster do EKS não está acessível. | Verifique se o cluster do EKS existe e tem as permissões corretas. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: falha no JobRun envio devido a um erro interno. failureReason: INTERNAL\$1ERROR state: FAILED | Ocorreu um erro interno com o cluster do EKS. | N/D |
| StateDetails: *EKS Cluster ID* O cluster não tem recursos suficientes. failureReason: USER\$1ERROR state: FAILED | Não há recursos suficientes no cluster do EKS para executar o trabalho. | Adicione mais capacidade ao grupo de nós do EKS ou configure o Autoscaler do EKS. Para obter mais informações, consulte [Autoscaler do cluster](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html). |
Os erros a seguir podem ocorrer ao executar a API `DescribeJobRun` depois da execução de trabalho.
| Mensagem de erro | Condição de erro | Próxima etapa recomendada |
| --- | --- | --- |
| StateDetails: Problemas para monitorar seu. JobRun *EKS Cluster ID*O cluster não existe. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O cluster do EKS não existe. | Verifique se o cluster do EKS existe e tem as permissões corretas. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: Problemas para monitorar seu. JobRun *EKS Cluster ID*O cluster não tem permissões suficientes. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O Amazon EMR não tem permissões para acessar o cluster do EKS. | Verifique se as permissões estão configuradas para o Amazon EMR no namespace registrado. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: Problemas para monitorar seu. JobRun No momento, *EKS Cluster ID* o cluster não está acessível. failureReason: CLUSTER\$1UNAVAILABLE state: FAILED | O cluster do EKS não está acessível. | Verifique se o cluster do EKS existe e tem as permissões corretas. Para obter mais informações, consulte [Configuração do Amazon EMR no EKS](setting-up.md). |
| StateDetails: Problemas para monitorar seu JobRun devido a um erro interno failureReason: INTERNAL\$1ERROR state: FAILED | Ocorreu um erro interno que está impedindo o JobRun monitoramento. | N/D |
O erro apresentado a seguir pode ocorrer quando um trabalho não pode ser iniciado e aguarda no estado SUBMITTED por 15 minutos. Isso pode ser causado pela falta de recursos do cluster.
| Mensagem de erro | Condição de erro | Próxima etapa recomendada |
| --- | --- | --- |
| cluster timeout | O trabalho está no estado SUBMITTED há 15 minutos ou mais. | Você pode substituir a configuração padrão de 15 minutos para este parâmetro com a substituição de configuração mostrada abaixo. |
Use a configuração a seguir para alterar a configuração de tempo limite do cluster para 30 minutos. Observe que você fornece o novo valor para `job-start-timeout` em segundos:
```
{
"configurationOverrides": {
"applicationConfiguration": [{
"classification": "emr-containers-defaults",
"properties": {
"job-start-timeout":"1800"
}
}]
}
```