Was ist Bottlerocket und wie benutzt man es in EKS?

Wenn Sie sich mitten in einer Compliance-Phase befinden oder versuchen, ihre schwierige Reise zu beginnen, werden Sie möglicherweise auf viele rote Warnmeldungen für die EC2-Instances stoßen, die Sie gerade einrichten. Darüber hinaus beginnen Sie auch, die Verwendung Ihrer Standard-Amazon-Linux-Images in Frage zu stellen, ob sie für Ihren Anwendungsfall geeignet sind? Sie fragen sich vielleicht, ob es benutzerdefinierte AMI (s) gibt, die Ihre containerisierten Workloads unterstützen könnten, weniger Aufwand für Patches haben und bessere Sicherheit bieten.

Bottlerocket ist ein speziell entwickeltes Linux-basiertes Betriebssystem, das sorgfältig darauf ausgelegt ist, als optimaler Container-Host zu dienen. Bottlerocket wurde entwickelt, um unnötigen Overhead zu reduzieren. Es ist eine schlanke und effiziente Lösung, die auf die modernen Anforderungen containerisierter Anwendungen zugeschnitten ist.

💡

Dieses spezielle Linux-Image wurde mit einem einzigen Fokus auf die Rationalisierung der Container-Orchestrierung entwickelt, wobei Sicherheit, Compliance und betriebliche Effizienz im Vordergrund stehen.

Die Kernwerte von Bottlerocket

Bottlerocket stützt sich auf drei Hauptkernwerte, die im Folgenden näher erläutert werden

Minimal sein

Warum sollte ich Hunderte von unerwünschten Anwendungen haben, wenn ich nur ein Docker-Image ausführen möchte. Bottlerocket verfolgt einen minimalistischen Ansatz, bei dem nur die erforderlichen Pakete im nackten Image enthalten sind, sodass es leichter und einfacher zu verwalten ist.

Alle erforderlichen Pakete sind in einem einzigen Linux-Image installiert, das eine Kombination aus verschiedenen AWS-Services und verschiedenen unterstützten Plattformen/Architekturen ist. Jede Kombination wird als bezeichnet Variante.

Zum Beispiel Flaschenrakete AWS-K8S-1.28-x86_64-1.16 ist ein Variante für Bottlerocket Image von EKS Version 1.28 auf x86_64 Architektur. Eine andere Variante für ECS wäre so etwas wie Flaschenrocket-AWS-ECS-2-x86_64-1.16

Sichere Updates

Bottlerocket basiert im Wesentlichen auf dem Konzept, alles in ein einziges AMI-Image zu packen, und daher gibt es kein Paketmanager.

Da alles an ein Image gebunden wird, würden Sie zum Aktualisieren einfach die Image-Version aktualisieren, in der die neueste (stabile und sichere) Version aller getesteten Komponenten enthalten wäre, sodass die Pakete nicht separat verwaltet werden müssen.

Die linke Seite zeigt die laufende Instanz, in der die laufende Version ein neueres Versionsupdate hat. Dieses wird in dieselbe Instanz heruntergeladen, jedoch an einem anderen Ort. Sobald der Download abgeschlossen ist, findet ein Neustart statt, bei dem die neue Version als Hauptquelle für den Kernel verwendet wird.

Sicherheit

Sicherheit ist das Hauptanliegen der Bottlerocket-Instance, und sie unternehmen nur wenige Maßnahmen, um dies sicherzustellen

1. Root-Dateisystem ist unveränderlich — Da das Root-Dateisystem unveränderlich wird, sind nur die stabilen und getesteten Versionen Teil des Instanz-Images. dm-verity wird für transparente Integrität verwendet, um das Dateisystem zusammen mit einem Root-Hash mit M zu überprüfenMerkle-Baum.
2. SELinux wird standardmäßig erzwungen
3. Keine Shell — also geringere Wahrscheinlichkeit von Angriffen aus der Ferne.

Konzepte

Im Folgenden finden Sie einige allgemeine Konzepte, um mehr über Bottlerocket-Instances zu erfahren

API-gesteuert

Da die Bottlerocket-Instanzen keine Shell haben, wie würden Sie Dinge wie die Image-Version und ihre Updates, grundlegende Operationen oder Aufgaben auf Admin-Ebene abfragen? Um diese Aufgaben zu lösen, bietet Bottlerocket eine gut definierte HTTP-API, die all diese Probleme für Sie lösen kann und gleichzeitig sicherstellt, dass nur rechtmäßige Operationen auf den Instanzen ausgeführt werden, wobei für jeden Vorgang präzise Schritte ausgeführt werden.

Bootstrap-Container

Wie wir bereits besprochen haben, ist das Root-Dateisystem unveränderlich und wird verifiziert durch dm-verity , das /usw wird Teil Ihres veränderlichen Dateisystems mit tmpfs.

