Plano de controle e nós de trabalho do EKS

O Amazon Elastic Kubernetes Service (EKS) é um serviço Kubernetes totalmente gerenciado que elimina a necessidade de instalar, operar e manter o plano de controle do Kubernetes. O AWS executa, dimensiona e atualiza o plano de controle em várias zonas de disponibilidade, fornecendo um endpoint de cluster altamente disponível. Você se concentra inteiramente na implantação e no gerenciamento das cargas de trabalho da sua aplicação.

O plano de controle do EKS consiste no servidor da API, no etcd, no gerenciador de controladores e no agendador — todos gerenciados pelo AWS. Esses componentes são executados em contas pertencentes ao AWS, portanto você nunca acessa esses componentes por SSH. O AWS garante um SLA de 99,95% para o endpoint da API do EKS e substitui automaticamente os nós não íntegros do plano de controle. Você paga uma tarifa fixa por cluster e por hora pelo plano de controle.

Você pode criar um cluster EKS usando o console do AWS, eksctl ou CloudFormation. O cluster exige uma VPC com sub-redes distribuídas em pelo menos duas AZs e uma função do IAM que conceda ao plano de controle do Kubernetes permissão para chamar APIs do AWS. Depois de criado, o endpoint do cluster será uma URL HTTPS que você configurará no seu kubeconfig.

Depois de criar o cluster, atualize o kubeconfig local para que o kubectl saiba como acessar o servidor da API do EKS. A CLI do AWS gera automaticamente a entrada necessária. O servidor da API do EKS usa o AWS IAM para autenticação; seu usuário ou função do IAM é associado a uma identidade RBAC do Kubernetes por meio do aws-auth ConfigMap.

Os grupos de nós gerenciados permitem que o AWS provisione, registre e gerencie o ciclo de vida dos nós de trabalho do EC2 em seu nome. Quando você solicita uma atualização ou substituição, o EKS drena automaticamente os pods, substitui a instância e registra o nó novamente, tudo sem intervenção manual. Os grupos de nós gerenciados usam Auto Scaling Groups internamente, oferecendo controle da capacidade mínima, máxima e desejada, além de integração com o Cluster Autoscaler.

Com grupos de nós autogerenciados, você inicia as instâncias do EC2 por conta própria (por meio do CloudFormation ou do Terraform) e as registra no cluster EKS executando o script de Bootstrap. Isso oferece flexibilidade máxima: você pode usar AMIs personalizadas, tipos de instância com GPU ou configurações de kernel altamente personalizadas; porém, você é totalmente responsável por aplicar correções, drenar e substituir os nós.

Cada nó de trabalho deve ser executado com um perfil de instância do EC2 que tenha três políticas gerenciadas pelo AWS: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy e AmazonEC2ContainerRegistryReadOnly. Elas permitem que o nó entre no cluster, gerencie a rede dos pods com o plugin VPC CNI e extraia imagens do ECR. Sem essas políticas, os nós não conseguirão se registrar.

O EKS usa o ConfigMap aws-auth no namespace kube-system para associar usuários e funções do IAM a nomes de usuário e grupos do Kubernetes. Quando você cria um cluster, somente a identidade do IAM do criador recebe automaticamente acesso de administrador. Para permitir que outros usuários ou funções de CI/CD acessem o cluster, você deve adicionar entradas a este ConfigMap usando as chaves mapRoles ou mapUsers corretas.

Os complementos do EKS são componentes de software selecionados e validados pelo AWS — como o VPC CNI, o CoreDNS e o kube-proxy — que o EKS pode instalar e manter atualizados em seu nome. Quando você atualiza a versão do Kubernetes do cluster, primeiro atualiza o plano de controle e, em seguida, cada grupo de nós gerenciado para a versão correspondente. O EKS é compatível com uma diferença de até uma versão secundária entre o plano de controle e os nós durante a janela de implementação.

O endpoint do servidor da API do EKS pode ser configurado como somente público, somente privado ou ambos. Os endpoints públicos são protegidos pela autenticação do IAM; os endpoints somente privados exigem que o kubeconfig acesse a VPC por meio de VPN ou Direct Connect. Você também pode ativar a criptografia de envelope dos segredos do Kubernetes em repouso usando uma chave do AWS KMS, fornecendo uma camada adicional de proteção para dados de configuração confidenciais.

O Cluster Autoscaler é um pod do Kubernetes que monitora pods não agendáveis e ajusta automaticamente o tamanho dos grupos de Auto Scaling de nós gerenciados. Quando os pods não podem ser agendados por falta de recursos, o Cluster Autoscaler aumenta a escala. Quando os nós estão subutilizados e seus pods podem ser reagendados em outro local, ele reduz a escala. É necessário ter permissões do IAM para chamar a API do Auto Scaling do EC2 por meio do IRSA.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: AWS gerencia o plano de controle do EKS com um SLA de 99,95%; os grupos de nós gerenciados permitem que a AWS cuide do ciclo de vida dos nós, enquanto os grupos autogerenciados oferecem o máximo de personalização; e o ConfigMap aws-auth mapeia identidades do IAM para o RBAC do Kubernetes, controlando o acesso ao cluster. A seguir, exploraremos os perfis do Fargate para a execução sem servidor de pods.