SkyPilot Kubernetes 开发环境搭建指南:从本地 kind 集群到 GKE/EKS 实战
2026/9/16 11:50:11 网站建设 项目流程

SkyPilot Kubernetes 开发环境搭建指南:从本地 kind 集群到 GKE/EKS 实战

【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot

SkyPilot 将 Kubernetes 作为一等公民的云后端,本文围绕仓库中 tests/kubernetes/README.md 的开发脚本体系,完整讲解 SkyPilot 容器镜像的构建与推送、基于 kind 的本地开发集群(sky local up)、GPU 节点模拟,以及 GKE 与 EKS 云上集群的创建、GPU 驱动与标签配置、清理回收全流程。读完你可以在本机或公有云上独立搭建一套可用于 SkyPilot 任务开发与验证的 Kubernetes 环境,并理解其底层节点标注(node labeling)机制。

目录概览:开发脚本的用途与定位

tests/kubernetes目录是 SkyPilot 开发者在 Kubernetes 上做日常开发、调试与测试的“工具箱”。除了本文依据的 README.md 外,该目录还包含:

  • 集群创建/删除脚本scripts/create_cluster.shscripts/delete_cluster.shscripts/clean_k8s.shscripts/delete.sh等,用于一键创建和销毁 GKE/EKS 测试集群;
  • 部署与验证脚本scripts/deploy_k3s.sh(在 GCP 虚拟机上一键部署带 GPU 的 K3s 调试集群)、scripts/helm_deploy_and_verify.shscripts/helm_upgrade.shscripts/helm_okta.shscripts/install_dashboard.sh(Kubernetes Dashboard);
  • 测试负载清单eks_test_cluster.yaml(eksctl 集群配置)、gpu_test_pod.yaml(验证 GPU operator 的nvidia-smiPod)、cpu_test_pod.yaml(验证镜像与 Service 的 HTTP 服务 Pod)、ingress_test.yamlloadbalancer_test_svc.yaml
  • 网络基准测试networking_benchmarks/下的k8s_network_benchmarks.mdrsync_bench.shskylaunch_bench.sh,用于评估 Kubernetes 上的存储与网络性能;
  • 升级测试upgrade/README.mdupgrade/test-upgrade.sh

下文将按照 README 的主线,从镜像构建开始,逐步走完“本地开发集群 → 云上集群 → GPU 支持 → 验证清理”的完整链路。

构建并推送 SkyPilot 容器镜像

SkyPilot 维护了一个预装了全部基础依赖的容器镜像,托管在 Google Artifact Registry:

us-docker.pkg.dev/sky-dev-465/skypilotk8s/skypilot:latest

该镜像同时被本目录下的测试 Pod 直接引用,例如 cpu_test_pod.yaml 中container: skytest使用us-docker.pkg.dev/sky-dev-465/skypilotk8s/skypilot:latest作为镜像,并执行sudo apt update && python3 -m http.server 8080来验证基础环境可用;gpu_test_pod.yaml 则使用带 GPU 运行时依赖的skypilot-gpu:latest镜像。可以看出,仓库维护了 CPU 与 GPU 两套镜像 Tag。

构建与推送通过build_image.sh完成(注意:该脚本面向 SkyPilot 核心维护者,未随仓库分发,需要时请向项目维护团队索要或在本地自行编写等价脚本):

# 构建并在本地加载镜像(不推送) ./build_image.sh # 构建并推送到 SkyPilot 官方 registry(谨慎!会覆盖线上镜像) ./build_image.sh -p # 构建并推送 GPU 版本镜像(谨慎!同样会覆盖线上镜像) ./build_image.sh -p -g

关键注意点:

  • 不带参数时仅执行build && load,适合本地迭代;
  • -p(push)会向us-docker.pkg.dev/sky-dev-465/skypilotk8s推送,涉及共享 registry 的写权限,仅限授权人员操作;
  • -g追加构建带 NVIDIA GPU 依赖的镜像(对应skypilot-gpu:latestTag),用于 GPU 节点验证(见下文 gpu_test_pod.yaml)。

