Gerenciar recursos computacionais usando nós - Amazon EKS

Gerenciar recursos computacionais usando nós

Um nó do Kubernetes é uma máquina que executa aplicações conteinerizadas. Todo nó tem os seguintes componentes:

  • Runtime do contêiner - Software responsável pela execução dos contêineres.

  • kubelet - Garante que os contêineres estejam íntegros e em execução em seus respectivos Pod.

  • kube-proxy - Mantém as regras de rede que permitem a comunicação com seu Pods.

Para obter mais informações, consulte Nodes (Nós) na documentação do Kubernetes.

Seu cluster do Amazon EKS pode agendar Pods em qualquer combinação de nós autogerenciados, grupos de nós gerenciados do Amazon EKS e AWS Fargate. Para saber mais sobre nós implantados em seu cluster, consulte Visualize os recursos do Kubernetes na seção AWS Management Console.

Importante

O AWS Fargate com Amazon EKS não está disponível nas regiões AWS GovCloud (EUA-Leste) e AWS GovCloud (EUA-Oeste).

nota

Os nós devem estar na mesma VPC que as sub-redes selecionadas na ocasião da criação do cluster. Porém, esses nós não precisam estar nas mesmas sub-redes.

A tabela a seguir fornece vários critérios para avaliar ao decidir quais opções atendem melhor às suas necessidades. Esta tabela não inclui nós conectados que foram criados fora do Amazon EKS, que só podem ser visualizadas.

nota

O Bottlerocket tem algumas diferenças específicas em relação às informações gerais desta tabela. Para obter mais informações, consulte a documentação do Bottlerocket no GitHub.

Critérios Grupos de nós gerenciados do EKS Nós autogerenciados AWS Fargate

Pode ser implantado no AWS Outposts

Não

Sim

Não

Pode ser implantado em uma Zona local da AWS

Sim

Sim

Não

Pode executar contêineres que exijam o Windows

Sim

Sim: mas, o cluster ainda requer, pelo menos, um nó Linux (dois são recomendáveis para garantir disponibilidade).

Não

Pode executar contêineres que exijam o Linux

Sim

Sim

Sim

Pode executar workloads que exijam o chip do Inferentia

Sim. Somente nós do Amazon Linux

Sim. Somente Amazon Linux

Não

Pode executar workloads que exijam uma GPU

Sim. Somente nós do Amazon Linux

Sim. Somente Amazon Linux

Não

Pode executar workloads que exijam processadores ARM

Sim

Sim

Não

Pode executar o AWS Bottlerocket

Sim

Sim

Não

Pods compartilham um ambiente de runtime do kernel com outros Pods

Sim. Todos os Pods em cada um dos nós

Sim. Todos os Pods em cada um dos nós

Não. Cada Pod tem um kernel dedicado

Os pods compartilham recursos de CPU, memória, armazenamento e rede com outros Pods.

Sim. Pode resultar em recursos não utilizados em cada nó

Sim. Pode resultar em recursos não utilizados em cada nó

Não. Cada Pod tem recursos dedicados e pode ser dimensionado independentemente para maximizar a utilização dos recursos.

Os pods podem usar mais hardware e memória do que o solicitado nas especificações do Pod

Sim. Se o Pod exigir mais recursos do que o solicitado e os recursos estiverem disponíveis no nó, o Pod poderá usar recursos adicionais.

Sim. Se o Pod exigir mais recursos do que o solicitado e os recursos estiverem disponíveis no nó, o Pod poderá usar recursos adicionais.

Não. Porém, o Pod pode ser reimplantado usando uma configuração maior de vCPU e memória.

Deve implantar e gerenciar instâncias do Amazon EC2

Sim. Automatizado pelo Amazon EKS se você implantou uma AMI otimizada do Amazon EKS Se você implantou uma AMI personalizada, você deve atualizar a instância manualmente.

Sim - Configuração manual ou uso de modelos AWS CloudFormation fornecidos pelo Amazon EKS para implantar nós Linux (x86), Linux (Arm) ou Windows.

