Personalizar nós gerenciados com modelos de execução

Para obter o nível mais alto de personalização, é possível implementar nós gerenciados usando seu próprio modelo de execução. O uso de um modelo de execução permite recursos como os seguintes:

• Fornecer argumentos de inicialização na implantação de um nó, como argumentos de kubelet extras.

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

• Implantar sua própria AMI personalizada nos nós.

• Implantar sua própria CNI personalizada nos nós.

Ao fornecer seu próprio modelo de execução na primeira criação de um grupo de nós gerenciados, você também terá maior flexibilidade posteriormente. Contanto que você implemente um grupo de nós gerenciados com seu próprio modelo de execução, é possível atualizá-lo iterativamente para uma versão diferente do mesmo modelo de execução. Quando você atualiza para o grupo de nós para uma versão mais recente do modelo de execução, todos os nós do grupo são reciclados para corresponder à nova configuração da versão do modelo de execução especificada.

Os grupos de nós gerenciados são sempre implantados com um modelo de execução do grupo do Amazon EC2 Auto Scaling. Quando você não fornece um modelo de execução, a API do Amazon EKS cria um modelo com valores padrão em sua conta automaticamente. No entanto, não recomendamos modificar os modelos de execução gerados automaticamente. Além disso, os grupos de nós existentes que não usarem um modelo de execução personalizado não poderão ser atualizados diretamente. Em vez disso, você deverá criar um novo grupo de nós com um modelo de execução personalizado para fazer isso.

Conceitos básicos do modelo de execução

É possível criar um modelo de execução do Amazon EC2 Auto Scaling com o AWS Management Console, o AWS CLI ou um AWS SDK. Para obter mais informações, consulte Criação de um modelo de execução para um grupo do Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling. Algumas das configurações em um modelo de execução são semelhantes às usadas para a configuração do nó gerenciado. Ao implantar ou atualizar um grupo de nós com um modelo de execução, algumas configurações devem ser especificadas na configuração do grupo de nós ou no modelo de execução. Não especifique uma configuração em ambos os locais. Se uma configuração existir onde não deveria, as operações, como criar ou atualizar um grupo de nós, falharão.

A tabela a seguir lista as configurações proibidas em um modelo de execução. Também são listadas configurações semelhantes, se houver, que são obrigatórias na configuração do grupo de nós gerenciados. As configurações listadas são as configurações que aparecem no console. Elas podem ter nomes semelhantes, mas diferentes na AWS CLI e no SDK.

Modelo de execução – Proibido	Configuração do grupo de nós do Amazon EKS
Subnet (Sub-rede) em Network interfaces (Interfaces de rede) (Adicionar interface de rede)	Subnet (Sub-redes) em Node Group network configuration (Configuração de rede do grupo de nós) na página Specify networking (Especificar rede)
IAM instance profile (Perfil de instância do IAM) em Advanced details (Detalhes avançados)	Node IAM Role (Função do IAM do nó) em Node Group configuration (Configuração do grupo de nós) na página Configure Node Group (Configurar o grupo de nós)
Shutdown behavior (Comportamento de desligamento) e Stop - Hibernate behavior (Parar - comportamento de hibernação) em Advanced details (Detalhes avançados). Reter o padrão Não incluir na configuração do modelo de execução para as duas configurações.	Não há equivalente. O Amazon EKS deve controlar o ciclo de vida da instância, não o grupo Auto Scaling.

A tabela a seguir lista as configurações proibidas em uma configuração de grupo de nós gerenciados. Também lista configurações semelhantes, se houver, que serão necessárias em um modelo de execução. As configurações listadas são as configurações que aparecem no console. Elas podem ter nomes semelhantes na AWS CLI e no SDK.

