**Unterstützung für die Verbesserung dieser Seite beitragen** Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Erstellen Sie eine benutzerdefinierte Bottlerocket AMI-Variante für Amazon EKS Wenn Sie GPU-Workloads auf Amazon Elastic Kubernetes Service (Amazon EKS) ausführen, wählen Sie eine Bottlerocket-Variante. Die Variante muss Ihrer Kubernetes-Version und Ihrem Beschleunigertyp entsprechen. Bottlerocket liefert validierte Varianten für gängige Konfigurationen. Ihre Organisation benötigt jedoch möglicherweise aus einem der folgenden Gründe eine andere Variante: + Ein neuerer NVIDIA-Treiberzweig + Eine fixierte Treiberversion zur Einhaltung gesetzlicher Vorschriften + Zusätzliche Pakete für die Überwachung + Ein von Ihrem Sicherheitsteam geforderter robuster Basisstandard Da [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) auf der GitHub Website vollständig quelloffen ist, können Sie eine benutzerdefinierte Variante erstellen, die diese Anforderungen erfüllt. In diesem Thema wird gezeigt, wie eine bestehende Variante geklont und der NVIDIA-Treiber vom R580-Zweig auf R595 (Version 595.71.05) umgestellt wird. Anschließend erstellen Sie das Image und registrieren es als privates AMI. **Wichtig** Für den Instance-Typ G7 EC2 ist die NVIDIA-Treiberversion 595 oder höher erforderlich. Die NVIDIA-AMIs von EKS Bottlerocket enthalten derzeit die NVIDIA-Treiberversion 580, die keine G7-Instances unterstützt. Anweisungen zum Erstellen einer Variante mit der NVIDIA-Treiberversion 595 finden Sie im [Bottlerocket-Repository](https://github.com/bottlerocket-os/bottlerocket) auf der GitHub Website. [In diesem Thema wird der gesamte Prozess ab Schritt 1 beschrieben.](#bottlerocket-custom-variant-step1) ## Wie funktioniert das Build-System Wenn du rennst`cargo make -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia`, passieren drei Dinge: + **Abhängigkeiten abrufen.** Twoliter (der Bottlerocket Build Orchestrator) liest `Twoliter.toml` und ruft drei Artefakte der Open Container Initiative (OCI) ab von: `public.ecr.aws/bottlerocket` + **bottlerocket-sdk** — ein Container-Image mit der vollständigen Cross-Compilation-Toolchain (GCC-, Rust-, Go-, RPM-Makros). + **bottlerocket-kernel-kit — vorgefertigte RPMs für Kernel, Kernelmodule (einschließlich NVIDIA-Kmod-Pakete**) und Firmware. + **bottlerocket-core-kit** — vorgefertigte RPMs für den Userspace: kubelet, containerd, das NVIDIA-Geräte-Plugin und Container-Toolkit, Einstellungs-Plugins und Systemdienste. `Twoliter.toml`pinnt die Versionen `Twoliter.lock` und sperrt ihre Digests. Um eines der beiden zu ändern, führen Sie den Befehl aus, `./tools/twoliter/twoliter update` um es erneut aufzulösen. + **Erstellen Sie die Variante.** Twoliter startet einen Docker-Build im SDK-Container. Es kompiliert die Kiste mit den Einstellungen und Standardeinstellungen Ihrer Variante, löst den RPM-Abhängigkeitsbaum aus den Kits auf und fügt alles zu einem Disk-Image zusammen. + **Ausgabe.** Twoliter schreibt die endgültige `.img.lz4` Datei in. `build/images/` Der Build erzeugt eine deterministische Ausgabe: Die gleichen `Twoliter.toml` Pins und die gleiche Variante erzeugen `Cargo.toml` immer dasselbe Bild, unabhängig vom Host. ## Aufbau des Repositor Die folgenden Verzeichnisse sind für die Variantenarbeit relevant: ``` bottlerocket/ ├── Cargo.toml # workspace: lists every variant ├── Twoliter.toml # pins SDK + kit versions ├── Twoliter.lock # locked digests for the above ├── Licenses.toml # you create this (NVIDIA license acknowledgement) ├── Infra.toml # you create this (AMI publish regions) │ ├── variants/ │ ├── aws-k8s-1.36-nvidia/ # example variant you'll copy │ │ ├── Cargo.toml # package list + kernel params │ │ └── amispec.toml # symlink → ../shared/amispec-split.toml │ └── shared/ # shared AMI spec templates │ ├── sources/ │ ├── Cargo.toml # workspace: lists every settings-defaults crate │ ├── shared-defaults/ # the actual defaults (symlink targets) │ └── settings-defaults/ │ └── aws-k8s-1.36-nvidia/ │ ├── Cargo.toml │ └── defaults.d/ # 30+ symlinks into shared-defaults/ │ └── packages/ ├── settings-defaults/ │ └── settings-defaults.spec # RPM: declares which variants exist └── settings-plugins/ └── settings-plugins.spec # RPM: maps variants to settings plugins ``` Lesen Sie die folgenden Hinweise zur Repository-Struktur: + Eine Variante besteht hauptsächlich aus Metadaten. Die externen Kits stellen den Kernel, die Treiber und den Userspace bereit. + Settings-defaults Dateien sind Symlinks, keine Kopien. Verwenden Sie `cp -R` (nicht `cp -r` unter macOS), um sie aufzubewahren. + Das Hinzufügen einer Variante erfordert Änderungen an fünf Stellen: zwei `Cargo.toml` Workspace-Dateien, zwei `.spec` Dateien und`README.md`. ## Voraussetzungen Um die exemplarische Vorgehensweise abzuschließen, benötigen Sie: + Ein AWS Konto mit Berechtigungen zum Starten von EC2-Instances und zum Registrieren von AMIs + Eine EC2-Instance (oder ein gleichwertiger Linux x86\_64-Host) mit mindestens 8 Kernen, 16 GiB Arbeitsspeicher und 150 GB Festplatte + Ubuntu 24.04 LTS (oder Fedora; macOS wird nicht als Build-Host unterstützt) + Docker 20.10 oder höher + Rust (stabile Toolchain, installiert über Rustup) + cargo-make (neueste Version) + Vertrautheit mit den Verpackungskonzepten Git, Rust's Cargo und RPM **Anmerkung** Wenn Sie diese exemplarische Vorgehensweise abgeschlossen haben, beenden Sie die EC2-Instance und melden Sie alle AMIs ab, die Sie nicht mehr benötigen, um laufende Gebühren zu vermeiden. Anweisungen zum Aufräumen finden Sie unter. [Bereinigen](#bottlerocket-custom-variant-cleanup) ## Schritt 1: Bereiten Sie den Build-Host vor Starten Sie eine EC2-Instance, z. B. eine `c7i.8xlarge` (32 vCPU, 64 GiB Arbeitsspeicher). Verwenden Sie ein GP3-Root-Volume mit 150 GB und hängen Sie die `AmazonSSMManagedInstanceCore` verwaltete Richtlinie für den SSM-Zugriff an. Stellen Sie mithilfe des AWS Systems Manager (SSM) Session Manager eine Connect zur Instanz her: ``` aws ssm start-session --target cd ~ ``` Installieren Sie die erforderlichen Betriebssystempakete: ``` apt-get update apt-get install -y build-essential openssl libssl-dev pkg-config lz4 \ git ca-certificates curl gnupg ``` **Anmerkung** Die offiziellen `BUILDING.md` Referenzen`liblz4-tool`. In neueren Ubuntu-Versionen trägt das Paket einen Namen`lz4`. Installieren Sie Docker mit den folgenden Befehlen: ``` install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg \ -o /etc/apt/keyrings/docker.asc chmod a+r /etc/apt/keyrings/docker.asc echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \ https://download.docker.com/linux/ubuntu noble stable" \ > /etc/apt/sources.list.d/docker.list apt-get update apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin systemctl enable --now docker ``` Installieren Sie Rust und cargo-make mit den folgenden Befehlen: ``` curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y . "$HOME/.cargo/env" cargo install cargo-make ``` ## Schritt 2: Klonen Sie das Repository Klonen Sie das [Bottlerocket-Repository](https://github.com/bottlerocket-os/bottlerocket) auf der GitHub Website und navigieren Sie in das Verzeichnis: ``` cd ~/bottlerocket ``` Um einen reproduzierbaren Build zu erstellen, schauen Sie sich eine mit Tags versehene Version an (z. B.). `git checkout v1.62.1` Um die neuesten Pakete zu verwenden, bleiben Sie in der `develop` Filiale. ## Schritt 3: Überprüfen Sie die Kit-Versionen Öffnen `Twoliter.toml` und bestätigen Sie die Kit-Versionen. Für die Unterstützung von R595 benötigen Sie `bottlerocket-kernel-kit` Version 6.2.2 oder höher: ``` [[kit]] name = "bottlerocket-kernel-kit" version = "6.2.2" vendor = "bottlerocket" ``` Wenn die Version älter ist, aktualisieren Sie sie und generieren Sie die Sperre neu: ``` ./tools/twoliter/twoliter update ``` ## Schritt 4: Umgehen Sie das Problem mit dem Frachtpfad Twoliter ist `CARGO_HOME` auf eingestellt`~/bottlerocket/.cargo`, wodurch verhindert wird, dass der interne Cargo-Prozess Ihre global installierte Frachtmarke findet. Erstellen Sie einen Symlink: ``` mkdir -p ~/bottlerocket/.cargo/bin ln -sf /root/.cargo/bin/cargo-make ~/bottlerocket/.cargo/bin/cargo-make ``` Ohne diesen Schritt schlägt der Build mit fehl. `error: no such command: make` ## Schritt 5: Suchen Sie nach verfügbaren Treiberzweigen Die NVIDIA-Kmod-Pakete werden im `bottlerocket-kernel-kit` Lieferumfang enthalten. Informationen zu verfügbaren Treiberpaketen finden Sie im [Verzeichnis kernel-kit-Pakete](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) auf der GitHub Website oder in den [Versionshinweisen](https://github.com/bottlerocket-os/bottlerocket-kernel-kit/releases) auf der Website. GitHub Für Kernel 6.18 (von `aws-k8s-1.36` Varianten verwendet): ``` kmod-6.18-nvidia-r580 ← driver 580.159.03 (current default) kmod-6.18-nvidia-r595 ← driver 595.71.05 ``` Für Kernel 6.12 (verwendet von`aws-k8s-1.33`,`1.34`,`1.35`): ``` kmod-6.12-nvidia-r580 kmod-6.12-nvidia-r595 ``` **Anmerkung** Jedes Mod-Paket enthält Unterpakete (`-tesla`,,, `-open-gpu``-grid`,`-fabricmanager`). `-imex` Die offizielle Bottlerocket NVIDIA-Variantenreferenz`-tesla`, die alle erforderlichen Unterpakete über RPM-Abhängigkeiten einbezieht. Beim Booten wählt Bottlerocket automatisch die passende Treibervariante basierend auf dem Instanztyp aus. ## Schritt 6: Erstellen Sie die neue Variante Kopieren Sie die bestehende Variante. Wird verwendet`cp -R`, um Symlinks beizubehalten: ``` cp -R variants/aws-k8s-1.36-nvidia variants/aws-k8s-1.36-nvidia-595 cp -R sources/settings-defaults/aws-k8s-1.36-nvidia \ sources/settings-defaults/aws-k8s-1.36-nvidia-595 ``` Bearbeiten`variants/aws-k8s-1.36-nvidia-595/Cargo.toml`: ``` - name = "aws-k8s-1_36-nvidia" + name = "aws-k8s-1_36-nvidia-595" - "kmod-6.18-nvidia-r580-tesla", + "kmod-6.18-nvidia-r595-tesla", ``` Bearbeiten`sources/settings-defaults/aws-k8s-1.36-nvidia-595/Cargo.toml`: ``` - name = "settings-defaults-aws-k8s-1_36-nvidia" + name = "settings-defaults-aws-k8s-1_36-nvidia-595" ``` ## Schritt 7: Registriere die Variante Registrieren Sie die neue Variante in fünf Dateien: **1. `Cargo.toml`**— füge das Workspace-Mitglied hinzu: ``` "variants/aws-k8s-1.36-nvidia", + "variants/aws-k8s-1.36-nvidia-595", "variants/aws-k8s-1.36-nvidia-fips", ``` **2. `sources/Cargo.toml`**— füge das Mitglied settings-defaults hinzu: ``` "settings-defaults/aws-k8s-1.36-nvidia", + "settings-defaults/aws-k8s-1.36-nvidia-595", ``` **3. `packages/settings-defaults/settings-defaults.spec`**— füge einen `%package` Block, Einträge in beiden Build-Schleifen und einen `%files` Abschnitt hinzu: ``` %package aws-k8s-1.36-nvidia-595 Summary: Settings defaults for the aws-k8s 1.36 nvidia-595 variant Requires: %{_cross_os}variant(aws-k8s-1.36-nvidia-595) Provides: %{_cross_os}settings-defaults(any) Provides: %{_cross_os}settings-defaults(aws-k8s-1.36-nvidia-595) Conflicts: %{_cross_os}settings-defaults(any) %description aws-k8s-1.36-nvidia-595 %{summary}. ``` Zu beiden `for defaults in` Schleifen hinzufügen: ``` aws-k8s-1.36-nvidia \ + aws-k8s-1.36-nvidia-595 \ metal-dev \ ``` Fügen Sie den `%files` Abschnitt hinzu: ``` %files aws-k8s-1.36-nvidia-595 %{_cross_defaultsdir}/aws-k8s-1.36-nvidia-595.toml %{_cross_tmpfilesdir}/storewolf-defaults-aws-k8s-1.36-nvidia-595.conf ``` **4. `packages/settings-plugins/settings-plugins.spec`**— füge eine `Provides:` Zeile hinzu unter`%package aws-k8s-nvidia`: ``` Provides: %{_cross_os}settings-plugin(aws-k8s-1.36-nvidia) +Provides: %{_cross_os}settings-plugin(aws-k8s-1.36-nvidia-595) Conflicts: %{_cross_os}settings-plugin(any) ``` ## Schritt 8: Aktualisieren Sie die Sperrdatei Das Hinzufügen eines Workspace-Mitglieds wird ungültig`sources/Cargo.lock`. Aktualisiere es: ``` cd ~/bottlerocket/sources cargo update --workspace ``` **Wichtig** Benutze es nicht`cargo generate-lockfile`. Es schreibt die gesamte Sperrdatei neu und verhindert transitive Abhängigkeiten, was zu Fehlern bei doppelten Versionen führt. `cargo-deny` ## Schritt 9: Erstellen Sie die NVIDIA-Lizenzdatei NVIDIA schränkt die Weiterverteilung von Treiberquellen ein. Sie müssen eine ausdrückliche Lizenzbestätigung hinzufügen, bevor Sie Folgendes erstellen: ``` cat > ~/bottlerocket/Licenses.toml <<'EOF' [nvidia] spdx-id = "LicensesRef-NVIDIA-Customer-Use" licenses = [ { path = "LICENSE", license-url = "https://www.nvidia.com/en-us/drivers/nvidia-license/" } ] EOF ``` ## Schritt 10: AMI erstellen und veröffentlichen Erstellen Sie eine `Infra.toml` mit Ihren Zielregionen: ``` cat > ~/bottlerocket/Infra.toml <<'EOF' [aws] regions = ["us-west-2", "us-east-1", "us-east-2"] EOF ``` Erstellen Sie das Bild: ``` cd ~/bottlerocket cargo make \ -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia-595 \ -e BUILDSYS_UPSTREAM_SOURCE_FALLBACK=true \ -e BUILDSYS_UPSTREAM_LICENSE_FETCH=true \ -e BUILDSYS_JOBS=32 ``` Beim ersten Build werden die SDK- und Kit-Images abgerufen (insgesamt \~2 GB). Nachfolgende Builds dauern auf einem 32-Core-Host 3—5 Minuten. Veröffentlichen Sie das AMI: ``` cargo make \ -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia-595 \ -e PUBLISH_REGIONS=us-west-2,us-east-1,us-east-2 \ ami ``` Der Build schreibt AMI-IDs in`build/images/x86_64-aws-k8s-1.36-nvidia-595/latest/*-amis.json`. Verwenden Sie diese in Ihren von EKS verwalteten Knotengruppen, Karpenter `EC2NodeClass` - oder Startvorlagen. ## Andere Kombinationen, die Sie erstellen können In dieser exemplarischen Vorgehensweise wird der NVIDIA-Treiberzweig ausgetauscht, Sie können jedoch denselben Ansatz für jedes Paket verwenden, das in den Upstream-Kits verfügbar ist. Die folgenden Beispiele zeigen, was Sie zusammenbauen können, ohne einen Bausatz zu forken: | Was willst du | Was soll an der Variante geändert werden `Cargo.toml` | | --- | --- | | Anderer NVIDIA-Treiberzweig | `kmod-6.18-nvidia-r580-tesla` → `kmod-6.18-nvidia-r595-tesla` | | Andere Kernel-Version | `kernel-6.18`→ `kernel-6.12` (kmod entsprechend anpassen) | | NVIDIA vollständig entfernen | Lösche die drei `nvidia-*` Zeilen von `included-packages` | | EFA-Unterstützung hinzufügen | Zu hinzufügen `kmod-6.18-efa` `included-packages` | | Wechseln Sie zur Container-Laufzeitversion | `containerd-2.2` → `containerd-2.1` | Informationen zu verfügbaren Paketen finden Sie im [Kernel-Kit](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) auf der GitHub Website und im [Core-Kit](https://github.com/bottlerocket-os/bottlerocket-core-kit) auf der Website. GitHub **Wichtig** Das Bottlerocket-Root-Dateisystem ist unveränderlich. Sie können Pakete nicht zur Laufzeit installieren. Jedes Paket in den Kits ist speziell für Bottlerocket querkompiliert — Standard-Upstream-RPMs funktionieren nicht. Wenn Sie Software benötigen, die noch nicht in einem Kit enthalten ist, sollten Sie [Bootstrap-Container auf der GitHub Website oder [Host-Container](https://github.com/bottlerocket-os/bottlerocket#host-containers)](https://github.com/bottlerocket-os/bottlerocket#bootstrap-containers-settings) auf der GitHub Website als Laufzeitalternative in Betracht ziehen. ## Bereinigen Wenn Sie den Build-Host nicht mehr benötigen, beenden Sie die EC2-Instance, um laufende Gebühren zu vermeiden. Die AMIs werden unabhängig in Ihrem Konto gespeichert. Melden Sie sie mit der EC2-Konsole oder CLI ab, wenn Sie sie nicht mehr benötigen. ## Zusammenfassung In diesem Thema wurde gezeigt, wie Sie eine benutzerdefinierte Bottlerocket-Variante mit einem anderen NVIDIA-Treiberzweig erstellen. Der Prozess umfasst das Kopieren einer vorhandenen Variante, das Ändern einer Paketreferenz, das Registrieren der neuen Variante in den Workspace- und RPM-Spezifikationen und das Ausführen des Builds. Derselbe Ansatz gilt für jede Anpassung: das Austauschen von Kernelversionen, das Hinzufügen von Paketen oder das Erstellen von Varianten für neue Kubernetes-Versionen.