Karpenter CRD Helm Chart 完全指南karpenter-crd 的安装、配置与故障排查【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-awskarpenter-crd 是 Karpenter 官方提供的独立 Helm Chart用于将 Karpenter 所需的全部自定义资源定义CRD以 Helm 原生的方式安装到 Kubernetes 集群。本文以仓库中 charts/karpenter-crd/README.md 为骨架结合 Chart 源码与生成流水线讲解该 Chart 的定位、唯一可配置项additionalAnnotations的用法、内置 CRD 清单、安装升级流程以及常见的 Helm ownership 冲突故障排查读完即可独立完成 CRD 的安装、定制与升级。一、karpenter-crd 是什么一个独立于控制器之外的 CRD Chart在 Karpenter 的早期版本中CRD 与控制器一起打包在同一个karpenterHelm Chart 中。随着 Karpenter 0.26.1 起引入karpenter-crdCRD 被拆分为独立 Chart 进行管理和发布其定位在 Chart 元数据中写得很清楚A Helm chart for Karpenter Custom Resource Definitions (CRDs).也就是说karpenter-crd只负责把 CRD 安装进集群本身不包含控制器 Deployment、ServiceAccount、RBAC 等运行时组件——那些仍由主karpenterChart见 charts/karpenter/Chart.yaml负责。这种拆分带来的直接好处是升级顺序可控先升级 CRD再滚动升级控制器避免新版本控制器引用旧版 CRD schema 导致校验失败职责清晰CRD 属于集群级别的全局资源与控制器命名空间内的资源解耦方便单独管理、审计与回滚可独立定制通过 values 注入 annotations满足企业内部的合规标签需求。二、Chart 元信息解读根据 charts/karpenter-crd/Chart.yaml该 Chart 的完整元信息如下字段值说明apiVersionv2Helm 3 Chart API 版本namekarpenter-crdChart 名称typeapplication应用类型 Chart区别于libraryversion1.14.1Chart 版本号与主karpenterChart 同步appVersion1.14.1被管理应用的版本即 Karpenter 版本keywordscluster、node、scheduler、autoscaling、lifecycle用于 Helm 仓库搜索的关键词注意version与appVersion均为1.14.1与主 Chart charts/karpenter/Chart.yaml 完全一致——这保证 CRD 与控制器以同一版本号发布、配套升级。README 顶部徽章Version / Type / AppVersion即由 helm-docs 从这些元数据自动生成其模板见 charts/karpenter-crd/README.md.gotmpl。此外charts/karpenter-crd/artifacthub-repo.yaml 中的ignore规则表明该 Chart 不会被发布到 ArtifactHub 公共仓库karpenter-crd被排除它的分发走 Helm OCI 仓库路径发布逻辑见 hack/release/common.sh 中的publishHelmChart ... karpenter-crd ...调用。三、内置 CRD 清单五个模板文件逐一解析Chart 的核心内容全部位于 charts/karpenter-crd/templates 目录共 5 个 CRD YAML。它们并非手写维护而是由controller-gen从 Go API 类型生成后同步进 Chart见下文“生成与维护流水线”一节。这 5 个 CRD 与 pkg/apis/crds 目录一一对应1.nodepools.karpenter.shNodePool文件charts/karpenter-crd/templates/karpenter.sh_nodepools.yaml所属 groupkarpenter.shkindNodePoolscopeCluster集群级资源additionalPrinterColumns定义了kubectl get nodepool的默认输出列NodeClass引用spec.template.spec.nodeClassRef.name、Nodes来自status.nodes、Readystatus.conditions、Age以及优先级为 1 的Weight、CPU、Memory列。NodePool 是 Karpenter 的核心抽象定义了节点模板、调度约束与自动扩缩行为其 Go API 类型定义在 pkg/apis/v1/nodepool_validation_cel_test.go 等文件中。2.nodeclaims.karpenter.shNodeClaim文件charts/karpenter-crd/templates/karpenter.sh_nodeclaims.yaml所属 groupkarpenter.shscopeClusteradditionalPrinterColumns输出Type节点实例类型标签node.kubernetes.io/instance-type、Capacitykarpenter.sh/capacity-type、Zonetopology.kubernetes.io/zone、Nodestatus.nodeName、Ready、Age方便一眼看出每台由 Karpenter 拉起的工作节点。NodeClaim 描述 Karpenter 实际创建的每个节点实例一个 NodePool 可以对应多个 NodeClaim。3.ec2nodeclasses.karpenter.k8s.awsEC2NodeClass文件charts/karpenter-crd/templates/karpenter.k8s.aws_ec2nodeclasses.yaml所属 groupkarpenter.k8s.awsAWS Provider 专属scopeCluster定义 AMI 族、子网、安全组、实例配置等 AWS 维度信息是 Karpenter on AWS 场景下 NodePool 的配套资源其状态与校验逻辑见 pkg/apis/v1/ec2nodeclass.go 与 pkg/apis/v1/ec2nodeclass_status.go。4.nodeoverlays.karpenter.shNodeOverlay文件charts/karpenter-crd/templates/karpenter.sh_nodeoverlays.yaml所属 groupkarpenter.shscopeCluster用于在节点上叠加额外的文件系统/目录挂载等自定义配置。5.capacitybuffers.autoscaling.x-k8s.ioCapacityBuffer文件charts/karpenter-crd/templates/autoscaling.x-k8s.io_capacitybuffers.yaml与前四个不同它属于 groupautoscaling.x-k8s.iokindCapacityBuffer且scope 为Namespaced命名空间级资源并定义了短名cbadditionalPrinterColumns输出Strategyspec.provisioningStrategy与引用的 PodTemplate 名称用于提前预留容量、应对突发扩缩。主 Chart charts/karpenter/Chart.yaml 的artifacthub.io/crds注解进一步印证了对外发布的 CRD 集合EC2NodeClassv1beta1、NodeClaimv1beta1、NodePoolv1beta1。四、唯一 Values 配置项additionalAnnotationskarpenter-crd是全仓库配置面最小的 Chart 之一仅暴露一个可配置项见 charts/karpenter-crd/values.yaml# -- Additional annotations for the custom resource definitions. additionalAnnotations: {}这是关联文档 Values 表中的唯一条目KeyTypeDefaultDescriptionadditionalAnnotationsobject{}Additional annotations for the custom resource definitions.4.1 作用原理additionalAnnotations的值会被注入到每一个CRD 的metadata.annotations下。以 charts/karpenter-crd/templates/karpenter.sh_nodepools.yaml 为例每个模板文件的开头都是相同的模板片段metadata: annotations: {{- with .Values.additionalAnnotations }} {{- toYaml . | nindent 4 }} {{- end }} controller-gen.kubebuilder.io/version: v0.20.1即如果设置了additionalAnnotationstoYaml会把整个对象以 4 空格缩进渲染进 annotations同时保留controller-gen.kubebuilder.io/version这一生成器溯源注解。这 5 个模板中的注入片段并非手工编写而是由 hack/mutation/crd_annotations.sh 脚本统一批量注入的——脚本遍历charts/karpenter-crd/templates/*.yaml用awk在每个 CRD 的annotations:节点后插入with模板块保证所有 CRD 行为一致。4.2 实际用法示例典型的应用场景是给 CRD 打上团队归属、合规或审计类注解例如helm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd \ --version v1.14.1 \ --namespace karpenter --create-namespace \ --set additionalAnnotations.teamplatform \ --set additionalAnnotations.example\.com/managedtrue等价于在 values 文件中写additionalAnnotations: team: platform example.com/managed: true安装完成后可用kubectl get crd nodepools.karpenter.sh -o jsonpath{.metadata.annotations}验证注解是否已注入。五、安装、升级与卸载5.1 安装 CRD Chartkarpenter-crd以 OCI 方式从 Karpenter 官方 Helm 仓库分发发布逻辑见 hack/release/common.shhelm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd \ --version v1.14.1 \ --namespace karpenter \ --create-namespace \ --set additionalAnnotations.teamplatform仓库内已发布的 Chart 压缩包同时保留了历史版本如 charts/karpenter-0.16.3.tgz 等可直接用helm template karpenter-crd ./charts/karpenter-crd --set additionalAnnotations.teamplatform在本地渲染校验后再应用。安装后建议确认 5 个 CRD 均处于ESTABLISHED状态kubectl get crd | grep -E karpenter|capacitybuffers5.2 与主 Chart 的配合与升级顺序主 Chart charts/karpenter 仍然在crds/目录下携带一份 CRD 副本见 charts/karpenter/crds。因此存在两条安装路径只用主 ChartCRD 由主 Chart 的crds/目录自动安装Helm 对crds/目录中的文件只做安装、不参与升级管理CRD 与控制器分离推荐先装karpenter-crd再装karpenter控制器 Chart。升级时必须先升级karpenter-crd再升级控制器确保新控制器引用的 schema 已就绪helm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd --version v1.14.1 --namespace karpenter helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version v1.14.1 --namespace karpenter5.3 卸载helm uninstall karpenter-crd --namespace karpenter注意卸载 CRD Chart 会删除集群中的 CRD 及对应 API 资源实例请确保集群中已无正在被 Karpenter 管理的 NodeClaim/NodePool 等对象。Karpenter 主 Chart 的卸载指引finalizer 清理等见 website/content/en/docs/troubleshooting.md。六、故障排查Helm invalid ownership metadata 冲突从旧版本0.26.1 之前迁移或此前通过kubectl replace手动安装过 CRD 的集群在安装karpenter-crd时可能报invalid ownership metadata错误根因是既有 CRD 缺少 Helm 的 ownership 标签/注解。官方排查指引位于 website/content/en/docs/troubleshooting.md对应两种报错各有一条修复命令。报错一label validation error: missing key app.kubernetes.io/managed-by: must be set to Helmkubectl label crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh app.kubernetes.io/managed-byHelm --overwrite报错二annotation validation error: missing key meta.helm.sh/release-namespace: must be set to karpenterKARPENTER_NAMESPACEkube-system kubectl annotate crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh meta.helm.sh/release-namekarpenter-crd --overwrite kubectl annotate crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh meta.helm.sh/release-namespace${KARPENTER_NAMESPACE} --overwrite执行完成后重新运行helm upgrade --install karpenter-crd ...即可。若希望保留kubectl replace的手动管理方式而不引入 Helm ownership可跳过本 Chart 直接使用 pkg/apis/crds 下的 CRD 文件。七、生成与维护流水线CRD 如何进入 Chartkarpenter-crd的模板文件不是人工维护的而是完整的代码生成流水线的产物理解这条链路有助于把握 CRD 与源码的对应关系Go API 类型如 pkg/apis/v1/ec2nodeclass.go、pkg/apis/v1/kubeletconfiguration.go经controller-gen生成 CRD产物先落入 pkg/apis/crdsMakefile 的verify目标执行cp pkg/apis/crds/* charts/karpenter-crd/templates把最新 CRD 同步进 Chart 的 templates 目录随后调用 hack/mutation/crd_annotations.sh 向每个模板注入additionalAnnotations的with渲染块最后README.md.gotmpl 配合 helm-docs 根据 Chart.yaml 与 values.yaml 自动生成并更新 charts/karpenter-crd/README.md即本仓库中该文档正文的来源。因此当你看到 README 中徽章版本、描述、Values 表时它们都直接由 Chart 元数据实时生成任何 Chart 配置变更都会在文档中同步反映这也是该文档信息量虽小但可信度高的原因。总结karpenter-crd是 Karpenter 集群安装中的“地基层”Chart它以 Helm 原生方式管理 5 个集群级/命名空间级 CRDNodePool、NodeClaim、EC2NodeClass、NodeOverlay、CapacityBuffer仅暴露additionalAnnotations一个配置项用于注入自定义注解升级时需先于控制器 Chart 执行从旧版本迁移遇到invalid ownership metadata时按官方 troubleshooting 指引补齐 Helm ownership 标签/注解即可。理解它的生成流水线controller-gen → pkg/apis/crds → Makefile 同步 → helm-docs 文档化就能在需要定制或排查 CRD 问题时快速定位到对应的 Go API 源码。【免费下载链接】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），仅供参考 Karpenter CRD Helm Chart 完全指南：karpenter-crd 的安装、配置与故障排查
Karpenter CRD Helm Chart 完全指南karpenter-crd 的安装、配置与故障排查【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-awskarpenter-crd 是 Karpenter 官方提供的独立 Helm Chart用于将 Karpenter 所需的全部自定义资源定义CRD以 Helm 原生的方式安装到 Kubernetes 集群。本文以仓库中 charts/karpenter-crd/README.md 为骨架结合 Chart 源码与生成流水线讲解该 Chart 的定位、唯一可配置项additionalAnnotations的用法、内置 CRD 清单、安装升级流程以及常见的 Helm ownership 冲突故障排查读完即可独立完成 CRD 的安装、定制与升级。一、karpenter-crd 是什么一个独立于控制器之外的 CRD Chart在 Karpenter 的早期版本中CRD 与控制器一起打包在同一个karpenterHelm Chart 中。随着 Karpenter 0.26.1 起引入karpenter-crdCRD 被拆分为独立 Chart 进行管理和发布其定位在 Chart 元数据中写得很清楚A Helm chart for Karpenter Custom Resource Definitions (CRDs).也就是说karpenter-crd只负责把 CRD 安装进集群本身不包含控制器 Deployment、ServiceAccount、RBAC 等运行时组件——那些仍由主karpenterChart见 charts/karpenter/Chart.yaml负责。这种拆分带来的直接好处是升级顺序可控先升级 CRD再滚动升级控制器避免新版本控制器引用旧版 CRD schema 导致校验失败职责清晰CRD 属于集群级别的全局资源与控制器命名空间内的资源解耦方便单独管理、审计与回滚可独立定制通过 values 注入 annotations满足企业内部的合规标签需求。二、Chart 元信息解读根据 charts/karpenter-crd/Chart.yaml该 Chart 的完整元信息如下字段值说明apiVersionv2Helm 3 Chart API 版本namekarpenter-crdChart 名称typeapplication应用类型 Chart区别于libraryversion1.14.1Chart 版本号与主karpenterChart 同步appVersion1.14.1被管理应用的版本即 Karpenter 版本keywordscluster、node、scheduler、autoscaling、lifecycle用于 Helm 仓库搜索的关键词注意version与appVersion均为1.14.1与主 Chart charts/karpenter/Chart.yaml 完全一致——这保证 CRD 与控制器以同一版本号发布、配套升级。README 顶部徽章Version / Type / AppVersion即由 helm-docs 从这些元数据自动生成其模板见 charts/karpenter-crd/README.md.gotmpl。此外charts/karpenter-crd/artifacthub-repo.yaml 中的ignore规则表明该 Chart 不会被发布到 ArtifactHub 公共仓库karpenter-crd被排除它的分发走 Helm OCI 仓库路径发布逻辑见 hack/release/common.sh 中的publishHelmChart ... karpenter-crd ...调用。三、内置 CRD 清单五个模板文件逐一解析Chart 的核心内容全部位于 charts/karpenter-crd/templates 目录共 5 个 CRD YAML。它们并非手写维护而是由controller-gen从 Go API 类型生成后同步进 Chart见下文“生成与维护流水线”一节。这 5 个 CRD 与 pkg/apis/crds 目录一一对应1.nodepools.karpenter.shNodePool文件charts/karpenter-crd/templates/karpenter.sh_nodepools.yaml所属 groupkarpenter.shkindNodePoolscopeCluster集群级资源additionalPrinterColumns定义了kubectl get nodepool的默认输出列NodeClass引用spec.template.spec.nodeClassRef.name、Nodes来自status.nodes、Readystatus.conditions、Age以及优先级为 1 的Weight、CPU、Memory列。NodePool 是 Karpenter 的核心抽象定义了节点模板、调度约束与自动扩缩行为其 Go API 类型定义在 pkg/apis/v1/nodepool_validation_cel_test.go 等文件中。2.nodeclaims.karpenter.shNodeClaim文件charts/karpenter-crd/templates/karpenter.sh_nodeclaims.yaml所属 groupkarpenter.shscopeClusteradditionalPrinterColumns输出Type节点实例类型标签node.kubernetes.io/instance-type、Capacitykarpenter.sh/capacity-type、Zonetopology.kubernetes.io/zone、Nodestatus.nodeName、Ready、Age方便一眼看出每台由 Karpenter 拉起的工作节点。NodeClaim 描述 Karpenter 实际创建的每个节点实例一个 NodePool 可以对应多个 NodeClaim。3.ec2nodeclasses.karpenter.k8s.awsEC2NodeClass文件charts/karpenter-crd/templates/karpenter.k8s.aws_ec2nodeclasses.yaml所属 groupkarpenter.k8s.awsAWS Provider 专属scopeCluster定义 AMI 族、子网、安全组、实例配置等 AWS 维度信息是 Karpenter on AWS 场景下 NodePool 的配套资源其状态与校验逻辑见 pkg/apis/v1/ec2nodeclass.go 与 pkg/apis/v1/ec2nodeclass_status.go。4.nodeoverlays.karpenter.shNodeOverlay文件charts/karpenter-crd/templates/karpenter.sh_nodeoverlays.yaml所属 groupkarpenter.shscopeCluster用于在节点上叠加额外的文件系统/目录挂载等自定义配置。5.capacitybuffers.autoscaling.x-k8s.ioCapacityBuffer文件charts/karpenter-crd/templates/autoscaling.x-k8s.io_capacitybuffers.yaml与前四个不同它属于 groupautoscaling.x-k8s.iokindCapacityBuffer且scope 为Namespaced命名空间级资源并定义了短名cbadditionalPrinterColumns输出Strategyspec.provisioningStrategy与引用的 PodTemplate 名称用于提前预留容量、应对突发扩缩。主 Chart charts/karpenter/Chart.yaml 的artifacthub.io/crds注解进一步印证了对外发布的 CRD 集合EC2NodeClassv1beta1、NodeClaimv1beta1、NodePoolv1beta1。四、唯一 Values 配置项additionalAnnotationskarpenter-crd是全仓库配置面最小的 Chart 之一仅暴露一个可配置项见 charts/karpenter-crd/values.yaml# -- Additional annotations for the custom resource definitions. additionalAnnotations: {}这是关联文档 Values 表中的唯一条目KeyTypeDefaultDescriptionadditionalAnnotationsobject{}Additional annotations for the custom resource definitions.4.1 作用原理additionalAnnotations的值会被注入到每一个CRD 的metadata.annotations下。以 charts/karpenter-crd/templates/karpenter.sh_nodepools.yaml 为例每个模板文件的开头都是相同的模板片段metadata: annotations: {{- with .Values.additionalAnnotations }} {{- toYaml . | nindent 4 }} {{- end }} controller-gen.kubebuilder.io/version: v0.20.1即如果设置了additionalAnnotationstoYaml会把整个对象以 4 空格缩进渲染进 annotations同时保留controller-gen.kubebuilder.io/version这一生成器溯源注解。这 5 个模板中的注入片段并非手工编写而是由 hack/mutation/crd_annotations.sh 脚本统一批量注入的——脚本遍历charts/karpenter-crd/templates/*.yaml用awk在每个 CRD 的annotations:节点后插入with模板块保证所有 CRD 行为一致。4.2 实际用法示例典型的应用场景是给 CRD 打上团队归属、合规或审计类注解例如helm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd \ --version v1.14.1 \ --namespace karpenter --create-namespace \ --set additionalAnnotations.teamplatform \ --set additionalAnnotations.example\.com/managedtrue等价于在 values 文件中写additionalAnnotations: team: platform example.com/managed: true安装完成后可用kubectl get crd nodepools.karpenter.sh -o jsonpath{.metadata.annotations}验证注解是否已注入。五、安装、升级与卸载5.1 安装 CRD Chartkarpenter-crd以 OCI 方式从 Karpenter 官方 Helm 仓库分发发布逻辑见 hack/release/common.shhelm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd \ --version v1.14.1 \ --namespace karpenter \ --create-namespace \ --set additionalAnnotations.teamplatform仓库内已发布的 Chart 压缩包同时保留了历史版本如 charts/karpenter-0.16.3.tgz 等可直接用helm template karpenter-crd ./charts/karpenter-crd --set additionalAnnotations.teamplatform在本地渲染校验后再应用。安装后建议确认 5 个 CRD 均处于ESTABLISHED状态kubectl get crd | grep -E karpenter|capacitybuffers5.2 与主 Chart 的配合与升级顺序主 Chart charts/karpenter 仍然在crds/目录下携带一份 CRD 副本见 charts/karpenter/crds。因此存在两条安装路径只用主 ChartCRD 由主 Chart 的crds/目录自动安装Helm 对crds/目录中的文件只做安装、不参与升级管理CRD 与控制器分离推荐先装karpenter-crd再装karpenter控制器 Chart。升级时必须先升级karpenter-crd再升级控制器确保新控制器引用的 schema 已就绪helm upgrade --install karpenter-crd oci://public.ecr.aws/karpenter/karpenter-crd --version v1.14.1 --namespace karpenter helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version v1.14.1 --namespace karpenter5.3 卸载helm uninstall karpenter-crd --namespace karpenter注意卸载 CRD Chart 会删除集群中的 CRD 及对应 API 资源实例请确保集群中已无正在被 Karpenter 管理的 NodeClaim/NodePool 等对象。Karpenter 主 Chart 的卸载指引finalizer 清理等见 website/content/en/docs/troubleshooting.md。六、故障排查Helm invalid ownership metadata 冲突从旧版本0.26.1 之前迁移或此前通过kubectl replace手动安装过 CRD 的集群在安装karpenter-crd时可能报invalid ownership metadata错误根因是既有 CRD 缺少 Helm 的 ownership 标签/注解。官方排查指引位于 website/content/en/docs/troubleshooting.md对应两种报错各有一条修复命令。报错一label validation error: missing key app.kubernetes.io/managed-by: must be set to Helmkubectl label crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh app.kubernetes.io/managed-byHelm --overwrite报错二annotation validation error: missing key meta.helm.sh/release-namespace: must be set to karpenterKARPENTER_NAMESPACEkube-system kubectl annotate crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh meta.helm.sh/release-namekarpenter-crd --overwrite kubectl annotate crd ec2nodeclasses.karpenter.k8s.aws nodepools.karpenter.sh nodeclaims.karpenter.sh nodeoverlays.karpenter.sh meta.helm.sh/release-namespace${KARPENTER_NAMESPACE} --overwrite执行完成后重新运行helm upgrade --install karpenter-crd ...即可。若希望保留kubectl replace的手动管理方式而不引入 Helm ownership可跳过本 Chart 直接使用 pkg/apis/crds 下的 CRD 文件。七、生成与维护流水线CRD 如何进入 Chartkarpenter-crd的模板文件不是人工维护的而是完整的代码生成流水线的产物理解这条链路有助于把握 CRD 与源码的对应关系Go API 类型如 pkg/apis/v1/ec2nodeclass.go、pkg/apis/v1/kubeletconfiguration.go经controller-gen生成 CRD产物先落入 pkg/apis/crdsMakefile 的verify目标执行cp pkg/apis/crds/* charts/karpenter-crd/templates把最新 CRD 同步进 Chart 的 templates 目录随后调用 hack/mutation/crd_annotations.sh 向每个模板注入additionalAnnotations的with渲染块最后README.md.gotmpl 配合 helm-docs 根据 Chart.yaml 与 values.yaml 自动生成并更新 charts/karpenter-crd/README.md即本仓库中该文档正文的来源。因此当你看到 README 中徽章版本、描述、Values 表时它们都直接由 Chart 元数据实时生成任何 Chart 配置变更都会在文档中同步反映这也是该文档信息量虽小但可信度高的原因。总结karpenter-crd是 Karpenter 集群安装中的“地基层”Chart它以 Helm 原生方式管理 5 个集群级/命名空间级 CRDNodePool、NodeClaim、EC2NodeClass、NodeOverlay、CapacityBuffer仅暴露additionalAnnotations一个配置项用于注入自定义注解升级时需先于控制器 Chart 执行从旧版本迁移遇到invalid ownership metadata时按官方 troubleshooting 指引补齐 Helm ownership 标签/注解即可。理解它的生成流水线controller-gen → pkg/apis/crds → Makefile 同步 → helm-docs 文档化就能在需要定制或排查 CRD 问题时快速定位到对应的 Go API 源码。【免费下载链接】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），仅供参考