Atualização do Amazon Linux 2 para o Amazon Linux 2023

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 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 DescribeCluster 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 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 e 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.

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.

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.