Mithilfe von Bootstrap-Containern können Sie bestimmte Programme oder Funktionen aktivieren, die Sie beim Booten Ihrer Instance auf dem Root-Dateisystem installieren möchten. Dabei handelt es sich um eine Reihe von Containern, die zusätzlich zur Container-Laufzeit ausgeführt werden enthalten . Sie können mehrere solcher Bootstrap-Container ausführen und der Instanzstart wird abgeschlossen, sobald alle Container erfolgreich beendet wurden. Sie können bestimmte Ausgangsbedingungen auf diese Bootstrap-Container anwenden. Sie können mehr darüber lesen hier.

Standardmäßig ist auch Secure Boot aktiviert, um sicherzustellen, dass die richtige Software von der UEFI-Firmware abgeladen wird, wenn versucht wird, den Computer zu starten.

Komponenten

Bottlerocket-Instances sind spezifisch für containerisierte Workloads und dafür zwei Sätze von enthalten Instanzen werden ausgeführt. Einer von ihnen wird verwendet, um Ihre normalen Container auf Ihrer Orchestrator-Engine auszuführen, wie Kubelet und eine andere besteht darin, einen Admin-Container auszuführen, der als Pseudo-Shell dienen kann, mit der Sie API-gesteuerte HTTP-Aufrufe ausführen können apiklient , ein von bottlerocket bereitgegebenes Tool zum Ausführen von API-Anfragen und zum Debuggen Ihrer Instanzen. Dieser Admin-Container gewährleistet keine Veränderbarkeit des Root-Dateisystems.

Verwenden von Bottlerocket-Instanzen in EKS

Die Verwendung von Bottlerocket-Instances in Ihren EKS-Knoten ist sehr einfach. Wir müssen nur sicherstellen, dass wir die richtigen AMIs und die richtigen Labels an die Knoten weitergeben, damit der Bottlerocket-Update-Operator tatsächlich die Image-Updates auf diesen Knoten überprüfen und sie neu starten kann, sobald ein Update verfügbar ist. Wir werden in Kürze über den Bottlerocket Update Operator sprechen.

In unserer aktuellen EKS-Bereitstellung stellen wir Knoten in zwei Formen bereit

1. Terraform — das die anfängliche Knotengruppe für uns dreht. Diese anfängliche Knotengruppe wird zum Ausführen verwendet Karpenter Pods, die den Knoten dann nach Bedarf weiter drehen
2. Karpenter-Knoten — diese Knoten werden vom Karpenter Controller immer dann aktiviert, wenn eine ausstehende Arbeitslast ansteht.

Terraform EKS ändert sich

Um Änderungen in der Tour vorzunehmen Terraform-Code für EKS, wir übergeben eine Option eks_managed_node_groups in dem wir einen zusätzlichen Node-Pool hinzufügen, ungefähr so

eks_managed_node_groups = {
Flasche = {
enable_bootstrap_user_data = wahr
platform = „Bottlerocket“
bootstrap_extra_args = <<-EOT
[Einstellungen]
„motd“ = „trueFoundry: MLOps-Plattform“
[settings.kubernetes.node-labels]
„bottlerocket.aws/updater-interface-version“ = „2.0.0"
EOT

instance_types = local.env.user_input.tfy_control_plane.enabled == „Wahr“? ["c6a.xlarge“, „m6a.xlarge“, „c6i.xlarge“, „r6a.xlarge"]: ["c6a.large“, „m6a.large“, „c6i.large“, „r6a.xlarge"]
capacity_type = „SPOT“
ami_type = „BottleRocket_x86_64"
# Weder erforderlich noch verwendet - vermeiden Sie es, auch zwei Sicherheitsgruppen mit demselben Tag zu kennzeichnen
create_security_group = falsch

# Sorgen Sie für genügend Kapazität für den Betrieb von 2 Karpenter Pods
min_size = 2
max_size = 2
gewünschte_Größe = 2

Beschriftungen = {
„class.truefoundry.io“ = „Flasche“
}

Stichworte = {
# Dadurch wird die Startvorlage markiert, die für die Verwendung durch Karpenter erstellt wurde
„karpenter.sh/discovery“ = local.env.cluster_name
}
Gerätezuordnungen blockieren = {
xvdb = {
Gerätename = „/dev/xvdb“
ebs = {
Volumengröße = 100
volume_type = „gp3"
Durchsatz = 150
delete_on_termination = wahr
}
}
}
}
}


In diesen gibt es in der obigen Spezifikation nur wenige wichtige Dinge zu beachten

1. Wir müssen das bestehen „bottlerocket.aws/updater-interface-version“ = „2.0.0" damit der Bottlerocket-Update-Operator eine Schnittstelle herstellen kann.
2. ami_type = „BOTTLEROCKET_X86_64" — um die Bottlerocket AMI zu bestehen
3. Gerätezuordnung blockieren zu /dev/xvdb — Bottlerocket kann nicht benutzt werden /dev/xvda wie das benutzerdefinierte AMI verwendet /dev/xvda um das Root-Image der Größe 2 GB zu speichern.

