AMIs do Amazon Linux otimizadas para Amazon EKS - Amazon EKS
Atualização do AL2 para o AL2023AceleradoArmTeste a migração do Docker para containerdMais informações

AMIs do Amazon Linux otimizadas para Amazon EKS

A AMI do Amazon Linux otimizada para o Amazon EKS é desenvolvida com base no Amazon Linux 2 (AL2) e no Amazon Linux 2023 (AL2023). Está configurada para servir como imagem base para nós do Amazon EKS. A AMI é configurada para funcionar com o Amazon EKS e inclui os seguintes componentes:

  • kubelet

  • AWS IAM Authenticator

  • Docker(Amazon EKS versão 1.23 e anteriores)

  • containerd

nota

  • É possível acompanhar eventos de segurança ou de privacidade para o AL2 no Amazon Linux Security Center ou ao se tornar assinante do Feed RSS associado. Os eventos de segurança e privacidade incluem uma visão geral do problema, quais pacotes são afetadas e como atualizar suas instâncias para corrigir o problema.

  • Antes de implantar uma AMI acelerada ou do Arm, analise as informações em AMIs do Amazon Linux aceleradas e otimizadas para Amazon EKS e AMIs Amazon Linux Arm otimizadas para Amazon EKS.

  • Para o Kubernetes versão1.23, você pode usar um sinalizador de bootstrap opcional para testar a migração de Docker para containerd. Para ter mais informações, consulte Teste a migração do Docker para containerd.

  • A partir do Kubernetes versão 1.25, não será mais possível usar instâncias P2 do Amazon EC2 com as AMIs aceleradas do Amazon Linux otimizadas para o Amazon EKS prontas para uso. Essas AMIs para o Kubernetes versões 1.25 ou posteriores serão compatíveis com drivers série NVIDIA 525 ou posterior, que são incompatíveis com as instâncias P2. No entanto, os drivers da série NVIDIA 525 ou posteriores são compatíveis com as instâncias P3, P4 e P5. Portanto, é possível usar essas instâncias com as AMIs para o Kubernetes versão 1.25 ou posterior. Antes que seus clusters do Amazon EKS sejam atualizados para a versão 1.25, migre qualquer instância P2 para instâncias P3, P4 e P5. Você também deverá atualizar proativamente suas aplicações para funcionar com a série NVIDIA 525 ou posterior. Planejamos transferir os drivers da série NVIDIA 525 ou mais recente ou para as versões 1.23 e 1.24 do Kubernetes no final de janeiro de 2024.

  • A partir da versão 1.30 do Amazon EKS ou em versões mais recentes, qualquer grupo de nós gerenciados recém-criados será automaticamente padronizado para usar o AL2023 como o sistema operacional do nó. Anteriormente, os novos grupos de nós seriam padronizados para usar o AL2. É possível continuar a usar AL2 ao escolhê-lo como o tipo de AMI durante a criação de um novo grupo de nós.

  • O suporte para o AL2 será encerrado em 30 de junho de 2025. Para obter mais informações, consulte Perguntas frequentes do Amazon Linux 2.

Atualização do AL2 para o AL2023

A AMI otimizada para o Amazon EKS está disponível em duas famílias baseadas no AL2 e no AL2023. O AL2023 é um novo 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, incluindo as versões 1.23 e 1.24 que estão em suporte estendido. As AMIs aceleradas do Amazon EKS baseadas no AL2023 estarão disponíveis posteriormente. Se você tiver workloads aceleradas, deverá continuar a usar a AMI acelerada do AL2 ou o Bottlerocket.

O AL2023 oferece diversas melhorias em relação ao AL2. Para obter uma comparação completa, consulte Comparing AL2 and Amazon Linux 2023 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 nas Notas de lançamento do Amazon Linux 2023.

