As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Grupos de nós gerenciados pelo EKS
Os [grupos de nós gerenciados do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) são um recurso que automatiza o provisionamento e o gerenciamento do ciclo de vida dos nós (instâncias EC2) para clusters do Amazon EKS Kubernetes. Os clientes podem provisionar grupos otimizados de nós para seus clusters e o EKS manterá seus nós atualizados com as versões mais recentes do Kubernetes e do sistema operacional host.
Um grupo de nós gerenciados pelo EKS é um grupo de escalonamento automático e instâncias EC2 associadas que são gerenciadas pela AWS para um cluster Amazon EKS. Cada grupo de nós usa o Amazon EKS-optimized Amazon Linux 2 AMI. O Amazon EKS facilita a aplicação de correções de bugs e patches de segurança aos nós, bem como a atualização deles para as versões mais recentes do Kubernetes. Cada grupo de nós lança um grupo de escalonamento automático para seu cluster, que pode abranger várias zonas de disponibilidade e sub-redes do AWS VPC para alta disponibilidade.
**NOVO** [suporte ao modelo de lançamento para grupos de nós gerenciados](launch-template-support.md)
**nota**
O termo “grupos de nós não gerenciados” tem sido usado para se referir aos grupos de nós que o eksctl suporta desde o início (representados por meio do campo). `nodeGroups` O `ClusterConfig` arquivo continua usando o `nodeGroups` campo para definir grupos de nós não gerenciados, e os grupos de nós gerenciados são definidos com o campo. `managedNodeGroups`
## Criação de grupos de nós gerenciados
```
$ eksctl create nodegroup
```
### Novos clusters
Para criar um novo cluster com um grupo de nós gerenciado, execute
```
eksctl create cluster
```
Para criar vários grupos de nós gerenciados e ter mais controle sobre a configuração, um arquivo de configuração pode ser usado.
**nota**
Grupos de nós gerenciados não têm paridade completa de recursos com grupos de nós não gerenciados.
```
# cluster.yaml
# A cluster with two managed nodegroups
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: managed-cluster
region: us-west-2
managedNodeGroups:
- name: managed-ng-1
minSize: 2
maxSize: 4
desiredCapacity: 3
volumeSize: 20
ssh:
allow: true
publicKeyPath: ~/.ssh/ec2_id_rsa.pub
# new feature for restricting SSH access to certain AWS security group IDs
sourceSecurityGroupIds: ["sg-00241fbb12c607007"]
labels: {role: worker}
tags:
nodegroup-role: worker
iam:
withAddonPolicies:
externalDNS: true
certManager: true
- name: managed-ng-2
instanceType: t2.large
minSize: 2
maxSize: 3
```
[Outro exemplo de arquivo de configuração para criar um grupo de nós gerenciado pode ser encontrado aqui.](https://github.com/eksctl-io/eksctl/blob/main/examples/15-managed-nodes.yaml)
É possível ter um cluster com grupos de nós gerenciados e não gerenciados. Grupos de nós não gerenciados não aparecem no console do AWS EKS, mas `eksctl get nodegroup` listarão os dois tipos de grupos de nós.
```
# cluster.yaml
# A cluster with an unmanaged nodegroup and two managed nodegroups.
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: managed-cluster
region: us-west-2
nodeGroups:
- name: ng-1
minSize: 2
managedNodeGroups:
- name: managed-ng-1
minSize: 2
maxSize: 4
desiredCapacity: 3
volumeSize: 20
ssh:
allow: true
publicKeyPath: ~/.ssh/ec2_id_rsa.pub
# new feature for restricting SSH access to certain AWS security group IDs
sourceSecurityGroupIds: ["sg-00241fbb12c607007"]
labels: {role: worker}
tags:
nodegroup-role: worker
iam:
withAddonPolicies:
externalDNS: true
certManager: true
- name: managed-ng-2
instanceType: t2.large
privateNetworking: true
minSize: 2
maxSize: 3
```
**NOVO** Suporte para AMI personalizada, grupos de segurança`instancePrefix`,`instanceName`,`ebsOptimized`,`volumeType`,`volumeName`,`volumeEncrypted`,`volumeKmsKeyID`,`volumeIOPS`,`maxPodsPerNode`,`preBootstrapCommands`,`overrideBootstrapCommand`, e `disableIMDSv1`
```
# cluster.yaml
# A cluster with a managed nodegroup with customization.
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: managed-cluster
region: us-west-2
managedNodeGroups:
- name: custom-ng
ami: ami-0e124de4755b2734d
securityGroups:
attachIDs: ["sg-1234"]
maxPodsPerNode: 80
ssh:
allow: true
volumeSize: 100
volumeName: /dev/xvda
volumeEncrypted: true
# defaults to true, which enforces the use of IMDSv2 tokens
disableIMDSv1: false
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'
```
Se você estiver solicitando um tipo de instância disponível somente em uma zona (e a configuração do eksctl exigir a especificação de duas), certifique-se de adicionar a zona de disponibilidade à sua solicitação de grupo de nós:
```
# cluster.yaml
# A cluster with a managed nodegroup with "availabilityZones"
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: flux-cluster
region: us-east-2
version: "1.23"
availabilityZones: ["us-east-2b", "us-east-2c"]
managedNodeGroups:
- name: workers
instanceType: hpc6a.48xlarge
minSize: 64
maxSize: 64
labels: { "fluxoperator": "true" }
availabilityZones: ["us-east-2b"]
efaEnabled: true
placement:
groupName: eks-efa-testing
```
Isso pode ser verdade para tipos de exemplo, como [a família Hpc6](https://aws.amazon.com/ec2/instance-types/hpc6/), que só estão disponíveis em uma zona.
### Clusters existentes
```
eksctl create nodegroup --managed
```
Dica: se você estiver usando um `ClusterConfig` arquivo para descrever todo o cluster, descreva seu novo grupo de nós gerenciados no `managedNodeGroups` campo e execute:
```
eksctl create nodegroup --config-file=YOUR_CLUSTER.yaml
```
## Atualizando grupos de nós gerenciados
Você pode atualizar um grupo de nós para a versão mais recente da EKS-optimized AMI para o tipo de AMI que você está usando a qualquer momento.
Se seu grupo de nós for da mesma versão do Kubernetes do cluster, você poderá atualizar para a versão mais recente da AMI para aquela versão do Kubernetes do tipo de AMI que você está usando. Se seu nodegroup for a versão anterior do Kubernetes da versão do Kubernetes do cluster, você poderá atualizar o nodegroup para a versão mais recente da AMI que corresponda à versão do Kubernetes do nodegroup ou atualizar para a versão mais recente da AMI que corresponda à versão do Kubernetes do cluster. Você não pode reverter um grupo de nós para uma versão anterior do Kubernetes.
Para atualizar um grupo de nós gerenciado para a versão mais recente da AMI:
```
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster
```
O nodegroup pode ser atualizado para a versão mais recente da AMI para uma versão específica do Kubernetes usando:
```
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster --kubernetes-version=
```
Para fazer o upgrade para uma versão específica da AMI em vez da versão mais recente, passe`--release-version`:
```
eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster --release-version=1.19.6-20210310
```
**nota**
Se os nós gerenciados forem implantados usando AMIs personalizadas, o fluxo de trabalho a seguir deverá ser seguido para implantar uma nova versão da AMI personalizada.
+ a implantação inicial do grupo de nós deve ser feita usando um modelo de lançamento. por exemplo
```
managedNodeGroups:
- name: launch-template-ng
launchTemplate:
id: lt-1234
version: "2" #optional (uses the default version of the launch template if unspecified)
```
+ crie uma nova versão da AMI personalizada (usando o console AWS EKS).
+ crie uma nova versão do modelo de lançamento com o novo ID da AMI (usando o console AWS EKS).
+ atualize os nós para a nova versão do modelo de lançamento. por exemplo
```
eksctl upgrade nodegroup --name nodegroup-name --cluster cluster-name --launch-template-version new-template-version
```
## Manipulando atualizações paralelas para nós
Vários nós gerenciados podem ser atualizados simultaneamente. Para configurar atualizações paralelas, defina o `updateConfig` de um grupo de nós ao criar o grupo de nós. Um exemplo `updateConfig` pode ser encontrado [aqui](https://github.com/eksctl-io/eksctl/blob/main/examples/15-managed-nodes.yaml).
Para evitar qualquer tempo de inatividade em suas cargas de trabalho devido à atualização de vários nós ao mesmo tempo, você pode limitar o número de nós que podem ficar indisponíveis durante uma atualização especificando isso no campo de um. `maxUnavailable` `updateConfig` Como alternativa, use`maxUnavailablePercentage`, que define o número máximo de nós indisponíveis como uma porcentagem do número total de nós.
Observe que `maxUnavailable` não pode ser maior que`maxSize`. Além disso, `maxUnavailable` e `maxUnavailablePercentage` não pode ser usado simultaneamente.
Esse recurso está disponível somente para nós gerenciados.
## Atualizando grupos de nós gerenciados
`eksctl`permite atualizar a [UpdateConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-nodegroup-updateconfig.html)seção de um grupo de nós gerenciado. Esta seção define dois campos. `MaxUnavailable``MaxUnavailablePercentage`e. Seus grupos de nós não são afetados durante a atualização, portanto, o tempo de inatividade não deve ser esperado.
O comando `update nodegroup` deve ser usado com um arquivo de configuração usando o `--config-file` sinalizador. O grupo de nós deve conter uma `nodeGroup.updateConfig` seção. Mais informações podem ser encontradas [aqui](https://geoffcline.github.io/eksctl-schema-demo/#nodeGroups-updateConfig).
## Problemas de saúde do Nodegroup
O EKS Managed Nodegroups verifica automaticamente a configuração do seu grupo de nós e dos nós em busca de problemas de saúde e os relata por meio da API e do console do EKS. Para ver os problemas de saúde de um grupo de nós:
```
eksctl utils nodegroup-health --name=managed-ng-1 --cluster=managed-cluster
```
## Gerenciando rótulos
Os grupos de nós gerenciados do EKS oferecem suporte à anexação de rótulos que são aplicados aos nós do Kubernetes no grupo de nós. Isso é especificado por meio do `labels` campo em eksctl durante a criação do cluster ou do nodegroup.
Para definir novos rótulos ou atualizar rótulos existentes em um grupo de nós:
```
eksctl set labels --cluster managed-cluster --nodegroup managed-ng-1 --labels kubernetes.io/managed-by=eks,kubernetes.io/role=worker
```
Para desmarcar ou remover rótulos de um grupo de nós:
```
eksctl unset labels --cluster managed-cluster --nodegroup managed-ng-1 --labels kubernetes.io/managed-by,kubernetes.io/role
```
Para ver todos os rótulos definidos em um grupo de nós:
```
eksctl get labels --cluster managed-cluster --nodegroup managed-ng-1
```
## Dimensionando grupos de nós gerenciados
`eksctl scale nodegroup`também oferece suporte a grupos de nós gerenciados. A sintaxe para escalar um grupo de nós gerenciado ou não gerenciado é a mesma.
```
eksctl scale nodegroup --name=managed-ng-1 --cluster=managed-cluster --nodes=4 --nodes-min=3 --nodes-max=5
```
## Mais informações
+ [Grupos de nós gerenciados pelo EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)