Flexibilidade aprimorada da VPC: modifique sub-redes e grupos de segurança no Amazon EKS

Por Jeremy Cowan, Gokul Chandra e Mike Stefaniak

Introdução

Com o Amazon Elastic Kubernetes Service (Amazon EKS), os usuários podem modificar a configuração do cluster antes e depois da criação do cluster sem precisar criar um novo cluster. Antes de provisionar o cluster, os usuários podem definir parâmetros específicos, como a versão do Kubernetes, a VPC e as sub-redes e as preferências de registro. Após a criação, eles podem ajustar dinamicamente várias configurações, como:

• Modificar quais registros do plano de controle são enviados para o Amazon CloudWatch.
• Ajustando o acesso público ao endpoint alterando os blocos CIDR (Classless Inter-Domain Routing) e alternando a visibilidade do servidor público da API.
• Alternando a acessibilidade do endpoint privado dentro da VPC (Virtual Private Cloud).
• Refinando funções e políticas do AWS Identity and Access Management (AWS IAM) por meio do aws-auth ConfigMap.
• Gerenciando complementos como a VPC CNI (Container Network Interface) e alterar rótulos de cluster.
• Ativar a criptografia do AWS Key Management Service (AWS KMS) para segredos do Kubernetes, se não for feito inicialmente.
• Atualizar a versão do Kubernetes para as mais recentes compatíveis.
• Ajustando políticas de endpoint para o servidor Amazon EKS API (Application Programming Interface).
• Habilitando um provedor OIDC (OpenID Connect).

Embora o Amazon EKS seja altamente configurável, certos parâmetros definidos anteriormente no momento da criação do cluster não podiam ser alterados sem a criação de um novo cluster. Notavelmente, as sub-redes e os grupos de segurança que foram associados ao cluster. Agora, o Amazon EKS aumentou seu nível de flexibilidade pós-cluster, e o Amazon EKS oferece suporte à mudança de sub-redes de cluster e grupos de segurança.

Visão geral da solução

O que é uma sub-rede de cluster?

Uma sub-rede de cluster no contexto do Amazon EKS se refere às sub-redes específicas que você escolhe ao criar seu cluster Amazon EKS. Embora os nós subjacentes desse plano de controle sejam gerenciados pela AWS e sejam invisíveis para o usuário, existem certos componentes de rede, como as interfaces de rede elástica (ENIs) entre contas, que são implantadas automaticamente nas sub-redes do cluster.

Ao criar um cluster, você especifica uma VPC e pelo menos duas sub-redes que estão em diferentes zonas de disponibilidade (AZs), o plano de controle é provisionado em uma VPC gerenciada pela AWS, enquanto os nós (ou seja, instâncias do Amazon Elastic Compute Cloud [Amazon EC2]) são executados na conta VPC do usuário. Para conseguir essa comunicação entre contas, os ENIs da conta de serviço do Amazon EKS são colocados nas sub-redes de cluster especificadas. Essas ENIs facilitam a comunicação bidirecional necessária entre o plano de controle na conta gerenciada pela AWS e os nós em sua conta. Essas interfaces de rede também habilitam recursos do Kubernetes, como kubectl exec e kubectl logs. Cada interface de rede criada pelo Amazon EKS tem o texto Amazon EKS cluster-name em sua descrição.

O Amazon EKS pode criar suas interfaces de rede em qualquer sub-rede que você especificar ao criar um cluster. Anteriormente, você não podia alterar em quais sub-redes o Amazon EKS cria suas interfaces de rede após a criação do cluster. Para controlar em quais sub-redes as interfaces de rede são criadas, você pode limitar o número de sub-redes que você especifica a apenas duas ao criar um cluster.

Passo a passo