Além dessas alterações, você deve 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 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 cidr do serviço, consulte DescribeCluster na Referência de APIs do Amazon EKS.

  • O Docker não é compatível no AL2023 para todas as versões compatíveis do Amazon EKS. O suporte para o Docker foi encerrado e removido com a versão 1.24 ou com versões posteriores do Amazon EKS no AL2. Para obter mais informações sobre a descontinuação, consulte Amazon EKS ended support for Dockershim.

  • 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.

    nota

    Para o IMDSv2, a contagem de saltos padrão para os grupos de nós gerenciados é definida 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 ao substituir manualmente HttpPutResponseHopLimit em um modelo de inicialização personalizado do Amazon EC2 e aumentá-lo para 2. Como alternativa, é possível usar a Identidade de Pod do Amazon EKS 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.

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, você poderá realizar uma atualização local ao alterar o ID da AMI no modelo de inicialização. Você deve 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, você poderá 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 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 seus nós de processamento para a AMI mais recente, quando disponível.

AMIs do Amazon Linux aceleradas e otimizadas para Amazon EKS

nota

As AMIs aceleradas do Amazon EKS baseadas no AL2023 estarão disponíveis posteriormente. Caso tenha workloads aceleradas, você deverá continuar a usar a AMI acelerada do AL2 ou o Bottlerocket.

A AMI do Amazon Linux otimizada e acelerada para o Amazon EKS é desenvolvida sobre a AMI do Amazon Linux otimizada para o Amazon EKS padrão. A AMI está configurada para servir como uma imagem opcional para nós do Amazon EKS com a finalidade de oferecer suporte a workloads baseadas em GPU, no Inferentia e no Trainium.

Além da configuração padrão da AMI otimizada para Amazon EKS, a AMI acelerada inclui o seguinte:

  • Drivers NVIDIA

  • nvidia-container-runtime (como o runtime padrão)

  • Runtime do contêiner do AWS Neuron

Para obter uma lista dos componentes mais recentes incluídos na AMI acelerada, consulte amazon-eks-ami Releases no GitHub.

nota

  • A AMI acelerada, otimizada para o Amazon EKS, é compatível apenas com tipos de instâncias baseadas em GPU e Inferentia. Especifique esses tipos de instância no template do AWS CloudFormation do nó. Ao usar a AMI acelerada, otimizada para o Amazon EKS, você concorda com o Contrato de licença do usuário final (EULA) da NVIDIA.

  • A AMI acelerada, otimizada para o Amazon EKS, era mencionada anteriormente como a AMI otimizada para o Amazon EKS compatível com GPU.

  • As versões anteriores da AMI acelerada, otimizada para o Amazon EKS, tinham o repositório nvidia-docker instalado. O repositório não está mais incluído na versão v20200529 da AMI para o Amazon EKS e posteriores.

Para habilitar workloads baseadas em GPU

O procedimento a seguir descreve como executar uma workload em uma instância baseada em GPU com a AMI acelerada otimizada para o Amazon EKS. Para outras opções, consulte as seguintes referências:

  1. Depois que seus nós de GPU ingressarem no cluster, você deverá aplicar o Plug-in de dispositivo NVIDIA para Kubernetes como um DaemonSet em seu cluster. Substitua vX.X.X pela versão desejada de NVIDIA/k8s-device-plugin antes de executar o comando a seguir.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml

  2. Você pode verificar se os nós têm GPUs alocáveis com o seguinte comando:

    kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"
Para implantar um Pod e testar se os nós da GPU estão configurados corretamente

  1. Crie um arquivo denominado nvidia-smi.yaml com o seguinte conteúdo: Substitua tag pela tag desejada para nvidia/cuda. Este manifesto inicia um contêiner NVIDIA CUDA que executa o nvidia-smi em um nó.

    apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: nvidia/cuda:tag
    args:
    - "nvidia-smi"
    resources:
      limits:
        nvidia.com/gpu: 1

  2. Aplique o manifesto com o comando a seguir.

    kubectl apply -f nvidia-smi.yaml

  3. Após a execução do Pod ser concluída, visualize os logs com o comando a seguir.

    kubectl logs nvidia-smi

    Veja um exemplo de saída abaixo.

    Mon Aug  6 20:23:31 20XX
+-----------------------------------------------------------------------------+
| NVIDIA-SMI XXX.XX                 Driver Version: XXX.XX                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1C.0 Off |                    0 |
| N/A   46C    P0    47W / 300W |      0MiB / 16160MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

AMIs Amazon Linux Arm otimizadas para Amazon EKS

