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á. # Definição de configurações para endpoints interativos Esta seção contém uma série de tópicos que abrangem várias configurações para endpoints interativos e configurações de pod. Eles permitem monitorar e solucionar falhas, enviar informações de log para o Amazon S3 ou Amazon CloudWatch Logs para, ou criar endpoints interativos nos quais você especifica modelos de pod personalizados. **Topics** + [Monitorar trabalhos Spark do](monitoring-spark-jobs.md) + [Especificação de modelos de pod personalizados com endpoints interativos](custom-pod-templates.md) + [Implantação de um pod do JEG em um grupo de nós](managed-endpoint-nodegroups-setup.md) + [Opções de configuração do Jupyter Enterprise Gateway (JEG)](jeg-config-options.md) + [Modificando os parâmetros PySpark da sessão](modify-pyspark-parameters.md) + [Imagem de kernel personalizada com o endpoint interativo](custom-kernel.md) # Monitorar trabalhos Spark do Para que você possa monitorar e solucionar falhas, configure seus endpoints interativos para que os trabalhos iniciados com o endpoint possam enviar informações de log para o Amazon S3, Amazon CloudWatch Logs ou ambos. As seções a seguir descrevem como enviar logs de aplicações do Spark para o Amazon S3 para os trabalhos do Spark executados com endpoints interativos do Amazon EMR no EKS. **Configuração da política do IAM para os logs do Amazon S3** Antes que seus kernels possam enviar dados de log ao Amazon S3, a política de permissões para o perfil de execução de trabalho deve incluir as permissões apresentadas a seguir. Substitua *amzn-s3-demo-destination-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 S3. Se um bucket do S3 não estiver disponível, inclua a permissão `s3:CreateBucket` na política do IAM. Após conceder as permissões necessárias para o envio de logs ao bucket do S3 ao perfil de execução, os dados de log serão enviados para os locais do Amazon S3 apresentados a seguir. Isso acontece quando `s3MonitoringConfiguration` é transferido na seção `monitoringConfiguration` de uma solicitação `create-managed-endpoint`. + **Logs de driver**: `logUri/virtual-cluster-id/endpoints/endpoint-id/containers/spark-application-id/spark-application-id-driver/(stderr.gz/stdout.gz)`. + **Logs de executor**: `logUri/virtual-cluster-id/endpoints/endpoint-id/containers/spark-application-id/executor-pod-name-exec-/(stderr.gz/stdout.gz)`. **nota** O Amazon EMR no EKS não faz o upload dos logs do endpoint para o bucket do S3. # Especificação de modelos de pod personalizados com endpoints interativos É possível criar endpoints interativos nos quais você especifica modelos de pod personalizados para drivers e executores. Os *modelos de pod* são especificações que determinam como ocorrerá a execução de cada pod. Você pode usar arquivos de modelo de pod para definir as configurações de pods de drivers ou de executores para as quais as configurações do Spark não oferecem suporte. No momento, os modelos de pod são compatíveis com as versões 6.3.0 e posteriores do Amazon EMR. Para obter mais informações sobre modelos de pod, consulte [Using pod templates](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/pod-templates.html) no *Guia de desenvolvimento do Amazon EMR no EKS*. O seguinte exemplo mostra como criar um endpoint interativo com modelos de pod: ``` aws emr-containers create-managed-endpoint \ --type JUPYTER_ENTERPRISE_GATEWAY \ --virtual-cluster-id virtual-cluster-id \ --name example-endpoint-name \ --execution-role-arn arn:aws:iam::aws-account-id:role/EKSClusterRole \ --release-label emr-6.9.0-latest \ --configuration-overrides '{ "applicationConfiguration": [ { "classification": "spark-defaults", "properties": { "spark.kubernetes.driver.podTemplateFile": "path/to/driver/template.yaml", "spark.kubernetes.executor.podTemplateFile": "path/to/executor/template.yaml" } }] }' ``` # Implantação de um pod do JEG em um grupo de nós O posicionamento do pod do JEG (Jupyter Enterprise Gateway) é um recurso que permite implantar um endpoint interativo em um grupo de nós específico. Com esse recurso, você pode definir configurações, como `instance type`, para o endpoint interativo. ## Associação de um pod do JEG a um grupo de nós gerenciado A propriedade de configuração apresentada a seguir permite especificar o nome de um grupo de nós gerenciado no cluster do Amazon EKS em que o pod do JEG será implantado. ``` //payload --configuration-overrides '{ "applicationConfiguration": [ { "classification": "endpoint-configuration", "properties": { "managed-nodegroup-name": NodeGroupName } } ] }' ``` Um grupo de nós deve ter o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes anexado a todos os nós que fazem parte do grupo de nós. Para listar todos os nós de um grupo de nós que têm essa etiqueta, use o seguinte comando: ``` kubectl get nodes --show-labels | grep for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` Se a saída do comando acima não retornar nós que fazem parte do seu grupo de nós gerenciado, então não há nós no grupo de nós que tenham o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes anexado. Nesse caso, siga as etapas abaixo para anexar esse rótulo aos nós do seu grupo de nós. 1. Use o comando a seguir para adicionar o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes a todos os nós em um grupo de nós gerenciado `NodeGroupName`: ``` kubectl label nodes --selector eks:nodegroup-name=NodeGroupName for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` 1. Verifique se os nós foram rotulados corretamente usando o seguinte comando: ``` kubectl get nodes --show-labels | grep for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` Um grupo de nós gerenciado deve estar associado a um grupo de segurança do cluster do Amazon EKS, o que geralmente acontece se você criou o cluster e o grupo de nós gerenciado usando `eksctl`. Você pode verificar isso no AWS console usando as etapas a seguir. 1. Acesse o cluster no console do Amazon EKS. 1. Acesse a guia de redes do cluster e anote o grupo de segurança do cluster. 1. Acesse a guia de computação do seu cluster e clique no nome do grupo de nós gerenciado. 1. Na guia **Detalhes** do grupo de nós gerenciado, verifique se o grupo de segurança do cluster anotado anteriormente está listado em **Grupos de segurança**. Se o grupo de nós gerenciado não estiver anexado ao grupo de segurança do cluster do Amazon EKS, será necessário anexar a etiqueta `for-use-with-emr-containers-managed-endpoint-sg=ClusterName/NodeGroupName` ao grupo de segurança do grupo de nós. Use as etapas abaixo para anexar essa etiqueta. 1. Acesse o console do Amazon EC2 e clique em grupos de segurança no painel de navegação à esquerda. 1. Selecione o grupo de segurança do seu grupo de nós gerenciado ao clicar na caixa de seleção. 1. Na guia **Etiquetas**, adicione a etiqueta `for-use-with-emr-containers-managed-endpoint-sg=ClusterName/NodeGroupName` usando o botão **Gerenciar etiquetas**. ## Associação de um pod do JEG a um grupo de nós autogerenciado A propriedade de configuração apresentada a seguir permite especificar o nome de um grupo de nós autogerenciado ou não gerenciado no cluster do Amazon EKS em que o pod do JEG será implantado. ``` //payload --configuration-overrides '{ "applicationConfiguration": [ { "classification": "endpoint-configuration", "properties": { "self-managed-nodegroup-name": NodeGroupName } } ] }' ``` O grupo de nós deve ter o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes anexado a todos os nós que fazem parte do grupo de nós. Para listar todos os nós de um grupo de nós que têm essa etiqueta, use o seguinte comando: ``` kubectl get nodes --show-labels | grep for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` Se a saída do comando acima não retornar nós que fazem parte do seu grupo de nós autogerenciado, então não há nós no grupo de nós que tenham o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes anexado. Nesse caso, siga as etapas abaixo para anexar esse rótulo aos nós do seu grupo de nós. 1. Se você criou o grupo de nós autogerenciado usando `eksctl`, use o comando a seguir para adicionar o rótulo `for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName` do Kubernetes a todos os nós no grupo de nós autogerenciado `NodeGroupName` de uma vez só. ``` kubectl label nodes --selector alpha.eksctl.io/nodegroup-name=NodeGroupName for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` Caso não tenha usado `eksctl` para criar o grupo de nós autogerenciado, você precisará substituir o seletor no comando acima por um rótulo diferente do Kubernetes que esteja anexado a todos os nós do grupo de nós. 1. Use o seguinte comando para verificar se os nós foram rotulados corretamente: ``` kubectl get nodes --show-labels | grep for-use-with-emr-containers-managed-endpoint-ng=NodeGroupName ``` O grupo de segurança do grupo de nós autogerenciado deve ter a etiqueta `for-use-with-emr-containers-managed-endpoint-sg=ClusterName/NodeGroupName` anexada. Use as etapas apresentadas a seguir para anexar a etiqueta ao grupo de segurança do Console de gerenciamento da AWS. 1. Navegue até o console do Amazon EC2. Selecione **Grupos de segurança** no painel de navegação à esquerda. 1. Selecione a caixa de seleção ao lado do grupo de segurança do seu grupo de nós autogerenciado. 1. Na guia **Etiquetas**, use o botão **Gerenciar etiquetas** para adicionar a etiqueta `for-use-with-emr-containers-managed-endpoint-sg=ClusterName/NodeGroupName`. Substitua `ClusterName` e `NodeGroupName` com os valores apropriados. ## Associação de um pod do JEG a um grupo de nós gerenciado com instâncias sob demanda Você também pode definir rótulos adicionais, conhecidos como *seletores de rótulos do Kubernetes*, para especificar limitações ou restrições adicionais à execução de um endpoint interativo em um determinado nó ou grupo de nós. O exemplo a seguir mostra como usar as instâncias sob demanda do Amazon EC2 para um pod do JEG. ``` --configuration-overrides '{ "applicationConfiguration": [ { "classification": "endpoint-configuration", "properties": { "managed-nodegroup-name": NodeGroupName, "node-labels": "eks.amazonaws.com/capacityType:ON_DEMAND" } } ] }' ``` **nota** Você pode usar a propriedade `node-labels` somente com uma propriedade `managed-nodegroup-name` ou `self-managed-nodegroup-name`. # Opções de configuração do Jupyter Enterprise Gateway (JEG) O Amazon EMR no EKS usa o Jupyter Enterprise Gateway (JEG) para ativar os endpoints interativos. É possível definir os valores a seguir para as configurações do JEG listadas como permitidas ao criar o endpoint. + **`RemoteMappingKernelManager.cull_idle_timeout`**: tempo limite em segundos (inteiro), após o qual um kernel é considerado inativo e pronto para ser descartado. Valores iguais ou inferiores a `0` desativam o descarte. Tempos limite curtos podem resultar no descarte de kernels para usuários com conexões de rede ruins. + **`RemoteMappingKernelManager.cull_interval`**: o intervalo em segundos (inteiro) no qual verificar se há kernels inativos que excedem o valor do tempo limite de descarte. # Modificando os parâmetros PySpark da sessão Começando com o Amazon EMR no EKS versão 6.9.0, no Amazon EMR Studio você pode ajustar a configuração do Spark associada a uma PySpark sessão executando o comando `%%configure` mágico na célula do notebook EMR. O exemplo a seguir mostra uma carga útil de exemplo que você pode usar para modificar a memória, os núcleos e outras propriedades do driver e do executor do Spark. Para as configurações `conf`, você pode definir qualquer configuração do Spark mencionada na [documentação de configuração do Apache Spark](https://spark.apache.org/docs/latest/configuration.html). ``` %%configure -f { "driverMemory": "16G", "driverCores": 4, "executorMemory" : "32G", "executorCores": 2, "conf": { "spark.dynamicAllocation.maxExecutors" : 10, "spark.dynamicAllocation.minExecutors": 1 } } ``` O exemplo a seguir mostra uma carga útil de exemplo que você pode usar para adicionar arquivos, pyFiles e dependências em JAR a um runtime do Spark. ``` %%configure -f { "files": "s3://amzn-s3-demo-bucket-emr-eks/sample_file.txt", "pyFiles": : "path-to-python-files", "jars" : "path-to-jars } ``` # Imagem de kernel personalizada com o endpoint interativo Para garantir que você tenha as dependências corretas para sua aplicação ao executar as workloads interativas do Amazon EMR Studio, você pode personalizar as imagens do Docker para os endpoints interativos e executar imagens base de kernel personalizadas. Para criar um endpoint interativo e conectá-lo a uma imagem do Docker personalizada, execute as etapas a seguir. **nota** Você pode substituir somente as imagens base. Não é possível adicionar novos tipos de imagens de kernel. 1. **Crie e publique uma imagem do Docker personalizada.** A imagem base contém o runtime do Spark e os kernels do caderno que são executados com ele. Para criar a imagem, você pode seguir as etapas de 1 a 4 descritas em [Como personalizar imagens do Docker](docker-custom-images-steps.md). Na etapa 1, o URI da imagem base em seu arquivo do Docker deve usar `notebook-spark` no lugar de `spark`. ``` ECR-registry-account.dkr.ecr.Region.amazonaws.com/notebook-spark/container-image-tag ``` Para obter mais informações sobre como selecionar Regiões da AWS e armazenar tags de imagem, consulte[Detalhes sobre como selecionar um URI de imagem base](docker-custom-images-tag.md). 1. **Crie um endpoint interativo que possa ser usado com a imagem personalizada.** 1. Crie um arquivo JSON `custom-image-managed-endpoint.json` com o conteúdo apresentado a seguir. Este exemplo usa a versão 6.9.0 do Amazon EMR. **Example** ``` { "name": "endpoint-name", "virtualClusterId": "virtual-cluster-id", "type": "JUPYTER_ENTERPRISE_GATEWAY", "releaseLabel": "emr-6.9.0-latest", "executionRoleArn": "execution-role-arn", "configurationOverrides": { "applicationConfiguration": [ { "classification": "jupyter-kernel-overrides", "configurations": [ { "classification": "python3", "properties": { "container-image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/custom-notebook-python:latest" } }, { "classification": "spark-python-kubernetes", "properties": { "container-image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/custom-notebook-spark:latest" } } ] } ] } } ``` 1. Crie um endpoint interativo com as configurações especificadas no arquivo JSON, conforme mostrado no exemplo a seguir. Para obter mais informações, consulte [Criação de um endpoint interativo com o comando `create-managed-endpoint`](create-managed-endpoint.md#create-using-json-file). ``` aws emr-containers create-managed-endpoint --cli-input-json custom-image-managed-endpoint.json ``` 1. **Conecte-se ao endpoint interativo usando o EMR Studio.** Para obter mais informações e etapas a serem concluídas, consulte [Conectando-se do Studio](https://emr-on-eks.workshop.aws/advanced/emr-studio/connecting-from-studio.html) na seção Amazon EMR no EKS dos documentos do AWS Workshop Studio.