Deploy

Cluster Bootstrap

Describe your target environment. The wizard generates a phased bootstrap plan — from hardware validation through GPU enablement to workload validation — with parameterized scripts and manifests, per-phase validation, and rollback. Nothing runs against a live cluster.

Bootstrap plan

Amazon EKS · H100 SXM5

Managed8 phases
  1. 1

    Provider prerequisites

    low risk

    Confirm GPU instance quota, region availability, and IAM before provisioning.

    • ·Check GPU instance/VM quota in the target region.
    • ·Confirm networking (VPC/subnets) and identity/roles.
    • ·Confirm H100 SXM5 capacity is available.
    Validation
    • Quota and capacity confirmed for the GPU type.

    Rollback: None — read-only validation.

  2. 2

    Provision managed cluster & GPU node pool

    high risk

    Create the Amazon EKS cluster and a GPU node pool for H100 SXM5.

    • ·Create the Amazon EKS control plane (managed).
    • ·Add a GPU node pool sized to 4 node(s).
    • ·Decide driver strategy: provider-managed vs. GPU operator.
    Node pool 1 · H100 SXM5
    eksctl create nodegroup --cluster $CLUSTER \
      --name gpu --node-type p5.48xlarge --nodes 4 \
      --node-labels node-type=gpu   # H100 SXM5
    Validation
    • `kubectl get nodes` shows the GPU node pool(s) Ready.

    Rollback: Delete the GPU node pool(s) (and cluster) via the provider CLI/console.

  3. 3

    GPU drivers & device plugin

    high risk

    Install the NVIDIA GPU operator to manage drivers, the container runtime, and the device plugin.

    • ·Install the NVIDIA GPU Operator via Helm.
    • ·Let the operator(s) pull upstream images.
    • ·Standard containerd — the operator configures the GPU runtime.
    NVIDIA GPU Operator
    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
    helm repo update
    helm install --wait gpu-operator nvidia/gpu-operator \
      -n gpu-operator --create-namespace
    Validation
    • Operator pods Running
    • Nodes advertise `nvidia.com/gpu` as allocatable.

    Rollback: helm uninstall the operator(s); the driver DaemonSet(s) are removed.

  4. 4

    GPU partitioning (optional)

    medium risk

    Enable MIG on H100 SXM5 to share each GPU across smaller workloads.

    • ·Set a MIG strategy on the operator's ClusterPolicy.
    • ·Label nodes with the desired MIG profile.
    Enable MIG (single strategy)
    kubectl label nodes -l node-type=gpu \
      nvidia.com/mig.config=all-1g.10gb --overwrite
    # The operator reconfigures the GPUs into MIG instances.
    Validation
    • Allocatable resources show MIG instances (e.g. nvidia.com/mig-1g.10gb).

    Rollback: Set `nvidia.com/mig.config=all-disabled` to return to full GPUs.

  5. 5

    Observability

    low risk

    Install metrics + GPU telemetry (DCGM for NVIDIA / ROCm exporter for AMD).

    • ·Install kube-prometheus-stack.
    • ·The GPU operator ships DCGM-exporter; add its ServiceMonitor.
    • ·Import GPU dashboards into Grafana.
    kube-prometheus-stack
    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
    helm install kps prometheus-community/kube-prometheus-stack \
      -n monitoring --create-namespace
    Validation
    • GPU utilization/temperature/power metrics appear in Prometheus.
    • Grafana dashboards render for GPU nodes.

    Rollback: helm uninstall kps; remove ServiceMonitors.

  6. 6

    GitOps (Argo CD)

    medium risk

    Bootstrap declarative delivery so future changes flow through Git.

    • ·Install Argo CD.
    • ·Point it at your platform repo.
    • ·Connect to your Git provider.
    Argo CD
    kubectl create namespace argocd
    kubectl apply -n argocd -f \
      https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
    Validation
    • Argo CD reconciles the platform repo with no drift.

    Rollback: Uninstall Argo CD; cluster state remains.

  7. 7

    Security policies

    medium risk

    Enforce admission policy and pod security before workloads land.

    • ·Install a policy engine (Kyverno or Gatekeeper).
    • ·Apply pod-security and signed-image policies.
    • ·Restrict registries and enforce non-root.
    Install Kyverno
    helm repo add kyverno https://kyverno.github.io/kyverno
    helm install kyverno kyverno/kyverno -n kyverno --create-namespace
    Validation
    • A policy-violating pod is rejected at admission.

    Rollback: helm uninstall kyverno; policies no longer enforced.

  8. 8

    Workload validation

    low risk

    Prove the whole stack by scheduling a real GPU workload.

    • ·Run a CUDA test pod requesting a GPU.
    • ·Confirm it schedules onto a GPU node and sees the device.
    GPU test pod
    apiVersion: v1
    kind: Pod
    metadata:
      name: gpu-test
    spec:
      restartPolicy: Never
      containers:
        - name: cuda
          image: nvidia/cuda:12.4.1-base-ubuntu22.04
          command: ["nvidia-smi"]
          resources:
            limits:
              nvidia.com/gpu: 1
    Validation
    • Pod completes and `nvidia-smi` lists the GPU.

    Rollback: `kubectl delete pod gpu-test` — no lasting change.

Generated artifacts are starting points — pin versions and review before running. Destructive steps are flagged; nothing here executes against a live cluster.