|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Referência de Configuração do Cluster EKS
Acesso à Conta
Preencha cada menu suspenso e campo usando as informações obtidas para sua política IAM.
| Configuração | Descrição |
|---|---|
Região |
No menu suspenso, escolha a região geográfica na qual deseja construir seu cluster. |
Credenciais de Nuvem |
Selecione as credenciais de nuvem que você criou para sua política IAM. Para mais informações sobre como criar credenciais de nuvem no Rancher, consulte esta página. |
Função de Serviço
Escolha uma função de serviço.
| Função de Serviço | Descrição |
|---|---|
Normal: Função de serviço gerada pelo Rancher |
Se você escolher esta função, o Rancher adiciona automaticamente uma função de serviço para uso com o cluster. |
Personalizado: Escolha entre suas funções de serviço existentes |
Se você escolher esta função, o Rancher permite que você escolha entre funções de serviço que você já criou na AWS. Para mais informações sobre como criar uma função de serviço personalizada na AWS, consulte a documentação da Amazon. |
Criptografia de Segredos
Opcional: Para criptografar segredos, selecione ou insira uma chave criada no Serviço de Gerenciamento de Chaves da AWS (KMS).
Acesso ao Endpoint do Servidor API
Configurar o acesso público/privado à API é um caso de uso avançado. Para detalhes, consulte a documentação de controle de acesso ao endpoint do cluster EKS.
Endpoints da API apenas privados.
Se você habilitar o acesso privado e desabilitar o acesso público ao endpoint da API ao criar um cluster, haverá um passo extra que você deve seguir para que o Rancher se conecte ao cluster com sucesso. Nesse caso, uma janela pop-up será exibida com um comando que você executará no cluster para registrá-lo no Rancher. Uma vez que o cluster esteja provisionado, você pode executar o comando exibido em qualquer lugar que você consiga se conectar à API do Kubernetes do cluster.
Existem duas maneiras de evitar esse passo manual extra:
-
Você pode criar o cluster com acesso tanto privado quanto público ao endpoint da API na criação do cluster. Você pode desabilitar o acesso público após o cluster ser criado e estar em um estado ativo, e o Rancher continuará a se comunicar com o cluster EKS.
-
Você pode garantir que o Rancher compartilhe uma sub-rede com o cluster EKS. Então, grupos de segurança podem ser usados para permitir que o Rancher se comunique com o endpoint da API do cluster. Nesse caso, o comando para registrar o cluster não é necessário, e o Rancher poderá se comunicar com seu cluster. Para mais informações sobre como configurar grupos de segurança, consulte a documentação de grupos de segurança.
Endpoints de Acesso Público
Opcionalmente, limite o acesso ao endpoint público por meio de blocos CIDR explícitos.
Se você limitar o acesso a blocos CIDR específicos, é recomendável que você também habilite o acesso privado para evitar perder a comunicação de rede com o cluster.
Um dos seguintes é necessário para habilitar o acesso privado:
-
O IP do Rancher deve fazer parte de um bloco CIDR permitido
-
O acesso privado deve ser habilitado, e o Rancher deve compartilhar uma sub-rede com o cluster e ter acesso à rede do cluster, o que pode ser configurado com um grupo de segurança.
Para mais informações sobre o acesso público e privado ao endpoint do cluster, consulte a documentação da Amazon EKS.
Rede IPv6 / Dual-stack
O Rancher suporta o provisionamento e gerenciamento de clusters Amazon EKS com roteamento de rede IPv6. Quando o IPv6 está habilitado, os pods e serviços do Kubernetes recebem endereços IPv6. No entanto, os nós de trabalho EC2 subjacentes operam em um modo dual-stack (recebendo endereços IPv4 e IPv6). Essa arquitetura dual-stack garante que os nós ainda possam se comunicar com a API da AWS e o plano de controle do Kubernetes via IPv4, enquanto suas cargas de trabalho de aplicativo se comunicam via IPv6.
Para provisionar um cluster dual-stack pela interface do Rancher:
-
Durante a criação do cluster, expanda a seção Rede.
-
Em Família de IP, selecione o botão de opção IPv6.
Alterar a Família de IP limpa quaisquer seleções de sub-rede atuais que você tenha feito no formulário.
-
Em VPCs e Sub-redes, escolha entre Criar uma nova VPC e sub-rede automaticamente ou Selecionar entre sub-redes existentes.
Aviso para VPCs PersonalizadasSe você optar por selecionar sub-redes existentes, você deve selecionar sub-redes Dual-Stack. As sub-redes selecionadas devem ter um bloco CIDR IPv4 e um bloco CIDR IPv6. Sub-redes apenas IPv6 não são suportadas.
-
Complete o restante da configuração do cluster (Grupos de Nós, etc.).
-
Clique em Criar.
|
A configuração da Família de IP é imutável. Após a criação de um cluster EKS, você não pode converter um cluster IPv4 para IPv6, nem pode converter um cluster IPv6 para IPv4. |
Importando Clusters IPv6 Existentes
O Rancher suporta totalmente o registro (importação) de clusters Amazon EKS existentes que foram configurados com rede IPv6 fora do Rancher (por exemplo, via Terraform ou o Console da AWS).
Quando você registra um cluster EKS existente:
-
Siga o processo padrão de registro de cluster (Gerenciamento de Cluster > Adicionar Cluster > Genérico).
-
O Rancher consulta a API AWS EKS para ler o estado upstream do cluster.
-
O Rancher detecta automaticamente se o cluster foi provisionado com IPv6.
Ao configurar um cluster IPv6, vários comportamentos automatizados e requisitos rigorosos se aplicam:
-
Service CIDR: A AWS atribui automaticamente o Service CIDR de um intervalo fixo de IPv6 (
fd00::/108). Você não pode personalizar o Service CIDR para um cluster IPv6. -
Requisito do Provedor OIDC (IRSA): Em um cluster IPv6, o plugin Amazon VPC CNI exige rigorosamente permissões IAM para atribuir prefixos IPv6 às interfaces de rede elásticas (ENIs). Essa autenticação é gerenciada via Funções IAM para Contas de Serviço (IRSA). Portanto, um provedor OIDC IAM é obrigatório e é habilitado automaticamente pelo Rancher ao provisionar um cluster IPv6. Sem isso, os pods falham em adquirir endereços IP.
Exemplo de Referência de Configuração do EKSCluster (IPv6)
Se você estiver implantando clusters EKS programaticamente usando o eksclusterconfigs.eks.cattle.io Recurso Personalizado, pode habilitar o IPv6 definindo o campo ipFamily como ipv6.
Abaixo segue um exemplo mínimo de EKSClusterConfig configurado para IPv6. Observe que o ipFamily está definido, e campos padrão de IPv4 como serviceCidr estão omitidos porque a AWS os gerencia automaticamente no modo IPv6.
apiVersion: eks.cattle.io/v1
kind: EKSClusterConfig
metadata:
name: my-ipv6-cluster
namespace: cluster-fleet-default
spec:
amazonCredentialSecret: cattle-global-data/my-aws-credentials
displayName: my-ipv6-cluster
region: us-west-2
imported: false
kubernetesVersion: "1.33"
ipFamily: "ipv6" # Enables Dual-Stack IPv6 networking. Triggers automatic OIDC creation.
nodeGroups:
- nodegroupName: initial-nodegroup
desiredSize: 2
maxSize: 3
minSize: 1
instanceType: t3.medium
diskSize: 20
requestSpotInstances: false
version: "1.33"
privateAccess: false
publicAccess: true
secretsEncryption: falseSub-rede
| Opção | Descrição |
|---|---|
Normal: VPC e Sub-rede geradas pelo Rancher |
Ao provisionar seu cluster, o Rancher gera uma nova VPC com 3 sub-redes públicas. |
Personalizado: Escolha entre sua VPC e Sub-redes existentes. |
Ao provisionar seu cluster, o Rancher configura seu Plano de Controle e nós para usar uma VPC e Sub-rede que você já criou na AWS. |
Para mais informações, consulte a documentação da AWS sobre Considerações sobre VPC do Cluster. Siga um dos conjuntos de instruções abaixo com base na sua seleção do passo anterior.
|
Aviso para VPCs Personalizadas
Se você selecionou |
Registro
Configure os logs do plano de controle para enviar ao Amazon CloudWatch. Você será cobrado pelos custos padrão de ingestão e armazenamento de dados do CloudWatch Logs para quaisquer logs enviados ao CloudWatch Logs a partir de seus clusters.
Cada tipo de log corresponde a um componente do plano de controle do Kubernetes. Para saber mais sobre esses componentes, veja Componentes do Kubernetes na documentação do Kubernetes.
Para mais informações sobre o registro de logs do plano de controle do EKS, consulte a documentação oficial.
Grupos de Nós Gerenciados
Os grupos de nós gerenciados do Amazon EKS automatizam o provisionamento e a gestão do ciclo de vida dos nós (instâncias do Amazon EC2) para clusters Kubernetes do Amazon EKS.
Para mais informações sobre como os grupos de nós funcionam e como são configurados, consulte a documentação do EKS.
Modelos de Lançamento fornecidos pelo Usuário
Você pode fornecer seu próprio ID e versão do modelo de lançamento para configurar as instâncias EC2 em um grupo de nós. Se você fornecer o modelo de lançamento, nenhuma das configurações do modelo será configurável a partir do Rancher. Você deve definir todas as opções obrigatórias listadas abaixo em seu modelo de lançamento.
Além disso, se você fornecer o modelo de lançamento, poderá apenas atualizar a versão do modelo, não o ID do modelo. Para usar um novo ID de modelo, crie um novo grupo de nós gerenciado.
| Opção | Descrição | Necessária/opcional |
|---|---|---|
Tipo de Instância |
Escolha as especificações de hardware para a instância que você está provisionando. |
Obrigatória |
ID da Imagem |
Especifique uma AMI personalizada para os nós. AMIs personalizadas usadas com EKS devem ser configuradas corretamente |
Opcional |
Tamanho do Volume do Nó |
O modelo de lançamento deve especificar um volume EBS com o tamanho desejado |
Obrigatória |
Chave SSH |
Uma chave a ser adicionada às instâncias para fornecer acesso SSH aos nós |
Opcional |
Dados do Usuário |
Script init em formato MIME multi-part |
Opcional |
Tags de Recursos da Instância |
Marque cada instância EC2 e seus volumes no grupo de nós |
Opcional |
|
Você não pode atualizar diretamente um grupo de nós para uma versão mais recente do Kubernetes se o grupo de nós foi criado a partir de um modelo de lançamento personalizado. Você deve criar um novo modelo de lançamento com a versão correta do Kubernetes e associar o grupo de nós ao novo modelo. |
Modelos de Lançamento Gerenciados pelo Rancher
Se você não especificar um modelo de lançamento, poderá configurar as opções acima na interface do Rancher e todas elas poderão ser atualizadas após a criação. Para aproveitar todas essas opções, o Rancher criará e gerenciará um modelo de lançamento para você. Cada cluster no Rancher terá um modelo de lançamento gerenciado pelo Rancher e cada grupo de nós gerenciado que não tiver um modelo de lançamento especificado terá uma versão do modelo de lançamento gerenciado. O nome deste modelo de lançamento terá o prefixo "rancher-managed-lt-" seguido pelo nome de exibição do cluster. Além disso, o modelo de lançamento gerenciado pelo Rancher será marcado com a chave "rancher-managed-template" e o valor "do-not-modify-or-delete" para ajudar a identificá-lo como gerenciado pelo Rancher. É importante que este modelo de lançamento e suas versões não sejam modificados, excluídos ou usados com outros clusters ou grupos de nós gerenciados. Fazer isso pode resultar em seus grupos de nós sendo "degradados" e precisando ser destruídos e recriados.
AMIs Personalizadas
Se você especificar uma AMI personalizada, seja em um modelo de lançamento ou no Rancher, a imagem deve ser configurada corretamente e você deve fornecer dados do usuário para inicializar o nó. Isso é considerado um caso de uso avançado e entender os requisitos é imperativo.
Se você especificar um modelo de lançamento que não contenha uma AMI personalizada, a Amazon usará a AMI otimizada para EKS para a versão do Kubernetes e a região selecionada. Você também pode selecionar uma instância habilitada para GPU para cargas de trabalho que se beneficiariam disso.
|
A configuração de instância habilitada para GPU no Rancher é ignorada se uma AMI personalizada for fornecida, seja no menu suspenso ou em um modelo de lançamento. |
Instâncias Spot
As instâncias Spot agora são suportadas pelo EKS. Se um modelo de lançamento for especificado, a Amazon recomenda que o modelo não forneça um tipo de instância. Em vez disso, a Amazon recomenda fornecer múltiplos tipos de instância. Se a caixa de seleção "Solicitar Instâncias Spot" estiver habilitada para um grupo de nós, você terá a oportunidade de fornecer múltiplos tipos de instância.
|
Qualquer seleção que você fez no menu suspenso do tipo de instância será ignorada nesta situação e você deve especificar pelo menos um tipo de instância na seção "Tipos de Instância Spot". Além disso, um modelo de lançamento usado com EKS não pode solicitar instâncias spot. Solicitar instâncias spot deve fazer parte da configuração do EKS. |
Configurações do Grupo de Nós
As seguintes configurações também são configuráveis. Todas essas, exceto pelo "Nome do Grupo de Nós", são editáveis após a criação do grupo de nós.
| Opção | Descrição |
|---|---|
Nome do Grupo de Nós |
O nome do grupo de nós. |
Tamanho Desejado do ASG |
O número desejado de instâncias. |
Tamanho Máximo do ASG |
O número máximo de instâncias. Esta configuração não terá efeito até que o Cluster Autoscaler esteja instalado. |
Tamanho Mínimo do ASG |
O número mínimo de instâncias. Esta configuração não terá efeito até que o Cluster Autoscaler esteja instalado. |
Rótulos |
Rótulos do Kubernetes aplicados aos nós no grupo de nós gerenciado. |
Tags |
Essas são etiquetas para o grupo de nós gerenciado e não se propagam para nenhum dos recursos associados. |
Nós do Amazon Linux Gerenciados pelo Usuário
Você pode registrar um cluster EKS contendo nós do Amazon Linux gerenciados pelo usuário. Você deve configurar este tipo de cluster de acordo com as instruções na documentação oficial da AWS para lançar nós do Amazon Linux gerenciados pelo usuário. Os clusters EKS contendo nós Amazon Linux gerenciados pelo usuário são geralmente operados pelo projeto Karpenter. Após provisionar um cluster EKS contendo nós Amazon Linux gerenciados pelo usuário, registre o cluster para que ele possa ser gerenciado pelo Rancher. No entanto, os nós não estarão visíveis na interface do Rancher.
Funções IAM para Contas de Serviço
Uma implantação de aplicativos em execução em um cluster EKS pode fazer solicitações a serviços da AWS por meio de permissões IAM. Esses aplicativos devem assinar suas solicitações com credenciais da AWS. As funções IAM para contas de serviço gerenciam essas credenciais usando um endpoint OIDC da AWS. Em vez de distribuir credenciais da AWS para contêineres ou depender da função de uma instância EC2, você pode vincular uma função IAM a uma conta de serviço Kubernetes e configurar seus Pods para usar essa conta.
|
A vinculação a uma função IAM não é suportada para pods do Rancher em um cluster EKS. |
Para habilitar funções IAM para contas de serviço:
Configurando o Intervalo de Atualização
A configuração eks-refresh-cron está descontinuada. Ela foi migrada para a configuração eks-refresh, que é um inteiro representando segundos.
O valor padrão é 300 segundos.
O intervalo de sincronização pode ser alterado executando kubectl edit setting eks-refresh.
Se a configuração eks-refresh-cron foi definida anteriormente, a migração ocorrerá automaticamente.
Quanto menor a janela de atualização, menor a probabilidade de ocorrerem condições de corrida, mas isso aumenta a probabilidade de encontrar limites de solicitação que podem estar em vigor para as APIs da AWS.