**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.
# Atualização do Amazon Linux 2 para o Amazon Linux 2023
**Atenção**
A partir de 26 de novembro de 2025, a Amazon EKS não publica mais AMIs do Amazon Linux 2 (AL2) otimizadas para o EKS. As AMIs baseadas no AL2023 e no Bottlerocket para o Amazon EKS estão disponíveis para todas as versões compatíveis com Kubernetes, incluindo a versão 1.33 e as versões posteriores.
O AL2023 é um sistema operacional baseado no Linux que foi projetado para fornecer um ambiente seguro, estável e de alta performance para as aplicações em nuvem. Ele corresponde à próxima geração do Amazon Linux da Amazon Web Services e está disponível em todas as versões do Amazon EKS com suporte.
O AL2023 oferece diversas melhorias em relação ao AL2. Para obter uma comparação completa, consulte [Comparing AL2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) no *Guia do usuário do Amazon Linux 2023*. Vários pacotes foram adicionados, atualizados e removidos em relação ao AL2. É altamente recomendável testar as aplicações com o AL2023 antes de realizar a atualização. Para obter uma lista de todas as alterações de pacote no AL2023, consulte [Package changes in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) nas *Notas de lançamento do Amazon Linux 2023*.
Além dessas alterações, é necessário estar ciente do seguinte:
+ O 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
```
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*.
+ Para o AL2023, o `nodeadm` também altera o formato para aplicar parâmetros ao `kubelet` para cada nó usando [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). No AL2, isso era feito com o parâmetro `--kubelet-extra-args`. Isso é comumente usado para adicionar rótulos e taints aos nós. Um exemplo abaixo mostra a aplicação de `maxPods` e `--node-labels` ao nó.
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ A versão `1.16.2` ou as versões posteriores do plug-in CNI da Amazon VPC são necessárias para o AL2023.
+ O AL2023 requer `IMDSv2` por padrão. O `IMDSv2` tem diversos benefícios que ajudam a aprimorar a postura de segurança. Ele usa um método de autenticação orientado por sessão que requer a criação de um token secreto em uma solicitação HTTP PUT simples para iniciar a sessão. O token de uma sessão pode ter validade de um segundo a seis horas. Para obter mais informações sobre como fazer a transição do `IMDSv1` para o `IMDSv2`, consulte [Transition to using Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) e [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Se desejar usar o `IMDSv1`, você ainda poderá fazê-lo ao substituir manualmente as configurações usando as propriedades de inicialização da opção de metadados da instância.
**nota**
Para `IMDSv2` com AL2023, a contagem de saltos padrão para os grupos de nós gerenciados pode variar:
Quando não estiver usando um modelo de lançamento, o padrão será definido como `1`. Isso significa que os contêineres não terão acesso às credenciais do nó usando o IMDS. Se você precisar de acesso de contêiner às credenciais do nó, ainda poderá obtê-lo usando um [modelo de execução personalizado do Amazon EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html).
Ao usar uma AMI personalizada em um modelo de execução, o padrão `HttpPutResponseHopLimit` será definido como `2`. É possível substituir manualmente o `HttpPutResponseHopLimit` no modelo de execução.
Como alternativa, é possível usar a [Identidade de Pods do Amazon EKS](pod-identities.md) para fornecer credenciais em vez de usar o `IMDSv2`.
+ O AL2023 apresenta a próxima geração de hierarquia de grupo de controle unificada (`cgroupv2`). A hierarquia `cgroupv2` é usada para implementar um runtime de contêiner e usar `systemd`. Embora o AL2023 ainda inclua códigos que podem fazer o sistema funcionar ao usar `cgroupv1`, esta não é uma configuração recomendada ou com suporte. Essa configuração será completamente removida em uma versão principal futura do Amazon Linux.
+ O `eksctl` versão `0.176.0` ou superior é necessário para o `eksctl` oferecer suporte ao AL2023.
Para grupos de nós gerenciados anteriormente existentes, é possível realizar uma atualização no local ou uma atualização azul/verde, dependendo de como você está usando um modelo de inicialização:
+ Caso esteja usando uma AMI personalizada com um grupo de nós gerenciados, será possível realizar uma atualização local ao alterar o ID da AMI no modelo de inicialização. É necessário garantir que as aplicações e quaisquer dados do usuário sejam transferidos para o AL2023 antes de executar essa estratégia de atualização.
+ Se você estiver usando grupos de nós gerenciados com o modelo de inicialização padrão ou com um modelo de inicialização personalizado que não especifica o ID da AMI, será necessário fazer upgrade usando uma estratégia azul/verde. Uma atualização azul/verde, normalmente, é mais complexa e envolve a criação de um grupo de nós totalmente novo no qual você especificaria o AL2023 como o tipo de AMI. O novo grupo de nós precisará ser configurado cuidadosamente para garantir que todos os dados personalizados do grupo de nós do AL2 sejam compatíveis com o novo sistema operacional. Depois que o novo grupo de nós tiver sido testado e validado com as aplicações, os pods poderão ser migrados do grupo de nós antigo para o novo grupo de nós. Depois que a migração for concluída, será possível excluir o grupo de nós antigo.
Se estiver usando o Karpenter e desejar usar o AL2023, você precisará modificar o campo `EC2NodeClass` `amiFamily` com o AL2023. Por padrão, a Oscilação está habilitada no Karpenter. Isso significa que assim que o campo `amiFamily` for alterado, o Karpenter atualizará automaticamente os nós de processamento para a AMI mais recente, quando disponível.
## Informações adicionais sobre o nodeadm
Ao utilizar uma AMI do Amazon Linux 2023 otimizada para EKS ou criar uma AMI personalizada do EKS Amazon Linux 2023 por meio dos scripts do Packer fornecidos no repositório oficial amazon-eks-ami do GitHub, será necessário evitar executar explicitamente nodeadm init nos dados do usuário do EC2 ou como parte da sua AMI personalizada.
Se você quiser gerar um NodeConfig dinâmico em seus dados de usuário, é possível gravar essa configuração em um arquivo yaml ou json drop-in em `/etc/eks/nodeadm.d`. Esses arquivos de configuração serão mesclados e aplicados ao seu nó quando a inicialização do nodeadm for iniciada automaticamente, posteriormente no processo de inicialização. Por exemplo:
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
As AMIs do Amazon Linux 2023 otimizadas para EKS executam automaticamente a inicialização do nodeadm em duas fases por meio de serviços systemd separados: nodeadm-config é executado antes da execução dos dados do usuário, enquanto nodeadm-run é executado depois. O serviço nodeadm-config estabelece configurações básicas para containerd e kubelet antes da execução dos dados do usuário. O serviço nodeadm-run executa alguns daemons do sistema e conclui todas as configurações finais após a execução dos dados do usuário. Se o comando de inicialização do nodeadm for executado mais uma vez, por meio de dados do usuário ou de uma AMI personalizada, ele poderá quebrar as suposições sobre a ordem de execução, levando a resultados inesperados, incluindo ENIs configurados incorretamente.