Karpenter

Karpenter ist eine relativ neue Methode zur automatischen Skalierung Ihrer Workloads. Basierend auf der benötigten Rechenleistung wird versucht, den Knoten mit der richtigen Größe zu finden und gleichzeitig die Daemonsets zu packen, sodass alle erforderlichen Workloads auf dem Knoten ausgeführt werden.

Wir verlassen uns stark auf Karpenter, um Compute- und GPU-Workloads zu verteilen. Karpenter hat ein Konzept namens Versorger(was jetzt veraltet ist und heißt Knotenpool ) definiert die zulässige Größe von Knoten mit den richtigen Beschriftungen und Taints, falls erforderlich. Außerdem durch AWS-Knotenvorlagen (was jetzt veraltet ist und heißt Node-Klassen ) können Sie die Vorlage des Knotens definieren und dabei die richtige Sicherheitsgruppe, AMI-Familie und Root-Volume-Größe angeben.

Jetzt können Sie verstehen, wo wir möglicherweise Änderungen im Karpenter vornehmen müssen. Versorger und AWS-Knotenvorlagen um sicherzustellen, dass Karpenter Bottlerocket-Instanzen startet.

1. Wir geben das Etikett „bottlerocket.aws/updater-interface-version“ = „2.0.0" in der Versorger Abschnitt.
2. Wir geben das Wurzelvolumen als /dev/xvdb und Familie Ami als Bottlerocket in AWS-Knotenvorlage

Dadurch kann Karpenter auch Bottlerocket-Instances unterstützen.

Ich versuche zu vermeiden, das zu erwähnen Versorger und AWS-Knotenvorlage Spezifikation, da sie jetzt von Karpenter in älteren Versionen veraltet sind.

Betreiber von Bottlerocket Update (Brupop)

Bottlerocket Update Operator oder Brupop ist ein Controller, um Ihre Bottlerocket-Instances in einem EKS-Cluster auf dem neuesten Stand zu halten.

Brupop-Entwurf

Es besteht aus drei Hauptkomponenten

1. Controller — Der Controller ist das Hauptgehirn, das nach Upstream-Image-Updates sucht und den gesamten Aktualisierungsprozess orchestriert
2. Agent — Der Agent wird auf jedem Knoten ausgeführt, der vom Controller Anweisungen zur Ausführung des Vorgangs erhält
3. API-Server — API, die den Agenten und die API-Aufrufe, die er zu tätigen versucht, authentifiziert

Brupop installieren

Brupop hat zwei Steuerkarten, die wir installieren müssen

• Bottlerocket-Shadow — welches besteht aus Flasche Rocket Shadow CRDs

API-Version: argoproj.io/v1alpha1
Art: Anwendung
Metadaten:
Name: Bottlerocket-Shadow
Namespace: argocd
Finalisierer:
- resources-finalizer.argocd.argoproj.io
spezifikation:
Ziel:
Namensraum: brupop-bottlerocket-aws
Server: https://kubernetes.default.svc
Projekt: Standard
Quelle:
Diagramm: Bottlerocket-Shadow
URL melden: https://bottlerocket-os.github.io/bottlerocket-update-operator
Zielversion: 1.0.0
Synchronisierungsrichtlinie:
automatisiert: {}
Synchronisierungsoptionen:
- createNamespace=Wahr

• Bottlerocket-Update-Operator — das besteht aus dem eigentlichen Bediener

API-Version: argoproj.io/v1alpha1
Art: Anwendung
Metadaten:
Name: Bottlerocket-Update-Operator
Namespace: argocd
Finalisierer:
- resources-finalizer.argocd.argoproj.io
spezifikation:
Ziel:
Namensraum: brupop-bottlerocket-aws
Server: https://kubernetes.default.svc
Projekt: Standard
Quelle:
Diagramm: Bottlerocket-Update-Operator
URL melden: https://bottlerocket-os.github.io/bottlerocket-update-operator
Zielversion: 1.3.0
Synchronisierungsrichtlinie:
automatisiert: {}
Synchronisierungsoptionen:
- createNamespace=Wahr


Stellen Sie sicher, dass der Ziel-Namespace immer Brupop-Flaschenrocket-AWS wie es in ihrer Helmkarte festgelegt ist.

Der Controller verwendet die Flasche Rocket Shadow CRDS zur Verwaltung Ihrer Knoten. Zu Beginn des Dokuments haben wir die Knoten gebeten, Beschriftungen zu tragen „bottlerocket.aws/updater-interface-version“ = „2.0.0" . Dies wurde getan, damit der Controller erkennen kann, welche Bottlerocket-Instanzen Brupop für Sie steuern soll.

Sie können den Status Ihrer Knoten einfach überprüfen, indem Sie Folgendes ausführen

$ kubectl get brs -n brupop-bottlerocket-aws
NAME, STATUS, VERSION, ZIELSTAAT, ZIELVERSION, ANZAHL DER ABSTÜRZE
<no value>brs-ip-xx-xx-1-243.ec2.internal Leerlauf 1.17.0 Leerlauf 0
<no value>brs-ip-xx-xx-14-136.ec2.internal Leerlauf 1.17.0 Leerlauf 0
<no value>brs-ip-xx-xx-31-78.ec2.internal Leerlauf 1.17.0 Leerlauf 0


Bottlerocket-Unterstützung für TrueFoundry

Wir bei Wahre Gießerei unterstützen Sie Bottlerocket-Instances, um sowohl CPU- als auch GPU-Workloads zu unterstützen, sodass sich Ihre gesamte MLOps-Reise nun darauf konzentrieren kann, den richtigen Code zur Lösung der richtigen Probleme zu entwickeln, wodurch der Druck auf wartbare Patches und Sicherheitsupdates verringert wird.

Häufig gestellte Fragen

Was ist eine Bottlerocket?

Bottlerocket ist ein speziell entwickeltes Linux-basiertes Betriebssystem, das speziell als optimaler Container-Host entwickelt wurde. Es reduziert den Aufwand für containerisierte Anwendungen, da es schlank und effizient ist. Dieses spezialisierte Betriebssystem optimiert die Container-Orchestrierung in EKS und legt Wert auf hohe Sicherheit, Compliance und betriebliche Effizienz für moderne Workloads.

Warum Bottlerocket verwenden?

Verwenden Sie **bottlerocket** für sein minimalistisches, speziell entwickeltes Design, das für containerisierte Workloads optimiert ist. Es erhöht die Sicherheit durch ein unveränderliches Root-Dateisystem und bietet optimierte, imagebasierte Updates, sodass eine komplexe Paketverwaltung entfällt. Dieses spezialisierte Betriebssystem steigert die betriebliche Effizienz und Compliance und ist daher ideal für EKS-Cluster.

Verwendet der EKS Auto Mode Bottlerocket?

EKS-Tools zur automatischen Skalierung wie Karpenter können Bottlerocket tatsächlich nutzen. Sie konfigurieren Karpenter so, dass Knoten mithilfe von Bottlerocket-AMIs bereitgestellt werden und so ein sicherer, minimaler und effizienter Host für Ihre containerisierten Anwendungen bereitgestellt wird. Diese Integration gewährleistet optimierte Abläufe und erhöhte Sicherheit für Ihre dynamischen EKS-Workloads.

Was ist ein Bottlerocket AMI?

Ein Bottlerocket-AMI ist ein Amazon Machine Image, das mit Bottlerocket OS vorkonfiguriert ist. Dieses spezielle Linux-Image ist ein sicherer, minimaler Container-Host, der für moderne containerisierte Anwendungen konzipiert wurde. Es vereinfacht die Verwaltung und gewährleistet sichere Updates, indem es alle Komponenten in einem Image bündelt — ideal für EKS-Umgebungen in den USA.

Ist Bottlerocket unveränderlich?

Ja, das Root-Dateisystem einer Bottlerocket-Instanz ist unveränderlich. Diese wichtige Sicherheitsfunktion stellt sicher, dass nur stabile und getestete Versionen Teil des Images sind, was die Integrität erhöht. Updates werden durchgeführt, indem das gesamte Bottlerocket-Image ausgetauscht wird. Dies vereinfacht die Verwaltung und erhöht die Sicherheit Ihrer EKS-Umgebungen.

Was ist Bottlerocket in EKS?

Bottlerocket ist ein speziell entwickeltes Linux-Betriebssystem, das für containerisierte Workloads auf Amazon EKS optimiert ist. Es bietet eine minimale, sichere und effiziente Basis für Ihre EKS-Knoten, reduziert den Betriebsaufwand und verbessert die Sicherheitslage. Dieses spezialisierte Betriebssystem optimiert die Container-Orchestrierung und macht Ihre Bottlerocket-EKS-Umgebung zuverlässiger.

Was ist Bottlerocket OS?

Bottlerocket OS ist ein speziell entwickeltes Linux-basiertes Betriebssystem, das als optimaler Container-Host konzipiert wurde. Es wurde für maximale Effizienz, Sicherheit und Compliance entwickelt. Dieses spezialisierte Betriebssystem bietet einen minimalistischen Ansatz, der die Container-Orchestrierung optimiert und die Verwaltung von containerisierten Anwendungen, insbesondere in Umgebungen wie EKS, vereinfacht, indem unnötiger Overhead reduziert wird.