O que é Bottlerocket e como usá-lo no EKS?

Se você está em meio a um processo de conformidade ou tentando iniciar sua difícil jornada, pode encontrar muitos alertas vermelhos para as instâncias EC2 que está criando. Além disso, você também começa a questionar o uso de suas imagens padrão do Amazon Linux, se elas são adequadas para o seu caso de uso? Você pode estar se perguntando se existem AMIs personalizadas que possam suportar suas cargas de trabalho conteinerizadas, ter menos sobrecarga para aplicar patches e oferecer melhor segurança.

Bottlerocket é um sistema operacional baseado em Linux, construído especificamente e meticulosamente elaborado para servir como um host de contêiner ideal. Projetado para reduzir a sobrecarga desnecessária, o Bottlerocket surge como uma solução enxuta e eficiente, adaptada às demandas modernas de aplicações conteinerizadas.

💡

Esta imagem Linux especializada é projetada com um foco singular na otimização da orquestração de contêineres, priorizando segurança, conformidade e eficiência operacional.

Valores Fundamentais do Bottlerocket

O Bottlerocket baseia-se em três valores fundamentais principais, detalhados abaixo

Ser Minimalista

Por que ter centenas de aplicações indesejadas quando tudo o que quero executar é uma imagem Docker? O Bottlerocket adota uma abordagem minimalista para ter apenas os pacotes necessários em sua imagem base, tornando-o leve e mais fácil de gerenciar.

Todos os pacotes necessários são instalados em uma única imagem Linux que é uma combinação de diferentes serviços AWS, juntamente com as diferentes plataformas/arquiteturas que suporta. Cada combinação é chamada de variante.

Por exemplo, bottlerocket-aws-k8s-1.28-x86_64-1.16 é uma variante para a imagem Bottlerocket do EKS versão 1.28 na arquitetura x86_64 . Outra variante para ECS seria algo como bottlerocket-aws-ecs-2-x86_64-1.16

Atualizações seguras

O Bottlerocket baseia-se fundamentalmente nos conceitos de empacotar tudo numa única imagem AMI e, portanto, não há gestor de pacotes.

Como tudo é vinculado a uma imagem, para atualizar qualquer coisa, basta atualizar a versão da imagem, que conteria a versão mais recente (estável e segura) de todos os componentes testados, eliminando a necessidade de gerenciar os pacotes separadamente.

O lado esquerdo mostra a instância em execução onde a versão atual tem uma atualização mais recente. Esta está a ser descarregada para a mesma instância, mas num local separado. Assim que o descarregamento estiver concluído, ocorre um reinício, alternando a nova versão como a fonte primária para o kernel.

Segurança

A segurança é a principal preocupação da instância Bottlerocket e estão a ser tomadas algumas medidas para garantir isso

1. O sistema de ficheiros raiz é imutável — Como o sistema de ficheiros raiz se torna imutável, apenas as versões estáveis e testadas fazem parte da imagem da instância. dm-verity é usado para integridade transparente para verificar o sistema de ficheiros juntamente com um hash raiz usando Merkle tree.
2. O SeLinux é imposto por padrão
3. Sem shell — menor chance de ataques remotos.

Conceitos

Abaixo estão alguns conceitos de alto nível para entender melhor as instâncias Bottlerocket

Orientado por API

Como as instâncias Bottlerocket não têm shell, como consultaria coisas como a versão da imagem e suas atualizações, operações básicas ou tarefas de nível de administrador? Para resolver essas tarefas, o Bottlerocket oferece uma API HTTP bem definida que pode resolver todos esses problemas para si, garantindo simultaneamente que apenas operações legítimas sejam realizadas nas instâncias com etapas precisas para cada operação.

Containers bootstrap

Como já discutimos que o sistema de arquivos raiz é imutável e é verificado por dm-verity , o /etc torna-se parte do seu sistema de arquivos mutável usando tmpfs.

Usando containers bootstrap, você pode habilitar certos programas ou recursos que deseja instalar sobre o sistema de arquivos raiz durante a inicialização da sua instância. Estes são um conjunto de containers que são executados sobre o runtime de containers containerd . Você pode executar vários containers bootstrap como esses e a inicialização da instância será concluída assim que todos os containers tiverem saído com sucesso. Você pode aplicar certas condições de saída a esses containers bootstrap. Você pode ler mais sobre isso aqui.

Por padrão, o secure boot também está ativado, garantindo que o software correto seja carregado pelo firmware UEFI ao tentar inicializar a máquina.

Componentes

As instâncias Bottlerocket são específicas para cargas de trabalho conteinerizadas e, para isso, dois conjuntos de containerd instâncias são executados. Um deles é usado para executar seus containers normais em seu motor orquestrador, como kubelet e o outro é para executar um container de administração que pode atuar como um pseudo-shell para você executar chamadas HTTP orientadas por API usando apiclient , uma ferramenta fornecida pelo Bottlerocket para executar requisições de API e para depurar suas instâncias. Este contêiner de administração não garante mutabilidade no sistema de arquivos raiz.

