Skip to content

Commit e216e89

Browse files
mikecookmikecook
committed
feat(recipes): add GKE GB200 (A4X) recipe with NVLS NCCL validation
Add the gb200-gke-cos-{training,training-kubeflow,training-slurm, inference,inference-dynamo} recipe leaves, covering GB200 (A4X) on GKE with COS. New gke-gb200-rdma component wires the NCCL gIB ARM64 plugin installer needed for GPUDirect-RDMA over RoCE, plus its health check and BOM/tuning docs. The GKE multi-networking objects (GKENetworkParamSet/Network: gvnic-1, rdma-0..rdma-3) are provisioned with the cluster before the node pool exists, not by this component: AICR treats them as a prerequisite and validates all 5 objects — including deviceMode and parametersRef linkage — via health check. GB200 on GKE is NVLS-only: MNNVL across the A4X nodes' IMEX domain is the fabric that actually carries all-reduce traffic, so nccl-all-reduce-bw-nvls (not the plain check) is wired into the training leaves' performance phase, backed by a new runtime-nvls.yaml TrainingRuntime template with IMEX ComputeDomain wiring. GPU NIC discovery in the NCCL validator is skipped for this accelerator/service pair since it uses the gke-gb200-rdma Network CRs instead of the TCPXO gpu-nic-* fabric. GB200 already has a Kubeflow leaf overlay on EKS and OKE; adds the same kubeflow-trainer component here so GKE isn't the only GB200 platform missing one, giving robust-controller conformance a supported operator to validate instead of always skipping. Also adds a gb200-gke-cos-inference-dynamo leaf (grove + dynamo-platform, DRA-gated to Kubernetes 1.34+), mirroring the GB200 EKS/OKE Dynamo overlays' performance-gate thresholds until a GKE-specific baseline is published. This turns the bare gb200-gke-cos-inference overlay from a leaf into a base shared by both the plain and Dynamo inference leaves, the same base/platform-variant pattern already used above for training/training-kubeflow. And a gb200-gke-cos-training-slurm leaf (Slinky operator + a Slinky-managed Slurm cluster), mirroring gb200-eks-ubuntu-training-slurm's GPU GRES, task isolation, and NVLS/IMEX ComputeDomain wiring for the same 4-GPU-per-node accelerator shape. Unlike the Kubeflow Trainer/JobSet controllers above, Slinky's controller/restapi/nodeset Deployments already go through AICR's ordinary nodeScheduling tolerationPaths, so this leaf needs no Trainer-style toleration workaround. Floor calibrated on a4x-highgpu-4g (4x GB200/node): 2-node/8-GPU all_reduce_perf measured 281.936 GB/s avg bus bandwidth. Validated on a live A4X cluster across conformance, deployment, and NVLS performance for the training and training-kubeflow leaves. gb200-gke-cos-inference-dynamo is validated across all three phases on the same cluster: deployment, conformance, and performance (103,971 tokens/sec throughput, 1388.55ms TTFT p99). gb200-gke-cos-training-slurm is validated through deployment and conformance, including the GB200-specific slinky-slurm-imex-channel health check; its NVLS performance phase has not yet been run. Signed evidence bundles for both (Sigstore/Rekor, keyless OIDC) are pushed to ghcr.io/mikecook/aicr-evidence with pointers committed under recipes/evidence/, and the signer is added to the community allowlist. Signed-off-by: Mike Cook <micook@nvidia.com>
1 parent 5dd6dd7 commit e216e89

35 files changed

Lines changed: 2141 additions & 15 deletions

File tree

‎docs/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ For pipelines and platforms that call AICR programmatically or host
4646
| Add or modify recipe metadata | [Recipe Development](integrator/recipe-development.md) |
4747
| Verify artifacts (SLSA, SBOM, attestations) | [Supply Chain Verification](integrator/supply-chain-verification.md) |
4848
| Ship custom validators via `--data` | [Validator Extension](integrator/validator-extension.md) |
49-
| Cloud-specific GPU setup | [AKS](integrator/aks-gpu-setup.md), [GKE](integrator/gke-gpu-setup.md), [EKS networking](integrator/eks-dynamo-networking.md), [GKE networking](integrator/gke-tcpxo-networking.md), [Talos](integrator/talos-integration.md) |
49+
| Cloud-specific GPU setup | [AKS](integrator/aks-gpu-setup.md), [GKE](integrator/gke-gpu-setup.md), [EKS networking](integrator/eks-dynamo-networking.md), [GKE TCPXO networking](integrator/gke-tcpxo-networking.md), [GKE GB200 networking](integrator/gke-gb200-networking.md), [Talos](integrator/talos-integration.md) |
5050

