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á.
Nodos híbridos EKS
Introdução
O AWS EKS apresenta os nós híbridos, um novo recurso que permite que você execute aplicativos locais e de ponta em uma infraestrutura gerenciada pelo cliente com os mesmos clusters, recursos e ferramentas do AWS EKS que você usa na nuvem da AWS. O AWS EKS Hybird Nodes traz uma experiência de Kubernetes gerenciada pela AWS para ambientes locais para que os clientes simplifiquem e padronizem a forma como você executa aplicativos em ambientes locais, periféricos e na nuvem. Leia mais em EKS Hybrid Nodes.
Para facilitar o suporte a esse recurso, o eksctl introduz um novo campo de nível superior chamado. remoteNetworkConfig Qualquer configuração relacionada ao Hybrid Nodes deve ser configurada por meio desse campo, como parte do arquivo de configuração; não há sinalizadores CLI equivalentes. Além disso, na inicialização, qualquer configuração de rede remota só pode ser configurada durante a criação do cluster e não pode ser atualizada posteriormente. Isso significa que você não poderá atualizar os clusters existentes para usar nós híbridos.
A remoteNetworkConfig seção do arquivo de configuração permite que você configure as duas áreas principais quando se trata de unir nós remotos aos seus clusters EKS: rede e credenciais.
Redes
O EKS Hybrid Nodes é flexível de acordo com seu método preferido de conectar sua (s) rede (s) local (s) a uma AWS VPC. Há várias opções documentadas disponíveis, incluindo o AWS Site-to-Site VPN e o AWS Direct Connect, e você pode escolher o método que melhor se adequa ao seu caso de uso. Na maioria dos métodos que você pode escolher, sua VPC será conectada a um gateway privado virtual (VGW) ou a um gateway de trânsito (TGW). Se você confiar no eksctl para criar uma VPC para você, o eksctl também configurará, dentro do escopo de sua VPC, quaisquer pré-requisitos relacionados à rede para facilitar a comunicação entre seu plano de controle EKS e os nós remotos, ou seja,
-
regras SG de entrada/saída
-
rotas nas tabelas de rotas das sub-redes privadas
-
o anexo do gateway VPC ao determinado TGW ou VGW
Exemplo de arquivo de configuração:
remoteNetworkConfig: vpcGatewayID: tgw-xxxx # either VGW or TGW to be attached to your VPC remoteNodeNetworks: # eksctl will create, behind the scenes, SG rules, routes, and a VPC gateway attachment, # to facilitate communication between remote network(s) and EKS control plane, via the attached gateway - cidrs: ["10.80.146.0/24"] remotePodNetworks: - cidrs: ["10.86.30.0/23"]
Se seu método de conectividade preferido não envolver o uso de um TGW ou VGW, você não deve confiar no eksctl para criar a VPC para você e, em vez disso, fornecer uma pré-existente. Em uma observação relacionada, se você estiver usando uma VPC preexistente, a eksctl não fará nenhuma alteração nela, e garantir que todos os requisitos de rede estejam em vigor é de sua responsabilidade.
nota
eksctl não configura nenhuma infraestrutura de rede fora da sua AWS VPC (ou seja, qualquer infraestrutura de VGW/TGW até as redes remotas)
Credenciais
Os EKS Hybrid Nodes usam o AWS IAM Authenticator e credenciais temporárias do IAM provisionadas pelo AWS SSM ou pelo AWS IAM Roles Anywhere para se autenticar com o cluster EKS. Semelhante aos grupos de nós autogerenciados, se não for fornecido de outra forma, o eksctl criará para você uma função do IAM de nós híbridos a ser assumida pelos nós remotos. Além disso, ao usar o IAM Roles Anywhere como seu provedor de credenciais, o eksctl configurará um perfil e uma âncora confiável com base em um determinado pacote de autoridade de certificação (), por exemplo iam.caBundleCert
remoteNetworkConfig: iam: # the provider for temporary IAM credentials. Default is SSM. provider: IRA # the certificate authority bundle that serves as the root of trust, # used to validate the X.509 certificates provided by your nodes. # can only be set when provider is IAMRolesAnywhere. caBundleCert: xxxx
O ARN da função de nós híbridos criada por eksctl é necessário posteriormente no processo de unir seus nós remotos ao clusternodeadm, NodeConfig para configurar e criar ativações (se estiver usando SSM). Para buscá-lo, use:
aws cloudformation describe-stacks \ --stack-name eksctl-<CLUSTER_NAME>-cluster \ --query 'Stacks[].Outputs[?OutputKey==`RemoteNodesRoleARN`].[OutputValue]' \ --output text
Da mesma forma, se estiver usando o IAM Roles Anywhere, você pode buscar o ARN da âncora de confiança e do perfil anywhere criado por eksctl, alterando o comando anterior substituindo-o por ou, respectivamente. RemoteNodesRoleARN RemoteNodesTrustAnchorARN RemoteNodesAnywhereProfileARN
Se você tiver uma configuração preexistente do IAM Roles Anywhere ou estiver usando SSM, poderá fornecer uma função do IAM para nós híbridos por meio de. remoteNetworkConfig.iam.roleARN Lembre-se de que, nesse cenário, o eksctl não criará a âncora de confiança e o perfil em qualquer lugar para você. Por exemplo
remoteNetworkConfig: iam: roleARN: arn:aws:iam::000011112222:role/HybridNodesRole
Para mapear a função para uma identidade do Kubernetes e autorizar os nós remotos a se juntarem ao cluster EKS, eksctl cria uma entrada de acesso com a função IAM de nós híbridos como ARN principal e do tipo. ou seja HYBRID_LINUX
eksctl get accessentry --cluster my-cluster --principal-arn arn:aws:iam::000011112222:role/eksctl-my-cluster-clust-HybridNodesSSMRole-XiIAg0d29PkO --output json [ { "principalARN": "arn:aws:iam::000011112222:role/eksctl-my-cluster-clust-HybridNodesSSMRole-XiIAg0d29PkO", "kubernetesGroups": [ "system:nodes" ] } ]
Suporte a complementos
Interface de rede de contêineres (CNI): a CNI da AWS VPC não pode ser usada com nós híbridos. Os principais recursos do Cilium e do Calico são compatíveis com o uso com nós híbridos. Você pode gerenciar a CNI com ferramentas de sua escolha, como o Helm. Para obter mais informações, consulte Configurar uma CNI para nós híbridos.
nota
Se você instalar o VPC CNI em seu cluster para seus grupos de nós autogerenciados ou gerenciados pelo EKS, precisará usar v1.19.0-eksbuild.1 ou posterior, pois isso inclui uma atualização do daemonset do complemento para impedir que ele seja instalado em nós híbridos.