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á.
# Arquitetura Beanstalk Cluster
O Beanstalk Cluster usa os mesmos conceitos de aplicativo, versão do aplicativo, ambiente e opção de configuração do Elastic Beanstalk que o Beanstalk Standard. Beanstalk Standard é o EC2-based tipo de ambiente. O Beanstalk Cluster usa uma camada de computação e uma superfície de configuração diferentes. Este tópico descreve as diferenças por aspecto e identifica o tipo de ambiente aplicável.
## Modelo computacional
No Beanstalk Standard, o Elastic Beanstalk lança instâncias do Amazon Elastic Compute Cloud (Amazon EC2) em um grupo de Auto Scaling dedicado ao ambiente. O aplicativo é executado diretamente nessas instâncias. Em um ambiente Beanstalk Cluster, o Elastic Beanstalk, em vez disso, executa o aplicativo como uma imagem de contêiner em um cluster Amazon EKS que pode ser compartilhado por seus ambientes Beanstalk Cluster. O Elastic Beanstalk cria e opera o cluster. O Elastic Beanstalk programa o aplicativo no cluster. O Elastic Beanstalk isola cada ambiente no cluster e reconcilia o número de réplicas de aplicativos para corresponder aos valores configurados. Você não cria um cluster, escolhe em qual cluster um ambiente é executado nem seleciona sua versão do Kubernetes.
Vários de seus ambientes podem ser executados no mesmo cluster do Amazon EKS. O Elastic Beanstalk coloca um ambiente no cluster que atende às sub-redes VPC configuradas. Ele cria um cluster na primeira vez que essas sub-redes são usadas; consulte. [Agrupamento de ambientes](#beanstalk-cluster-clusters-sharing) O Amazon EKS Auto Mode fornece capacidade de nós. Ele adiciona e remove nós para caber nos contêineres que estão programados. Como o cluster pode ser compartilhado e a capacidade dos nós é gerenciada pelo Amazon EKS, as contagens de instâncias não são configuradas por meio do `aws:autoscaling:asg` namespace. Em vez disso, o número de réplicas do aplicativo é definido com as `max-replica` opções `min-replica` e no `aws:elasticbeanstalk:eks:environment:autoscaling` namespace. Para saber os limites da réplica e os gatilhos que alteram a contagem de réplicas, consulte. [Dimensionamento de ambientes Beanstalk Cluster](configuring-cluster-scaling.md)
O Elastic Beanstalk resolve a configuração do ambiente a partir das configurações de opção que você fornece e aplica a configuração resolvida ao criar ou atualizar o ambiente. Quando a mesma opção de configuração é fornecida mais de uma vez, a última ocorrência vence. Para alterar a configuração, atualize as configurações da opção.
## Diferenças do Beanstalk Standard
A tabela a seguir resume as diferenças enfrentadas pelo cliente entre o Beanstalk Standard e um ambiente Beanstalk Cluster. Cada linha está vinculada ao tópico que aborda detalhadamente o conceito do Elastic Beanstalk.
| Aspecto | Padrão Beanstalk | Ambiente Beanstalk Cluster |
| --- | --- | --- |
| Computação | Instâncias dedicadas do Amazon EC2 em um grupo de Auto Scaling configurado por meio dos aws:autoscaling:\* namespaces. | Contêineres programados em um cluster Amazon EKS que podem ser compartilhados por seus ambientes do Beanstalk Cluster. O Elastic Beanstalk isola cada ambiente no cluster. Os nós são fornecidos pelo Amazon EKS Auto Mode. |
| Escalabilidade | Instâncias do Amazon EC2 adicionadas e removidas por um grupo de Auto Scaling, com gatilhos e ações agendadas configurados por meio dos namespaces. aws:autoscaling:\* Consulte [Ajuste de escala automático das instâncias do seu ambiente do Elastic Beanstalk](using-features.managing.as.md). | Réplicas de aplicativos adicionadas e removidas dentro dos max-replica limites min-replica e, na CPU, na memória, em um cronograma ou em uma métrica que seu próprio endpoint relata. Consulte [Dimensionamento de ambientes Beanstalk Cluster](configuring-cluster-scaling.md). |
| Artefato de implantação | Um pacote de origem que o Elastic Beanstalk executa em uma AMI de plataforma (pilha de soluções). Consulte [Plataformas compatíveis com Elastic Beanstalk](concepts.platforms.md). | Uma imagem de contêiner no Amazon Elastic Container Registry (Amazon ECR). A imagem é fornecida diretamente ou a fonte é fornecida para o Elastic Beanstalk incorporar a uma imagem. Consulte [Criação de imagens de contêiner para ambientes Beanstalk Cluster](beanstalk-cluster-app-versions.md). |
| Conceito de plataforma | Uma pilha de soluções gerenciadas (sistema operacional, servidor web e tempo de execução de linguagem em uma AMI). Consulte [Plataformas compatíveis com Elastic Beanstalk](concepts.platforms.md). | Sem pilha de soluções ou AMI. O tempo de execução é definido pela imagem do contêiner e pela versão do cluster que o Elastic Beanstalk cria. |
| Política de implantação | All-at-onceimplantações contínuas ou imutáveis configuradas por meio do namespace. aws:elasticbeanstalk:command | Uma atualização contínua (o padrão) ou de uma só vez, configurada com a strategy opção no aws:elasticbeanstalk:eks:environment:deployment namespace. O valor da opção para tudo de uma vez éRecreate. |
| Namespaces de configuração | Namespaces clássicos, como e. aws:autoscaling:\* aws:elasticbeanstalk:environment Consulte [Opções de configuração](command-options.md). | Os aws:elasticbeanstalk:eks:\* namespaces. Nenhum dos namespaces de computação clássicos se aplica. |
| Integridade | Relatado pelo gerenciador de host e balanceador de carga em cada instância. | Per-instance a saúde não é relatada. Com um Application Load Balancer, a integridade inclui as métricas do balanceador de carga que o Elastic Beanstalk avalia. Comload-balancer-type=None, essa avaliação de taxa de solicitação, taxa de erro e latência não se aplica. Consulte [Monitorando ambientes do Beanstalk Cluster](monitoring-cluster-environments.md). |
## Customer-provided e recursos gerenciados por serviços
O Elastic Beanstalk cria e opera o cluster Amazon EKS que executa um ambiente de cluster Beanstalk. As funções de cluster e node AWS Identity and Access Management (IAM) exigidas pelo Amazon EKS são fornecidas pelo cliente. Recomendamos que você use os nomes das funções e as políticas AWS gerenciadas descritas em[Permissões para o Beanstalk Cluster](beanstalk-cluster-permissions.md), pois o Elastic Beanstalk exige que cada ambiente em um cluster forneça as mesmas funções. Uma função de aplicativo também pode ser fornecida para o aplicativo em execução por meio do Amazon EKS Pod Identity. A função do aplicativo é selecionada no console do Elastic Beanstalk durante a criação do ambiente. Para ver o modelo completo de responsabilidade do IAM e o procedimento de função do aplicativo, consulte. [Permissões para o Beanstalk Cluster](beanstalk-cluster-permissions.md)
As sub-redes VPC para o ambiente são opcionais. Quando as sub-redes são omitidas, o Elastic Beanstalk usa as sub-redes públicas da VPC padrão. O conjunto de sub-redes determina qual cluster executa o ambiente. Para a atribuição de clusters e a infraestrutura que o Elastic Beanstalk opera, consulte. [Agrupamento de ambientes](#beanstalk-cluster-clusters-sharing)
O Elastic Beanstalk opera o aplicativo no cluster criado pelo serviço. Ele implanta a imagem do contêiner e aplica atualizações contínuas por meio do `aws:elasticbeanstalk:eks:environment:deployment` namespace. Ele reconcilia o número em execução de réplicas de aplicativos com os `max-replica` limites `min-replica` e na configuração. Ele relata a saúde em nível ambiental por meio dos estados de saúde descritos em. [Monitorando ambientes do Beanstalk Cluster](monitoring-cluster-environments.md) O Elastic Beanstalk rastreia cada cluster ao qual atribui ambientes como gerenciado por serviços.
**Importante**
O Elastic Beanstalk atribui ambientes somente a clusters que correspondam à configuração esperada de gerenciamento de serviços. Se a infraestrutura não corresponder mais a essa configuração, o Elastic Beanstalk interromperá a seleção do cluster para novos ambientes. As mudanças no ambiente são feitas por meio de operações e configurações do Elastic Beanstalk.
## Requisitos e limitações do aplicativo
Um ambiente Beanstalk Cluster exige um aplicativo que possa ser executado como uma imagem de contêiner e como uma ou mais réplicas idênticas e intercambiáveis. Um balanceador de carga é opcional. Quando um balanceador de carga é configurado, ele distribui solicitações entre réplicas de aplicativos. Um serviço web ou API sem estado cujas réplicas não contêm nenhum estado local que deva sobreviver a uma reinicialização atende a esse requisito. A porta de solicitação, as solicitações de CPU e memória, o número de réplicas de aplicativos e o comportamento de implantação são configurados por meio das `aws:elasticbeanstalk:eks:*` opções. O Elastic Beanstalk fornece a capacidade do cluster por meio do Amazon EKS Auto Mode.
Confirme os seguintes requisitos e limitações do aplicativo antes de criar um ambiente Beanstalk Cluster:
+ O armazenamento local não é persistente. Cada cópia do aplicativo tem armazenamento temporário que é perdido quando a cópia é reiniciada. Um aplicativo que grava uploads, caches ou arquivos de trabalho no disco local e exige que eles sobrevivam a uma reinicialização é incompatível sem armazenamento externo persistente.
+ As solicitações são distribuídas entre as réplicas do aplicativo.
+ O Elastic Beanstalk cria uma imagem de contêiner a partir da fonte para os idiomas compatíveis. Você também pode fornecer um Dockerfile ou uma imagem pré-construída. Consulte [Criação de imagens de contêiner para ambientes Beanstalk Cluster](beanstalk-cluster-app-versions.md).
## Exemplo de configuração
A AWS CLI solicitação a seguir define a porta de solicitação, a solicitação de memória, o número de réplicas em execução e o comportamento de implantação para um ambiente Beanstalk Cluster. As configurações usam os `aws:elasticbeanstalk:eks:*` namespaces.
```
$ aws elasticbeanstalk update-environment \
--environment-name my-cluster-env \
--option-settings \
Namespace=aws:elasticbeanstalk:eks:environment,OptionName=service-port,Value=8080 \
Namespace=aws:elasticbeanstalk:eks:environment,OptionName=memory,Value=1Gi \
Namespace=aws:elasticbeanstalk:eks:environment,OptionName=load-balancer-type,Value=ALB \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=3 \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=3 \
Namespace=aws:elasticbeanstalk:eks:environment:deployment,OptionName=strategy,Value=RollingUpdate \
Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-surge,Value=25% \
Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-unavailable,Value=0
```
A `strategy` opção aceita `RollingUpdate` ou`Recreate`, que o console mostra como uma atualização contínua e de uma só vez. Com`RollingUpdate`, `max-surge` limita quantas réplicas extras o Elastic Beanstalk inicia durante uma implantação. A `max-unavailable` opção limita quantas réplicas existentes são removidas por vez. Cada opção aceita uma contagem ou uma porcentagem. O `memory` valor usa a notação de quantidade do Kubernetes, como ou. `1Gi` `512Mi` Para ver o conjunto completo de opções, consulte[Opções de configuração para ambientes Beanstalk Cluster](command-options-general-eks.md).
## Agrupamento de ambientes
O Elastic Beanstalk agrupa seus ambientes Beanstalk Cluster em clusters pelas sub-redes VPC que eles usam:
+ Ambientes na mesma AWS conta que usam o mesmo conjunto de sub-redes são executados no * mesmo * cluster.
+ Um ambiente que usa um conjunto diferente de sub-redes é executado em um cluster * diferente*.
O primeiro ambiente criado com um determinado conjunto de sub-redes faz com que o Elastic Beanstalk crie um cluster para ele, o que leva cerca de dez minutos. O Elastic Beanstalk relata isso nos eventos do ambiente:
```
INFO Creating CloudFormation stack for cluster infrastructure. This is a one-time operation and generally takes about 10 minutes. stack='beanstalk-cluster-{{uuid}}'
INFO Starting cluster assignment. environment='my-cluster-env'
INFO Successfully completed cluster assignment. environment='my-cluster-env' clusterArn='arn:aws:eks:us-east-1:{{111122223333}}:cluster/beanstalk-cluster-{{uuid}}'
```
O Elastic Beanstalk coloca ambientes posteriores que usam as mesmas sub-redes nesse cluster existente. Seus eventos relatam a tarefa sem a mensagem de criação da pilha. O Elastic Beanstalk nomeia o cluster e a AWS CloudFormation pilha que o cria. `beanstalk-cluster-{{uuid}}`
A ordem na qual o Elastic Beanstalk considera as sub-redes não importa; as mesmas sub-redes em uma ordem diferente são o mesmo conjunto. Somente o conjunto de sub-redes seleciona o cluster. Quando um cluster já está registrado para o conjunto de sub-redes, as configurações de função de cluster e nó que você fornece devem corresponder às funções registradas para esse cluster. O Elastic Beanstalk rejeita configurações de função conflitantes; ARNs de funções diferentes não selecionam um cluster diferente. Você também fornece a função de observabilidade, e o Elastic Beanstalk a valida em relação ao cluster da mesma forma. A função opcional do aplicativo pertence ao ambiente e pode diferir entre os ambientes. Configure-o com o procedimento de criação de ambiente em. [Configurar uma função de aplicativo](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-application-role)
O Elastic Beanstalk não limita quantos ambientes compartilham um cluster. O Amazon EKS Auto Mode adiciona nós para caber nos contêineres programados no cluster. O compartilhamento de clusters não adiciona um limite de escalabilidade específico do ambiente. Cada ambiente permanece sujeito aos limites configurados de réplica ou escalonamento automático, às cotas de serviço aplicáveis e à capacidade disponível. Para executar um ambiente em um cluster separado, crie-o com um conjunto diferente de sub-redes.
**Importante**
Você não pode alterar as sub-redes ou as funções de cluster, nó e observabilidade de um ambiente existente do Beanstalk Cluster. O Elastic Beanstalk rejeita essa atualização em vez de mover seu ambiente para um cluster diferente e relata: `Changes to EKS cluster configuration (subnets and IAM roles) are not currently supported for an existing environment. Please revert these option settings to continue.` Para mover um aplicativo para diferentes sub-redes ou funções, crie um novo ambiente com as configurações desejadas e, em seguida, troque os dois CNAMEs do ambiente. Consulte [Blue/Green implantações com o Elastic Beanstalk](using-features.CNAMESwap.md). Decida quais sub-redes e funções de cluster um ambiente usa ao criá-lo. Consulte [Começando com o Beanstalk Cluster](beanstalk-cluster-getting-started.md).
## Isolamento entre ambientes que compartilham computação
As sub-redes são o principal limite entre os ambientes. Como o conjunto de sub-redes seleciona o cluster, dar a um grupo de ambientes suas próprias sub-redes dá a esse grupo seu próprio cluster, seus próprios nós e sua própria rede. Em um único cluster, o Elastic Beanstalk isola o tráfego de rede entre os ambientes do Beanstalk Cluster por padrão, e as opções no `aws:elasticbeanstalk:eks:environment` namespace permitem que ambientes específicos se comuniquem ou coloquem um ambiente em nós dedicados.
Para o limite que cada opção oferece, as opções que o ampliam e o que um cluster compartilhado não separa, consulte. [Multi-tenancy para ambientes Beanstalk Cluster](beanstalk-cluster-multi-tenancy.md)
## Configuração de infraestrutura gerenciada
O Elastic Beanstalk cria cada cluster com uma configuração fixa que você não escolhe:
| Configuração | O que o Elastic Beanstalk configura |
| --- | --- |
| Versão do Kubernetes | O Elastic Beanstalk seleciona a versão na criação do cluster. O Elastic Beanstalk cria um novo cluster com a versão mais recente do Kubernetes que ele suporta. Um ambiente em um cluster existente executa a versão que o cluster já tem. Essa versão permanece fixa durante toda a vida útil do cluster. |
| Capacidade do nó | Modo automático do Amazon EKS, que adiciona e remove nós para caber nos contêineres programados no cluster. Node-capacity a configuração é gerenciada pelo serviço. |
| Acesso à infraestrutura do cluster | Service-managed. Configure o ambiente por meio da API do Elastic Beanstalk AWS CLI, do console ou do Elastic Beanstalk. |
| Complementos de cluster | O Elastic Beanstalk instala e fixa os complementos dos quais seu ambiente depende. Quando o Elastic Beanstalk introduz uma nova versão fixa do complemento, ele aplica a atualização ao seu cluster durante a criação ou atualização subsequente do ambiente. Você não planeja nem aplica a atualização sozinho. |
Como o Elastic Beanstalk os define sozinho, você configura seu * aplicativo * por meio das `aws:elasticbeanstalk:eks:*` opções em vez de configurar o cluster. Consulte [Opções de configuração para ambientes Beanstalk Cluster](command-options-general-eks.md).
## Desvio na configuração do cluster
O Elastic Beanstalk opera um cluster criado somente enquanto esse cluster corresponde à configuração esperada de gerenciamento de serviços. Se a infraestrutura não corresponder mais a essa configuração, o Elastic Beanstalk detecta desvios na configuração, pausa a manutenção do cluster e relata um evento do ambiente:
```
ERROR Cluster drift detected for environment 'my-cluster-env'. {{what changed}}. Service will skip cluster maintenance for this environment.
```
Enquanto um cluster está à deriva:
+ O Elastic Beanstalk não coloca novos ambientes nele.
+ O Elastic Beanstalk não o mantém mais, incluindo atualizações de versões complementares gerenciadas pelo serviço.
+ As atualizações nos ambientes que já estão em execução falham.
A deriva é recuperável. Para se recuperar, reverta a alteração que a causou, para que o cluster corresponda novamente à configuração que o Elastic Beanstalk espera. O evento de deriva nomeia o que mudou, o que indica o que reverter. O Elastic Beanstalk reavalia o cluster na próxima operação do ambiente e retoma o gerenciamento quando a configuração coincide. Tente novamente a operação que falhou.
Se você não conseguir restaurar a configuração esperada, entre em contato com o AWS Suporte.
Para evitar desvios, faça alterações no ambiente por meio de operações e opções de configuração do Elastic Beanstalk, em vez de alterar diretamente o cluster. Consulte [Opções de configuração para ambientes Beanstalk Cluster](command-options-general-eks.md).
## Exclusão de cluster
O Elastic Beanstalk agenda a exclusão do cluster três horas após você encerrar seu último ambiente. Se você criar outro ambiente com as mesmas sub-redes durante esse intervalo, o Elastic Beanstalk cancela a limpeza pendente e reutiliza o cluster existente.
**Para verificar a exclusão da infraestrutura gerenciada pelo serviço**
1. Antes de encerrar o último ambiente, registre o ARN do cluster por meio do Elastic Beanstalk. Para a infraestrutura de cluster criada pelo serviço, o CloudFormation modelo define o nome do cluster como o nome da pilha. Portanto, o nome após a barra final do ARN do cluster identifica a pilha para a verificação de exclusão somente para leitura neste procedimento:
```
$ aws elasticbeanstalk describe-environment-resources \
--environment-name my-cluster-env \
--query 'EnvironmentResources.Cluster.Name'
```
O comando retorna o ARN do cluster. O nome da pilha é a parte do ARN após a barra final.
**Importante**
O nome da pilha derivada é apenas para o CloudFormation garçom somente para leitura e descreve as operações mostradas abaixo. Não o transmita para `delete-stack``update-stack`, nem para qualquer outra operação que altere a infraestrutura gerenciada pelo serviço.
Registre o ARN do cluster e o nome da pilha derivada; você os usa para as etapas de verificação somente para leitura a seguir.
1. Encerre o ambiente e verifique se ele chega `Terminated` seguindo as etapas em[Encerrar um ambiente do Elastic Beanstalk](using-features.terminating.md). A limpeza do cluster começa separadamente após o intervalo de reutilização de três horas; o encerramento do ambiente não espera pela exclusão do cluster.
1. Depois de três horas, use um principal do IAM com permissão para descrever a pilha criada pelo serviço. O CloudFormation garçom usa descrições de pilha somente para leitura a cada 30 segundos por até 60 minutos e é bem-sucedido quando a pilha não existe mais:
```
$ aws cloudformation wait stack-delete-complete \
--stack-name {{cluster-stack-name}}
```
O garçom é bem-sucedido quando a pilha não existe mais. Se falhar, a pilha ainda existirá após o prazo; use `aws cloudformation describe-stacks` e `aws cloudformation describe-stack-events` para inspecionar o status da pilha e quaisquer eventos. `DELETE_FAILED`
1. Se o garçom informar que a pilha ainda existe após o prazo, determine se outro ambiente reutilizou o cluster. Liste os ambientes ativos do Beanstalk Cluster na conta e na região:
```
$ aws elasticbeanstalk describe-environments \
--query "Environments[?Tier.Name=='Cluster' && Tier.Type=='EKS'].EnvironmentName"
```
Para cada ambiente listado, leia o ARN do cluster:
```
$ aws elasticbeanstalk describe-environment-resources \
--environment-name {{environment-name}} \
--query 'EnvironmentResources.Cluster.Name'
```
Um ambiente cujo ARN do cluster corresponde ao ARN do cluster registrado significa que a exclusão foi cancelada para reutilização. Se nenhum ambiente corresponder, use o status e os `DELETE_FAILED` eventos da pilha para diagnosticar os recursos retidos. Não exclua nem modifique manualmente uma pilha gerenciada por serviços. Entre em contato com o AWS suporte se a pilha permanecer após o prazo sem um ambiente ativo ou uma falha acionável CloudFormation .