As instâncias Arm oferecem uma economia significativa para aplicações de expansão e baseadas no Arm, como servidores Web, microsserviços conteinerizados, frotas de armazenamento em cache e datastores distribuídos. Ao adicionar nós do Arm ao cluster, revise as considerações a seguir.

Considerações

  • Se o cluster tiver sido implantado antes de 17 de agosto de 2020, será necessário fazer uma atualização única dos manifestos essenciais do complemento de cluster. Isso serve para que o Kubernetes possa extrair a imagem correta para cada arquitetura de hardware em uso em seu cluster. Para obter mais informações sobre como atualizar complementos do cluster, consulte Atualizar a versão do Kubernetes de um cluster do Amazon EKS. Se você implantou o cluster a partir de 17 de agosto de 2020, os complementos CoreDNS, kube-proxy e Amazon VPC CNI plugin for Kubernetes já têm capacidade para várias arquiteturas.

  • As aplicações implantadas em nós do Arm devem ser compiladas para Arm.

  • Se tiver DaemonSets implantados em um cluster existente ou quiser implantá-los em um novo cluster no qual também queira implantar nós do Arm, verifique se o DaemonSet pode ser executado em todas as arquiteturas de hardware do cluster.

  • Você pode executar grupos de nós do Arm e grupos de nós x86 no mesmo cluster. Se o fizer, considere implantar imagens de contêiner de várias arquiteturas em um repositório de contêineres, como o Amazon Elastic Container Registry, e depois adicionar seletores de nós aos manifestos para que o Kubernetes saiba em que arquitetura de hardware um Pod pode ser implantado. Para obter mais informações, consulte Enviar uma imagem de várias arquiteturas no Guia do usuário do Amazon ECR e a publicação de blog Introducing multi-architecture container images for Amazon ECR.

Teste a migração do Docker para containerd

O Amazon EKS deixou de ser compatível com o Docker a partir da versão 1.24 do Kubernetes. Para ter mais informações, consulte O Amazon EKS deixou de ser compatível com o Dockershim.

Para a versão 1.23 do Kubernetes, é possível usar um sinalizador de inicialização opcional para habilitar o runtime do containerd para AMIs do AL2 otimizadas para o Amazon EKS. Esse recurso fornece um caminho claro de migração para o containerd ao atualizar para a versão 1.24 ou posterior. O Amazon EKS deixou de ser compatível com o Docker a partir da versão 1.24 do Kubernetes. O runtime do containerd tem sido amplamente adotado na comunidade do Kubernetes e é um projeto graduado com a CNCF. Você pode testá-lo adicionando um grupo de nós a um cluster novo ou existente.

Você pode habilitar o sinalizador de boostrap criando um dos tipos de grupos de nós a seguir.

Autogerenciado

Implante o grupo de nós usando as instruções em Lançar nós autogerenciados do Amazon Linux. Especifique uma AMI otimizada para o Amazon EKS e o texto a seguir para o parâmetro BootstrapArguments.

--container-runtime containerd
Gerenciados

Se você usar o eksctl, crie um arquivo denominado my-nodegroup.yaml com o conteúdo a seguir. Substitua example value por seus próprios valores. 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 recuperar um ID de AMI otimizada para ami-1234567890abcdef0, consulte IDs da AMI da AMI do Amazon Linux otimizada para Amazon EKS.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
nota

Se você iniciar muitos nós ao mesmo tempo, também poderá especificar valores para os argumentos de bootstrap --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip para evitar erros. Para ter mais informações, consulte Especificar uma AMI.

Execute os comandos a seguir para criar um grupo de nós.

eksctl create nodegroup -f my-nodegroup.yaml

Se preferir usar uma ferramenta diferente para criar o grupo de nós gerenciados, é necessário implantar o grupo de nós usando um modelo de execução. No seu modelo de execução, especifique um ID de AMI otimizada para Amazon EKS e implante o grupo de nós usando um modelo de execução e forneça os seguintes dados de usuário. Esses dados do usuário transmitem argumentos para o arquivo bootstrap.sh. Para obter mais informações sobre o arquivo de bootstrap, consulte bootstrap.sh no GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

Mais informações

Para obter mais informações sobre o uso de AMIs Amazon Linux otimizadas para Amazon EKS, consulte as seguintes seções: