Wat is Bottlerocket en hoe gebruik je het in EKS?

Als je midden in een compliance-traject zit of probeert aan deze lastige reis te beginnen, zie je mogelijk veel rode meldingen voor de EC2-instances die je opstart. Bovendien begin je je af te vragen of het gebruik van je standaard Amazon Linux-images wel juist is voor jouw toepassing. Je vraagt je misschien af of er custom AMI's zijn die je gecontaineriseerde workloads kunnen ondersteunen, minder overhead hebben bij het patchen en betere beveiliging bieden.

Bottlerocket is een doelgericht, op Linux gebaseerd besturingssysteem dat zorgvuldig is ontworpen om te dienen als een optimale containerhost. Ontworpen om onnodige overhead te verminderen, is Bottlerocket een slanke en efficiënte oplossing, afgestemd op de moderne eisen van gecontaineriseerde toepassingen.

💡

Deze gespecialiseerde Linux-image is ontwikkeld met een enkele focus op het stroomlijnen van containerorchestratie, waarbij beveiliging, compliance en operationele efficiëntie vooropstaan.

Kernwaarden van Bottlerocket

Bottlerocket vertrouwt op drie belangrijke kernwaarden die hieronder worden toegelicht

Minimalistisch zijn

Waarom honderden ongewenste toepassingen hebben als het enige wat ik wil uitvoeren een Docker-image is? Bottlerocket hanteert een minimalistische benadering om alleen de vereiste pakketten in de basis-image op te nemen, zodat deze licht en eenvoudiger te beheren wordt.

Alle vereiste pakketten worden geïnstalleerd in een enkele Linux-image, wat een combinatie is van verschillende AWS-services en de verschillende platforms/architecturen die het ondersteunt. Elke combinatie wordt een variant genoemd.

Bijvoorbeeld bottlerocket-aws-k8s-1.28-x86_64-1.16 is een variant voor de Bottlerocket-image van EKS-versie 1.28 op de x86_64-architectuur. Een andere variant voor ECS zou zoiets zijn als bottlerocket-aws-ecs-2-x86_64-1.16

Veilige updates

Bottlerocket vertrouwt fundamenteel op het concept van het samenpakken van alles in een enkele AMI-image, waardoor er geen pakketbeheerder is.

Aangezien alles aan een image wordt gekoppeld, hoef je om iets te updaten simpelweg de image-versie bij te werken. Deze bevat de nieuwste (stabiele en veilige) geteste versie van alle componenten, waardoor het afzonderlijk beheren van pakketten niet meer nodig is.

De linkerkant toont de actieve instance waarvoor een nieuwere versie-update beschikbaar is. Deze wordt gedownload naar dezelfde instance, maar op een afzonderlijke locatie. Zodra de download is voltooid, vindt er een herstart plaats die de nieuwe versie inschakelt als de primaire bron voor de kernel.

Beveiliging

Beveiliging is de hoogste prioriteit van de Bottlerocket-instance, en er worden verschillende dingen gedaan om dat te waarborgen

1. Het root-bestandssysteem is onveranderbaar (immutable) — Omdat het root-bestandssysteem onveranderbaar wordt, maken alleen de stabiele en geteste versies deel uit van de instance-image. dm-verity wordt gebruikt voor transparante integriteit om het bestandssysteem te controleren samen met een root-hash met behulp van een Merkle-tree.
2. SELinux is standaard afgedwongen (enforced)
3. Geen shell — dus minder kans op aanvallen van buitenaf.

Concepten

Hieronder staan enkele concepten op hoofdlijnen om Bottlerocket-instances beter te begrijpen

API-gedreven

Aangezien Bottlerocket-instances geen shell hebben, hoe stel je dan vragen over zaken als de image-versie en updates, basisbewerkingen of taken op beheerdersniveau? Om deze taken op te lossen, biedt Bottlerocket een goed gedefinieerde HTTP API die al deze problemen voor je kan oplossen. Tegelijkertijd garandeert dit dat alleen rechtmatige bewerkingen op de instances worden uitgevoerd met nauwkeurige stappen voor elke bewerking.

Bootstrap-containers

Zoals we al hebben besproken is het root-bestandssysteem onveranderbaar en wordt het geverifieerd door dm-verity . De /etc maakt deel uit van je veranderbare bestandssysteem via tmpfs.

Met behulp van bootstrap-containers kun je bepaalde programma's of functies inschakelen die je wilt installeren op het root-bestandssysteem tijdens het opstarten van de instance. Dit is een set containers die draait bovenop de container runtime containerd . Je kunt meerdere van zulke bootstrap-containers uitvoeren en het opstarten van de instance wordt voltooid zodra alle containers succesvol zijn afgesloten. Je kunt specifieke afsluitvoorwaarden toepassen op deze bootstrap-containers. Je kunt hier meer over lezen hier.

Standaard is secure boot ook ingeschakeld, wat ervoor zorgt dat de juiste software wordt geladen door de UEFI-firmware bij het opstarten van de machine.

Componenten

