Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
Selecione os tipos de instância e o posicionamento dos clusters locais do Amazon EKS no AWS Outposts configurado com o armazenamento de instância do EC2
Este tópico fornece orientação para a seleção de tipos de instância do ambiente de gerenciamento do Kubernetes e a configuração do seu posicionamento para atender aos requisitos de alta disponibilidade do cluster local do Amazon EKS em um outpost da AWS configurado com armazenamento de instância do EC2.
nota
Se o outpost estiver configurado com o Amazon EBS em vez do armazenamento de instância do EC2, a arquitetura descrita neste tópico não estará disponível para ele. Os outposts configurados com o EBS continuarão a usar a implementação de clusters locais existente. Para obter mais informações, consulte Selecione tipos de instância e grupos de posicionamento para clusters do Amazon EKS em AWS Outposts com base em considerações de capacidade.
Se você estiver interessado em criar um cluster local em um outpost baseado no EBS usando a arquitetura de clusters locais atualizada, entre em contato com a equipe da sua conta da AWS.
Arquitetura do ambiente de gerenciamento
O ambiente de gerenciamento do Kubernetes do cluster local é executado em seis instâncias do EC2 no outpost:
-
Três instâncias de ambiente de gerenciamento: hospedam os componentes do ambiente de gerenciamento do Kubernetes, incluindo o servidor de API, o agendador e o gerenciador do controlador do Kubernetes.
-
Três instâncias do
etcd: armazenam o estado do cluster do Kubernetes em uma topologia externa do etcd.
Essas instâncias são executadas em uma conta de serviço gerenciada pela AWS no outpost. Elas não aparecem como instâncias do EC2 na sua conta da AWS nem no console do Amazon EC2. A capacidade consumida pelo ambiente de gerenciamento é visível no console do AWS Outposts.
O ambiente de gerenciamento não tem escalabilidade horizontal sob carga. Se precisar de uma instância do ambiente de gerenciamento de outro tamanho, crie um novo cluster.
Seleção do tipo de instância
Com a arquitetura atualizada dos clusters locais do Amazon EKS no AWS Outposts, o ambiente de gerenciamento do Kubernetes usa uma topologia de etcd dedicada: o servidor de API e o etcd são executados em instâncias separadas. Ao criar um cluster, especifique dois tipos de instância: controlPlaneInstanceType para o servidor de API e etcdInstanceType para o etcd.
Os tipos de instância que você escolher devem estar disponíveis no outpost. As famílias de instâncias disponíveis dependem da geração e do SKU do outpost, e diferentes famílias de instâncias podem ter diferentes configurações de vCPU e memória no mesmo tamanho de instância.
Servidor de API (controlPlaneInstanceType)
| Nós de processamento esperados | vCPUs | Memória |
|---|---|---|
|
1–20 |
2 |
8 GiB |
|
21–100 |
4 |
16 GiB |
|
101–250 |
8 |
32 GiB |
|
251–500 |
16 |
64 GiB |
etcd (etcdInstanceType)
| Nós de processamento esperados | vCPUs | Memória |
|---|---|---|
|
1 a 50 |
2 |
8 GiB |
|
51–250 |
4 |
16 GiB |
|
251–500 |
8 |
32 GiB |
Importante
Certifique-se de que o outpost tenha capacidade para três instâncias controlPlaneInstanceType e três instâncias etcdInstanceType durante a vida útil do cluster local.
Use essas tabelas como uma diretriz, não como uma exigência rígida. Recomendamos a seleção de uma família e de um tamanho de instância que comportem o crescimento previsto, pois o controlPlaneInstanceType e o etcdInstanceType não podem ser alterados após a criação do cluster. Para alterar qualquer um dos dois, crie um novo cluster.
Ambiente de gerenciamento e posicionamento do etcd
Para garantir alta disponibilidade, recomendamos que o ambiente de gerenciamento e instâncias do etcd sejam distribuídos por diversos domínios de falha de hardware. Você pode controlar essa distribuição com a propriedade spreadLevel em controlPlanePlacement e etcdPlacement em outpostConfig. Quando você define o spreadLevel, o Amazon EKS cria um grupo de posicionamento do EC2 com a estratégia de distribuição. Não é necessário criar antecipadamente um grupo de posicionamento.
nota
O parâmetro groupName em controlPlanePlacement não é usado com outposts que executam instâncias do EC2 baseadas em armazenamento de instância. Se você usava anteriormente um grupo de posicionamento com um cluster local, em vez disso, passará a usar um spreadLevel.
Níveis de distribuição
A propriedade spreadLevel aceita dois valores:
-
host: distribui as instâncias do ambiente de gerenciamento entre diferentes hosts físicos. Requer pelo menos três hosts configurados com o tipo de instância escolhido. -
rack: distribui as instâncias do ambiente de gerenciamento entre diferentes racks físicos do outpost. Requer pelo menos três racks configurados com o tipo de instância escolhido.
Planejamento de capacidade
Ao planejar a capacidade do outpost para clusters locais, considere o seguinte:
-
Ambiente de gerenciamento e instâncias do
etcd: seis instâncias por cluster (três docontrolPlaneInstanceTypee três doetcdInstanceType). -
Nós de trabalho: as instâncias do EC2 para os grupos de nós autogerenciados.
-
Hosts virtualizados: o ambiente de gerenciamento deve ser executado em hosts virtualizados. O outpost deve ter hosts virtualizados com capacidade suficiente.
Solução de problemas de posicionamento
Se o cluster permanecer no estado CREATING ou UPDATING por um longo período após você especificar um nível de distribuição, verifique se o outpost tem hosts ou racks suficientes com o tipo de instância escolhido para atender à topologia de distribuição.
Para obter informações sobre como solucionar problemas de clusters locais, consulte Solucionar problemas de clusters locais do Amazon EKS no AWS Outposts configurado com o armazenamento de instância do EC2.