用 kind 搭建本地开发集群

sky local up:一条命令拉起本地 Kubernetes

本地开发推荐使用 kind(Kubernetes in Docker)。SkyPilot 将其封装为sky local up命令:

sky local up

从源码看,该命令是经过完整的 Client/Server 链路实现的:CLI 入口位于 sky/client/cli/command.py(local_up(gpus, name, port_start, num_nodes)),通过 sky/client/sdk.py 发送POST /local_up请求到 SkyPilot API server,最终在 sky/server/server.py 执行,核心实现位于 sky/core.py。其关键约束如下:

  • 仅在本地单机 Kubernetes 集群场景下支持,且需要本机 kind 环境;
  • 该命令创建的 kind 集群上下文名为kind-skypilot,这一定义在 sky/provision/kubernetes/utils.py 中:KIND_CONTEXT_NAME = 'kind-skypilot' # Context name used by sky local up
  • sky local up还支持--gpus等参数。若本机集群未就绪,SkyPilot 会提示“runsky local upto start the cluster”,见 sky/adaptors/kubernetes.py;
  • 需要清理时,可调用对应的local_down接口(定义于 sky/core.py 附近,SDK 封装见 sky/client/sdk.py);
  • 值得留意的是,sky local up创建的 kind 集群默认使用ingress 网络模式,相关逻辑见 sky/provision/kubernetes/network_utils.py 的注释说明。

sky local up创建的 kind 控制面节点默认名为skypilot-control-plane,这也是下文 GPU 模拟操作的对象。

在本地集群上模拟 GPU 节点

本地机器通常没有真实 GPU,但 SkyPilot 调度依赖节点上的 GPU 资源量与标签。README 给出了“无 GPU 硬件也能模拟 GPU 节点”的方法:给 kind 控制面节点打上加速器标签,并用kubectl proxy通过 API 直接修改节点的status.capacity,向节点注入虚拟的nvidia.com/gpu资源。

操作分两步:

第一步:给节点打上加速器标签

# 确保 sky local up 集群已运行 kubectl label node skypilot-control-plane skypilot.co/accelerator=h100 # 可换成其他 GPU,务必使用小写!

skypilot.co/accelerator是 SkyPilot 在 Kubernetes 上识别加速器类型的标准节点标签(源码中的常量定义与错误提示见 sky/provision/kubernetes/utils.py)。标签值必须小写——SkyPilot 内部会做小写归一化匹配(例如NEURON_ACCELERATORS = {'trainium', 'trainium2', 'inferentia', 'inferentia2'}等常量均以小写形式参与比较),大写标签会导致识别失败。

第二步:注入虚拟 GPU 资源

# 在第一个终端启动 kubectl proxy kubectl proxy # 在第二个终端执行 PATCH 请求,向节点容量注入 8 个虚拟 GPU curl --header "Content-Type: application/json-patch+json" \ --request PATCH \ --data '[{"op": "add", "path": "/status/capacity/nvidia.com~1gpu", "value": "8"}]' \ http://localhost:8001/api/v1/nodes/skypilot-control-plane/status

原理说明:

  • kubectl proxylocalhost:8001上暴露 Kubernetes API Server,并自动处理鉴权,便于用curl发起 PATCH;
  • JSON Patch 路径中的~1是 Kubernetes 对/的转义形式,/status/capacity/nvidia.com~1gpu实际指向status.capacity["nvidia.com/gpu"]
  • "value": "8"表示把该节点的 GPU 容量改为 8(可按需改成任意数字,如 1、4、16)。

完成两步后,运行kubectl describe node skypilot-control-plane可以看到节点同时具备skypilot.co/accelerator=h100标签与nvidia.com/gpu: 8的可分配资源,此时sky check kubernetes即可识别出这台“H100 GPU 节点”,从而在不接触真实 GPU 硬件的情况下验证 SkyPilot 的 GPU 调度逻辑。

创建 GKE 集群进行开发测试

集群创建前置条件

在 GCP 上创建测试集群需注意:

  • 至少 1 个节点,官方建议每个节点至少 4 vCPU
  • 仅支持 GKE Standard 集群,GKE Autopilot 集群不受支持(两者在节点管理与准入控制上的差异会影响 SkyPilot 的调度与标注机制)。

一键创建多类型节点池的 GKE 集群

README 提供了一个完整的示例命令,用于创建包含 6 个节点、覆盖多种 GPU 与 CPU 类型的测试集群(2× T4-8cpu、2× V100-8cpu、2× 16cpu 纯 CPU 节点)。该命令分为三部分:

(1)准备公共参数

PROJECT_ID=$(gcloud config get-value project) CLUSTER_NAME=skypilot-test-cluster REGION=us-central1-c GKE_VERSION=$(gcloud container get-server-config \ --region=${REGION} \ --flatten=channels \ --filter="channels.channel=REGULAR" \ --format="value(channels.defaultVersion)") # 集群与节点池的公共参数 ARGS="--project ${PROJECT_ID} \ --zone ${REGION} \ --machine-type n1-standard-8 \ --image-type COS_CONTAINERD \ --disk-type pd-balanced \ --disk-size 100 \ --metadata disable-legacy-endpoints=true \ --scopes https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/trace.append \ --num-nodes 2 \ --enable-autoupgrade \ --enable-autorepair \ --max-surge-upgrade 1 \ --max-unavailable-upgrade 0 \ --node-locations ${REGION}"

要点解析:

  • GKE_VERSION通过get-server-config动态获取 REGULAR 渠道的默认版本,避免硬编码过时版本号;
  • COS_CONTAINERD是 Container-Optimized OS + containerd 运行时,后续 GPU 驱动安装需要对应 COS 版本的 DaemonSet(见下文);
  • 磁盘使用pd-balanced、100GB,开启自动升级(autoupgrade)与自动修复(autorepair);
  • 滚动升级参数--max-surge-upgrade 1 --max-unavailable-upgrade 0保证升级期间至少保留 1 个可用节点;
  • --scopes为节点授予读写 GCS、写日志、监控、服务控制等必要权限。

(2)创建集群

gcloud beta container clusters create ${CLUSTER_NAME} ${ARGS} \ --cluster-version ${GKE_VERSION} \ --release-channel "regular" \ --no-enable-basic-auth \ --logging=SYSTEM,WORKLOAD \ --monitoring=SYSTEM \ --enable-ip-alias \ --network "projects/${PROJECT_ID}/global/networks/default" \ --subnetwork "projects/${PROJECT_ID}/regions/${REGION%-*}/subnetworks/default" \ --no-enable-intra-node-visibility \ --default-max-pods-per-node "110" \ --security-posture=standard \ --workload-vulnerability-scanning=disabled \ --no-enable-master-authorized-networks \ --addons HorizontalPodAutoscaling,HttpLoadBalancing,GcePersistentDiskCsiDriver \ --enable-managed-prometheus \ --enable-shielded-nodes

(3)创建节点池

# Spot T4 节点池(抢占式,成本更低) gcloud beta container node-pools create "spot-t4" ${ARGS} \ --cluster ${CLUSTER_NAME} --spot \ --accelerator "type=nvidia-tesla-t4,count=1" # 按需 T4 节点池 gcloud beta container node-pools create "t4" ${ARGS} \ --cluster ${CLUSTER_NAME} --accelerator "type=nvidia-tesla-t4,count=1" # V100 节点池 gcloud beta container node-pools create "v100" ${ARGS} \ --cluster ${CLUSTER_NAME} --accelerator "type=nvidia-tesla-v100,count=1" # L4 节点池(使用 g2-standard-4 机型) gcloud beta container node-pools create "l4" ${ARGS} \ --cluster ${CLUSTER_NAME} --machine-type "g2-standard-4" \ --accelerator "type=nvidia-l4,count=1" # 纯 CPU 大节点池(16 vCPU) gcloud beta container node-pools create "largecpu" ${ARGS} \ --cluster ${CLUSTER_NAME} --machine-type "n1-standard-16"

节点池设计说明:

  • spot-t4使用--spot创建抢占式(Spot)节点池,用于验证 SkyPilot 在可被回收实例上的容错与自动恢复能力;
  • 各节点池通过--accelerator "type=nvidia-xxx,count=1"挂载 GPU,其中 L4 使用g2-standard-4机型(G2 系列为 L4 优化的机型),其余使用默认的n1-standard-8
  • 这样形成的异构集群可用于测试 SkyPilot 对多加速器、多机型的 failover 与调度逻辑。

获取 kubeconfig 并验证

gcloud container clusters get-credentials <cluster-name> --region <region> # 示例: # gcloud container clusters get-credentials $CLUSTER_NAME --region us-central1-c # 验证节点可见 kubectl get nodes

get-credentials会把集群凭据合并写入~/.kube/configkubectl get nodes应能看到所有节点。

安装 GPU 驱动

只有需要 GPU 支持时才需要执行本步。GKE 不会自动为 GPU 节点安装驱动,需部署 Google 官方维护的 NVIDIA 驱动安装 DaemonSet。根据节点镜像类型选择:

# COS 镜像节点(如上面示例): kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded-latest.yaml # Ubuntu 镜像节点: kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded.yaml kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R525.yaml

驱动安装成功后,节点会出现nvidia.com/gpu: 1这类可分配资源:

kubectl describe nodes

注意:本步只解决 GPU 资源可见性,尚未解决 GPU 类型标注。在 GKE 上,SkyPilot 判断节点 GPU 类型所依赖的skypilot.co/accelerator标签需要由 SkyPilot 的 GPU 标签器(GPU labeler)来设置,详见下文的“sky gpus label机制”一节。

运行sky check验证后端

sky check

sky check会探测所有已配置云后端的可用性;对 Kubernetes 后端,它会检查 kubeconfig 是否可读、节点是否可达,并列出可用的加速器资源(包括通过nvidia.com/gpu暴露的 GPU 与通过节点标签识别的加速器类型)。看到 Kubernetes 后端显示enabled后即可运行 SkyPilot 任务。

网络模式注意事项:NodePort 防火墙

注意:如果使用 NodePort 网络模式,请确保节点池 VPC 的防火墙放行 32100 端口。

SkyPilot 在 Kubernetes 上可选择 ingress / port-forward / NodePort 等服务暴露方式。当使用 NodePort 模式时,SkyPilot 的服务会绑定到节点的高位端口(其中 32100 是 SkyPilot 约定的服务端口之一),因此必须保证该端口在节点池的安全组/防火墙规则中开放,否则任务的服务无法被外部访问。

清理集群与节点池

测试结束后,删除集群:

gcloud container clusters delete <cluster-name> --region <region> # 示例: # gcloud container clusters delete testcluster --region us-central1-c

如需分别删除节点池(异步执行),可运行:

gcloud container node-pools delete "spot-t4" --region ${REGION} --cluster ${CLUSTER_NAME} --async gcloud container node-pools delete "t4" --region ${REGION} --cluster ${CLUSTER_NAME} --async gcloud container node-pools delete "v100" --region ${REGION} --cluster ${CLUSTER_NAME} --async gcloud container node-pools delete "l4" --region ${REGION} --cluster ${CLUSTER_NAME} --async gcloud container node-pools delete "largecpu" --region ${REGION} --cluster ${CLUSTER_NAME} --async