Bottlerocket-instances zijn specifiek voor gecontaineriseerde workloads en hiervoor draaien twee sets van containerd-instances. Een daarvan wordt gebruikt om je normale containers uit te voeren op je orchestratie-engine zoals kubelet en de andere is om een admin-container uit te voeren die kan fungeren als een pseudo-shell om API-gedreven HTTP-calls uit te voeren via apiclient , een tool van Bottlerocket om API-verzoeken uit te voeren en je instances te debuggen. Deze admin-container garandeert geen onveranderbaarheid op het root-bestandssysteem.

Bottlerocket-instances gebruiken in EKS

Het gebruik van Bottlerocket-instances in je EKS-nodes is heel eenvoudig. We moeten er alleen voor zorgen dat we de juiste AMI's en correcte labels aan de nodes doorgeven, zodat de Bottlerocket update operator daadwerkelijk kan controleren op image-updates op deze nodes en ze kan herstarten wanneer er een update beschikbaar is. We zullen de Bottlerocket update operator zo dadelijk bespreken.

In onze huidige EKS-deployment zetten we nodes in op twee manieren

1. Terraform — waarmee de initiële nodegroup voor ons wordt aangemaakt. Deze initiële nodegroup wordt gebruikt om Karpenter-pods uit te voeren, die vervolgens naar behoefte extra nodes opstarten
2. Karpenter-nodes — deze nodes worden opgestart door de Karpenter controller wanneer er een wachtende workload is.

Terraform EKS-wijzigingen

Om wijzigingen aan te brengen in onze Terraform-code voor EKS, geven we een optie eks_managed_node_groups mee waarin we een extra nodepool toevoegen, ongeveer zo

eks_managed_node_groups = {    
 bottle = {
     enable_bootstrap_user_data = true
     platform = "bottlerocket"
     bootstrap_extra_args = <<-EOT
       [settings]
       "motd" = "TrueFoundry: MLOps platform"
       [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"
     # Not required nor used - avoid tagging two security groups with same tag as well
     create_security_group = false

     # Ensure enough capacity to run 2 Karpenter pods
     min_size = 2
     max_size = 2
     desired_size = 2

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

     tags = {
       # This will tag the launch template created for use by 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
         }
       }
     }
   }
 }


Hierin zijn een paar belangrijke dingen op te merken in de bovenstaande specificatie

1. We moeten de "bottlerocket.aws/updater-interface-version" = "2.0.0" doorgeven zodat de Bottlerocket update operator ermee kan communiceren.
2. ami_type = "BOTTLEROCKET_X86_64" — om de Bottlerocket AMI door te geven
3. Block device mapping naar /dev/xvdb — Bottlerocket kan geen /dev/xvda gebruiken omdat de custom AMI /dev/xvda gebruikt om de root-image van 2GB op te slaan.

Karpenter

Karpenter is een relatief nieuwe manier om je workloads automatisch te schalen. Op basis van de benodigde rekenkracht probeert het de node met de juiste grootte te vinden, terwijl het tegelijkertijd de daemonsets efficiënt bundelt (bin-packing), zodat alle noodzakelijke workloads op de node worden uitgevoerd.

We vertrouwen zwaar op Karpenter voor het opstarten van Compute- en GPU-workloads. Karpenter kent een concept genaamd Provisioner(wat nu verouderd is en hernoemd naar NodePool ) dat de toegestane grootte van nodes definieert met de juiste labels en taints indien nodig. Bovendien kun je via AwsNodeTemplates (wat nu verouderd is en hernoemd naar NodeClasses ) het sjabloon van de node definiëren, waarbij je de juiste security group, AMI-familie en root-volumegrootte opgeeft.

Nu begrijp je waar we mogelijk wijzigingen moeten aanbrengen in de Karpenter provisioner en awsnodetemplates om ervoor te zorgen dat Karpenter Bottlerocket-instances opstart.

1. We geven het label "bottlerocket.aws/updater-interface-version" = "2.0.0" op in het gedeelte provisioner .
2. We stellen het root-volume in op /dev/xvdb en amiFamily als Bottlerocket in awsnodetemplate

Hierdoor is Karpenter ook in staat om Bottlerocket-instances te ondersteunen.

Ik probeer het vermelden van de provisioner en awsnodetemplate specificatie te vermijden, aangezien deze in oudere versies door Karpenter als verouderd zijn gemarkeerd.

Bottlerocket Update operator (brupop)

Bottlerocket update operator of brupop is een controller om je Bottlerocket-instances in een EKS-cluster up-to-date te houden.

Ontwerp van Brupop

Het bestaat uit drie hoofdcomponenten

1. Controller — De controller is het brein dat controleert op upstream image-updates en het gehele updateproces orchestreert
2. Agent — De agent draait op elke node en ontvangt instructies van de controller om de bewerking uit te voeren
3. API-server — De API die de agent en de API-calls die hij probeert te maken authenticeert

Brupop installeren

Brupop heeft twee Helm charts die we moeten installeren

• bottlerocket-shadow — die bestaat uit bottlerocketshadow CRD's

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-shadow
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 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 — die bestaat uit de daadwerkelijke operator

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
   

Zorg ervoor dat de bestemmings-namespace altijd brupop-bottlerocket-aws is, aangezien dit vaststaat in hun Helm chart.

De controller gebruikt de bottlerocketshadow CRD's om je nodes te beheren. Eerder in het document hebben we de nodes gevraagd om de labels "bottlerocket.aws/updater-interface-version" = "2.0.0" te hebben. Dit is gedaan zodat de controller kan identificeren welke Bottlerocket-instances je door brupop wilt laten beheren.

Je kunt de status van je nodes eenvoudig controleren door het volgende uit te voeren

$ kubectl get brs  -n brupop-bottlerocket-aws
NAME                               STATE   VERSION   TARGET STATE   TARGET VERSION   CRASH COUNT
brs-ip-xx-xx-1-243.ec2.internal    Idle    1.17.0    Idle           <no value>       0
brs-ip-xx-xx-14-136.ec2.internal   Idle    1.17.0    Idle           <no value>       0
brs-ip-xx-xx-31-78.ec2.internal    Idle    1.17.0    Idle           <no value>       0


Bottlerocket-ondersteuning voor TrueFoundry

Wij bij TrueFoundry ondersteunen Bottlerocket-instances voor zowel CPU- als GPU-workloads, zodat je gehele MLOps-traject nu gericht kan zijn op het ontwikkelen van de juiste code om de juiste problemen op te lossen, wat de druk op onderhoudbare patches en beveiligingsfixes verlicht.

Veelgestelde vragen

Wat is Bottlerocket?

Bottlerocket is een doelgericht, op Linux gebaseerd besturingssysteem, specifiek ontworpen als een optimale containerhost. Het vermindert overhead voor gecontaineriseerde toepassingen door slank en efficiënt te zijn. Dit gespecialiseerde OS stroomlijnt containerorchestratie in EKS, met prioriteit voor sterke beveiliging, compliance en operationele efficiëntie voor moderne workloads.

Waarom Bottlerocket gebruiken?

Gebruik Bottlerocket vanwege het minimalistische, doelgerichte ontwerp dat is geoptimaliseerd voor gecontaineriseerde workloads. Het verbetert de beveiliging met een onveranderbaar root-bestandssysteem en biedt gestroomlijnde, op images gebaseerde updates, waardoor complex pakketbeheer vervalt. Dit gespecialiseerde OS verhoogt de operationele efficiëntie en compliance, wat het ideaal maakt voor EKS-clusters.

Gebruikt EKS Auto Mode Bottlerocket?

EKS autoscaling-tools zoals Karpenter kunnen inderdaad gebruikmaken van Bottlerocket. Je configureert Karpenter om nodes te provisionen met behulp van Bottlerocket AMI's, wat zorgt voor een veilige, minimale en efficiënte host voor je gecontaineriseerde toepassingen. Deze integratie zorgt voor gestroomlijnde operaties en verbeterde beveiliging voor je dynamische EKS-workloads.

Wat is een Bottlerocket AMI?

Een Bottlerocket AMI is een Amazon Machine Image dat vooraf is geconfigureerd met Bottlerocket OS. Deze gespecialiseerde Linux-image is een veilige, minimale containerhost, gebouwd voor moderne gecontaineriseerde toepassingen. Het vereenvoudigt het beheer en zorgt voor veilige updates door alle componenten in één image te bundelen, wat ideaal is voor EKS-omgevingen.

Is Bottlerocket onveranderbaar (immutable)?

Ja, het root-bestandssysteem van een Bottlerocket-instance is onveranderbaar (immutable). Deze cruciale beveiligingsfunctie zorgt ervoor dat alleen stabiele en geteste versies deel uitmaken van de image, wat de integriteit verhoogt. Updates worden uitgevoerd door de gehele Bottlerocket-image te vervangen, wat het beheer vereenvoudigt en de beveiliging van je EKS-omgevingen verbetert.

Wat is Bottlerocket in EKS?

Bottlerocket is een doelgericht Linux-besturingssysteem dat is geoptimaliseerd voor gecontaineriseerde workloads op Amazon EKS. Het biedt een minimale, veilige en efficiënte basis voor je EKS-nodes, wat de operationele overhead vermindert en de beveiliging versterkt. Dit gespecialiseerde OS stroomlijnt containerorchestratie, waardoor je Bottlerocket EKS-omgeving betrouwbaarder wordt.

Wat is Bottlerocket OS?

Bottlerocket OS is een doelgericht, op Linux gebaseerd besturingssysteem dat is ontworpen als een optimale containerhost. Het is ontwikkeld voor maximale efficiëntie, beveiliging en compliance. Dit gespecialiseerde OS biedt een minimalistische benadering, stroomlijnt containerorchestratie en vereenvoudigt het beheer van gecontaineriseerde toepassingen, met name binnen omgevingen zoals EKS, door onnodige overhead te verminderen.