**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Crea una variante AMI Bottlerocket personalizzata per Amazon EKS Quando esegui carichi di lavoro GPU su Amazon Elastic Kubernetes Service (Amazon EKS), scegli una variante Bottlerocket. La variante deve corrispondere alla versione di Kubernetes e al tipo di acceleratore in uso. Bottlerocket fornisce varianti convalidate per configurazioni comuni. Tuttavia, la tua organizzazione potrebbe aver bisogno di una variante diversa per uno dei seguenti motivi: + Un ramo di driver NVIDIA più recente + Una versione del driver bloccata per la conformità alle normative + Pacchetti aggiuntivi per il monitoraggio + Una linea di base consolidata richiesta dal team di sicurezza Poiché [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sul GitHub sito Web è completamente open source, puoi creare una variante personalizzata che soddisfi queste esigenze. Questo argomento mostra come clonare una variante esistente e sostituire il driver NVIDIA dal ramo R580 a R595 (versione 595.71.05). Quindi crei l'immagine e la registri come AMI privata. **Importante** Il tipo di istanza G7 EC2 richiede il driver NVIDIA versione 595 o successiva. Le AMI NVIDIA EKS Bottlerocket attualmente includono il driver NVIDIA versione 580, che non supporta le istanze G7. Consulta il [repository Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sul GitHub sito Web per istruzioni su come creare una variante con il driver NVIDIA versione 595. [Questo argomento illustra l'intero processo a partire dalla Fase 1.](#bottlerocket-custom-variant-step1) ## Come funziona il sistema di compilazione Quando corri`cargo make -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia`, succedono tre cose: + **Recupera le dipendenze.** Twoliter (l'orchestrator di build di Bottlerocket) legge `Twoliter.toml` ed estrae tre artefatti della Open Container Initiative (OCI) da: `public.ecr.aws/bottlerocket` + **bottlerocket-sdk**: un'immagine del contenitore con la toolchain completa di compilazione incrociata (macro GCC, Rust, Go, RPM). + **bottlerocket-kernel-kit: RPM predefiniti per kernel, moduli kernel (inclusi i pacchetti NVIDIA kmod**) e firmware. + **bottlerocket-core-kit** — RPM predefiniti per userspace: kubelet, containerd, il plug-in per dispositivi NVIDIA e il toolkit contenitore, plug-in di impostazioni e servizi di sistema. `Twoliter.toml`blocca `Twoliter.lock` le versioni e blocca i relativi digest. Per cambiarle, `./tools/twoliter/twoliter update` esegui per ri-risolvere. + **Costruisci la variante.** Twoliter lancia una build Docker all'interno del contenitore SDK. Compila la cartella settings-defaults della variante, risolve l'albero delle dipendenze RPM dai kit e assembla tutto in un'immagine del disco. + **Uscita.** Twoliter scrive il `.img.lz4` file finale su. `build/images/` La build produce un output deterministico: gli stessi `Twoliter.toml` pin e la stessa variante generano `Cargo.toml` sempre la stessa immagine, indipendentemente dall'host. ## Layout del repository Le seguenti directory sono rilevanti per il lavoro sulle varianti: ``` 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 ``` Leggi le seguenti note sulla struttura del repository: + Una variante è costituita principalmente da metadati. I kit esterni forniscono il kernel, i driver e lo spazio utente. + Settings-defaults i file sono collegamenti simbolici, non copie. Usa `cp -R` (non `cp -r` su macOS) per conservarli. + L'aggiunta di una variante richiede modifiche in cinque punti: due file dell'area di lavoro, due `Cargo.toml` `.spec` file e. `README.md` ## Prerequisiti Per completare la procedura dettagliata, è necessario: + Un AWS account con le autorizzazioni per avviare istanze EC2 e registrare AMI + Un'istanza EC2 (o un host Linux x86\_64 equivalente) con almeno 8 core, 16 GiB di memoria e 150 GB di disco + Ubuntu 24.04 LTS (o Fedora; macOS non è supportato come host di build) + Docker 20.10 o successivo + Rust (toolchain stabile, installata tramite rustup) + cargo-make (ultima versione) + Familiarità con i concetti di packaging Git, Rust's Cargo e RPM **Nota** Una volta completata questa procedura dettagliata, interrompi l'istanza EC2 e annulla la registrazione di tutte le AMI che non ti servono più per evitare addebiti continui. Per istruzioni sulla pulizia, consulta. [Pulizia](#bottlerocket-custom-variant-cleanup) ## Fase 1: Preparare l'host di compilazione Avvia un'istanza EC2, ad esempio una `c7i.8xlarge` (32 vCPU, 64 GiB di memoria). Utilizza un volume root gp3 da 150 GB e allega la policy `AmazonSSMManagedInstanceCore` gestita per l'accesso SSM. Connect all'istanza utilizzando AWS Systems Manager (SSM) Session Manager (SSM): ``` aws ssm start-session --target cd ~ ``` Installa i pacchetti del sistema operativo richiesti: ``` apt-get update apt-get install -y build-essential openssl libssl-dev pkg-config lz4 \ git ca-certificates curl gnupg ``` **Nota** I `BUILDING.md` riferimenti ufficiali`liblz4-tool`. Nelle versioni recenti di Ubuntu, il pacchetto è denominato`lz4`. Installa Docker usando i seguenti comandi: ``` 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 ``` Installa Rust e cargo-make usando i seguenti comandi: ``` curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y . "$HOME/.cargo/env" cargo install cargo-make ``` ## Passaggio 2: clonare il repository Clona il [repository Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sul GitHub sito Web e accedi alla directory: ``` cd ~/bottlerocket ``` Per creare una build riproducibile, dai un'occhiata a una versione con tag (ad esempio,). `git checkout v1.62.1` Per utilizzare i pacchetti più recenti, rimanete nella filiale. `develop` ## Fase 3: Verifica le versioni del kit Apri `Twoliter.toml` e conferma le versioni del kit. Per il supporto di R595, è necessaria la `bottlerocket-kernel-kit` versione 6.2.2 o successiva: ``` [[kit]] name = "bottlerocket-kernel-kit" version = "6.2.2" vendor = "bottlerocket" ``` Se la versione è precedente, aggiornala e rigenera il lucchetto: ``` ./tools/twoliter/twoliter update ``` ## Fase 4: Risolvi il problema del percorso di fabbricazione del carico Twoliter è impostato `CARGO_HOME` su`~/bottlerocket/.cargo`, il che impedisce al processo interno di Cargo di trovare la marca di carico installata a livello globale. Crea un symlink: ``` mkdir -p ~/bottlerocket/.cargo/bin ln -sf /root/.cargo/bin/cargo-make ~/bottlerocket/.cargo/bin/cargo-make ``` Senza questo passaggio, la build fallisce con. `error: no such command: make` ## Passaggio 5: Trova le filiali di driver disponibili I pacchetti mod NVIDIA vengono spediti all'interno. `bottlerocket-kernel-kit` [Per informazioni sui pacchetti driver disponibili, consulta la [directory dei pacchetti kernel-kit](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) sul sito Web o le note di rilascio sul GitHub sito Web.](https://github.com/bottlerocket-os/bottlerocket-kernel-kit/releases) GitHub Per il kernel 6.18 (usato dalle varianti): `aws-k8s-1.36` ``` kmod-6.18-nvidia-r580 ← driver 580.159.03 (current default) kmod-6.18-nvidia-r595 ← driver 595.71.05 ``` Per il kernel 6.12 (usato da`aws-k8s-1.33`,,): `1.34` `1.35` ``` kmod-6.12-nvidia-r580 kmod-6.12-nvidia-r595 ``` **Nota** Ogni pacchetto kmod spedisce pacchetti secondari (`-tesla`,,,`-open-gpu`,`-grid`). `-fabricmanager` `-imex` Il riferimento ufficiale alle varianti NVIDIA di Bottlerocket`-tesla`, che richiama tutti i sottopacchetti richiesti tramite dipendenze RPM. All'avvio, Bottlerocket seleziona automaticamente il tipo di driver appropriato in base al tipo di istanza. ## Fase 6: Creare la nuova variante Copia la variante esistente. Usa `cp -R` per conservare i collegamenti simbolici: ``` 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 ``` Modifica`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", ``` Modifica`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" ``` ## Fase 7: Registrare la variante Registra la nuova variante in cinque file: **1. `Cargo.toml`**— aggiungi il membro dell'area di lavoro: ``` "variants/aws-k8s-1.36-nvidia", + "variants/aws-k8s-1.36-nvidia-595", "variants/aws-k8s-1.36-nvidia-fips", ``` **2. `sources/Cargo.toml`**— aggiungi il membro settings-defaults: ``` "settings-defaults/aws-k8s-1.36-nvidia", + "settings-defaults/aws-k8s-1.36-nvidia-595", ``` **3. `packages/settings-defaults/settings-defaults.spec`**— aggiungi un `%package` blocco, voci in entrambi i cicli di compilazione e una `%files` sezione: ``` %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}. ``` Aggiungi a entrambi i `for defaults in` loop: ``` aws-k8s-1.36-nvidia \ + aws-k8s-1.36-nvidia-595 \ metal-dev \ ``` Aggiungi la `%files` sezione: ``` %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`**— aggiungi una `Provides:` riga sotto`%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) ``` ## Fase 8: Aggiorna il file di blocco L'aggiunta di un membro dell'area di lavoro invalida. `sources/Cargo.lock` Aggiorna: ``` cd ~/bottlerocket/sources cargo update --workspace ``` **Importante** Non usare`cargo generate-lockfile`. Riscrive l'intero file di blocco ed elimina le dipendenze transitive, causando errori di versione duplicata. `cargo-deny` ## Fase 9: Creare il file di licenza NVIDIA NVIDIA limita la ridistribuzione delle fonti dei driver. È necessario aggiungere un riconoscimento esplicito della licenza prima di creare: ``` 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 ``` ## Fase 10: Creare e pubblicare l'AMI Crea un file `Infra.toml` con le tue regioni target: ``` cat > ~/bottlerocket/Infra.toml <<'EOF' [aws] regions = ["us-west-2", "us-east-1", "us-east-2"] EOF ``` Costruisci l'immagine: ``` 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 ``` La prima build recupera l'SDK e le immagini del kit (\~2 GB in totale). Le build successive richiedono 3-5 minuti su un host a 32 core. Pubblica l'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 ``` La build scrive gli ID AMI su`build/images/x86_64-aws-k8s-1.36-nvidia-595/latest/*-amis.json`. Usali nei tuoi gruppi di nodi gestiti da EKS, Karpenter o nei `EC2NodeClass` modelli di avvio. ## Altre combinazioni che puoi creare Questa procedura dettagliata sostituisce il ramo dei driver NVIDIA, ma puoi usare lo stesso approccio per qualsiasi pacchetto disponibile nei kit upstream. Gli esempi seguenti mostrano cosa è possibile assemblare senza forare un kit: | Cosa vuoi | Cosa cambiare nella variante `Cargo.toml` | | --- | --- | | Diverso ramo dei driver NVIDIA | `kmod-6.18-nvidia-r580-tesla` → `kmod-6.18-nvidia-r595-tesla` | | Versione del kernel diversa | `kernel-6.18`→ `kernel-6.12` (aggiusta kmod di conseguenza) | | Rimuovi completamente NVIDIA | Elimina le tre `nvidia-*` righe da `included-packages` | | Aggiungi il supporto EFA | Aggiungi `kmod-6.18-efa` a `included-packages` | | Cambia la versione di runtime del contenitore | `containerd-2.2` → `containerd-2.1` | Per informazioni sui pacchetti disponibili, consultate il [kernel-kit](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) sul GitHub sito Web e il [core-kit](https://github.com/bottlerocket-os/bottlerocket-core-kit) sul sito Web. GitHub **Importante** Il filesystem root di Bottlerocket è immutabile. Non è possibile installare pacchetti in fase di esecuzione. Ogni pacchetto dei kit è compilato in modo incrociato appositamente per Bottlerocket: gli RPM upstream standard non funzionano. Se hai bisogno di software che non sia già incluso in un kit, prendi in considerazione i contenitori [bootstrap sul GitHub sito Web o i contenitori](https://github.com/bottlerocket-os/bottlerocket#bootstrap-containers-settings) di [hosting sul sito Web come alternativa di runtime](https://github.com/bottlerocket-os/bottlerocket#host-containers). GitHub ## Pulizia Se non hai più bisogno dell'host di build, interrompi l'istanza EC2 per evitare addebiti continui. Le AMI persistono indipendentemente nel tuo account; annullale con la console EC2 o la CLI se non ti servono più. ## Riepilogo Questo argomento ha mostrato come creare una variante Bottlerocket personalizzata con un ramo di driver NVIDIA diverso. Il processo prevede la copia di una variante esistente, la modifica del riferimento di un pacchetto, la registrazione della nuova variante nell'area di lavoro e nelle specifiche RPM e l'esecuzione della build. Lo stesso approccio si applica a qualsiasi personalizzazione: scambio di versioni del kernel, aggiunta di pacchetti o creazione di varianti per nuove versioni di Kubernetes.