一键导入
eks-nodes
Generate Terraform for additional EKS managed node groups: compute and GPU pools for KAS/NVCF workloads. Use after eks-cluster and before eks-storage.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Generate Terraform for additional EKS managed node groups: compute and GPU pools for KAS/NVCF workloads. Use after eks-cluster and before eks-storage.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Orchestrate an end-to-end NVIDIA self-managed streaming stack across AWS or Azure. Use when planning, generating, sequencing, deploying, or validating the full path from CSP base infrastructure through NVCF self-managed control plane, NVCF auxiliary services, caches, storage APIs, and post-deploy readiness gates. Trigger when the user asks for orchestration, full-stack setup, bring-up order, runbook, dependency sequencing, AWS/Azure streaming deployment, csp-infra plus NVCF, caches, or storage API coordination. Do not use for a single component task when the user explicitly asks only for one child skill.
Deploy DDCS as a shader cache for Kit/write-render-worker on GKE. Produces Kubernetes manifests, the Helm values override for write-render-worker (drivercachewrapper + UJITSO), and optionally runs a proof-of-life test. Use when setting up DDCS for MEGA shader caching (replacing GX cache).
Deploy NVIDIA Omniverse Content Cache (OVCC) alongside a MEGA simulation stack. Covers evaluation, sizing (NGINX queue-depth model), configuration for GCS/S3/Azure backends, Helm install from NGC (chart ovcontentcache v4.0.4), TLS setup, in-place upgrade from UCC 3.0.3, and wiring to write-render-worker and storage-service. MEGA does not use Nucleus; always disable it. Use when deploying OVCC for MEGA — whether exploring fit, sizing replicas, or ready to install.
Use for installing, debugging, or modifying NVCF GXCache across self-managed Kubernetes environments. Trigger on explicit GXCache, helm-gxcache, gxcache-init, gxcache-webhook, distributed shader cache, NVCA cache feature gates, or GXCache provider adaptation for Kubernetes clusters.
Generate the AWS network and IAM foundation for a KAS/NVCF EKS deployment: VPC, public/private subnets, route tables, Internet/NAT gateways, and base IAM/tagging inputs. Use as Stage 01 of aws-infra before eks-cluster.
Orchestrate the AWS KAS/NVCF EKS foundation by delegating to the component AWS infrastructure skills: aws-tf-conventions, aws-iam-vpc, eks-cluster, eks-nodes, eks-storage, ecr, eks-gpu-operator, eks-validate, and optionally ecr-mirror. Use when setting up, reviewing, or tearing down the full AWS foundation end-to-end; not for runtime installation, functions, or stream validation.
| name | eks-nodes |
| description | Generate Terraform for additional EKS managed node groups: compute and GPU pools for KAS/NVCF workloads. Use after eks-cluster and before eks-storage. |
Generate Terraform for workload node groups on an existing EKS cluster:
Do not create the EKS control plane here. Do not install GPU Operator here.
Required:
| Input | Notes |
|---|---|
CLUSTER_NAME | Existing EKS cluster name. |
private_subnet_ids | Private subnet IDs from aws-iam-vpc. |
node_role_arn or node IAM role config | Role used by managed node groups. |
Defaults:
| Input | Default |
|---|---|
| compute node instance type | m6i.2xlarge |
| compute min/max/desired | 1 / 3 / 1 |
| GPU node instance type | g6.12xlarge or closest quota-approved GPU SKU |
| GPU AMI type | AL2023_x86_64_NVIDIA |
| GPU min/max/desired | 0 / 2 / 1 |
Required labels:
compute: node-type=compute
gpu: node-type=gpu, nvidia.com/gpu.deploy.driver=false
Terraform module values should carry the same contract:
ami_type = "AL2023_x86_64_NVIDIA"
labels = {
"node-type" = "gpu"
"nvidia.com/gpu.deploy.driver" = "false"
}
The GPU node group must use ami_type = "AL2023_x86_64_NVIDIA" or a reviewed
custom GPU AMI with the NVIDIA driver and container toolkit already installed.
Managed node groups launch instances with the default IMDS
HttpPutResponseHopLimit = 1. A hop limit of 1 lets host-network pods reach
IMDS but blocks ordinary (extra-hop) pods, so controllers that rely on the node
instance-role credentials cannot read them. The aws-ebs-csi-driver
controller (a normal Deployment) then CrashLoops with
no EC2 IMDS role found … context deadline exceeded, while its hostNetwork
node DaemonSet works — persistent-volume provisioning stays broken.
Each node group must therefore raise the hop limit to 2 via a launch template
metadata_options block (so it survives scaling), and keep IMDSv2 required:
metadata_options {
http_endpoint = "enabled"
http_tokens = "required" # IMDSv2
http_put_response_hop_limit = 2 # allow non-hostNetwork pods to reach IMDS
}
When the node group is created via aws_eks_node_group, attach this through a
launch_template (managed node groups do not expose metadata_options
directly). Alternatively, provision IRSA / EKS Pod Identity for the EBS CSI
driver (and other controllers) so they do not depend on node-role IMDS at all;
in that case the hop limit may stay at 1. Raising the hop limit is the simpler
default and mirrors AWS best practice for EKS + IMDSv2.
aws-tf-conventions before generating Terraform.desired_size defaults to 1 so a freshly applied cluster has a GPU
node and eks-validate gpu-resource/cuda-smoke checks pass out of the
box. If you intentionally set GPU min/desired to zero (scale-to-zero for
cost), eks-validate will FAIL those checks unless you run it with
ALLOW_GPU_ZERO=true, which downgrades them to WARN.node-type=compute.node-type=gpu.nvidia.com/gpu.deploy.driver=false.AL2023_x86_64_NVIDIA or reviewed equivalent.http_put_response_hop_limit = 2 (via launch
template) with http_tokens = "required", or IRSA / EKS Pod Identity is
provisioned for IMDS-dependent controllers (e.g. aws-ebs-csi-driver).