Utilizando instâncias Bottlerocket no EKS

Utilizar instâncias Bottlerocket nos seus nós EKS é muito simples. Só precisamos garantir que estamos a passar as AMIs corretas e as etiquetas certas para os nós, para que o operador de atualização do Bottlerocket possa verificar as atualizações de imagem nestes nós e reiniciá-los sempre que uma atualização estiver disponível. Discutiremos o operador de atualização do Bottlerocket em breve.

Na nossa implantação EKS atual, implantamos nós de duas formas

1. Terraform — que provisiona o grupo de nós inicial para nós. Este grupo de nós inicial é usado para executar Karpenter pods que então provisionam o nó conforme a necessidade
2. nós Karpenter — estes nós são provisionados pelo controlador Karpenter sempre que há uma carga de trabalho pendente.

Alterações no Terraform EKS

Para fazer alterações no nosso código Terraform para EKS, passamos uma opção eks_managed_node_groups na qual adicionamos um pool de nós adicional, algo como isto

eks_managed_node_groups = {    
 bottle = {
     enable_bootstrap_user_data = true
     platform = "bottlerocket"
     bootstrap_extra_args = <<-EOT
       [settings]
       "motd" = "TrueFoundry: plataforma MLOps"
       [settings.kubernetes.node-labels]
       "bottlerocket.aws/updater-interface-version" = "2.0.0"
     EOT

     instance_types = local.env.user_input.tfy_control_plane.enabled == "True" ? ["c6a.xlarge", "m6a.xlarge", "c6i.xlarge", "r6a.xlarge"] : ["c6a.large", "m6a.large", "c6i.large", "r6a.xlarge"]
     capacity_type  = "SPOT"
     ami_type       = "BOTTLEROCKET_x86_64"
     # Não é necessário nem usado - evite também marcar dois grupos de segurança com a mesma tag
     create_security_group = false

     # Garantir capacidade suficiente para executar 2 pods Karpenter
     min_size = 2
     max_size = 2
     desired_size = 2

     labels = {
       "class.truefoundry.io" = "bottle"
     }

     tags = {
       # Isso irá marcar o modelo de inicialização criado para uso pelo Karpenter
       "karpenter.sh/discovery" = local.env.cluster_name
     }
     block_device_mappings = {
       xvdb = {
         device_name = "/dev/xvdb"
         ebs = {
           volume_size           = 100
           volume_type           = "gp3"
           throughput            = 150
           delete_on_termination = true
         }
       }
     }
   }
 }


Nestas, há alguns pontos importantes a serem observados na especificação acima

1. Precisamos passar o "bottlerocket.aws/updater-interface-version" = "2.0.0" para que o operador de atualização do Bottlerocket possa interagir com ele.
2. ami_type = "BOTTLEROCKET_X86_64" — para passar a AMI do Bottlerocket
3. mapeamento de dispositivo de bloco para /dev/xvdb — o bottlerocket não pode usar /dev/xvda já que a AMI personalizada está usando /dev/xvda para armazenar a imagem raiz de 2GB.

Karpenter

Karpenter é uma forma relativamente mais recente de autoescalar suas cargas de trabalho. Com base nos recursos computacionais necessários, ele tentará trazer o nó do tamanho certo, empacotando simultaneamente os daemonsets para que todas as cargas de trabalho necessárias sejam executadas no nó.

Nós dependemos muito do Karpenter para iniciar cargas de trabalho de Computação e GPU. O Karpenter tem um conceito chamado Provisioner(que agora está obsoleto e foi renomeado para NodePool ) que define o tamanho permitido dos nós com os rótulos e taints corretos, se necessário. Além disso, através de AwsNodeTemplates (que agora está obsoleto e foi renomeado para NodeClasses ) você pode definir o modelo do nó, fornecendo o grupo de segurança correto, a família AMI e o tamanho do volume raiz.

Agora você pode entender onde talvez tenhamos que fazer alterações no Karpenter provisioner e awsnodetemplates para garantir que o Karpenter inicie instâncias Bottlerocket.

1. Atribuímos o rótulo "bottlerocket.aws/updater-interface-version" = "2.0.0" na provisioner seção.
2. Definimos o volume raiz como /dev/xvdb e amiFamily como Bottlerocket em awsnodetemplate

Dessa forma, o Karpenter também consegue suportar instâncias Bottlerocket.

Estou tentando evitar mencionar o provisioner e awsnodetemplate spec, pois agora estão obsoletos pelo karpenter em versões mais antigas.

Operador de Atualização Bottlerocket (brupop)

Operador de atualização Bottlerocket ou brupop é um controlador para manter suas instâncias bottlerocket em um cluster EKS atualizadas.

Design do Brupop

Consiste em três componentes principais

1. Controlador — O Controlador é o cérebro principal que verifica as atualizações de imagem upstream e orquestra todo o processo de atualização
2. Agente — O Agente executa em cada nó e recebe instruções do controlador para realizar a operação
3. Servidor API — API que autentica o agente e as chamadas de API que ele tenta fazer

