Karpenter Helm Chart 完整指南：安装、签名验证与 Values 配置详解（karpenter-provider-aws 1.14.1）

Karpenter Helm Chart 完整指南安装、签名验证与 Values 配置详解karpenter-provider-aws 1.14.1【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws导读本文以 charts/karpenter/README.md 为骨架完整讲解 karpenter-provider-aws 官方 Helm Chart 的安装流程、Cosign 签名验证机制以及全部 Values 配置项的语义与默认值并对照仓库内 values.yaml 与 deployment.yaml 等模板源码说明每个配置项最终如何映射为 Deployment 环境变量、RBAC 规则与调度策略。读完本文你将能够独立完成 Karpenter 在生产集群上的安装、安全校验、参数调优与故障排查。一、Chart 概览这是什么、装了什么charts/karpenter是 karpenter-provider-aws 官方维护的 Helm Chart用于在 Kubernetes 集群中部署 Karpenter 控制器。从 Chart.yaml 可以看到其核心元数据apiVersion: v2 name: karpenter description: A Helm chart for Karpenter, an open-source node provisioning project built for Kubernetes. type: application version: 1.14.1 appVersion: 1.14.1 keywords: - cluster - node - scheduler - autoscaling - lifecycle当前 Chart 版本与 AppVersion 均为1.14.1。Chart 的annotations中还声明了随 Chart 一同交付的三类 CRD见 crds 目录EC2NodeClassec2nodeclasses.karpenter.k8s.awsv1beta1定义 AWS 节点类封装子网、安全组、AMI、实例配置等 AWS 侧参数NodeClaimnodeclaims.karpenter.shv1beta1描述 Karpenter 为运行 Pod 而创建的单台节点实例NodePoolnodepools.karpenter.shv1beta1描述调度约束、容量类型与中断策略是用户日常接触最多的 API。安装后Chart 会创建以下 Kubernetes 资源对应 templates 目录模板文件生成的资源deployment.yamlDeployment默认 2 副本service.yamlClusterIP Servicehttp-metrics端口serviceaccount.yamlServiceAccountclusterrole.yamlClusterRole ClusterRoleBindingEC2NodeClass 读写clusterrole-core.yamlClusterRole-core BindingNodePool/NodeClaim/Node 等核心读写aggregate-clusterrole.yaml-admin聚合 ClusterRole供管理员操作 CRDpoddisruptionbudget.yamlPodDisruptionBudget默认maxUnavailable: 1servicemonitor.yamlServiceMonitor可选默认关闭二、安装 Chart标准安装命令逐段拆解README 给出的标准安装命令如下helm upgrade --install --namespace karpenter --create-namespace \ karpenter oci://public.ecr.aws/karpenter/karpenter \ --version 1.14.1 \ --set serviceAccount.annotations.eks\.amazonaws\.com/role-arn${KARPENTER_IAM_ROLE_ARN} \ --set settings.clusterName${CLUSTER_NAME} \ --set settings.interruptionQueue${CLUSTER_NAME} \ --wait对命令各组成部分做逐段解释helm upgrade --install使用升级语义执行安装——Release 不存在时创建存在时升级保证幂等后续升级版本也复用同一条命令--namespace karpenter --create-namespace在karpenter命名空间部署若命名空间不存在则自动创建oci://public.ecr.aws/karpenter/karpenterChart 以 OCI 镜像形式发布在 AWS 公共 ECR 上Helm 3.8 原生支持 OCI 仓库协议无需额外插件--version 1.14.1锁定 Chart 版本--set serviceAccount.annotations.eks\.amazonaws\.com/role-arn...为控制器 ServiceAccount 注入 IRSA 注解将 AWS IAM 角色与 Pod 身份绑定注意eks.amazonaws.com中的点需用\.转义避免 Helm 将其解析为嵌套层级。该注解最终由 serviceaccount.yaml 模板渲染到 ServiceAccount 上--set settings.clusterName...必填项。查看 deployment.yaml 第 152-153 行可以发现CLUSTER_NAME环境变量使用了required函数- name: CLUSTER_NAME value: {{ required Chart cannot be installed without a valid settings.clusterName! (tpl .Values.settings.clusterName .) }}也就是说未设置settings.clusterName时 Chart 会直接渲染失败这是安装的唯一硬性必填参数--set settings.interruptionQueue...指定处理 EC2 中断事件的 SQS 队列名通常与集群同名用于启用中断处理能力--wait等待 Deployment 就绪后才返回便于在 CI/CD 中确认安装成功。三、安装前校验用 Cosign 验证 OCI Chart 签名README 强调OCI Chart 在发布流程中由 Cosign 签名安装前可先验证签名完整性防止供应链攻击。验证命令cosign verify public.ecr.aws/karpenter/karpenter:1.14.1 \ --certificate-oidc-issuerhttps://token.actions.githubusercontent.com \ --certificate-identity-regexphttps://github\.com/aws/karpenter-provider-aws/\.github/workflows/release\.yaml. \ --certificate-github-workflow-repositoryaws/karpenter-provider-aws \ --certificate-github-workflow-nameRelease \ --certificate-github-workflow-refrefs/tags/v1.14.1 \ --annotations version1.14.1各参数含义--certificate-oidc-issuer签名证书由 GitHub Actions 的 OIDC 令牌签发--certificate-identity-regexp签发身份必须是aws/karpenter-provider-aws仓库release.yaml工作流--certificate-github-workflow-*进一步约束工作流仓库、名称与触发 ref必须为对应的v1.14.1tag--annotations version1.14.1校验签名所附的版本注解与目标版本一致。从仓库内的发布脚本 hack/release/release.sh 与 hack/release/snapshot.sh 可以看出Chart 打包、签名、推送均在 CI 发布流水线中完成。验证通过后即可放心安装。四、Values 配置全解上元数据、镜像与调度本节完整覆盖 README 中的 Values 表格并结合 values.yaml 与模板源码讲解每个配置项的落点。建议以helm show values oci://public.ecr.aws/karpenter/karpenter --version 1.14.1获取与当前版本完全一致的完整 Values 文件对照使用。4.1 命名与通用元数据Key类型默认值说明nameOverridestring覆盖 Chart 计算出的名称影响app.kubernetes.io/name标签fullnameOverridestring覆盖 Chart 计算出的完整名称Deployment/Service 等资源名additionalLabelsobject{}追加到所有资源metadata.labels的标签additionalAnnotationsobject{}追加到所有资源metadata.annotations的注解podLabelsobject{}仅追加到 Pod 的标签podAnnotationsobject{}仅追加到 Pod 的注解名称计算逻辑实现在 _helpers.tpl 的karpenter.fullname模板中名称会按 DNS 规范截断至 63 字符若 Release 名已包含 Chart 名则直接复用 Release 名否则拼接为release-karpenter。additionalLabels/additionalAnnotations会被注入到几乎所有模板Deployment、Service、ServiceAccount、ClusterRole、PDB、ServiceMonitor 等的 metadata 上。4.2 镜像与拉取Key类型默认值说明controller.image.repositorystringpublic.ecr.aws/karpenter/controller控制器镜像仓库controller.image.tagstring1.14.1控制器镜像 Tagcontroller.image.digeststringsha256:7231...ae23控制器镜像 SHA256 DigestimagePullPolicystringIfNotPresent镜像拉取策略imagePullSecretslist[]私有仓库拉取凭据_helpers.tpl 中的karpenter.controller.image模板决定了镜像引用格式当配置了digest时渲染为repository:tagsha256:digest不可变引用安全性最高未配置 digest 时退化为repository:tag。当前版本默认携带 digest保证每次部署拉取的都是经过校验的同一镜像内容。4.3 副本数与更新策略Key类型默认值说明replicasint2控制器副本数默认双副本保障高可用revisionHistoryLimitint10保留的旧 ReplicaSet 数量用于回滚strategyobject{rollingUpdate:{maxUnavailable:1}}滚动更新策略默认最多允许 1 个副本不可用保证升级期间始终有控制器在服务podDisruptionBudget.namestringkarpenterPDB 名称podDisruptionBudget.maxUnavailableint1自愿中断时最多允许 1 个副本不可用PDB 由 poddisruptionbudget.yaml 渲染且 _helpers.tpl 中的karpenter.pdb.apiVersion会根据集群版本自动选择policy/v1Kubernetes ≥ 1.21或policy/v1beta1无需手动适配。4.4 调度约束Key类型默认值说明nodeSelectorobject{kubernetes.io/os:linux}将控制器调度到 Linux 节点affinityobject见下节点亲和 Pod 反亲和topologySpreadConstraintslist[{maxSkew:1,topologyKey:topology.kubernetes.io/zone,whenUnsatisfiable:DoNotSchedule}]跨可用区拓扑分布提高控制器韧性tolerationslist[{key:CriticalAddonsOnly,operator:Exists}]容忍关键插件污点priorityClassNamestringsystem-cluster-critical系统关键优先级保证控制器优先调度schedulerNamestringdefault-scheduler指定调度器hostNetworkboolfalse使用自定义 CNI 时需要设为truednsPolicystringClusterFirstPod DNS 策略dnsConfigobject{}Pod DNS 配置如ndotsterminationGracePeriodSecondsstringnil覆盖 Pod 默认终止宽限期默认affinity非常关键它保证 Karpenter 控制器不会被 Karpenter 自身纳管避免自举死锁affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: karpenter.sh/nodepool operator: DoesNotExist podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostnamenodeAffinity要求节点不携带karpenter.sh/nodepool标签即控制器只能落在静态节点池如托管节点组、自管节点上podAntiAffinity按主机名分散两个副本避免同机故障导致控制器整体宕机topologySpreadConstraints进一步要求两个副本跨可用区分布maxSkew: 1、DoNotSchedule。需要特别说明的是 _helpers.tpl 中patchAffinity/patchTopologySpreadConstraints的实现如果用户自定义的亲和性/拓扑约束未显式指定labelSelector模板会自动注入由app.kubernetes.io/name与app.kubernetes.io/instance构成的matchLabels选择器见 deployment.yaml 第 262-273 行的调用注释因此用户无需手动编写选择器即可获得正确的 Pod 匹配关系。4.5 安全上下文Key类型默认值说明podSecurityContextobject{fsGroup:65532,seccompProfile:{type:RuntimeDefault}}Pod 级安全上下文controller.securityContext.appArmorProfileobject{}控制器容器 AppArmor 配置controller.securityContext.seLinuxOptionsobject{}控制器容器 SELinux 选项controller.securityContext.seccompProfileobject{}控制器容器 Seccomp 配置除可配置项外deployment.yaml 第 65-74 行为控制器容器硬编码了一套不可覆盖的加固基线securityContext: privileged: false allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 65532 runAsGroup: 65532 capabilities: drop: - ALL即以非 root 用户UID/GID 65532运行、只读根文件系统、禁用特权提升并丢弃全部 Linux capabilities符合生产环境最小权限原则。五、Values 配置全解中服务账户、RBAC 与控制器容器5.1 ServiceAccount 与 RBACKey类型默认值说明serviceAccount.createbooltrue是否创建 ServiceAccountserviceAccount.namestring自定义名称为空且createtrue时由 fullname 模板生成serviceAccount.annotationsobject{}ServiceAccount 注解典型用途是 IRSA role-arn 注解additionalClusterRoleRuleslist[]追加到核心 ClusterRole 的额外 RBAC 规则Chart 默认创建两类 ClusterRolefullnameclusterrole.yaml仅包含对karpenter.k8s.aws/ec2nodeclasses的读写权限绑定到控制器 ServiceAccountfullname-coreclusterrole-core.yaml包含 Karpenter 核心运行所需的全部权限例如读nodepools、nodeclaims、nodeoverlays、capacitybuffers、pods、nodes、persistentvolumes、daemonsets、deployments、replicasets、statefulsets、poddisruptionbudgets、storageclasses、csinodes、volumeattachments等写nodeclaims增删改、nodespatch/delete/update、pods/evictioncreate、podsdelete、eventscreate/patch 等。用户自定义的additionalClusterRoleRules会通过{{- with .Values.additionalClusterRoleRules }}追加到-coreClusterRole 的 rules 中用于扩展控制器权限如访问自建 CRD。此外 aggregate-clusterrole.yaml 还会生成一个带rbac.authorization.k8s.io/aggregate-to-admin: true标签的fullname-adminClusterRole授予对nodepools/nodeclaims/ec2nodeclasses的完整读写自动聚合进集群admin角色方便集群管理员直接操作 Karpenter 资源。5.2 控制器容器Key类型默认值说明controller.containerNamestringcontroller容器名controller.envlist[]追加环境变量controller.envFromlist[]从 ConfigMap/Secret 注入环境变量controller.extraVolumeMountslist[]控制器容器额外挂载controller.sidecarContainerlist[]附加 sidecar 容器定义controller.sidecarVolumeMountslist[]sidecar 的额外挂载在extraVolumeMounts之上叠加controller.resourcesobject{}控制器资源 requests/limitscontroller.metrics.portint8080metrics 端口controller.healthProbe.portint8081健康探针端口资源配额注意事项values.yaml 中明确注释建议不预设默认资源把资源大小交给用户按集群规模决策。但 deployment.yaml 第 116-127 行会自动注入两个基于资源的自适应环境变量- name: CPU_REQUESTS valueFrom: resourceFieldRef: containerName: {{ include karpenter.controller.containerName . }} divisor: 1m resource: requests.cpu - name: MEMORY_LIMIT valueFrom: resourceFieldRef: containerName: {{ include karpenter.controller.containerName . }} divisor: 0 resource: limits.memory即 Karpenter 会读取自身requests.cpu与limits.memory来估算可管理的节点/资源规模。因此为控制器设置合理的 CPU requests 与内存 limits 不仅关乎稳定性还会直接影响其调度容量估算生产环境建议显式配置例如controller: resources: requests: cpu: 1 memory: 1Gi limits: cpu: 1 memory: 1Gi探针方面模板固定配置了livenessProbe/healthzinitialDelay 30s与readinessProbe/readyzinitialDelay 5s均走http端口即healthProbe.port。六、Values 配置全解下全局 settings 与 Feature Gatessettings是 Chart 中信息量最大的配置块对应 README 中的 Global Settings to configure Karpenter。这些值最终几乎全部映射为 Deployment 环境变量见 deployment.yaml 第 91-205 行并在控制器启动时由 pkg/operator/options/options.go 解析为运行时参数。以下按功能分组详解。6.1 集群接入Key默认值说明settings.clusterName必填集群名称缺失时 Chart 渲染失败settings.clusterEndpoint集群 API 端点为空时启动阶段自动发现仅 EKSsettings.clusterCABundle供被纳管节点使用的集群 CA 证书为空时取控制器自身与 API Server 通信的 TLS 配置settings.eksControlPlanefalse置true表示集群使用 EKS 控制面Karpenter 通过 DescribeCluster API 发现集群信息settings.isolatedVPCfalse置true表示无法访问未配置 VPC Endpoint 的 AWS 服务同时禁用 AWS 价格端点查询settings.reservedENIs0从 max-pods 与 kube-reserved 计算中排除的预留 ENI 数量常用于 VPC CNI 自定义网络场景settings.enableZonalShiftfalse置true时 Karpenter 在做 NodeClaim 时尊重 AWS Zonal Shift 状态6.2 批量调度BatchingKey默认值说明settings.batchMaxDuration10s单个批处理窗口的最大时长窗口越长一次可考虑的 Pod 越多通常产生更少但更大的节点settings.batchIdleDuration1s批处理窗口的空闲阈值若在maxDuration内持续有新 Pod 到达则窗口延续若 Pod 到达速度慢于该阈值则分批处理Karpenter 通过批处理窗口聚合短时间内的调度请求权衡调度延迟与节点利用率。生产实践中若工作负载突发性强可适当增大batchMaxDuration换取更大批量若对冷启动延迟敏感则保持默认或调小。6.3 调度策略Key默认值说明settings.minValuesPolicyStrictKarpenter 调度器对待 NodePool 中 min values 的策略Strict无法满足时调度失败或BestEffort无法满足时放宽 min 值settings.preferencePolicyRespect对待偏好的策略Respect尊重 preferredDuringScheduling 亲和性与 ScheduleAnyways 拓扑约束或Ignore忽略settings.ignoreDRARequeststrue调度模拟时忽略 Pod 的 DRADynamic Resource Allocation请求6.4 中断处理Key默认值说明settings.interruptionQueue处理 EC2 中断事件的 SQS 队列名为空则中断处理完全禁用。启用后需要为控制器 ServiceAccount 授予额外 IAM 权限文档有专门说明6.5 数据刷新频率API 成本与新鲜度权衡Key默认值说明settings.amiRefreshInterval1m从 EC2 刷新 AMI 数据的频率调大减少 DescribeImages 调用但会增大 AMI 发现与漂移检测的滞后最小 1msettings.subnetRefreshInterval1m刷新子网数据频率同理最小 1msettings.securityGroupRefreshInterval1m刷新安全组数据频率同理最小 1m以amiRefreshInterval为例pkg/operator/options/options.go 第 72 行将其绑定为--ami-refresh-interval参数fs.DurationVar(o.AMIRefreshInterval, ami-refresh-interval, env.WithDefaultDuration(AMI_REFRESH_INTERVAL, time.Minute), How often Karpenter refreshes AMI data from EC2. ... Must be at least 1m.)即在控制器代码层面同样校验了最小 1 分钟的下限Chart 默认值与环境变量AMI_REFRESH_INTERVAL完全对齐。这三个间隔参数适合在 AWS API 配额紧张的大规模集群中适当调大。6.6 资源估算Key默认值说明settings.vmMemoryOverheadPercent0.075从所有实例类型总内存中扣除的 VM 内存开销百分比0.075 7.5%。对应 options.go 第 67 行的--vm-memory-overhead-percent参数用于更准确地估算实例可用内存6.7 可观测性开关Key默认值说明settings.disableClusterStateObservabilityfalse置true关闭集群状态 metrics 与事件settings.disableDryRunfalse置true关闭 EC2NodeClass 的 dry-run 校验6.8 日志配置Key类型默认值说明logLevelstringinfo全局日志级别logOutputPathslist[stdout]日志输出路径logErrorOutputPathslist[stderr]错误日志输出路径对应渲染为LOG_LEVEL、LOG_OUTPUT_PATHS、LOG_ERROR_OUTPUT_PATHS环境变量多个路径以逗号拼接。排查问题时可将logLevel临时调为debug获取更详细日志。6.9 Feature Gates特性开关Feature Gates 遵循 Kubernetes 官方的 Alpha/Beta/GA 演进机制deployment.yaml 第 128-131 行会将其统一渲染为FEATURE_GATES与AWS_FEATURE_GATES环境变量- name: FEATURE_GATES value: ReservedCapacity{{ .Values.settings.featureGates.reservedCapacity }},SpotToSpotConsolidation{{ .Values.settings.featureGates.spotToSpotConsolidation }},NodeRepair{{ .Values.settings.featureGates.nodeRepair }},NodeOverlay{{ .Values.settings.featureGates.nodeOverlay }},StaticCapacity{{ .Values.settings.featureGates.staticCapacity }},CapacityBuffer{{ .Values.settings.featureGates.capacityBuffer }} - name: AWS_FEATURE_GATES value: NodeClassCEL{{ .Values.settings.awsFeatureGates.nodeClassCEL }}各开关的成熟度与默认值如下Key状态默认值功能settings.featureGates.reservedCapacityBETAtrue原生按需容量预留On-Demand Capacity Reservation支持settings.featureGates.spotToSpotConsolidationALPHAfalse单节点与多节点整合时的 Spot 替换整合settings.featureGates.nodeRepairALPHAfalse节点修复settings.featureGates.nodeOverlayALPHAfalse使用 NodeOverlay 影响调度决策settings.featureGates.staticCapacityALPHAfalse静态容量预置settings.featureGates.capacityBufferALPHAfalseCapacityBuffer预置备用容量settings.awsFeatureGates.nodeClassCELALPHAfalse对 EC2NodeClass 启用 CEL 校验注意对应 CRD 与实现已随 Chart 一并交付capacityBuffersautoscaling.x-k8s.io、nodeoverlayskarpenter.sh等 CRD 均可在 charts/karpenter/crds 中看到。Alpha 特性在生产启用前应充分评估稳定性风险。七、监控与告警ServiceMonitor 与指标端口Key类型默认值说明serviceMonitor.enabledboolfalse是否创建 ServiceMonitor需集群已安装 Prometheus OperatorserviceMonitor.additionalLabelsobject{}ServiceMonitor 附加标签用于被 Prometheus 的 serviceMonitorSelector 选中serviceMonitor.relabelingslist[]抓取前 relabel 配置serviceMonitor.metricRelabelingslist[]抓取后 metric relabel 配置serviceMonitor.sampleLimitstringnil单次抓取的样本数上限超过即视为抓取失败0 表示不限serviceMonitor.endpointConfigobject{}http-metrics端点的附加配置不可用于新增端点从 servicemonitor.yaml 可以看到ServiceMonitor 仅在serviceMonitor.enabledtrue且集群存在monitoring.coreos.com/v1API 时才会渲染并指向http-metrics端口的/metrics路径。启用 Prometheus 抓取的典型配置serviceMonitor: enabled: true additionalLabels: release: prometheus sampleLimit: 100000控制器 metrics 端口默认 8080同时被 service.yaml 暴露为 ClusterIP Service 的http-metrics端口Karpenter 官方文档与 website 站点的监控指南中也大量使用该端点如karpenter_nodes_allocatable、karpenter_pods_state等指标。八、自定义场景示例从最小改动到生产级配置8.1 标准生产安装含 IRSA、中断队列、监控helm upgrade --install --namespace karpenter --create-namespace \ karpenter oci://public.ecr.aws/karpenter/karpenter \ --version 1.14.1 \ --set serviceAccount.annotations.eks\.amazonaws\.com/role-arn${KARPENTER_IAM_ROLE_ARN} \ --set settings.clusterName${CLUSTER_NAME} \ --set settings.clusterEndpoint${CLUSTER_ENDPOINT} \ --set settings.interruptionQueue${CLUSTER_NAME} \ --set serviceMonitor.enabledtrue \ --set controller.resources.requests.cpu1 \ --set controller.resources.requests.memory1Gi \ --set controller.resources.limits.cpu1 \ --set controller.resources.limits.memory1Gi \ --wait8.2 使用自定义 Values 文件管理复杂配置参数较多时建议维护独立 values 文件# custom-values.yaml settings: clusterName: my-cluster interruptionQueue: my-cluster batchMaxDuration: 30s batchIdleDuration: 2s amiRefreshInterval: 5m subnetRefreshInterval: 5m securityGroupRefreshInterval: 5m serviceAccount: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/karpenter-controller serviceMonitor: enabled: true controller: resources: requests: cpu: 1 memory: 1Gi limits: cpu: 1 memory: 1Gi然后执行helm upgrade --install --namespace karpenter --create-namespace karpenter oci://public.ecr.aws/karpenter/karpenter --version 1.14.1 -f custom-values.yaml --wait。8.3 非 EKS 或特殊网络环境自定义 CNI需同时设置hostNetwork: true让控制器 Pod 直接使用宿主机网络隔离 VPC无公网端点设置settings.isolatedVPC: trueKarpenter 将不再查询 AWS 价格端点非 EKS 控制面显式提供settings.clusterEndpoint与settings.clusterCABundle并保持settings.eksControlPlane: false。九、安装后的验证与排障9.1 验证清单Pod 状态kubectl -n karpenter get pods -l app.kubernetes.io/namekarpenter确认两个副本均为Running且Ready就绪探针kubectl -n karpenter port-forward svc/karpenter 8081:8081后访问http://localhost:8081/readyz应返回 200CRD 就位kubectl get crd nodepools.karpenter.sh nodeclaims.karpenter.sh ec2nodeclasses.karpenter.k8s.aws日志kubectl -n karpenter logs deployment/karpenter -c controller正常启动日志中会包含集群发现、版本探测等信息Metricscurl localhost:8080/metrics经 port-forward应输出 Prometheus 格式指标。9.2 常见问题Chart cannot be installed without a valid settings.clusterName!未设置settings.clusterName这是 Chart 的硬校验补上即可控制器被调度到 Karpenter 纳管的节点检查是否覆盖了默认affinity中的karpenter.sh/nodepool: DoesNotExist约束或 NodePool 是否误用了会选中控制器的标签中断处理不生效确认settings.interruptionQueue已设置且 SQS 队列、IAM 权限Controller ServiceAccount 对应角色均已正确配置升级回滚得益于默认revisionHistoryLimit: 10与strategy.rollingUpdate.maxUnavailable: 1可通过helm rollback karpenter revision平滑回滚升级过程中始终有至少一个控制器副本在线。十、总结Karpenter 官方 Helm Chart 将控制器部署的每个环节——镜像与签名、RBAC、调度亲和、安全加固、监控暴露与运行时参数——都抽象为结构清晰的 Values 配置。掌握 charts/karpenter/README.md 与 values.yaml 中的每一项语义再结合 deployment.yaml 的渲染逻辑与 pkg/operator/options/options.go 的参数解析就能在任意 EKS/自建集群上精准安装、安全升级并持续调优 Karpenter。需要进一步深入时可继续阅读仓库内的 v1 API 设计文档、NodePool 示例 以及 EC2NodeClass 定义形成从装好到用好的完整链路。【免费下载链接】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），仅供参考