Ajudar a melhorar esta página
Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.
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 de contêiner
: software responsável pela execução dos contêineres. -
kubelet: garante a integridade e o funcionamento dos contêineres dentro do Pod associado. -
kube-proxy: mantém regras de rede que permitem a comunicação com os Pods.
Para obter mais informações, consulte Nodes
O 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 Visualizar recursos do Kubernetes no AWS Management Console.
Importante
O AWS Fargate com o Amazon EKS não está disponível para a AWS GovCloud (Leste dos EUA) e AWS GovCloud (Oeste dos EUA).
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
| 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 |
Não |
Sim. Para obter mais informações, consulte Executar clusters do EKS de baixa latência com zonas locais da AWS. |
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 |
Não |
||
| Pode executar o AWS Bottlerocket |
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 inicialização na implantação de um nó, como argumentos de |
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 |
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 |
Yes (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 |
Yes (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 |
Não |
||
|
Pode usar o armazenamento do Amazon EFS com os Pods |
|||
|
Pode usar o armazenamento do Amazon FSx para Lustre com os Pods |
Não |
||
|
Pode usar o Network Load Balancer para serviços |
Sim, quando usar o Criar um balanceador de carga da 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 |
Sim |
Sim |
Não |
|
Disponibilidade do Região da AWS |
|||
|
Pode executar contêineres em hosts dedicados do Amazon EC2 |
Sim |
Sim |
Não |
|
Definição de preço |
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 |
