¿Qué es Bottlerocket y cómo usarlo en EKS?

Si se encuentra en medio de una situación de cumplimiento o está intentando iniciar su difícil proceso, es posible que encuentre muchas alertas rojas para las instancias EC2 que está poniendo en marcha. Además, también empieza a cuestionar el uso de sus imágenes predeterminadas de Amazon Linux, y si son adecuadas para su caso de uso. Puede que se pregunte si existen AMI personalizadas que puedan soportar sus cargas de trabajo en contenedores, que supongan una menor sobrecarga de parches y que ofrezcan una mayor seguridad.

Bottlerocket es un sistema operativo basado en Linux diseñado específicamente para funcionar como un host de contenedores óptimo. Diseñado para reducir los gastos generales innecesarios, Bottlerocket se perfila como una solución ágil y eficiente diseñada para las demandas modernas de las aplicaciones en contenedores.

💡

Esta imagen de Linux especializada está diseñada con un enfoque singular en la optimización de la organización de contenedores y, al mismo tiempo, priorizar la seguridad, el cumplimiento y la eficiencia operativa.

Valores fundamentales de Bottlerocket

Bottlerocket se basa en tres valores fundamentales principales que se detallan a continuación

Ser mínimo

Por qué tener cientos de aplicaciones no deseadas cuando lo único que quiero ejecutar es una imagen de Docker. Bottlerocket aporta un enfoque minimalista al tener solo los paquetes necesarios en su imagen original, de modo que sea ligero y fácil de administrar.

Todos los paquetes necesarios se instalan en una única imagen de Linux, que es una combinación de diferentes servicios de AWS junto con las diferentes plataformas y arquitecturas que admite. Cada combinación se denomina variante.

Por ejemplo bottlerocket-aws-k8s-1.28-x86_64-1.16 es un variante para la imagen de Bottlerocket de la versión 1.28 de EKS en x86_64 arquitectura. Otra variante para ECS sería algo así como bottlerocket-aws-ecs-2-x86_64-1.16

Actualizaciones seguras

Bottlerocket se basa fundamentalmente en los conceptos de papelera empacar todo en una sola imagen AMI y, por lo tanto, hay sin administrador de paquetes.

Como todo se vincula a una imagen, para actualizar cualquier cosa basta con actualizar la versión de la imagen, que tendría la versión más reciente (estable y segura) de todos los componentes probados, eliminando la necesidad de administrar los paquetes por separado.

El lado izquierdo muestra la instancia en ejecución en la que la versión en ejecución tiene una actualización de versión más reciente. Se está descargando en la misma instancia, pero en una ubicación diferente. Una vez finalizada la descarga, se reinicia y la nueva versión pasa a ser la fuente principal del núcleo.

Seguridad

La seguridad es la principal preocupación de la instancia de BottleRocket y están haciendo pocas cosas para garantizar que

1. El sistema de archivos raíz es inmutable: a medida que el sistema de archivos raíz se vuelve inmutable, solo las versiones estables y probadas forman parte de la imagen de la instancia. dm-verity se usa para garantizar una integridad transparente para verificar el sistema de archivos junto con un hash raíz usando Márbol de Berkle.
2. SELinux se aplica por defecto
3. Sin caparazón, por lo que hay menos posibilidades de ataques remotos.

Conceptos

A continuación, se muestran algunos conceptos de alto nivel para comprender mejor las instancias de bottlerocket

Impulsado por API

Como las instancias de bottlerocket no tienen ningún shell, ¿cómo consultarías cosas como la versión de la imagen y sus actualizaciones, las operaciones básicas o las tareas a nivel de administrador? Para resolver estas tareas, bottlerocket ofrece una API HTTP bien definida que puede resolver todos estos problemas por ti y, al mismo tiempo, garantizar que solo se realicen las operaciones correctas en las instancias, con pasos precisos para cada operación.

Contenedores Bootstrap

Como ya hemos comentado, ese sistema de archivos raíz es inmutable y está verificado por dm-verity , el /etcétera se convierte en parte de su sistema de archivos mutable usando tmpfs.

Con los contenedores de arranque, puedes habilitar ciertos programas o funciones que deseas instalar en el sistema de archivos raíz durante el arranque de la instancia. Se trata de un conjunto de contenedores que se ejecutan además del tiempo de ejecución del contenedor contenedor . Puedes ejecutar varios contenedores de arranque de este tipo y el arranque de la instancia finalizará una vez que todos los contenedores hayan salido correctamente. Puedes aplicar ciertas condiciones de salida en estos contenedores de arranque. Puedes leer más sobre esto aquí.

De forma predeterminada, el arranque seguro también está habilitado para garantizar que el firmware UEFI descargue el software correcto al intentar arrancar la máquina.

Componentes

Las instancias de Bottlerocket son específicas de las cargas de trabajo en contenedores y, para ello, dos conjuntos de contenedor las instancias se ejecutan. Una de ellas se usa para ejecutar tus contenedores normales en tu motor de Orchestrator, como kubelet y otra es ejecutar un contenedor de administración que puede actuar como un pseduo shell para que pueda ejecutar llamadas HTTP impulsadas por API utilizando un cliente , una herramienta proporcionada por bottlerocket para ejecutar solicitudes de API y depurar tus instancias. Estos contenedores de administración no garantizan la mutabilidad en el sistema de archivos raíz.

Uso de instancias de Bottlerocket en EKS

El uso de instancias de bottlerocket en los nodos de EKS es muy sencillo. Solo necesitamos asegurarnos de que estamos transfiriendo las AMI correctas y las etiquetas correctas a los nodos para que el operador de actualización de bottlerocket pueda comprobar las actualizaciones de las imágenes en estos nodos y reiniciarlos cuando haya una actualización disponible. En breve hablaremos del operador de actualización de bottlerocket.

En nuestra implementación actual de EKS, implementamos los nodos de dos formas.

1. terraform: lo que hace girar el grupo de nodos inicial para nosotros. Este grupo de nodos inicial se usa para ejecutar carpintero vainas que luego hacen girar aún más el nodo según sea necesario
2. nodos karpenter: el controlador karpenter hace girar estos nodos cada vez que hay una carga de trabajo pendiente.

Cambios en Terraform EKS

Para realizar cambios en la nuestra código terraform para EKS, pasamos una opción eks_managed_node_groups en el que agregamos un grupo de nodos adicional, algo como esto

eks_managed_node_groups = {
botella = {
enable_bootstrap_user_data = verdadero
plataforma = «bottlerocket»
bootstrap_extra_args = <<-EOT
[ajustes]
«motd» = «TrueFoundry: plataforma MLOps»
[settings.kubernetes.node-labels]
«bottlerocket.aws/updater-interface-version» = «2.0.0"
MOTÍN

instance_types = local.env.user_input.tfy_control_plane.enabled == ¿"Verdadero»? ["c6a.xlarge», «m6a.xlarge», «c6i.xlarge», «r6a.xlarge"]: ["c6a.large», «m6a.large», «c6a.xlarge», «r6a.xlarge"]
capacity_type = «SPOT»
ami_type = «Bottlerocket_x86_64"
# No se requiere ni se usa: evite etiquetar también dos grupos de seguridad con la misma etiqueta
create_security_group = falso

# Garantice la capacidad suficiente para ejecutar 2 cápsulas Karpenter
tamaño_mínimo = 2
tamaño_máximo = 2
tamaño_deseado = 2

etiquetas = {
«class.truefoundry.io» = «botella»
}

etiquetas = {
# Esto etiquetará la plantilla de lanzamiento creada para que la utilice Karpenter
«karpenter.sh/discovery» = local.env.cluster_name
}
block_device_mappings = {
xvdb = {
nombre_dispositivo = «/dev/xvdb»
ebs = {
tamaño_volumen = 100
tipo_volumen = «gp3"
rendimiento = 150
delete_on_termination = verdadero
}
}
}
}
}


En estos, hay algunas cosas importantes a tener en cuenta en la especificación anterior.

1. Tenemos que pasar el «bottlerocket.aws/updater-interface-version» = «2.0.0" para que el operador de actualización de bottlerocket pueda interconectarlo.
2. ami_type = «BOTTLEROCKET_X86_64" — para pasar el AMI de bottlerocket
3. bloquear el mapeo de dispositivos a /dev/xvdb — bottlerocket no puede usar /dev/xvda como está usando la AMI personalizada /dev/xvda para almacenar la imagen raíz de un tamaño de 2 GB.

Carpintero

Karpenter es una forma relativamente nueva de escalar automáticamente sus cargas de trabajo. En función del cálculo requerido, intentará crear el nodo del tamaño correcto y empaquetar simultáneamente los conjuntos de demonios para que todas las cargas de trabajo necesarias se ejecuten en el nodo.

Confiamos en gran medida en karpenter para gestionar las cargas de trabajo de computación y GPU. Karpenter tiene un concepto llamado Aprovisionador(que ahora está en desuso y se denomina como Pool de nodos ) definiendo el tamaño permitido de los nodos con las etiquetas correctas y las manchas si es necesario. Además, a través de Plantillas de AWS Node (que ahora está en desuso y se denomina como Clases de nodos ) puede definir la plantilla del nodo, indicando el grupo de seguridad, la familia de AMI y el tamaño de volumen raíz correctos.

Ahora puedes entender dónde podríamos tener que hacer cambios en el Karpenter aprovisionador y plantillas de nodo AWS para asegurarse de que Karpenter haga girar instancias de Bottlerocket.

1. Le damos la etiqueta «bottlerocket.aws/updater-interface-version» = «2.0.0" en el aprovisionador sección.
2. Damos que el volumen de la raíz sea /dev/xvdb y Familia AMI como Bottlerocket en plantilla de nodo AWS

Gracias a esto, Karpenter también puede dar soporte a instancias de bottlerocket.

Intento evitar mencionar la aprovisionador y plantilla de nodo AWS especificación, ya que ahora karpenter las ha desaprobado en versiones anteriores.

Operador de actualización de Bottlerocket (brupop)

operador de actualización de Bottlerocket o brupop es un controlador para mantener actualizadas las instancias de bottlerocket de un clúster de EKS.

Diseño Brupop

Consta de tres componentes principales

1. Controlador: el controlador es el cerebro principal que comprueba si hay actualizaciones de imágenes en sentido ascendente y organiza todo el proceso de actualización
2. Agente: el agente se ejecuta en cada nodo y recibe instrucciones del controlador para realizar la operación
3. Servidor API: API que autentica al agente y las llamadas a la API que intenta realizar

Instalación de brupop

Brupop tiene dos gráficos de timón que necesitamos instalar

• botella Rocket-Shadow — que consiste en botella Rocketshadow CRD

Versión de API: argoproj.io/v1alpha1
tipo: Aplicación
metadatos:
nombre: bottlerocket-shadow
espacio de nombres: argocd
finalizadores:
- resources-finalizer.argocd.argoproj.io
especificación:
destino:
espacio de nombres: brupop-bottlerocket-aws
servidor: https://kubernetes.default.svc
proyecto: predeterminado
fuente:
gráfico: bottlerocket-shadow
URL del repositorio: https://bottlerocket-os.github.io/bottlerocket-update-operator
Revisión objetivo: 1.0.0
Política de sincronización:
automatizado: {}
Opciones de sincronización:
- createNameSpace=verdadero

• operador de actualización de bottlerocket- — que consiste en el operador real

Versión de API: argoproj.io/v1alpha1
tipo: Aplicación
metadatos:
nombre: bottlerocket-update-operator
espacio de nombres: argocd
finalizadores:
- resources-finalizer.argocd.argoproj.io
especificación:
destino:
espacio de nombres: brupop-bottlerocket-aws
servidor: https://kubernetes.default.svc
proyecto: predeterminado
fuente:
gráfico: bottlerocket-update-operator
URL del repositorio: https://bottlerocket-os.github.io/bottlerocket-update-operator
Revisión objetivo: 1.3.0
Política de sincronización:
automatizado: {}
Opciones de sincronización:
- createNameSpace=verdadero


Asegúrese de que el espacio de nombres de destino esté siempre brupop bottlerocket-aws como está fijado en su carta de timones.

El controlador usa el botella Rocketshadow CRDS para administrar sus nodos. Anteriormente en el documento pedimos a los nodos que tuvieran etiquetas «bottlerocket.aws/updater-interface-version» = «2.0.0" . Esto se hizo para que el controlador pueda identificar qué instancias de bottlerocket quieres que Brupop controle por ti.