Um equívoco comum é que as sub-redes de cluster escolhidas ao criar um cluster Amazon EKS servem como alvos principais para os nós e os usuários só podem usar essas sub-redes para criar os nós (ou seja, nós do Kubernetes). Em vez de serem as sub-redes designadas para nós, as sub-redes de cluster têm uma função distinta de hospedar ENIs entre contas, conforme especificado acima. Portanto, embora seja comum equiparar sub-redes de cluster e sub-redes de nós como sinônimos, reconhecer suas diferenças é essencial.

Embora colocar ENIs entre contas para que a comunicação entre nós e o plano de controle seja uma função principal das sub-redes de cluster, elas também podem desempenhar outras funções com base em sua configuração:

• Se você não especificar sub-redes separadas para nós, elas poderão ser implantadas nas mesmas sub-redes que suas sub-redes de cluster. Os nós e os recursos do Kubernetes podem ser executados nas sub-redes do cluster, mas isso não é recomendado. Durante as atualizações do cluster, o Amazon EKS provisiona ENIs adicionais nas sub-redes do cluster. Quando seu cluster se expande, os nós e pods podem consumir os IPs disponíveis na sub-rede do cluster. Portanto, para garantir que haja Ips disponíveis suficientes, convém considerar o uso de sub-redes de cluster dedicadas com máscara de rede /28.
• Com o controlador do AWS Load Balancer, você pode escolher as sub-redes específicas nas quais os balanceadores de carga podem ser implantados ou usar o recurso de descoberta automática marcando as sub-redes. As sub-redes de cluster ainda podem ser usadas para balanceadores de carga, mas essa não é uma prática recomendada, pois pode levar à exaustão do IP, semelhante ao caso anterior.

Os nós não estão restritos às sub-redes do cluster. Se os nós de trabalho estiverem em uma sub-rede diferente, eles precisarão de regras de roteamento e grupos de segurança apropriados para garantir que possam alcançar o ponto final do plano de controle. Essa comunicação é fundamental para que os nós se juntem ao cluster e para as operações de gerenciamento contínuas; no entanto, com essa adaptabilidade, vem uma nota de cautela.

• O Amazon EKS não cria automaticamente novas ENIs em sub-redes que não foram designadas como sub-redes de cluster durante a configuração inicial do cluster. Se você tiver nós de trabalho em sub-redes diferentes das sub-redes do cluster original (ou seja, onde as ENIs entre contas estão localizadas), elas ainda poderão se comunicar com o plano de controle do Amazon EKS se houver rotas locais na VPC que permitam esse tráfego. Essencialmente, os nós de trabalho precisam ser capazes de resolver e alcançar o endpoint do servidor de API Amazon EKS. Essa configuração pode envolver o trânsito pelas sub-redes com as ENIs, mas é o roteamento interno da VPC que torna isso possível.

Veja a seguir um exemplo de como pode ser a tabela de rotas da sua sub-rede privada. 10.0.0.0/16 representa o bloco CIDR para toda a sua VPC, que varia de acordo com a configuração real da VPC. As sub-redes devem ter comunicação direta ou roteada com as sub-redes do cluster em que as ENIs entre contas estão hospedadas.

A seguir está um exemplo de grupos de segurança para os nós de trabalho que permitem o tráfego do plano de controle gerenciado do Amazon EKS e o tráfego entre todas as sub-redes dentro de um cluster VPC.

• A AWS permite que você associe blocos CIDR adicionais à sua VPC de cluster existente, o que aumenta efetivamente o pool de endereços IP à sua disposição. Essa expansão pode ser feita adicionando mais intervalos de IP privados (por exemplo, RFC 1918) ou, se necessário, públicos (não RFC 1918). Quando você adiciona novos blocos CIDR à sua VPC, há um período de propagação antes que esses intervalos de CIDR sejam reconhecidos e utilizáveis pelo Amazon EKS. Pode levar até cinco horas para que uma associação de bloco CIDR seja reconhecida pelo Amazon EKS. Esse atraso significa que, mesmo depois de adicionar com sucesso o novo bloco CIDR, você deve esperar até quatro horas antes de esperar que os serviços dentro da VPC criem e operem sem problemas novos nós, pods ou serviços usando endereços IP do novo intervalo. Portanto, se você está considerando uma expansão da infraestrutura ou a introdução de novos nós em sub-redes com novos blocos CIDR, é crucial considerar esse atraso e planejar suas implantações adequadamente.