5151
### Contributor Guide
5252

‎docs/contributor/validator.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -804,7 +804,7 @@ default** (`Qwen/Qwen3-8B` at 256/GPU). A non-positive / non-integer
804804
| `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` | `10m` | Wait for the `DynamoGraphDeployment` to become ready (image pull + model load + worker health). Large models load slower — raise this **and** the catalog entry's `timeout` in tandem, or the parent deadline caps it. |
805805
| `AICR_INFERENCE_PERF_HEALTH_TIMEOUT` | `5m` | Wait for the endpoint to serve a real chat-completion *after* the workload reports Ready. Concurrent first-load from one RWO cache PVC can push first-serve past 5m; raise it (bounded by the catalog `timeout`). |
806806
| `AICR_INFERENCE_PERF_MODEL_CACHE_SIZE` | `100Gi` (on) | The PVC-backed model-weights cache is **on by default**. Set a different K8s quantity to resize, or a disable sentinel (`off`/`0`/`none`/`disabled`) to turn it off and download from HF directly. |
807-
| `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS` | cluster default | StorageClass for the cache PVC. On a cluster with **no default SC and no value here**, the check **fails fast** with guidance rather than leaving the PVC `Pending` until timeout. AICR-deployed EKS gets a default `gp3` SC from `aws-ebs-csi-driver`; GKE has `standard-rwo`. |
807+
| `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS` | cluster default | StorageClass for the cache PVC. On a cluster with **no default SC and no value here**, the check **fails fast** with guidance rather than leaving the PVC `Pending` until timeout. AICR-deployed EKS gets a default `gp3` SC from `aws-ebs-csi-driver`; GKE has `standard-rwo` — **except A4X/GB200 nodes**, which reject `standard-rwo`'s `pd-balanced` disks and need a Hyperdisk-backed class (see [GKE GB200 Storage Prerequisites](../integrator/gke-gb200-networking.md#storage-prerequisites)). |
808808
| `AICR_INFERENCE_PERF_MODEL_CACHE_POPULATE_TIMEOUT` | `13m` | Wait for the one-time model-cache populate Job (cold image pull + first-ever Hugging Face download into the PVC). Separate from — and larger than — `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` because the populate Job pays a cold pull *and* a multi-GB download; provide the optional HF-token secret to remove anonymous-download throttling. Raise it (and the catalog `timeout`) for very large models. **Migration:** the cache-populate wait no longer honors `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` (which now bounds only the DynamoGraphDeployment readiness wait) — set this knob instead to widen the populate budget. |
809809

810810
For gated models, or to lift Hugging Face rate limits on large downloads,

‎docs/index.yml‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -75,6 +75,8 @@ navigation:
7575
path: integrator/eks-dynamo-networking.md
7676
- page: GKE TCPXO Networking
7777
path: integrator/gke-tcpxo-networking.md
78+
- page: GKE GB200 Networking
79+
path: integrator/gke-gb200-networking.md
7880
- page: OpenShift Deployment
7981
path: integrator/openshift.md
8082
- page: Talos Integration

‎docs/integrator/components/nodewright.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -86,6 +86,7 @@ The table below is generated from the recipes by `make tuning-docs` — **do not
8686
| eks | rtx-pro-6000 | generic | - | nvidia-tuned 0.3.2 |
8787
| gke | a100 | h100 | - | nvidia-tuning-gke 0.1.2 |
8888
| gke | b200 | - | - | nvidia-tuning-gke 0.1.2 |
89+
| gke | gb200 | - | - | nvidia-tuning-gke 0.1.2 |
8990
| gke | h100 | - | - | nvidia-tuning-gke 0.1.2 |
9091

9192
{/* END AICR-TUNING */}

‎docs/integrator/gke-gb200-networking.md‎