Instalando o brupop

O Brupop possui dois helm charts que precisamos instalar

• bottlerocket-shadow — que consiste em bottlerocketshadow CRDs

apiVersion: argoproj.io/v1alpha1
kind: Aplicação
metadata:
 name: bottlerocket-shadow
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: padrão
 source:
   chart: bottlerocket-shadow
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.0.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true

• bottlerocket-update-operator — que consiste no operador em si

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-update-operator
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 source:
   chart: bottlerocket-update-operator
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.3.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true
   

Garanta que o namespace de destino seja sempre brupop-bottlerocket-aws pois está fixo no seu helm chart.

O controlador usa os bottlerocketshadow CRDS para gerenciar seus nós. Anteriormente no documento, pedimos que os nós tivessem os rótulos "bottlerocket.aws/updater-interface-version" = "2.0.0" . Isso foi feito para que o controlador possa identificar quais instâncias do bottlerocket você deseja que o brupop controle para você.

Você pode simplesmente verificar o status dos seus nós executando

$ kubectl get brs  -n brupop-bottlerocket-aws
NOME                               ESTADO   VERSÃO   ESTADO ALVO   VERSÃO ALVO   CONTAGEM DE FALHAS
brs-ip-xx-xx-1-243.ec2.internal    Ocioso   1.17.0    Ocioso           <sem valor>       0
brs-ip-xx-xx-14-136.ec2.internal   Ocioso   1.17.0    Ocioso           <sem valor>       0
brs-ip-xx-xx-31-78.ec2.internal    Ocioso   1.17.0    Ocioso           <sem valor>       0


Suporte ao Bottlerocket para TrueFoundry

Nós da TrueFoundry suportar instâncias bottlerocket para cargas de trabalho de CPU e GPU, para que toda a sua jornada de MLOps possa agora focar-se no desenvolvimento do código certo para resolver os problemas certos, aliviando a pressão sobre patches de manutenção e correções de segurança.

Perguntas Frequentes

O que é um bottlerocket?

Bottlerocket é um sistema operacional baseado em Linux, construído para um propósito específico, projetado como um host de contêiner ideal. Ele reduz a sobrecarga para aplicações conteinerizadas por ser leve e eficiente. Este SO especializado otimiza a orquestração de contêineres no EKS, priorizando segurança robusta, conformidade e eficiência operacional para cargas de trabalho modernas.

Por que usar bottlerocket?

Use o **bottlerocket** pelo seu design minimalista e construído para um propósito específico, otimizado para cargas de trabalho conteinerizadas. Ele aprimora a segurança com um sistema de arquivos raiz imutável e oferece atualizações simplificadas baseadas em imagem, eliminando o gerenciamento complexo de pacotes. Este SO especializado aumenta a eficiência operacional e a conformidade, tornando-o ideal para clusters EKS.

O EKS em modo automático usa bottlerocket?

Ferramentas de autoescalonamento do EKS como o Karpenter podem, de fato, aproveitar o Bottlerocket. Você configura o Karpenter para provisionar nós usando AMIs Bottlerocket, fornecendo um host seguro, mínimo e eficiente para suas aplicações conteinerizadas. Essa integração garante operações simplificadas e segurança aprimorada para suas cargas de trabalho dinâmicas do EKS.

O que é uma AMI bottlerocket?

Uma AMI bottlerocket é uma Amazon Machine Image pré-configurada com o Bottlerocket OS. Esta imagem Linux especializada é um host de contêiner seguro e mínimo, criado para aplicações conteinerizadas modernas. Ela simplifica o gerenciamento e garante atualizações seguras ao agrupar todos os componentes em uma única imagem, ideal para ambientes EKS nos EUA.

O bottlerocket é imutável?

Sim, o sistema de arquivos raiz de uma instância bottlerocket é imutável. Este recurso de segurança crucial garante que apenas versões estáveis e testadas façam parte da imagem, aumentando a integridade. As atualizações são realizadas substituindo a imagem bottlerocket inteira, simplificando o gerenciamento e aprimorando a segurança para seus ambientes EKS.

O que é bottlerocket no EKS?

Bottlerocket é um sistema operacional Linux construído para um propósito específico, otimizado para cargas de trabalho conteinerizadas no Amazon EKS. Ele oferece uma base mínima, segura e eficiente para seus nós EKS, reduzindo a sobrecarga operacional e aprimorando a postura de segurança. Este SO especializado otimiza a orquestração de contêineres, tornando seu ambiente bottlerocket EKS mais confiável.

O que é o Bottlerocket OS?

O Bottlerocket OS é um sistema operacional baseado em Linux, construído para um propósito específico e projetado como um host de contêiner ideal. Ele é projetado para máxima eficiência, segurança e conformidade. Este SO especializado oferece uma abordagem minimalista, otimizando a orquestração de contêineres e simplificando o gerenciamento para aplicações conteinerizadas, especialmente em ambientes como o EKS, ao reduzir a sobrecarga desnecessária.