Configuração do grupo de nós do Amazon EKS - Proibidas	Modelo de execução
(Somente se você especificou uma AMI personalizada em um modelo de inicialização) AMI type (Tipo de AMI) em Node Group compute configuration (Configuração da computação do grupo de nós) na página Set compute and scaling configuration (Definir configuração de computação e escalabilidade): o console exibe Specified in launch template (Especificado no modelo de inicialização) e o ID da AMI que foi especificado. Se Application and OS Images (Amazon Machine Image) [Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)] não tiver sido especificado no modelo de execução, você poderá selecionar uma AMI na configuração do grupo de nós.	Application and OS Images (Amazon Machine Image) [Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)] em Launch template contents (Conteúdo do modelo de execução): especifique um ID se você tiver um dos seguintes requisitos: Usar uma AMI personalizada. Se você especificar uma AMI que não atende aos requisitos listados em Especificar uma AMI, haverá falha na implantação do grupo de nós. Deseja fornecer dados de usuário para fornecer argumentos para o arquivo bootstrap.sh incluído com uma AMI otimizada do Amazon EKS. É possível habilitar que suas instâncias atribuam um número significativamente maior de endereços IP aos Pods, atribuam endereços IP aos Pods de um bloco de CIDR diferente do endereço da instância ou implantem um cluster privado sem acesso de saída à Internet. Para obter mais informações, consulte os tópicos a seguir. Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2 Rede personalizada para pods Implementar clusters privados com acesso limitado à internet Especificar uma AMI
Tamanho do disco em Node Group compute configuration (Configuração de computação do grupo de nós) a página Set compute and scaling configuration (Definir a configuração da computação e escalabilidade). Exibe o console Especificado no modelo de execução.	Size (Tamanho) em Storage (Volumes) Armazenamento (Volumes) (Add New volume) (Adicionar novo volume). Você deve especificar isso no modelo de execução.
Par de chaves SSH em Node Group configuration (Configuração do grupo de nós) na página Specify Networking (Especificar rede) — O console exibe a chave especificada no modelo de execução ou exibe Not specified in launch template (Não especificado no modelo de execução).	Key pair name (Nome do par de chaves) em Key pair (login) (Par de chaves).
Não é possível especificar grupos de segurança de origem que tenham permissão de acesso remoto ao usar um modelo de execução.	Security groups (Grupos de segurança) em Network settings (Configurações de rede) para a instância ou Security groups (Grupos de segurança) em Network interfaces (Interfaces de rede) (Add network interface (Adicionar interface de rede), mas não os dois. Para obter mais informações, consulte Usar grupos de segurança personalizados.

nota

• Se você implantar um grupo de nós usando um modelo de execução, especifique zero ou um tipo de instância em Launch template contents (Iniciar o conteúdo do modelo) em um modelo de execução. Se preferir, você pode especificar de 0 a 20 tipos de instância em Instance types (Tipos de instância) na página Set compute and scaling configuration (Definir configuração de computação e escalabilidade) no console. Ou você pode fazer isso com outras ferramentas que utilizam a API do Amazon EKS. Se você especificar um tipo de instância em um modelo de execução e usar esse modelo para implantar o grupo de nós, não será possível especificar nenhum tipo de instância no console ou usar outras ferramentas que usam a API do Amazon EKS. Se você não especificar um tipo de instância em um modelo de execução, no console ou usando outras ferramentas que usem a API do Amazon EKS, será usado o tipo de instância t3.medium. Se o grupo de nós estiver usando o tipo de capacidade spot, recomendamos especificar vários tipos de instância usando o console. Para obter mais informações, consulte Tipos de capacidade do grupo de nós gerenciados.

• Se algum contêiner implantado no grupo de nós usar o Serviço de Metadados de Instância Versão 2, defina a propriedade Metadata response hop limit (Limite de salto de resposta) como 2 no modelo de execução. Para obter mais informações, consulte Metadados da instância e dados do usuário no Manual do usuário do Amazon EC2. Se você implantar um grupo de nós gerenciados sem usar um modelo de execução personalizado, esse valor será definido automaticamente para o grupo de nós no modelo de execução padrão.

Etiquetar instâncias do Amazon EC2

Você pode usar o parâmetro TagSpecification de um modelo de execução para especificar quais etiquetas serão aplicadas às instâncias do Amazon EC2 em seu grupo de nós. A entidade do IAM que chama o método das APIs CreateNodegroup ou UpdateNodegroupVersion devem ter permissões para ec2:RunInstances e ec2:CreateTags, e as etiquetas devem ser adicionadas ao modelo de execução.

Usar grupos de segurança personalizados

Você pode usar um modelo de execução para especificar os grupos de segurança do Amazon EC2 a serem aplicados às instâncias do grupo de nós. Isso pode ser no parâmetro dos grupos de segurança do nível de instância ou como parte dos parâmetros de configuração da interface de rede. Porém, não é possível criar um modelo de execução que especifique o nível da instância e os grupos de segurança da interface de rede. Considere as seguintes condições que se aplicam ao uso de grupos de segurança personalizados com grupos de nós gerenciados:

• Quando o AWS Management Console é usado, o Amazon EKS permite modelos de execução somente com uma única especificação de interface de rede.

• Por padrão, o Amazon EKS aplica o Grupo de segurança de clusterpara as instâncias no grupo de nós, a fim de facilitar a comunicação entre os nós e o plano de controle. Se você especificar grupos de segurança personalizados no modelo de execução usando uma das opções mencionadas anteriormente, o Amazon EKS não adicionará o grupo de segurança do cluster. Então, você deve garantir que as regras de entrada e saída dos grupos de segurança permitam a comunicação com o endpoint do cluster. Se as regras do grupo de segurança estiverem incorretas, os nós de processamento não poderão ingressar no cluster. Para obter mais informações sobre regras do grupo de segurança, consulte Considerações e requisitos sobre grupos de segurança do Amazon EKS.

• Se você precisar de acesso SSH às instâncias no grupo de nós, inclua um grupo de segurança que permita esse acesso.

Dados do usuário do Amazon EC2

O modelo de execução contém uma seção para dados de usuário personalizados. É possível especificar configurações para o grupo de nós desta seção sem criar AMIs personalizadas individuais manualmente. Para obter mais informações sobre as configurações disponíveis para o Bottlerocket, consulte Using user data (Usar dados de usuário) no GitHub.

Você pode fornecer dados de usuário do Amazon EC2 no modelo de execução usando cloud-init na inicialização das instâncias. Para obter mais informações, consulte a documentação de cloud-init. Os dados de usuário podem ser usados para executar operações de configuração comuns. Isso inclui as seguintes operações:

• Incluindo usuários ou grupos

• Instalar pacotes

Os dados de usuários do Amazon EC2 em modelo de execução que são usados com grupos de nós gerenciados devem estar no formato arquivo MIME de várias partes para AMIs do Amazon Linux e em formato TOML para AMIs do Bottlerocket. Isso ocorre porque seus dados de usuário são mesclados com os dados de usuário do Amazon EKS necessários para que os nós participem do cluster. Não especifique nenhum comando nos dados de usuário que iniciem ou modifiquem kubelet. Isso é executado como parte dos dados de usuário mesclados pelo Amazon EKS. Certos parâmetros do kubelet, como a definição de rótulos em nós, podem ser configurados diretamente por meio da API de grupos de nós gerenciados.

nota

Para obter mais informações sobre personalização avançada do kubelet, inclusive para iniciá-la manualmente ou passar parâmetros de configuração personalizados, consulte Especificar uma AMI. Seu um ID de AMI personalizada for especificado em um modelo de execução, o Amazon EKS não mesclará os dados de usuário.

Os detalhes a seguir fornecem mais informações sobre a seção de dados de usuário.

Amazon Linux 2 user data

Você pode combinar vários blocos de dados de usuário em um único arquivo MIME de várias partes. Por exemplo, você pode combinar um boothook de nuvem que configure o daemon do Docker com um script do shell de dados do usuário que instale um pacote personalizado. Um arquivo em várias partes MIME consiste nos seguintes componentes:

• O tipo de conteúdo e a declaração de limite da parte: Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

• A declaração da versão MIME: MIME-Version: 1.0

• Um ou mais blocos de dados do usuário, que contêm os seguintes componentes:

  • O limite de abertura, que sinaliza o início de um bloco de dados do usuário: --==MYBOUNDARY==

  • A declaração de tipo de conteúdo para o bloco: Content-Type: text/cloud-config; charset="us-ascii". Para obter mais informações sobre os tipos de conteúdo, consulte a documentação do cloud-init.

  • O conteúdo de dados de usuário (por exemplo, uma lista de comandos de shell ou diretivas cloud-init).

  • O limite de fechamento, que sinaliza o término do arquivo em várias partes MIME: --==MYBOUNDARY==--

  Veja a seguir um exemplo de arquivo MIME com várias partes que você pode usar para criar seu próprio.

  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
  
  --==MYBOUNDARY==
  Content-Type: text/x-shellscript; charset="us-ascii"
  
  #!/bin/bash
  echo "Running custom user data script"
  
  --==MYBOUNDARY==--

Amazon Linux 2023 user data

O Amazon Linux 2023 (AL2023) introduz um novo processo de inicialização do nó nodeadm que usa um esquema de configuração YAML. Se estiver usando grupos de nós autogerenciados ou uma AMI com um modelo de inicialização, será necessário fornecer, de forma explícita, metadados de cluster adicionais ao criar um novo grupo de nós. Veja a seguir um exemplo dos parâmetros mínimos necessários, em que apiServerEndpoint, certificateAuthority e cidr do serviço passaram a ser necessários:

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16

Normalmente, você definirá essa configuração nos dados do usuário no estado em que se encontra ou incorporada em um documento MIME com várias partes:

MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]

--BOUNDARY--

No AL2, os metadados desses parâmetros eram revelados na chamada de API DescribeCluster do Amazon EKS. Com o AL2023, esse comportamento foi alterado, uma vez que a chamada de API adicional corre o risco de sofrer controle de utilização durante grandes aumentos de escala vertical para nós. Essa alteração não afetará você se estiver usando grupos de nós gerenciados sem um modelo de inicialização ou se estiver usando o Karpenter. Para obter mais informações sobre certificateAuthority e cidr do serviço, consulte DescribeCluster na Referência de APIs do Amazon EKS.

Bottlerocket user data

O Bottlerocket estrutura dados de usuário no formato TOML. Informe os dados de usuário a serem mesclados com os dados de usuário fornecidos pelo Amazon EKS. Por exemplo, você pode fornecer outras configurações do kubelet.

[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"

Para obter mais informações sobre as configurações compatíveis, consulte a documentação Bottlerocket. É possível configurar rótulos de nós e taints em seus dados de usuário. Porém, recomendamos configurá-los em seu grupo de nós. O Amazon EKS aplica essas configurações quando você faz isso.

Quando os dados de usuário são mesclados, a formatação não é preservada, mas o conteúdo permanece o mesmo. A configuração que você fornece nos dados de usuário substitui todas as configurações definidas pelo Amazon EKS. Dessa maneira, se você definir settings.kubernetes.max-pods ou settings.kubernetes.cluster-dns-ip, esses valores dos dados de usuário são aplicados aos nós.

O Amazon EKS não oferece suporte a todos os TOML válidos. Veja a seguir uma lista de formatos conhecidos não compatíveis:

• Aspas em chaves entre aspas: 'quoted "value"' = "value"

• Aspas de escape em valores: str = "I'm a string. \"You can quote me\""

• Floats mistos e números inteiros: numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]

• Tipos mistos em matrizes: contributors = ["[e-mail]", { name = "Baz", email = "[e-mail]" }]

• Cabeçalhos entre colchetes com chaves entre aspas: [foo."bar.baz"]

Windows user data

Os dados de usuário do Windows usam comandos do PowerShell. Ao criar um grupo de nós gerenciados, os dados de usuário personalizados se combinam com os dados de usuário gerenciados do Amazon EKS. Os comandos do PowerShell vêm em primeiro lugar, seguidos pelos comandos de dados de usuário gerenciados, tudo dentro de uma tag <powershell></powershell>.

nota

Quando nenhum ID de AMI for especificado no modelo de execução, não use o script de boostrap do Amazon EKS para Windows nos dados de usuário para configurar o Amazon EKS.

A seguir, um exemplo de dados do usuário.

<powershell>
Write-Host "Running custom user data script"
</powershell>

Especificar uma AMI

Se você tiver um dos seguintes requisitos, especifique um ID de AMI na caixa ImageId do modelo de execução. Selecione o requisito que você tem para obter informações adicionais.

Fornecer dados de usuário para passar argumentos para o arquivo bootstrap.sh incluído com uma AMI do Linux/Bottlerocket otimizada para o Amazon EKS

Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. Por exemplo, a inicialização permite o uso de argumentos kubelet extras. Você pode passar os argumentos para o script bootstrap.sh usando eksctl sem especificar um modelo de inicialização. Ou faça isso especificando as informações na seção de dados de usuário de um modelo de execução.

eksctl without specifying a launch template

Crie um arquivo denominado my-nodegroup.yaml com o seguinte conteúdo: Substitua example value por seus próprios valores. Os argumentos --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip são opcionais. No entanto, defini-los permite que o script bootstrap.sh evite fazer uma chamada describeCluster. Isso é útil em configurações de cluster privado ou clusters em que há aumento e redução de escala na horizontal com frequência. Para obter mais informações sobre o script bootstrap.sh, consulte o arquivo bootstrap.sh no GitHub.

• O único argumento necessário é o nome do cluster (my-cluster).

• Para recuperar um ID de AMI otimizado para ami-1234567890abcdef0, você pode usar as tabelas nas seguintes seções:

  • Recuperar IDs de AMI do Amazon Linux recomendadas

  • Recuperar IDs de AMI do Bottlerocket recomendadas

  • Recuperar IDs de AMI do Microsoft Windows recomendadas

• Para recuperar o certificate-authority do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar o api-server-endpoint do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• O valor para o --dns-cluster-ip é o serviço CIDR com .10 no final. Para recuperar o service-cidr do seu cluster, execute o comando a seguir. Por exemplo, se o valor retornado for ipv4 10.100.0.0/16, então seu valor será 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• Este exemplo fornece um argumento adicional do kubelet para definir um valor max-pods personalizado usando o valor do script bootstrap.sh incluído com a AMI otimizada para o Amazon EKS. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres. Para obter ajuda com a seleção de my-max-pods-value, consulte Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2.

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: region-code

managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    instanceType: m5.large
    privateNetworking: true
    disableIMDSv1: true
    labels: { x86-al2-specified-mng }
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster \
        --b64-cluster-ca certificate-authority \
        --apiserver-endpoint api-server-endpoint \
        --dns-cluster-ip service-cidr.10 \
        --kubelet-extra-args '--max-pods=my-max-pods-value' \
        --use-max-pods false

Para cada opção de arquivo eksctl config disponível, consulte Esquema do arquivo config, na documentação do eksctl. O utilitário eksctl ainda cria um modelo de inicialização para você e preenche seus dados de usuário com dados fornecidos no arquivo config.

Crie um grupo de nós com o comando a seguir.

eksctl create nodegroup --config-file=my-nodegroup.yaml

User data in a launch template

Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada example value por seus próprios valores. Os argumentos --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip são opcionais. No entanto, defini-los permite que o script bootstrap.sh evite fazer uma chamada describeCluster. Isso é útil em configurações de cluster privado ou clusters em que há aumento e redução de escala na horizontal com frequência. Para obter mais informações sobre o script bootstrap.sh, consulte o arquivo bootstrap.sh no GitHub.

• O único argumento necessário é o nome do cluster (my-cluster).

• Para recuperar o certificate-authority do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar o api-server-endpoint do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• O valor para o --dns-cluster-ip é o serviço CIDR com .10 no final. Para recuperar o service-cidr do seu cluster, execute o comando a seguir. Por exemplo, se o valor retornado for ipv4 10.100.0.0/16, então seu valor será 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• Este exemplo fornece um argumento adicional do kubelet para definir um valor max-pods personalizado usando o valor do script bootstrap.sh incluído com a AMI otimizada para o Amazon EKS. Para obter ajuda com a seleção de my-max-pods-value, consulte Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2.

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
  --b64-cluster-ca certificate-authority \
  --apiserver-endpoint api-server-endpoint \
  --dns-cluster-ip service-cidr.10 \
  --kubelet-extra-args '--max-pods=my-max-pods-value' \
  --use-max-pods false

--==MYBOUNDARY==--

Fornecer dados de usuário para passar argumentos para o arquivo Start-EKSBootstrap.ps1 incluído com uma AMI do Windows otimizada do Amazon EKS

Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. Você pode passar os argumentos para o script Start-EKSBootstrap.ps1 usando eksctl sem especificar um modelo de inicialização. Ou faça isso especificando as informações na seção de dados de usuário de um modelo de execução.

Se você quiser especificar uma ID de AMI do Windows, tenha em mente as seguintes considerações:

• Você deve usar um modelo de inicialização e fornecer os comandos de bootstrap necessários na seção de dados do usuário. Para recuperar o ID do Windows desejado, você pode usar a tabela em Criar nós com AMIs do Windows otimizadas.

• Existem vários limites e condições. Por exemplo, você deve adicionar eks:kube-proxy-windows ao mapa de configuração do AWS IAM Authenticator. Para obter mais informações, consulte Limites e condições ao especificar uma ID de AMI.

Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada example value por seus próprios valores. Os argumentos -APIServerEndpoint, -Base64ClusterCA e -DNSClusterIP são opcionais. No entanto, defini-los permite que o script Start-EKSBootstrap.ps1 evite fazer uma chamada describeCluster.

• O único argumento necessário é o nome do cluster (my-cluster).

• Para recuperar o certificate-authority do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar o api-server-endpoint do seu cluster, execute o comando a seguir.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• O valor para o --dns-cluster-ip é o serviço CIDR com .10 no final. Para recuperar o service-cidr do seu cluster, execute o comando a seguir. Por exemplo, se o valor retornado for ipv4 10.100.0.0/16, então seu valor será 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• Para obter argumentos adicionais, consulte Parâmetros de configuração do script de bootstrap.

  nota

  Se você estiver usando um CIDR de serviço personalizado, será necessário especificá-lo usando o parâmetro -ServiceCIDR. Caso contrário, a resolução de DNS Pods no cluster falhará.

<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>

Executar uma AMI personalizada devido a requisitos específicos de segurança, conformidade ou política interna

Para obter mais informações, consulte Imagens de máquina da Amazon (AMIs) no Guia do usuário do Amazon EC2. A especificação de compilação da AMI do Amazon EKS contém recursos e scripts de configuração para desenvolver uma AMI do Amazon EKS personalizada baseada no Amazon Linux. Para obter mais informações, consulte Amazon EKS AMI Build Specification (Especificação de criação de AMI do Amazon EKS) no GitHub. Para criar AMIs personalizadas instaladas com outros sistemas operacionais, consulte Amazon EKS Sample Custom AMIs (Amostras de AMIs personalizadas do Amazon EKS) no GitHub.

Importante

Ao especificar uma AMI, o Amazon EKS não mescla nenhum dado do usuário. Em vez disso, você é responsável por fornecer os comandos do bootstrap para que os nós se integrem ao cluster. Se os nós não conseguirem se integrar ao cluster, as ações do Amazon EKS CreateNodegroup e do UpdateNodegroupVersion também falharão.

Limites e condições ao especificar uma ID de AMI

Estes são os limites e condições envolvidos na especificação de um ID de AMI com grupos de nós gerenciados:

• Você deve criar um novo grupo de nós para alternar entre especificar um ID de AMI em um modelo de execução e não especificar um ID de AMI.

• Você não é notificado no console quando uma versão mais recente da AMI estiver disponível. Para atualizar seu grupo de nós para uma versão mais recente da AMI, é necessário criar uma nova versão do modelo de execução com um ID de AMI atualizado. Em seguida, é necessário atualizar o grupo de nós com a nova versão do modelo de execução.

• Os campos a seguir não podem ser definidos na API se você especificar um ID de AMI:

  • amiType

  • releaseVersion

  • version

• Qualquer taints conjunto na API é aplicado de forma assíncrona se você especificar um ID de AMI. Para aplicar contaminações antes de um nó ingressar no cluster, você deve transmiti-las para kubelet os dados do usuário usando a sinalização da linha de comando --register-with-taints. Para obter mais informações, consulte a kubelet documentação do Kubernetes.

• Ao especificar uma ID de AMI personalizada para grupos de nós gerenciados do Windows, adicione eks:kube-proxy-windows ao mapa de configuração do AWS IAM Authenticator. Essa API é necessária para o DNS funcionar bem.

  1. Abra o mapa de configuração do AWS IAM Authenticator para edição.

     kubectl edit -n kube-system cm aws-auth
     

  2. Adicione essa entrada à lista de groups abaixo de cada rolearn associado aos nós do Windows. O mapa de configuração deve ser semelhante ao aws-auth-cm-windows.yaml.

     - eks:kube-proxy-windows

  3. Salve o arquivo e saia do seu editor de texto.