Simplemente puede comprobar el estado de sus nodos ejecutando

$ kubectl consigue bares -en brupop-bottlerocket-aws
NOMBRE, ESTADO, VERSIÓN, ESTADO DE DESTINO, VERSIÓN DE DESTINO, NÚMERO DE BLOQUEOS
<no value>brs-ip-xx-xx-1-243.ec2.internal Inactivo 1.17.0 Inactivo 0
<no value>brs-ip-xx-xx-14-136.ec2.internal Inactivo 1.17.0 Inactivo 0
<no value>brs-ip-xx-xx-31-78.ec2.internal Inactivo 1.17.0 Inactivo 0


Soporte de Bottlerocket para TrueFoundry

Estamos en True Foundry admite instancias de bottlerocket para soportar cargas de trabajo de CPU y GPU, de modo que todo tu recorrido por los MLOps ahora pueda centrarse en desarrollar el código correcto para resolver los problemas correctos, liberando la presión sobre los parches y las correcciones de seguridad que se pueden mantener.

Preguntas frecuentes

¿Qué es un portabotellas?

Bottlerocket es un sistema operativo basado en Linux diseñado específicamente como un host de contenedores óptimo. Reduce los gastos generales de las aplicaciones en contenedores al ser eficiente y eficiente. Este sistema operativo especializado optimiza la organización de contenedores en EKS y prioriza la seguridad, el cumplimiento y la eficiencia operativa sólidos para las cargas de trabajo modernas.

¿Por qué usar bottlerocket?

Utilice **bottlerocket** por su diseño minimalista diseñado específicamente, optimizado para cargas de trabajo en contenedores. Mejora la seguridad con un sistema de archivos raíz inmutable y ofrece actualizaciones simplificadas basadas en imágenes, lo que elimina la compleja administración de paquetes. Este sistema operativo especializado aumenta la eficiencia operativa y el cumplimiento, por lo que es ideal para los clústeres de EKS.

¿El modo automático eks usa bottlerocket?

De hecho, las herramientas de escalado automático de EKS, como Karpenter, pueden aprovechar Bottlerocket. Usted configura Karpenter para aprovisionar nodos mediante las AMI de Bottlerocket, lo que proporciona un host seguro, mínimo y eficiente para sus aplicaciones en contenedores. Esta integración garantiza operaciones optimizadas y una mayor seguridad para sus cargas de trabajo dinámicas de EKS.

¿Qué es un AMI de bottlerocket?

Una AMI de bottlerocket es una imagen de máquina de Amazon preconfigurada con Bottlerocket OS. Esta imagen de Linux especializada es un host de contenedor mínimo y seguro diseñado para aplicaciones modernas en contenedores. Simplifica la administración y garantiza la seguridad de las actualizaciones al agrupar todos los componentes en una sola imagen, lo que resulta ideal para los entornos EKS de EE. UU.

¿Bottlerocket es inmutable?

Sí, el sistema de archivos raíz de una instancia de bottlerocket es inmutable. Esta característica de seguridad crucial garantiza que solo las versiones estables y probadas formen parte de la imagen, lo que aumenta la integridad. Las actualizaciones se realizan sustituyendo toda la imagen del cohete, lo que simplifica la administración y mejora la seguridad de los entornos de EKS.

¿Qué es bottlerocket en EKS?

Bottlerocket es un sistema operativo Linux diseñado específicamente y optimizado para cargas de trabajo en contenedores en Amazon EKS. Ofrece una base mínima, segura y eficiente para sus nodos de EKS, lo que reduce la sobrecarga operativa y mejora la seguridad. Este sistema operativo especializado agiliza la organización de contenedores, lo que hace que su entorno EKS de Bottlerocket sea más confiable.

¿Qué es bottlerocket OS?

Bottlerocket OS es un sistema operativo basado en Linux especialmente diseñado como un host de contenedores óptimo. Está diseñado para ofrecer la máxima eficiencia, seguridad y cumplimiento. Este sistema operativo especializado ofrece un enfoque minimalista, agiliza la organización de contenedores y simplifica la administración de las aplicaciones en contenedores, especialmente en entornos como EKS, al reducir la sobrecarga innecesaria.