O que é um grupo de segurança de cluster gerenciado pelo Amazon EKS?

Quando você cria um cluster, o Amazon EKS cria um grupo de segurança chamado eks-cluster-sg- -uniqueID. O Amazon EKS associa esse grupo de segurança de cluster gerenciado às ENIs de contas cruzadas gerenciadas. O EKS também anexa esse grupo de segurança por padrão aos nós criados por grupos de nós gerenciados e pelo Fargate (se você não especificar grupos de segurança personalizados com esses recursos). As regras padrão permitem que todo o tráfego flua livremente entre seu cluster e os nós e permitem que todo o tráfego de saída chegue a qualquer destino. Esse grupo de segurança é diferente do grupo de segurança padrão que vem com sua VPC.

As informações do grupo de segurança do cluster podem ser encontradas na seção Rede do console do Amazon EKS, conforme mostrado na imagem anterior. O diagrama a seguir ilustra a sub-rede do cluster:

Quando o Amazon EKS cria o grupo de segurança padrão para o plano de controle do cluster, ele pré-configura as regras de entrada e saída necessárias para garantir que o plano de controle do Amazon EKS possa operar corretamente e se comunicar com os serviços necessários da AWS, bem como com os nós.

As regras de entrada padrão incluem todo o acesso de dentro do grupo de segurança e do grupo de segurança do nó compartilhado, o que permite a comunicação bidirecional entre o plano de controle e os nós. Atualmente, essas regras não podem ser excluídas ou modificadas. Se você remover a regra de entrada padrão, o Amazon EKS a recriará sempre que o cluster for atualizado.

A regra de saída padrão do grupo de segurança do cluster permite todo o tráfego. Opcionalmente, os usuários podem remover essa regra de saída e limitar as portas abertas entre o cluster e os nós. Você pode remover a regra de saída padrão e adicionar as regras mínimas necessárias para o cluster.

No entanto, embora você não possa alterar as regras padrão do grupo de segurança, a AWS permite que você associe grupos de segurança adicionais ao plano de controle do Amazon EKS. Esses grupos de segurança adicionais gerenciados pelo cliente fornecem um nível de flexibilidade, que permite personalizar ainda mais o acesso se você tiver requisitos específicos além da configuração padrão. Vale ressaltar que, embora a AWS gerencie o grupo de segurança padrão para o plano de controle, os grupos de segurança dos nós normalmente estão sob seu controle e devem ser configurados para garantir uma comunicação segura e funcional com o plano de controle e outros recursos. Isso não é necessário ao usar grupos de nós gerenciados e o Fargate, pois, por padrão, o grupo de segurança do cluster é aplicado aos nós para permitir a união bem-sucedida ao cluster. Para obter mais informações, consulte a documentação da AWS sobre os requisitos e considerações do grupo de segurança do Amazon EKS.

A AWS está ciente da solicitação de recurso para permitir que os usuários pulem a criação de um grupo de segurança de cluster gerenciado pelo Amazon EKS para que possam ter controle total sobre seus grupos de segurança de cluster. Estamos pesquisando essa solicitação e é possível que adicionemos esse recurso no futuro. Se adicionarmos esse recurso, forneceremos orientações sobre as regras de entrada e saída necessárias para permitir a conectividade dos nós da sua conta com o plano de controle gerenciado.

Novo: adição e remoção dinâmicas de sub-redes de cluster

Agora, os administradores de cluster podem ajustar suas sub-redes e grupos de segurança de cluster com facilidade. O que isso significa? Bem, sempre que houver alterações nos recursos da VPC, seja para expandir a VPC, melhorar a segurança ou planejar eventos imprevistos, os administradores não precisam recriar clusters do zero.

Com o novo recurso, você pode ajustar convenientemente um cluster existente para se alinhar a quaisquer alterações nos recursos básicos da VPC e nos grupos de segurança associados ao cluster. A opção de ajustar sub-redes de cluster e grupos de segurança, mesmo após a criação inicial do seu cluster Amazon EKS, oferece um maior grau de flexibilidade. Isso é particularmente útil em cenários em que um recurso de VPC (seja uma sub-rede ou um grupo de segurança) vinculado a um cluster é excluído em um cenário em que não há objetos secundários, como nós ou recursos do Kubernetes vinculados a essas entidades. No passado, essas ações impediam que os clusters fossem atualizados para versões mais recentes do Kubernetes quando o Amazon EKS não conseguia encontrar as sub-redes do cluster em que o processo envolvia a exclusão das interfaces de rede originais inicialmente criadas e a criação de novas interfaces de rede. Outro cenário comum que pode ser resolvido por esse recurso é quando você fica sem endereços IP inesperadamente nas sub-redes do cluster devido a um planejamento inicial insuficiente. Agora você pode ajustar convenientemente um cluster existente para se alinhar a qualquer alteração nos recursos básicos da VPC. Isso não só economiza tempo, mas também garante operações mais suaves.

Essa flexibilidade no ajuste de sub-redes de cluster e grupos de segurança é usada por meio da API UpdateClusterConfiguration do Amazon EKS. Ao atualizar, os clientes inserem os IDs da sub-rede e do grupo de segurança no segmento de recursos de VPC da API. Uma coisa importante a ser observada é que, durante uma atualização, as sub-redes ainda devem ser consistentes com o conjunto original de AZs da criação do cluster e os grupos de segurança devem fazer parte da VPC do cluster.

O exemplo abaixo mostra como os usuários podem usar o novo recurso usando o console do Amazon EKS e a interface da linha de comando da AWS (AWS CLI). A configuração também é compatível com o AWS CloudFormation e o eksctl.

Agora, os usuários podem usar a opção Gerenciar recursos de VPC disponível na seção Rede do console do Amazon EKS para adicionar ou excluir sub-redes. O cluster de amostra a seguir foi criado usando duas sub-redes de duas AZs diferentes (ou seja, o requisito mínimo para criar um cluster Amazon EKS).

Quando duas sub-redes são fornecidas inicialmente durante a criação do cluster, o Amazon EKS cria duas ENIs entre contas criadas nas sub-redes do cluster selecionadas.

A seção Rede mostra as sub-redes e os grupos de segurança atuais associados ao cluster e, junto com a opção Gerenciar acesso ao endpoint, uma nova opção é adicionada ao console chamada Gerenciar recursos de VPC.

O campo de seleção de sub-redes fornece uma lista de sub-redes disponíveis para serem adicionadas às sub-redes do cluster. As considerações para a seleção da sub-rede são:

• As sub-redes fornecidas devem pertencer ao mesmo conjunto de AZs que são selecionadas durante a criação do cluster.
• As sub-redes fornecidas devem pertencer à mesma VPC fornecida durante a criação do cluster.

Ao usar o console, essas restrições são contabilizadas. Por exemplo, o menu suspenso lista apenas as sub-redes que atendem aos critérios. Se um usuário estiver usando API, AWS CLI ou qualquer outro método compatível, os requisitos mencionados acima precisam ser considerados.

Os usuários podem selecionar uma ou mais sub-redes que atendam aos critérios no menu suspenso.

Depois que as sub-redes são selecionadas, os usuários precisam confirmar a seleção.

Os clusters permanecem totalmente acessíveis durante a atualização. As atualizações do cluster são assíncronas e devem ser concluídas em alguns minutos. Durante uma atualização, o status do cluster passa para UPDATING (essa transição de status é eventualmente consistente). Quando a atualização for concluída (FALHA ou BEM-SUCEDIDA), o status do cluster será movido para ATIVO. Opcionalmente, os usuários podem verificar o status na seção Histórico de atualizações e essa seção também fornece os detalhes dos erros, se houver.

