Karpenter 开发环境搭建与开发者工作流实战指南【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws本指南面向希望为 Karpenterkarpenter-provider-aws贡献代码的开发者系统讲解从零搭建本地开发环境、进入“编码—构建—部署—调试”循环、以及使用 pprof 进行性能剖析的完整流程。读完本文你将掌握make驱动的开发工作流run/apply/delete/image/test/presubmit、AWS ECR 镜像仓库配置方法以及 metrics 与日志调试技巧可直接复用于日常开发与问题排查。开发依赖与工具链安装Karpenter 是一个 Go 语言编写的 Kubernetes 控制器其开发环境依赖以下基础工具工具版本要求安装方式Gov1.19官方安装包或包管理器kubectl与集群版本匹配brew install kubectlmacOShelm与集群版本匹配brew install helmmacOS其余构建/测试工具见下方make toolchain其中“其余工具”并非手写安装而是由仓库根目录下的 Makefile 中的toolchain目标调用 hack/toolchain.sh 一次性安装。从脚本源码看它通过go install安装了项目开发所需的完整 CLI 工具集包括kov0.18.1基于 Go 源码构建 OCI 镜像并推送是make image的核心工具golangci-lintv2.12.2静态检查与 lintcontroller-genv0.21.0生成 CRD 与 DeepCopy 代码setup-envtest下载并软链 kubebuilder 测试环境二进制默认 K8S_VERSION1.34.x安装到/usr/local/kubebuilder/binginkgov2.32.0单元测试与 e2e 测试的运行框架yqv4.52.5、helm-docs、cosign、crane、oras、hugo、govulncheck、actionlint、go-licenses、goveralls等。提示脚本运行后会检查 Go 的bin目录是否在PATH中若未包含会提示执行export PATH$PATH:${GOPATH:-$HOME/go}/bin请留意该输出。环境特定配置以 AWS ECR 为例开发 Karpenter 需要为控制器组件准备一个镜像仓库。官方推荐使用 AWS ECR并按“多个项目共用一个dev仓库、用镜像摘要digest而非 tag 引用”的方式管理。先创建 ECR 仓库建议开启镜像扫描scanOnPushtrueaws ecr create-repository \ --repository-name dev \ --image-scanning-configuration scanOnPushtrue \ --region ${AWS_DEFAULT_REGION}创建完成后让 Docker 守护进程登录该仓库并设置KO_DOCKER_REPO环境变量指向它export KO_DOCKER_REPO${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/dev aws ecr get-login-password --region ${AWS_DEFAULT_REGION} | docker login --username AWS --password-stdin ${KO_DOCKER_REPO}在 Makefile 中可以看到KO_DOCKER_REPO的默认值正是${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/dev与上述约定一致同时它还会通过aws sts get-caller-identity自动解析AWS_ACCOUNT_ID。确保运行make命令前已配置有效的 AWS 凭证本地开发时用于生成 CRD 清单、拉取定价数据等集群具备从该 ECR 仓库拉取镜像的权限如通过 IRSA 或节点 IAM 角色。开发循环编码到验证的标准节奏开发者的标准循环如下安装依赖运行make codegen重新生成 yaml 清单该目标定义见 Makefile其背后是 hack/codegen.sh基于 AWS API 响应生成带宽、价格、VPC 限制等数据文件。注意该命令需要可用的 AWS 凭证运行make toolchain安装构建与测试所需的 CLI 工具。准备个人开发镜像仓库见上文 ECR 配置并确保$KO_DOCKER_REPO指向该仓库。编写代码后执行构建与部署见下节。在集群中快速部署make applymake apply会完成“校验 → 构建镜像 → 部署到~/.kube/config指定集群”的完整链路。从 Makefile 的源码可见其实际执行的动作apply: verify image kubectl apply -f ./pkg/apis/crds/ helm upgrade --install karpenter charts/karpenter --namespace ${KARPENTER_NAMESPACE} \ $(HELM_OPTS) \ --set controller.image.repository$(IMG_REPOSITORY) \ --set controller.image.tag$(IMG_TAG) \ --set controller.image.digest$(IMG_DIGEST)即先依次执行verify依赖整理、代码生成、CRD 同步、lint、git 工作区检查和image用 ko 构建并推送镜像再应用 pkg/apis/crds 下的 CRD最后通过 charts/karpenter 这个 Helm Chart 完成部署并精确指定镜像仓库、tag 与 digest。make apply还默认注入了大量 Helm 参数见 HELM_OPTS包括服务账号的 IAM Role ARN${CLUSTER_NAME}-karpentersettings.clusterName、settings.interruptionQueue控制器资源 requests/limitsCPU 1、内存 1Gi一组 feature gatesnodeRepair、reservedCapacity、spotToSpotConsolidation、nodeOverlay、staticCapacity、capacityBuffer默认logLeveldebug对应下文的日志级别说明。卸载控制器则使用make delete # Uninstall Karpenter其实现为helm uninstall karpenter --namespace ${KARPENTER_NAMESPACE}见 Makefile命名空间默认是kube-systemMakefile。在本地直接运行控制器make run若不想把控制器部署进集群而是希望在本机以 Go 二进制方式运行、直接连到~/.kube/config指定的集群使用make run从 Makefile 的实现看该目标会先kubectl apply -f ./pkg/apis/crds/确保最新 CRD 已安装设置SYSTEM_NAMESPACE、CLUSTER_NAME、INTERRUPTION_QUEUE、FEATURE_GATES、AWS_FEATURE_GATES、LOG_LEVELdebug等环境变量执行go run ./cmd/controller/main.go启动控制器关闭了 leader election便于本地调试。这适合需要快速迭代、希望直接观察控制器日志与行为如调度、漂移检测、中断处理的场景。仅构建并发布镜像make image如果只想构建控制器镜像并推送到镜像仓库、暂不部署 Helm Release运行make image # build and push the karpenter images该目标Makefile使用ko build --bare从github.com/aws/karpenter-provider-aws/cmd/controller直接构建镜像并解析出IMG_REPOSITORY、IMG_TAG、IMG_DIGEST供apply使用。注意构建时会注入sigs.k8s.io/karpenter/pkg/operator.Version这个版本变量见 Makefile版本来自git describe --tags。本地替换 kubernetes-sigs/karpenter 依赖Karpenter 控制器依赖核心调度库sigs.k8s.io/karpenter。若你同时改动了上游核心代码并希望在本仓库验证可通过go mod的 replace 指令将依赖指向本地路径go mod edit -replace sigs.k8s.io/karpenter$PATH_TO_KUBERNETES_SIGS_KARPENTER将$PATH_TO_KUBERNETES_SIGS_KARPENTER替换为本地相对或绝对路径后再执行上述镜像构建即可。注意必须先将 go.mod 的改动提交commitmake image才会真正生效因为镜像构建读取的是工作区中已固化的依赖版本。恢复上游依赖时可将 update-karpenter 目标作为参考go get -u sigs.k8s.io/karpenterHEAD后go mod tidy。提交前全量检查make presubmit每次提交前建议运行make presubmit # run codegen, lint, and tests该目标定义于 Makefilepresubmit: verify test等价于依次执行完整校验依赖、代码生成、CRD 同步、lint、git 工作区洁净度检查与全部单元测试是 CI 的核心步骤。单元测试与 E2E 测试单元测试make test # E2E correctness tests实际执行Makefile的是go test ./pkg/...并附加覆盖率采集-cover -coverprofilecoverage.out与 Ginkgo 参数--ginkgo.randomize-all、--ginkgo.vv支持通过FOCUS/SKIP环境变量筛选用例。生成覆盖率报告后可运行make coverage用go tool cover生成 HTML 查看。此外仓库还提供了make deflake带--race竞态检测并循环执行直到失败用于排查偶发失败用例以及make benchmark-tagstest_performance性能基准测试等测试辅助目标。E2E 测试make test只是单元测试针对真实集群的端到端测试位于 test/suites 目录涵盖 ami、consolidation、drift、interruption、ipv6、scheduling、storage 等场景通过make e2etests运行e2etests: ## Run the e2e suite against your local cluster cd test CLUSTER_ENDPOINT${CLUSTER_ENDPOINT} ... go test -p 1 -count 1 -timeout 12h -v ./suites/$(...)/...其中TEST_SUITE变量用于指定某个套件目录默认...即全部套件所需的默认 EC2NodeClass / NodePool 资源位于 test/pkg/environment/aws/default_ec2nodeclass.yaml 与 test/pkg/environment/aws/default_nodepool.yaml可据此了解 e2e 依赖的集群前置条件。调试技巧日志级别、Metrics 与日志跟踪修改日志级别默认情况下make apply通过 Helm 参数把日志级别设为debug见 HELM_OPTS 中的--set logLeveldebug以输出最详细的调度与控制器日志。如需调整可在 Helm 安装/升级时覆盖--set logLeveldebug关于日志级别的合法取值可以参考 Settings 配置参考 中LOG_LEVEL条目可选debug、info、error默认值为info——也就是说生产环境默认是 info 级别开发时显式使用 debug 才能看到更完整的内部决策过程。调试 MetricsKarpenter 在METRICS_PORT默认 8080见 Settings 配置参考上暴露控制器自身运行指标可通过 port-forward 在本机浏览器查看macOSopen http://localhost:8080/metrics kubectl port-forward service/karpenter -n kube-system 8080Linuxgio open http://localhost:8080/metrics kubectl port-forward service/karpenter -n karpenter 8080注意两处命令的命名空间差异macOS 示例使用kube-systemLinux 示例使用karpenter。实际命名空间以你部署时KARPENTER_NAMESPACE默认kube-system见 Makefile为准请按你的部署环境调整。高效跟踪控制器日志除了直接kubectl logs文档推荐使用 Stern 这类多 pod 聚合日志工具一条命令即可跟随所有 Karpenter 控制器副本的日志stern -n karpenter -l app.kubernetes.io/namekarpenter该 label 选择器与 Helm Chart 中 Karpenter 组件的标准标签一致可按需将-n karpenter替换为实际命名空间。使用 pprof 进行性能剖析当在 Settings 配置参考 中启用 profiling对应ENABLE_PROFILING/--enable-profiling配置项后Karpenter 会在 metrics 端口上暴露 Go 标准的 pprof 调试端点可用于分析控制器内存与 CPU 热点。前置准备brew install graphviz go install github.com/google/pproflatestgraphviz用于 pprof 生成调用图graph视图pprof工具本身也建议通过go install安装最新版。采集并可视化 profile# 1. 连接 metrics 端点默认 8080 端口 kubectl port-forward service/karpenter -n karpenter 8080 # 2. 打开 pprof 索引页查看可用端点 open http://localhost:8080/debug/pprof/ # 3. 可视化内存堆快照 go tool pprof -http 0.0.0.0:9000 localhost:8080/debug/pprof/heap # 4. 可视化 CPU 剖析采样 60 秒 go tool pprof -http 0.0.0.0:9000 localhost:8080/debug/pprof/profile?seconds60要点先执行kubectl port-forward将集群内 8080 端口映射到本地再通过localhost:8080访问-http 0.0.0.0:9000会在本机 9000 端口启动一个交互式 Web UI支持火焰图、调用图、源码级热点标注等多种视图内存剖析用heap端点快照式CPU 剖析用profile端点并配合seconds60指定采样时长剖析端点与业务 metrics 共用同一端口因此启用 profiling 时请留意端口安全边界。常用 Make 目标速查以下目标均定义于仓库根目录 Makefile可使用make help查看全部带注释的目标目标作用make toolchain安装构建/测试所需全部 CLI 工具make codegen基于 AWS API 响应重新生成数据与 yaml 清单make run本地以 Go 二进制运行控制器连~/.kube/config集群make apply构建镜像并 Helm 部署到集群含 verifymake delete从集群卸载 Karpentermake image仅构建并推送控制器镜像make presubmit提交前全量校验verify testmake test运行单元测试并生成覆盖率make e2etests对真实集群运行端到端测试套件make deflake竞态检测 循环运行直至失败排查 flaky 用例make website本地启动文档站点Hugo完整的开发环境配置、构建部署与调试细节还可参考本仓库 website/content/en/v1.12/contributing 下的其他贡献者文档如 design-guide.md、documentation-updates.md以便在动手开发前对齐设计与文档规范。【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考