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:

Poiché 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.

Come funziona il sistema di compilazione

Quando corricargo make -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia, succedono tre cose:

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:

Prerequisiti

Per completare la procedura dettagliata, è necessario:

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 <instance-id>
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

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 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 sul sito Web o le note di rilascio sul GitHub sito Web. 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 daaws-k8s-1.33,,): 1.34 1.35

kmod-6.12-nvidia-r580
kmod-6.12-nvidia-r595

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

Modificavariants/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",

Modificasources/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

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 subuild/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:

Per informazioni sui pacchetti disponibili, consultate il kernel-kit sul GitHub sito Web e il core-kit sul sito Web. 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.