Lines changed: 283 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,283 @@
1+
# GKE GB200 (A4X) Networking Prerequisites
2+
3+
For the **GB200 GKE COS** recipes (`gb200-gke-cos-training`,
4+
`gb200-gke-cos-training-kubeflow`, `gb200-gke-cos-training-slurm`, and
5+
`gb200-gke-cos-inference-dynamo`, all on `a4x-highgpu-4g` nodes),
6+
GPUDirect-RDMA over RoCE enables high-speed inter-node GPU communication on
7+
GKE. Without it, NCCL has no fabric to use and all-reduce falls back to the
8+
default network path.
9+
10+
## Infrastructure Prerequisites
11+
12+
GKE clusters must have multi-networking configured before deploying AICR bundles:
13+
14+
- Multi-networking enabled (1 gVNIC + 4 RDMA NICs per `a4x-highgpu-4g` node)
15+
- `Network` + `GKENetworkParamSet` CRs for the gVNIC and 4 RDMA NICs (cluster-specific
16+
VPC/subnet values, but fixed object names — see below; not managed by AICR)
17+
- `nccl-rdma-installer` DaemonSet on GPU nodes (included in the AICR bundle)
18+
19+
The last one ships in the AICR bundle. The first is **cluster provisioning** —
20+
AICR's `gke-gb200-rdma` health check detects it but does not create it.
21+
22+
### Provisioning multi-networking
23+
24+
These steps are ordered, following Google's
25+
[A4X custom setup guide](https://docs.cloud.google.com/ai-hypercomputer/docs/create/gke-ai-hypercompute-custom-a4x):
26+
27+
1. **Create the VPCs and subnets** — one dedicated VPC + subnet per NIC, five in
28+
total (one gVNIC, four RDMA), in the cluster's region.
29+
2. **Create the cluster** with multi-networking enabled (HIPPO's `GKECluster` CR
30+
does this via `spec.networks.managed.gb200NetworkStrategy`).
31+
3. **Create the GPU node pool** on an `a4x-highgpu-4g` machine type, attaching
32+
the five VPC/subnet pairs as `additionalNodeNetworkConfigs`.
33+
4. **Apply the `Network` and `GKENetworkParamSet` CRs** — one pair per NIC,
34+
binding each additional node network into the cluster so pods can reference
35+
it. Unlike TCPXO (see [GKE TCPXO Networking](gke-tcpxo-networking.md)), the
36+
**object names are fixed, not cluster-specific**: `gvnic-1` for the gVNIC and
37+
`rdma-0` through `rdma-3` for the RDMA NICs. Only the `vpc`/`vpcSubnet` fields
38+
inside each `GKENetworkParamSet` vary per cluster (they name the VPC/subnet
39+
your cluster actually has):
40+
41+
```yaml
42+
apiVersion: networking.gke.io/v1
43+
kind: GKENetworkParamSet
44+
metadata:
45+
name: gvnic-1
46+
spec:
47+
vpc: "PREFIX-gvnic"
48+
vpcSubnet: "PREFIX-gvnic"
49+
deviceMode: NetDevice
50+
---
51+
apiVersion: networking.gke.io/v1
52+
kind: Network
53+
metadata:
54+
name: gvnic-1
55+
spec:
56+
type: "Device"
57+
parametersRef:
58+
group: networking.gke.io
59+
kind: GKENetworkParamSet
60+
name: gvnic-1
61+
```
62+
63+
Repeat for `rdma-0` through `rdma-3`, pointing `vpc`/`vpcSubnet` at
64+
`PREFIX-gpu-nic-{0..3}-gb` (or whatever names your VPCs/subnets were given
65+
in step 1, with `PREFIX` replaced by your own).
66+
67+
> **The fixed naming is a requirement, not a convention.** AICR's
68+
> `checks/gke-gb200-rdma/health-check.yaml` asserts these five objects by exact
69+
> name (`gvnic-1`, `rdma-0`..`rdma-3`), including `spec.deviceMode` and
70+
> `spec.parametersRef` linkage. A cluster provisioned with different `Network`
71+
> names passes Google's own setup guide but fails this check — rename to match
72+
> before running `aicr validate`.
73+
74+
AICR installs the `nccl-rdma-installer` DaemonSet and detects the CRs; it does
75+
not provision the networking itself. These steps are a summary of the
76+
prerequisite AICR depends on, not a complete provisioning runbook — follow
77+
Google's guide above for the full procedure, including firewall rules and
78+
supported GKE version floors.
79+
80+
### Verifying
81+
82+
```shell
83+
kubectl get network.networking.gke.io
84+
kubectl get gkenetworkparamset.networking.gke.io
85+
```
86+
87+
Expect `gvnic-1` and `rdma-0` through `rdma-3` (plus the `default` network),
88+
each `Network` bound to its `GKENetworkParamSet` via `spec.parametersRef`.
89+
Fewer than five, or a `GKENetworkParamSet` with the wrong `deviceMode`, means
90+
the prerequisite is incomplete or misconfigured — `aicr validate` (via the
91+
`gke-gb200-rdma` health check) reports the shortfall by name.
92+
93+
## Driver Installer
94+
95+
`a4x-highgpu-4g` recipes generated with `--profile gpuStack=driver-installer`
96+
(see [GKE GPU Setup](gke-gpu-setup.md#alternative-let-gpu-operator-manage-the-device-plugin))
97+
need Google's standalone `nvidia-driver-installer` DaemonSet applied before
98+
GPU workloads can schedule — this presumes the node-pool prerequisite
99+
(pools created with `gpu-driver-version=disabled` plus the
100+
`gke-no-default-nvidia-gpu-device-plugin=true` label) is already in place.
101+
GB200's NVL72 domain needs GPU partitioning that Google's generic upstream
102+
COS manifest doesn't include — use a manifest with an added
103+
`partition-gpus` init container pinned to a
104+
[COS-qualified driver version](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus#cos):
105+
106+
```yaml
107+
apiVersion: apps/v1
108+
kind: DaemonSet
109+
metadata:
110+
name: nvidia-driver-installer
111+
namespace: kube-system
112+
labels:
113+
k8s-app: nvidia-driver-installer
114+
spec:
115+
selector:
116+
matchLabels:
117+
k8s-app: nvidia-driver-installer
118+
updateStrategy:
119+
type: RollingUpdate
120+
template:
121+
metadata:
122+
labels:
123+
name: nvidia-driver-installer
124+
k8s-app: nvidia-driver-installer
125+
spec:
126+
priorityClassName: system-node-critical
127+
affinity:
128+
nodeAffinity:
129+
requiredDuringSchedulingIgnoredDuringExecution:
130+
nodeSelectorTerms:
131+
- matchExpressions:
132+
- key: cloud.google.com/gke-accelerator
133+
operator: Exists
134+
- key: cloud.google.com/gke-gpu-driver-version
135+
operator: DoesNotExist
136+
- key: gke-no-default-nvidia-gpu-device-plugin
137+
operator: In
138+
values: ["true"]
139+
- key: cloud.google.com/gke-confidential-nodes-instance-type
140+
operator: DoesNotExist
141+
tolerations:
142+
- operator: Exists
143+
hostNetwork: true
144+
hostPID: true
145+
volumes:
146+
- name: dev
147+
hostPath:
148+
path: /dev
149+
- name: vulkan-icd-mount
150+
hostPath:
151+
path: /home/kubernetes/bin/nvidia/vulkan/icd.d
152+
- name: nvidia-install-dir-host
153+
hostPath:
154+
path: /home/kubernetes/bin/nvidia
155+
- name: root-mount
156+
hostPath:
157+
path: /
158+
- name: cos-tools
159+
hostPath:
160+
path: /var/lib/cos-tools
161+
- name: nvidia-config
162+
hostPath:
163+
path: /etc/nvidia
164+
initContainers:
165+
- image: "cos-nvidia-installer:fixed"
166+
imagePullPolicy: Never
167+
name: nvidia-driver-installer
168+
resources:
169+
requests:
170+
cpu: 150m
171+
securityContext:
172+
privileged: true
173+
env:
174+
- name: NVIDIA_INSTALL_DIR_HOST
175+
value: /home/kubernetes/bin/nvidia
176+
- name: NVIDIA_INSTALL_DIR_CONTAINER
177+
value: /usr/local/nvidia
178+
- name: VULKAN_ICD_DIR_HOST
179+
value: /home/kubernetes/bin/nvidia/vulkan/icd.d
180+
- name: VULKAN_ICD_DIR_CONTAINER
181+
value: /etc/vulkan/icd.d
182+
- name: ROOT_MOUNT_DIR
183+
value: /root
184+
- name: COS_TOOLS_DIR_HOST
185+
value: /var/lib/cos-tools
186+
- name: COS_TOOLS_DIR_CONTAINER
187+
value: /build/cos-tools
188+
volumeMounts:
189+
- name: nvidia-install-dir-host
190+
mountPath: /usr/local/nvidia
191+
- name: vulkan-icd-mount
192+
mountPath: /etc/vulkan/icd.d
193+
- name: dev
194+
mountPath: /dev
195+
- name: root-mount
196+
mountPath: /root
197+
- name: cos-tools
198+
mountPath: /build/cos-tools
199+
command:
200+
- bash
201+
- -c
202+
- |
203+
echo "Checking for existing GPU driver modules"
204+
if lsmod | grep nvidia; then
205+
echo "GPU driver is already installed, skipping installation"
206+
exit 0
207+
else
208+
echo "No GPU driver module detected, installing 580.126.20"
209+
/cos-gpu-installer install --version=580.126.20 || exit 1
210+
chmod 755 /root/home/kubernetes/bin/nvidia
211+
fi
212+
- image: "gcr.io/gke-release/nvidia-partition-gpu@sha256:de12f85ebfb4fb6c1893cd30c23aab662a72fa0448f97ef74fccb82d7522ef17"
213+
name: partition-gpus
214+
env:
215+
- name: LD_LIBRARY_PATH
216+
value: /usr/local/nvidia/lib64
217+
resources:
218+
requests:
219+
cpu: 150m
220+
securityContext:
221+
privileged: true
222+
volumeMounts:
223+
- name: nvidia-install-dir-host
224+
mountPath: /usr/local/nvidia
225+
- name: dev
226+
mountPath: /dev
227+
- name: nvidia-config
228+
mountPath: /etc/nvidia
229+
containers:
230+
- image: "gke.gcr.io/pause:3.8@sha256:880e63f94b145e46f1b1082bb71b85e21f16b99b180b9996407d61240ceb9830"
231+
name: pause
232+
```
233+
234+
Re-pin the driver version (`580.126.20` above) and the `partition-gpus` image
235+
digest to whatever your GKE version's COS driver table and Google's release
236+
notes currently list — both drift over time and are not managed by AICR.
237+
238+
## Storage Prerequisites
239+
240+
`a4x-highgpu-4g` nodes reject the `pd-balanced` disk type that GKE's default
241+
StorageClass (`standard-rwo`) provisions: `pd-balanced disk type cannot be
242+
used by a4x-highgpu-4g machine type`. Any PVC scheduled onto a GB200 node —
243+
notably the `inference-perf` validator's model-weights cache
244+
(`AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS`, see
245+
[Validation](../user/validation.md)) — needs a Hyperdisk-backed StorageClass
246+
instead. Like the RDMA CRs above, this is a cluster prerequisite AICR does
247+
not provision:
248+
249+
```yaml
250+
apiVersion: storage.k8s.io/v1
251+
kind: StorageClass
252+
metadata:
253+
name: hyperdisk-balanced
254+
provisioner: pd.csi.storage.gke.io
255+
parameters:
256+
type: hyperdisk-balanced
257+
volumeBindingMode: WaitForFirstConsumer
258+
allowVolumeExpansion: true
259+
```
260+
261+
Apply it once per cluster, then point the validator's model cache at it via
262+
an `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS=hyperdisk-balanced` entry
263+
on the `inference-perf` catalog entry's `env` (or a catalog overlay in the
264+
`aicr validate --data <dir>` directory).
265+
266+
## Running the NCCL Benchmark
267+
268+
The GB200 GKE training recipe (`gb200-gke-cos-training`) selects the
269+
NVLS-variant performance check (`nccl-all-reduce-bw-nvls`) — MNNVL across the
270+
A4X nodes' IMEX domain is the fabric that carries all-reduce traffic; gIB is the
271+
transport driver underneath, not the NCCL algorithm itself. Run it via:
272+
273+
```shell
274+
aicr validate --recipe recipes/overlays/gb200-gke-cos-training.yaml \
275+
--phase performance
276+
```
277+
278+
## References
279+
280+
- [GKE A4X custom setup guide](https://docs.cloud.google.com/ai-hypercomputer/docs/create/gke-ai-hypercompute-custom-a4x)
281+
- [Component Catalog](../user/component-catalog.md)
282+
- [Validation readiness gate](../user/validation.md)
283+
- [GKE TCPXO Networking](gke-tcpxo-networking.md)

‎docs/integrator/gke-gpu-setup.md‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -212,7 +212,14 @@ install comes up **driverless** — never combine the label with
212212
must instead be created with `gpu-driver-version=disabled`, with driver
213213
provisioning supplied by Google's standalone
214214
[`nvidia-driver-installer` DaemonSet](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus#installing_drivers)
215-
applied to the cluster.
215+
applied to the cluster — **apply it before or right after pool creation**;
216+
until it lands, nodes come up with no `nvidia` kernel module loaded and the
217+
GPU Operator's toolkit/driver-validation init containers block waiting for a
218+
driver that never arrives. On A4X/GB200 (`a4x-highgpu-4g`) nodes, Google's
219+
generic upstream manifest is not sufficient — GB200's NVL72 domain needs an
220+
extra GPU-partitioning init container the generic manifest omits; see
221+
[GKE GB200 Networking › Driver Installer](gke-gb200-networking.md#driver-installer)
222+
for the GB200-specific manifest.
216223

217224
Set the label when you create the GPU node pool, alongside the disabled
218225
managed install:
@@ -431,3 +438,4 @@ confirm exactly which advertiser owns each node.
431438
- [Component Catalog › GKE Device-Plugin Ownership](../user/component-catalog.md#gke-device-plugin-ownership)
432439
- [Validation readiness gate](../user/validation.md)
433440
- [GKE TCPXO Networking](gke-tcpxo-networking.md)
441+
- [GKE GB200 Networking](gke-gb200-networking.md)

‎docs/integrator/index.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@ This section is for integrators who:
2222
| [Kubernetes Deployment](kubernetes-deployment.md) | Self-hosted API server deployment with Kubernetes manifests |
2323
| [EKS Dynamo Networking](eks-dynamo-networking.md) | Security group prerequisites for Dynamo overlays on EKS |
2424
| [GKE TCPXO Networking](gke-tcpxo-networking.md) | GPUDirect TCPXO prerequisites for GKE training overlays |
25+
| [GKE GB200 Networking](gke-gb200-networking.md) | GPUDirect-RDMA prerequisites for GB200 (A4X) GKE overlays |
2526
| [AKS GPU Setup](aks-gpu-setup.md) | AKS prerequisites: Kubernetes 1.34+ (DRA GA), GPU driver setup, DRA configuration |
2627
| [GKE GPU Setup](gke-gpu-setup.md) | GKE device-plugin ownership: the `gpuStack` profile, node-pool setup for both values, verification, and troubleshooting |
2728
| [Talos Integration](talos-integration.md) | Running AICR on Talos Linux |

‎docs/user/container-images.md‎

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -19,8 +19,8 @@ A machine-readable **CycloneDX 1.6 JSON** companion to this page is produced by
1919
<!-- BEGIN AICR-BOM -->
2020
## Summary
2121

22-
- Components: **43**
23-
- Unique images: **98**
22+
- Components: **44**
23+
- Unique images: **99**
2424
- Distinct registries: **11**
2525

2626
Registries: `602401143452.dkr.ecr.us-west-2.amazonaws.com`, `cr.agentgateway.dev`, `docker.io`, `gcr.io`, `ghcr.io`, `gke.gcr.io`, `nvcr.io`, `public.ecr.aws`, `quay.io`, `registry.k8s.io`, `us-docker.pkg.dev`
@@ -40,6 +40,7 @@ _Rendering fidelity:_ `catalog-parity: charts are rendered with the shared recip
4040
| cert-manager-ocp-olm | manifest | — | — | 0 |
4141
| dynamo-platform | helm | dynamo-platform | 1.2.1 | 3 |
4242
| gatekeeper | helm | gatekeeper/gatekeeper | 3.22.2 | 3 |
43+
| gke-gb200-rdma | manifest | — | — | 2 |
4344
| gke-nccl-tcpxo | manifest | — | — | 4 |
4445
| gpu-operator | helm | nvidia/gpu-operator | v26.3.3 | 15 |
4546
| gpu-operator-ocp | manifest | — | — | 0 |
@@ -134,6 +135,11 @@ _No images extracted._
134135
- `openpolicyagent/gatekeeper-crds:v3.22.2`
135136
- `openpolicyagent/gatekeeper:v3.22.2`
136137

138+
### gke-gb200-rdma
139+
140+
- `gke.gcr.io/pause:3.8@sha256:880e63f94b145e46f1b1082bb71b85e21f16b99b180b9996407d61240ceb9830`
141+
- `us-docker.pkg.dev/gce-ai-infra/gpudirect-gib/nccl-plugin-gib-arm64:v1.1.2@sha256:6b7950cac6e6833661d4206920f5633b6e361b18bfd5315b63f9bf4a4b84a80e`
142+
137143
### gke-nccl-tcpxo
138144

139145
- `gcr.io/gke-release/nri-device-injector:1.0.25-gke.6@sha256:7704e2bd74b8edbb76b6913c7904cc2362f1fa887c4d4aba7b19778ea353537c`

0 commit comments

Comments
 (0)