Depois que a atualização for concluída, os usuários poderão usar a seção Rede para validar a adição ou exclusão das sub-redes.

Os ENIs entre contas são configurados automaticamente com base nas sub-redes adicionadas sem qualquer intervenção manual.

Adicionar ou remover grupos de segurança associados ao cluster (console do Amazon EKS)

Semelhante à adição e exclusão de sub-redes, os usuários também podem adicionar ou remover os grupos de segurança associados ao cluster na seção Gerenciar recursos da VPC, conforme mostrado no diagrama anterior.

O campo de seleção do grupo de segurança fornece uma lista dos grupos de segurança disponíveis para serem adicionados ao cluster como grupos de segurança adicionais. As considerações para a seleção do grupo de segurança são:

• Os grupos de segurança fornecidos devem pertencer à mesma VPC fornecida durante a criação do cluster.
• O EKS Cluster Security Group não pode ser adicionado como um grupo de segurança adicional e não pode ser removido.

Ao usar o console, esses requisitos já são considerados, pois a lista suspensa exibe apenas os grupos de segurança que atendem a esses requisitos. Se um usuário estiver usando API, AWS CLI ou qualquer outro método compatível, os requisitos mencionados acima devem ser considerados.

A adição e a exclusão de grupos de segurança também são realizadas como uma ação de atualização e, quando a atualização for concluída, os usuários poderão usar a seção Rede e a seção de grupos de segurança adicionais para validar a adição e a exclusão dos grupos de segurança.

Conclusão

Neste post, mostramos como atualizar as sub-redes e os grupos de segurança associados aos clusters existentes do Amazon EKS. Essa adição de recursos permite maior flexibilidade no gerenciamento das configurações de rede. Os usuários com as permissões apropriadas podem atualizar facilmente sub-redes e grupos de segurança, o que facilita mudanças eficientes na configuração da rede. Esse recurso minimiza as interrupções e elimina a necessidade de recriar clusters que protejam o desempenho consistente dos aplicativos. Além disso, a capacidade de modificar os recursos da rede do cluster evita o tempo de inatividade, mesmo em eventos em que as sub-redes e grupos de segurança do cluster precisem ser reconfigurados ou restaurados, garantindo operações contínuas e sem problemas.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Autores

	Jeremy Cowan é arquiteto especializado em soluções para contêineres na AWS, embora sua família ache que ele vende “espaço na nuvem”. Antes de ingressar na AWS, Jeremy trabalhou para vários grandes fornecedores de software, incluindo VMware, Microsoft e IBM. Quando ele não está trabalhando, geralmente é possível encontrá-lo em uma trilha no deserto, longe da tecnologia.
	Gokul Chandra é arquiteto especializado em soluções na Amazon Web Services. Ele auxilia os clientes na modernização com contêineres, ajudando-os a usar os serviços de contêineres da AWS para projetar aplicativos escaláveis e seguros. Ele é apaixonado pelo espaço nativo da nuvem e pelo Kubernetes. As áreas de interesse de Gokul incluem contêineres, microsserviços, plataformas de nuvem pública e privada, nuvem nativa para telecomunicações, computação de ponta, arquiteturas híbridas e multinuvem e NFV. Você pode encontrá-lo no Medium @gokulchandrapr e no Linkedin @gokulchandra.
	Mike Stefaniak é gerente de produto principal da Amazon Web Services, com foco em tudo relacionado ao Kubernetes e fornecendo recursos que ajudam os clientes a acelerar sua jornada de modernização na AWS.

Revisor

Joao Melo é Arquiteto de Soluções atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 10 anos de experiência, João iniciou sua carreira como desenvolvedor Java e .NET, e posteriormente se especializou em infraestrutura como Engenheiro de Sistemas na Cisco Systems. Formado pela FEI, é entusiasta de Containers, DeFi, Sistemas de Pagamento e apaixonado por cinema e jogos. LinkedIn: @joamelo