Não

Deve proteger, manter e corrigir o sistema operacional das instâncias do Amazon EC2

Sim

Sim

Não

Pode fornecer argumentos de bootstrap na implantação de um nó, como argumentos kubelet extras.

Sim. Ao usar eksctl ou um modelo de execução com uma AMI personalizada.

Sim. Para obter mais informações, consulte as informações sobre o uso do script de bootstrap, no GitHub.

Não

Pode atribuir endereços IP a Pods de um bloco CIDR diferente do endereço IP atribuído ao nó.

Sim. Usando um modelo de execução com uma AMI personalizada Para ter mais informações, consulte Personalizar nós gerenciados com modelos de execução.

Sim. Para obter mais informações, consulte Implementar pods em sub-redes alternadas com rede personalizada.

Não

É possível executar o SSH no nó

Sim

Sim

Não: não há nenhum sistema operacional de host de nó para SSH.

Pode implantar sua própria AMI personalizada em nós

Sim. Usar um modelo de execução

Sim

Não

Pode implantar seu próprio CNI personalizado em nós

Sim. Usando um modelo de execução com uma AMI personalizada

Sim

Não

Você deve atualizar a AMI do nó por conta própria

Sim: se você implantou uma AMI otimizada do Amazon EKS, receberá uma notificação no console do Amazon EKS quando as atualizações estiverem disponíveis. É possível executar a atualização com um clique no console. Se você implantou uma AMI personalizada, não será notificado no console do Amazon EKS quando as atualizações estiverem disponíveis. Você deve executar a atualização por conta própria.

Yes (Sim): usar ferramentas que não sejam do console do Amazon EKS. Isso ocorre porque nós autogerenciados não podem ser gerenciados com o console do Amazon EKS.

Não

É necessário atualizar a versão Kubernetes do nó por conta própria

Sim: se você implantou uma AMI otimizada do Amazon EKS, receberá uma notificação no console do Amazon EKS quando as atualizações estiverem disponíveis. É possível executar a atualização com um clique no console. Se você implantou uma AMI personalizada, não será notificado no console do Amazon EKS quando as atualizações estiverem disponíveis. Você deve executar a atualização por conta própria.

Yes (Sim): usar ferramentas que não sejam do console do Amazon EKS. Isso ocorre porque nós autogerenciados não podem ser gerenciados com o console do Amazon EKS.

Não. Você não gerencia nós.

Pode usar o armazenamento do Amazon EBS com os Pods

Sim

Sim

Não

Pode usar o armazenamento do Amazon EFS com os Pods

Sim

Sim

Sim

Pode usar o armazenamento do Amazon FSx para Lustre com os Pods

Sim

Sim

Não

Pode usar o Network Load Balancer para serviços

Sim

Sim

Sim, ao usar a opção Criar um balanceador de carga de rede

Pods podem ser executados em uma sub-rede pública

Sim

Sim

Não

Pode atribuir grupos de segurança da VPC a Pods individuais

Sim: somente nós do Linux

Sim: somente nós do Linux

Sim

Pode executar o Kubernetes DaemonSets

Sim

Sim

Não

Compatível com HostPort e HostNetwork no manifesto do Pod

Sim

Sim

Não

Disponibilidade de regiões do AWS

Todas as regiões compatíveis com Amazon EKS

Todas as regiões compatíveis com Amazon EKS

Algumas regiões compatíveis com o Amazon EKS

Pode executar contêineres em hosts dedicados do Amazon EC2

Sim

Sim

Não

Preços

Custo de instância do Amazon EC2 que executa vários Pods. Para obter mais informações, consulte Definição de preço do Amazon EC2.

Custo de instância do Amazon EC2 que executa vários Pods. Para obter mais informações, consulte Definição de preço do Amazon EC2.

Custo da memória do Fargate e das configurações da CPU. Cada Pod tem seu próprio custo. Para obter mais informações, consulte Preços do AWS Fargate.