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á.
Multi-tenancy para ambientes Beanstalk Cluster
Os ambientes do Beanstalk Cluster que usam as mesmas sub-redes são executados no mesmo cluster do Amazon EKS, portanto, compartilham a infraestrutura de computação. O Elastic Beanstalk os separa nesse cluster compartilhado: o aplicativo de cada ambiente é executado em sua própria partição do cluster, e o Elastic Beanstalk bloqueia o tráfego de rede entre ambientes por padrão. Este tópico descreve a separação que você obtém, como ampliá-la ou reduzi-la e quais requisitos um cluster compartilhado não pode satisfazer.
O isolamento entre ambientes do Beanstalk Cluster tem duas dimensões independentes. O isolamento de rede controla quais ambientes podem enviar tráfego para o aplicativo de um ambiente. O isolamento computacional controla se as réplicas de aplicativos de um ambiente compartilham nós com outros ambientes. Você pode configurar qualquer um sem o outro.
Escolhendo um limite de isolamento
Decida a força de um limite que um ambiente precisa antes de criá-lo, porque a escolha é feita por meio das sub-redes que você atribui e você não pode alterar as sub-redes de um ambiente existente. Dois limites estão disponíveis e correspondem aos dois modelos de multilocação documentados pelo Amazon EKS.
| Limite | Como você consegue | O que ele separa |
|---|---|---|
| Cluster compartilhado (multilocação flexível) | Crie os ambientes com o mesmo conjunto de sub-redes. Esse é o padrão quando os ambientes compartilham uma configuração de VPC. | O aplicativo de cada ambiente é executado em sua própria partição do cluster, com o tráfego de rede entre ambientes bloqueado por padrão. Os ambientes compartilham o cluster em si e compartilham nós, a menos que você configure nós dedicados. |
| Clusters separados (multilocação rígida) | Crie os ambientes com diferentes conjuntos de sub-redes. Em seguida, o Elastic Beanstalk cria um cluster separado para cada conjunto. | Nada é compartilhado. Clusters separados têm planos de controle separados, nós separados e nenhum caminho de rede entre os aplicativos em execução neles. |
Um cluster compartilhado fornece separação lógica entre ambientes, imposta pela configuração que o Elastic Beanstalk aplica ao cluster. Um cluster separado fornece separação de infraestrutura. O Amazon EKS documenta o cluster como a construção que fornece um forte limite de segurança, porque uma carga de trabalho que obtivesse acesso a um nó poderia alcançar as credenciais e os dados de qualquer outra coisa em execução nesse nó. A separação lógica dentro de um cluster é multilocação flexível; um cluster para cada locatário é multilocação rígida. Para obter a orientação geral que isso reflete, consulte Isolamento de inquilinos no Guia de melhores práticas do Amazon EKS.
Importante
Use conjuntos de sub-redes separados e, portanto, clusters separados quando os ambientes executam cargas de trabalho que não devem compartilhar a infraestrutura. Os exemplos incluem ambientes que pertencem a diferentes clientes finais da sua empresa, ambientes que executam código que você não controla e ambientes no escopo de um regime de conformidade que exige a separação da infraestrutura. Os controles descritos no restante deste tópico separam ambientes em um cluster compartilhado, mas não tornam um cluster compartilhado equivalente a clusters separados.
Clusters separados custam mais e usam a capacidade com menos eficiência, porque cada cluster é cobrado separadamente e os nós não podem ser compartilhados entre clusters. Um cluster compartilhado é a escolha certa para ambientes que uma equipe possui e opera em conjunto, como os serviços que compõem um único aplicativo. Separar a produção do desenvolvimento é um motivo comum para usar conjuntos de sub-redes diferentes, mesmo quando nada exige isso. Para saber como o Elastic Beanstalk agrupa ambientes em clusters, consulte. Agrupamento de ambientes Para ver as configurações de sub-rede em si, consulteConfigurando redes para ambientes Beanstalk Cluster.
Isolamento de rede em um cluster compartilhado
Por padrão, o Elastic Beanstalk bloqueia o tráfego de rede entre os ambientes do Beanstalk Cluster em um cluster compartilhado. Nenhuma configuração é necessária para obter isso e não há opção que a desative. As réplicas de aplicativos de um ambiente não podem receber tráfego das cópias de aplicativos de outro ambiente em nenhuma porta, a menos que você permita isso com uma das opções desta seção.
O Elastic Beanstalk permite que seus próprios componentes operacionais cheguem ao seu aplicativo, para que os relatórios de saúde, a coleta de registros e o escalonamento baseado em métricas continuem funcionando.
O tráfego que chega a um ambiente por meio de seu balanceador de carga não é afetado. O bloqueio se aplica ao tráfego enviado das réplicas de aplicativos de um ambiente diretamente para o de outro, não ao tráfego que chega de fora do cluster. As solicitações que chegam ao seu aplicativo por meio do Application Load Balancer são entregues normalmente, incluindo solicitações que outro ambiente envia ao endpoint público desse balanceador de carga.
Permitindo que ambientes se comuniquem
Três opções no aws:elasticbeanstalk:eks:environment namespace permitem o tráfego entre ambientes em um cluster compartilhado. Cada um usa uma lista separada por vírgulas. Os nomes são limitados aos caracteres a-zA-Z,0-9, e-; eles devem começar com uma letra e ter de 4 a 40 caracteres. Alterar nenhum deles não interrompe o ambiente.
| Opção | Efeito | Use-o quando |
|---|---|---|
ingress-groups |
Une o ambiente a um ou mais grupos nomeados. Cada ambiente em um grupo pode enviar tráfego para todos os outros ambientes desse grupo, em ambas as direções. Um ambiente pode pertencer a mais de um grupo. | Todos um conjunto de ambientes precisa ligar uns para os outros, como os serviços de um aplicativo. |
ingress-allowlist-environments |
Permite que os ambientes nomeados enviem tráfego para esse ambiente. A permissão é uma forma: nomear um ambiente aqui não permite que esse ambiente o chame. | Um ambiente serve uma API interna que outros ambientes específicos chamam. |
ingress-allowlist-groups |
Permite que cada ambiente nos grupos nomeados envie tráfego para esse ambiente, de uma forma, sem se juntar a esses grupos. | Um ambiente atende a um conjunto de chamadores que já compartilham um grupo e não devem obter acesso a eles em troca. |
Definido ingress-groups em cada ambiente que se junta ao grupo; a associação ao grupo não é configurada em um só lugar. Um ambiente deixa um grupo quando você remove o grupo de seu ingress-groups valor ou encerra o ambiente. Defina as opções da lista de permissões no ambiente que recebe o tráfego, nomeando os chamadores que você deseja permitir.
Os dois mecanismos se combinam. Um ambiente pode se juntar a um grupo para os serviços com os quais trabalha como um par e permitir separadamente um chamador que deve alcançá-lo de uma maneira. Para saber como definir opções de configuração em um ambiente, consulteOpções de configuração.
Permitir tráfego não configura a descoberta. Seu aplicativo ainda precisa saber qual endereço chamar, que você fornece da mesma forma que fornece qualquer outra configuração, por meio de uma propriedade de ambiente. O Elastic Beanstalk não injeta os endereços dos ambientes que você permite.
Nodes dedicados para um ambiente
Por padrão, o Elastic Beanstalk programa réplicas de aplicativos de qualquer ambiente para a capacidade de nós compartilhados do cluster, para que cópias de diferentes ambientes possam ser executadas no mesmo nó. Para manter as réplicas de aplicativos de um ambiente em nós que nenhum outro ambiente usa, defina a node-pool opção no aws:elasticbeanstalk:eks:environment namespace com um nome de sua escolha.
O Elastic Beanstalk então reserva um conjunto de nós para esse nome e agenda somente réplicas de aplicativos de ambientes com o mesmo valor. node-pool Ambientes que não definem nenhum valor ou um valor diferente não podem ser colocados nesses nós.
Importante
Ambientes que compartilham um node-pool valor compartilham nós uns com os outros. Para dar a um único ambiente nós que nada mais usa, atribua a ele um valor que nenhum outro ambiente usa.
A alteração node-pool reinicia as réplicas de aplicativos do ambiente para que o Elastic Beanstalk possa reprogramá-las nos nós corretos. Os nós dedicados também reduzem o efeito do uso de recursos de um ambiente sobre outro, porque os ambientes não competem mais pela CPU e pela memória do mesmo nó. Os nós dedicados são independentes do isolamento da rede: os ambientes podem ser executados em nós separados e ainda ter permissão para se comunicar, ou compartilhar nós e serem impedidos de se comunicar.
Reserve node-pool para um requisito que diz respeito especificamente à capacidade do nó. Se seu objetivo é separar os ambientes uns dos outros, fornecer a eles sub-redes diferentes é mais simples e separa o cluster e os nós.
O que um cluster compartilhado não separa
Entenda esses limites antes de colocar ambientes com diferentes requisitos de segurança ou conformidade no mesmo cluster. Cada um deles é uma consequência do compartilhamento de um cluster entre os ambientes, e cada um é removido dando aos ambientes diferentes sub-redes para que o Elastic Beanstalk crie clusters separados.
-
O tráfego de saída não é restrito. A separação padrão bloqueia o tráfego que chega a um ambiente. Ela não restringe para onde o aplicativo de um ambiente pode enviar tráfego. Um aplicativo pode alcançar qualquer destino permitido pela configuração de rede e pelas permissões do IAM, incluindo a Internet e outros AWS serviços. Não há opção que restrinja o tráfego de saída de um ambiente Beanstalk Cluster.
-
O plano de controle do cluster é compartilhado. Cada ambiente no cluster é servido por um plano de controle do Amazon EKS, e sua versão do Kubernetes é fixa durante toda a vida útil do cluster. O Elastic Beanstalk opera o plano de controle e você não o configura, mas ele não é duplicado por ambiente.
-
Os nós são compartilhados, a menos que você configure nós dedicados. Sem
node-poolisso, as réplicas de aplicativos de diferentes ambientes são executadas nos mesmos nós e usam a mesma CPU e memória. O Elastic Beanstalk não reserva capacidade de nós por ambiente. -
Cluster-wide as falhas afetam todos os ambientes do cluster. Se o Elastic Beanstalk parar de gerenciar um cluster porque sua infraestrutura não corresponde mais à configuração esperada, as atualizações falharão em todos os ambientes desse cluster até que o desvio seja resolvido. A recuperação é por cluster e não por ambiente: reverta a alteração que a causou e o Elastic Beanstalk retomará o gerenciamento do cluster e de todos os seus ambientes. Consulte Desvio na configuração do cluster.
Application-level as proteções são de sua responsabilidade em qualquer limite. A separação de rede entre ambientes não autentica chamadores, criptografa o tráfego entre ambientes nem restringe o que um aplicativo faz com as credenciais que possui. Dê a cada ambiente sua própria função de aplicativo para que suas AWS permissões tenham como escopo, e trate o tráfego permitido entre ambientes como tráfego que seu aplicativo ainda precisa autorizar. Consulte Permissões para aplicativos.
Combinando um requisito com um controle
| Requisito | Controle |
|---|---|
| Os ambientes não devem compartilhar a infraestrutura | Crie-os com diferentes conjuntos de sub-redes, para que o Elastic Beanstalk crie um cluster separado para cada uma. Decida isso antes de criar os ambientes; você não pode alterar as sub-redes depois. |
| Os ambientes não devem se comunicar pela rede | Sem configuração. Esse é o padrão em um cluster compartilhado. |
| Um conjunto de ambientes deve se chamar | ingress-groupsDefina com o mesmo nome de grupo em cada um deles. |
| Um ambiente deve aceitar chamadas de outros específicos, mas não o contrário | Defina ingress-allowlist-environmentsingress-allowlist-groups, ou, no ambiente que recebe o tráfego. |
| As réplicas de aplicativos de um ambiente não devem compartilhar nós com outros ambientes | node-poolDefina como um valor que nenhum outro ambiente usa. |
| O tráfego de saída de um ambiente deve ser restrito | Não disponível por meio de uma opção de configuração. Restrinja-o no aplicativo ou por meio da configuração de rede das sub-redes que você atribui ao ambiente. |