--async表示立即返回、后台删除,适合批量清理多个节点池。

创建 EKS 集群进行开发测试

用 eksctl 一键创建集群

EKS 的搭建比 GKE 更简洁——仓库已提供现成的 eksctl 配置 tests/kubernetes/eks_test_cluster.yaml,一条命令即可创建集群并自动更新 kubeconfig:

eksctl create cluster -f tests/kubernetes/eks_test_cluster.yaml

该配置创建 3 个受管节点组(managed node groups):v100-nodesp3.2xlarge,1× V100)、t4-nodesg4dn.2xlarge,1× T4)、cpu-nodesm5.4xlarge,16 vCPU 纯 CPU),每个节点组desiredCapacity: 1eksctl create cluster会自动写入~/.kube/config,随后验证:

kubectl get nodes

EKS 的 GPU 支持:驱动已有,标注靠 SkyPilot

与 GKE 不同,EKS 集群自带 GPU 驱动(Amazon EKS 优化 AMI 预置了 NVIDIA 驱动与 runtime),因此无需安装驱动。但 EKS 节点不会自动标注 GPU 类型,需要借助 SkyPilot 的节点标注命令:

sky gpus label

这条命令的底层实现是 sky/utils/kubernetes/gpu_labeler.py:

  • 它会在kube-system命名空间为每个 GPU 节点创建一个标签任务(labeling job,标签job=sky-gpu-labeler),任务内运行nvidia-smi读取实际 GPU 型号,并将结果写入节点的skypilot.co/accelerator标签;
  • 任务完成后节点即被标注为正确的加速器类型(如skypilot.co/accelerator=h100);
  • 该脚本支持--cleanup参数,用于删除此前创建的全部标签资源,保证可重复执行(幂等性逻辑见 gpu_labeler.py);
  • 目前该命令仅支持 NVIDIA GPU(AMD 与 TPU 节点的标注需走其他路径)。

查看标签任务的执行状态:

kubectl get jobs -n kube-system

确认任务全部完成后,通过kubectl describe nodes检查每个 GPU 节点是否已出现skypilot.co/accelerator标签:

kubectl describe nodes

若标注过程出现问题,可一键清理标签资源后重试:

sky gpus label --cleanup

从实现上看,sky gpus labelkube-system命名空间下的job=sky-gpu-labeler系列资源强绑定,清理动作通过kubectl delete ... -n kube-system -l job=sky-gpu-labeler完成(见 gpu_labeler.py)。这一机制同样适用于 GKE:在 GKE 上安装 GPU 驱动后,节点虽暴露nvidia.com/gpu资源,但同样需要sky gpus label来补齐skypilot.co/accelerator类型标签,SkyPilot 才能按 GPU 型号正确调度。

运行sky check与清理集群

sky check

验证通过后,删除集群:

eksctl delete cluster -f tests/kubernetes/eks_test_cluster.yaml

同样地,若使用 NodePort 网络模式,请确保 EKS 集群默认安全组(default security group)放行 32100 端口。

GPU 标签机制:SkyPilot 在 Kubernetes 上识别加速器的关键

贯穿 GKE 与 EKS 两节的skypilot.co/accelerator节点标签,是 SkyPilot Kubernetes 后端的核心调度依据。综合 sky/provision/kubernetes/utils.py 的源码可以看到:

  • SkyPilot 通过节点标签识别加速器类型,支持的资源键包括 NVIDIA、AMD 与 TPU(常量SUPPORTED_GPU_RESOURCE_KEYSTPU_RESOURCE_KEY);
  • 当集群中存在 GPU/TPU 但标签缺失时,SkyPilot 会给出NO_ACCELERATOR_HELP_MESSAGE,提示检查nvidia.com/gpu等资源是否可用、skypilot.co/accelerator标签是否正确配置;
  • 因此,资源量(nvidia.com/gpu)与类型标签(skypilot.co/accelerator)二者缺一不可:前者由驱动/GPU operator 注入,后者由sky gpus label(或手动kubectl label)写入。

