**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. # Personalizar nós gerenciados com modelos de execução Para obter o máximo de personalização, é possível implantar nós gerenciados com seu próprio modelo de execução, seguindo as etapas descritas nesta página. O uso de um modelo de execução permite, entre outras funcionalidades, fornecer argumentos de inicialização durante a implantação de um nó (por exemplo, argumentos extras do [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)), atribuir endereços IP aos pods de um bloco CIDR diferente daquele atribuído ao endereço IP do nó, implantar uma AMI ou uma CNI personalizadas com base nos seus requisitos para os 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, será necessário 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 lançamento do Amazon EC2 Auto Scaling com o Console de gerenciamento da AWS, 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) 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. Eles podem ter nomes semelhantes, mas diferentes, na CLI e no SDK do AWS. | 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. Eles podem ter nomes semelhantes na CLI e no SDK do AWS. | Configuração do grupo de nós do Amazon EKS - Proibidas | Modelo de execução | | --- | --- | | (Somente se você tiver especificado uma AMI personalizada em um modelo de execução) Em **Tipo de AMI**, na **Configuração de computação do grupo de nós**, na página **Definir configuração de computação e escalabilidade**, o console exibe **Especificado no modelo de execução** e o ID da AMI especificada. Se **Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)** não tiver sido especificado no modelo de execução, será possível 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/launch-templates.html) | | **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). É necessário 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](#launch-template-security-groups). | **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](managed-node-groups.md#managed-node-group-capacity-types). 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) no *Manual do usuário do Amazon EC2*. Os modelos de execução não são compatíveis com o recurso `InstanceRequirements` que permite a seleção flexível do tipo de instância. ## Etiquetar instâncias do Amazon EC2 É possível 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 É possível usar um modelo de execução para especificar os [grupos de segurança](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) 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 Console de gerenciamento da AWS é 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 cluster](sec-group-reqs.md)para as instâncias no grupo de nós, a fim de facilitar a comunicação entre os nós e o ambiente de gerenciamento. 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, é necessário 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 [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). + 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 [Usar dados de usuário](https://github.com/bottlerocket-os/bottlerocket#using-user-data) no GitHub. É possível 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](https://cloudinit.readthedocs.io/en/latest/index.html). 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](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [Instalar pacotes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) Os dados de usuário 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](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) 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](#launch-template-custom-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. **Dados do usuário do Amazon Linux 2** É possível 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](https://cloudinit.readthedocs.io/en/latest/topics/format.html). + 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==-- ``` **Dados do usuário do Amazon Linux 2023** 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](https://awslabs.github.io/amazon-eks-ami/nodeadm/) 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 sobre o serviço de `cidr`, consulte [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) na *Referência de API do Amazon EKS*. Aqui está um exemplo completo dos dados do usuário do AL2023 que combinam um script de shell para personalizar o nó (como instalar pacotes ou pré-armazenar imagens de contêiner em cache) com a configuração de `nodeadm` necessária. Este exemplo mostra personalizações comuns, incluindo: \$1 Instalação de pacotes adicionais do sistema \$1 Pré-armazenamento em cache de imagens de contêiner para melhorar o tempo de inicialização do pod \$1 Configuração do proxy HTTP \$1 Configuração de sinalizadores `kubelet` para rotulagem de nós ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Dados do usuário do Bottlerocket** 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 do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) do GitHub. É possível configurar rótulos de nós e [taints](node-taints-managed-node-groups.md) 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 = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + Cabeçalhos entre colchetes com chaves entre aspas: `[foo."bar.baz"]` **Dados do usuário do Windows** Os dados do usuário do Windows usam os 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 dos comandos de dados de usuário gerenciados, tudo em uma tag ``. Ao criar grupos de nós do Windows, o Amazon EKS atualiza o `aws-auth` `ConfigMap` para permitir que os nós baseados em Linux façam parte do cluster. O serviço não configura automaticamente as permissões para AMIs do Windows. Se você estiver usando nós do Windows, precisará gerenciar o acesso por meio da API de entrada de acesso ou atualizando `aws-auth` `ConfigMap` diretamente. Para obter mais informações, consulte [Implantar nós Windows em clusters EKS](windows-support.md). 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. ``` Write-Host "Running custom user data script" ``` ## 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 Amazon EKS Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. Por exemplo, o bootstrapping permite o uso de argumentos adicionais [do kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/). É possível 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 sem especificar um modelo de inicialização** Crie um arquivo chamado *my-nodegroup.yaml* com o seguinte conteúdo. Substitua cada *valor de exemplo* 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](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/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 `, consulte as seguintes seções: + [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md) + [Recuperar IDs de AMI do Bottlerocket recomendadas](retrieve-ami-id-bottlerocket.md) + [Recuperar IDs de AMI do Microsoft Windows recomendadas](retrieve-windows-ami-id.md) + Para recuperar o *certificado de autoridade* do seu cluster, execute o seguinte comando. ``` 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 seguinte comando. ``` 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 seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *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 ajuda com a seleção de *my-max-pods-value*, consulte . Para obter mais informações sobre como `maxPods` é determinado ao usar grupos de nós gerenciados, consulte [Como maxPods é determinado](choosing-instance-type.md#max-pods-precedence). ``` --- 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](https://eksctl.io/usage/schema/), 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 ``` **Dados do usuário em um modelo de lançamento** Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada *valor de exemplo* 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](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) no GitHub. + O único argumento necessário é o nome do cluster*(my-cluster*). + Para recuperar o *certificado de autoridade* do seu cluster, execute o seguinte comando. ``` 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 seguinte comando. ``` 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 seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *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 ajuda com a seleção de *my-max-pods-value*, consulte . Para obter mais informações sobre como `maxPods` é determinado ao usar grupos de nós gerenciados, consulte [Como maxPods é determinado](choosing-instance-type.md#max-pods-precedence). ``` 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 para Amazon EKS Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. É possível 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 um ID de AMI do Windows, tenha em mente as seguintes considerações: + É necessário 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 otimizadas do Windows](eks-optimized-windows-ami.md). + Existem vários limites e condições. Por exemplo, é necessário 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](#mng-ami-id-conditions). Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada *valor de exemplo* 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 *certificado de autoridade* do seu cluster, execute o seguinte comando. ``` 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 seguinte comando. ``` 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 seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *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](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters). **nota** Se você estiver usando um CIDR de serviço personalizado, será necessário especificá-lo usando o parâmetro `-ServiceCIDR`. Do contrário, a resolução de DNS para pods no cluster falhará. ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### 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)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 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](https://github.com/awslabs/amazon-eks-ami/) (Especificação de compilação da AMI do Amazon EKS) no GitHub. Para criar AMIs personalizadas instaladas com outros sistemas operacionais, consulte [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) (AMIs personalizadas de amostra do Amazon EKS) no GitHub. Não é possível usar referências de parâmetros dinâmicos para IDs de AMI em Modelos de Lançamento usados com grupos de nós gerenciados. **Importante** Ao especificar uma AMI, o Amazon EKS não valida a versão do Kubernetes incorporada à sua AMI em relação à versão do ambiente de gerenciamento do seu cluster. Você é responsável por garantir que a versão do Kubernetes da sua AMI personalizada esteja em conformidade com a [política de distorção de versão do Kubernetes](https://kubernetes.io/releases/version-skew-policy): A versão `kubelet` em seus nós não deve ser mais recente que a versão do cluster A versão `kubelet` em seus nós deve ser igual ou até 3 versões secundárias atrás da versão do cluster (para a versão `1.28` ou posterior do Kubernetes) ou até 2 versões secundárias atrás da versão do cluster (para a versão `1.27` ou anterior do Kubernetes) A criação de grupos de nós gerenciados com violações de distorção de versão pode resultar em: Falha nos nós de operador ao ingressar no cluster Comportamento indefinido ou incompatibilidades de API Instabilidade do cluster ou falhas na workload 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: + É necessário 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, é necessário 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 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) na documentação do Kubernetes. + Ao especificar um ID de AMI personalizado 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 ``` 1. Adicione essa entrada à lista de `groups` abaixo de cada `rolearn` associado aos nós do Windows. Seu mapa de configuração deve ser semelhante a [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml). ``` - eks:kube-proxy-windows ``` 1. Salve o arquivo e saia do seu editor de texto. + Para qualquer AMI que usa um modelo de execução personalizado, o `HttpPutResponseHopLimit` padrão para grupos de nós gerenciados é definido como `2`.