本地 kind 集群、GKE 与 EKS 三种环境的 GPU 支持对比:

环境GPU 资源注入GPU 类型标注推荐标注方式
kind(sky local up手动 PATCH 节点 status手动kubectl label按 README 两步手动模拟
GKE Standard手动安装驱动 DaemonSet需要标注驱动安装后运行sky gpus label
EKS镜像自带驱动需要标注直接运行sky gpus label

配套验证清单与排障脚本

除了 README 主流程,tests/kubernetes目录提供了若干立即可用的验证与排障资源:

GPU 验证 Pod(tests/kubernetes/gpu_test_pod.yaml):以skypilot-gpu:latest镜像运行nvidia-smi并要求nvidia.com/gpu: "1"资源,用于确认 GPU operator 与 NVIDIA runtime 配置正确:

kubectl apply -f tests/kubernetes/gpu_test_pod.yaml # 若 Pod 正常 Succeeded 并输出 GPU 信息,说明 GPU 链路 OK

CPU/服务验证 Pod(tests/kubernetes/cpu_test_pod.yaml):以skypilot:latest镜像启动内置 HTTP 服务器,并创建skytest-svcService 对内暴露:

kubectl apply -f tests/kubernetes/cpu_test_pod.yaml kubectl port-forward svc/skytest-svc 8080:8080 # 浏览器访问 http://localhost:8080

K3s 调试集群(tests/kubernetes/scripts/deploy_k3s.sh):当需要隔离的 GPU 调试环境时,可在 GCP 虚拟机上部署带 GPU 的 K3s 集群。该脚本依次执行 k3s 安装、GPU operator(Helm)部署、RuntimeClass 创建、GPU 标注与等待(通过kubectl get jobs -n kube-system -l job=sky-gpu-labeler轮询完成状态,超时 10 分钟即失败)。它给出了 README 主流程之外一个非常完整的 GPU 集群自动化样例。

一键集群脚本(tests/kubernetes/scripts/create_cluster.sh):支持gcp|aws两种 provider 的参数化建集群,EKS 分支还会自动生成 eksctl 配置、注入自定义 VPC(EKS_VPC_CONFIG_PRIVATE)、配置默认 gp3 StorageClass,适合 CI 或日常开发复用。

网络基准测试tests/kubernetes/networking_benchmarks/):其中的k8s_network_benchmarks.mdrsync_bench.shskylaunch_bench.sh可用于量化评估 Kubernetes 集群内外的文件传输与启动性能,是优化 SkyPilot 在 K8s 上数据加载路径的参考工具。

总结

本文围绕 tests/kubernetes/README.md 完整还原了 SkyPilot 在 Kubernetes 上的开发环境搭建链路:

  1. 镜像层build_image.sh构建/推送skypilot:latestskypilot-gpu:latest,支撑后续所有 Pod 运行;
  2. 本地层sky local up一行拉起 kind 集群(上下文kind-skypilot),并通过kubectl label+kubectl proxy/PATCH 组合在无 GPU 硬件时模拟 GPU 节点;
  3. 云上层:GKE Standard 需自装驱动、EKS 自带驱动,两者都依赖sky gpus label(底层为 gpu_labeler.py)补齐skypilot.co/accelerator类型标签;
  4. 验证与回收sky check确认后端就绪,gpu_test_pod.yaml/cpu_test_pod.yaml冒烟验证,最后用gcloud/eksctl命令或配套脚本清理资源。

掌握以上流程后,你既能在本地无 GPU 环境下快速迭代 SkyPilot 的调度逻辑,也能在 GKE/EKS 异构 GPU 集群上验证真实的多加速器任务,是深入 SkyPilot Kubernetes 后端的实用起点。

【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询