karpenter-provider-aws v1.12 实例类型参考指南：标签体系、可调度资源与 NodePool 选型实践-港品优选

karpenter-provider-aws v1.12 实例类型参考指南：标签体系、可调度资源与 NodePool 选型实践

【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws

Karpenter 的核心能力之一是"按实例类型自动选型"：它把 AWS EC2 实例的硬件规格翻译成一组标准化的 Kubernetes 标签（Labels）与可调度资源（Resources），让调度器可以在数百种实例类型之间自由择优。本文以仓库中 v1.12 版本的 instance-types.md 为骨架，完整解读这份由代码自动生成的实例类型权威清单：它覆盖了 165 个实例族、1200 余种实例类型，包含了每种实例在扣除 Karpenter 预留开销之后的真实可调度资源，以及可供 NodePool 编写 requirements 使用的全部标签。读完本文，你将能够准确读懂表格中每个数字的含义，并据此在 NodePool 中写出精确、可维护的实例类型筛选规则。

文档定位：一份由生成器维护的权威数据源

website/content/en/v1.12/reference/instance-types.md是一份自动生成的文档，文件开头明确标注了它的出处：。这意味着你不需要手工维护这 3 万多行的数据——只要运行 hack/docs/instancetypes_gen/main.go 中的生成器，它就会连接 AWS EC2 API，把最新的实例类型数据重新渲染成 Markdown 表格。

从生成器源码看，文档数据的完整链路是：

依次在us-east-1、us-east-2、us-west-2三个区域加载 AWS 配置（生成器第 131 行），跨区域取实例类型的并集，保证文档覆盖面最大化；
构造一个 fake 的EC2NodeClass（AMI 选择al2023@latest，子网选择全部），通过instanceTypeProvider.List()拿到完整的实例类型列表（生成器第 165-193 行）；
按实例族（family）聚合、按 CPU 与内存排序后，输出每个实例类型的标签表与资源表；
输出前会剔除topology.kubernetes.io/zone、topology.k8s.aws/zone-id、karpenter.sh/capacity-type这三个随区域/容量类型变化的标签（生成器第 212-215 行），只保留全局稳定的属性。

因此这份文档实际上就是 Karpenter 运行时实例类型数据的一次"快照"，与控制器内部 pkg/providers/instancetype/instancetype.go 中DefaultProvider计算出来的数据同源同构，阅读价值与运行时的真实行为完全一致。

数值口径：三个必须知道的假设

文档开头有一段容易被忽略的说明，它决定了表中所有数字的含义：

The values provided below are the resources availablewith some assumptionsandafter the instance overhead has been subtracted:
blockDeviceMappingsare not configured
amiFamilyis set toAL2023

拆开解读：

已经扣除了实例开销（overhead）：表中cpu、memory等资源数量是it.Capacity减去it.Overhead.Total()之后的净值（生成器第 244 行）。Karpenter 会为系统组件（kubelet、容器运行时、系统保留等）预留一部分资源，因此cpu显示为940m而不是完整的1核，memory显示为1392Mi而不是2048Mi。这是真正可供 Pod 调度使用的量。
未配置blockDeviceMappings：即使用 EC2NodeClass 默认的根卷配置，所以所有实例的ephemeral-storage都统一显示为17Gi（AL2023 默认根卷规格下的可用量）。如果你在 EC2NodeClass 里配置了自定义块设备映射或实例存储策略，实际数值会不同。
amiFamily为AL2023：不同 AMI 家族（AL2、Bottlerocket、Windows 等）的开销计算方式不同，文档统一以 AL2023 为基准。

标签体系：用 Karpenter 标签描述 EC2 硬件

每个实例类型都会输出一组karpenter.k8s.aws/*标签，它们的键名统一定义在 pkg/apis/v1/labels.go 中，并在程序初始化时注册为karpv1.WellKnownLabels（labels.go 第 31-64 行），即"预定义、可直接用于 NodePool requirements 的合法标签"。以下是从源码和文档中提取的完整标签清单：

其中instance-category、instance-family、instance-generation、instance-size、instance-cpu、instance-memory、instance-cpu-manufacturer、instance-cpu-sustained-clock-speed-mhz、instance-hypervisor、instance-ebs-bandwidth、instance-network-bandwidth、instance-encryption-in-transit-supported、instance-capability-flex、instance-local-nvme等由 labels.go 第 144-172 行定义。注意：文档中instance-memory与instance-cpu是整数型规格值（如2048MiB），而资源表中的memory是扣除开销后的可调度量（如1392Mi），两者口径不同，使用时要区分。

另外，labels.go 第 66 行为instance-tenancy注册了合法的取值集合（default/dedicated），说明部分标签具有枚举约束，NodePool 校验会据此拒绝非法值。

资源清单：扣除开销后真正可调度的容量

每个实例类型都会输出一张资源表，资源名集合与 labels.go 第 87-99 行定义的WellKnownResources一致。以文档开头的a1.medium为例：

| Resource | Quantity | |--|--| | cpu | 940m | | ephemeral-storage | 17Gi | | memory | 1392Mi | | pods | 8 | | vpc.amazonaws.com/pod-eni | 10 |

各资源含义如下：

cpu：可调度 CPU，单位m（千分之一核）。a1.medium显示940m，说明 1 核中约 60m 被开销占用；c5.24xlarge显示95690m（96 核净值）。
memory：可调度内存，单位Mi。注意这是扣除 overhead 后的净值，例如a1.medium规格内存标签为2048MiB，资源表为1392Mi。
ephemeral-storage：临时存储。生成器对它的输出做了特殊处理，统一以BinarySI（即Gi）格式化（生成器第 268-271 行）。在"未配置 blockDeviceMappings"的假设下恒为17Gi。
pods：该实例类型可承载的最大 Pod 数量（受 ENI 数量与实例规格共同约束）。例如a1.medium为 8，c5.18xlarge为 737。
vpc.amazonaws.com/pod-eni：AWS VPC CNI 的辅助 ENI 数量，文档中约 1051 处出现该资源。这是使用 VPC CNI 时 Pod 密度的重要约束。
vpc.amazonaws.com/efa：弹性网卡适配器（EFA）数量，出现在支持 EFA 的实例类型（如部分 c5n、hpc、p 系列）中。
nvidia.com/gpu / amd.com/gpu：GPU 数量，出现在 g4ad/g4dn/g5/g6/p3/p4d/p5 等实例族中（文档中nvidia.com/gpu取值可见1、4等）。
aws.amazon.com/neuron / aws.amazon.com/neuroncore：AWS Inferentia/Trainium 的 Neuron 设备数与 NeuronCore 数，出现在 inf1/inf2/trn1 等实例族中（如neuron 1 + neuroncore 4、neuron 4 + neuroncore 16等组合）。
habana.ai/gaudi：Habana Gaudi 加速器数量，出现在 dl1 等实例族中（对应标签instance-gpu-name取值为gaudi-hl-205）。

这些扩展资源（GPU/Neuron/Gaudi/EFA）被 labels.go 第 100-106 行归类为WellKnownExoticResources，在 NodePool 的 requirements 中同样可以直接引用。

从表格到 NodePool：把标签变成调度规则

理解了标签与资源的含义，就可以把它们用于 NodePool 的requirements字段做实例类型筛选。仓库中的示例配置展示了最常见的组合方式：

examples/v1/general-purpose.yaml中，requirements组合了架构、容量类型、实例类别与代数：

spec: template: spec: requirements: - key: kubernetes.io/arch operator: In values: ["amd64"] - key: kubernetes.io/os operator: In values: ["linux"] - key: karpenter.sh/capacity-type operator: In values: ["on-demand"] - key: karpenter.k8s.aws/instance-category operator: In values: ["c", "m", "r"] - key: karpenter.k8s.aws/instance-generation operator: Gt values: ["2"]

这段配置的含义是：只用 amd64 + Linux 的按需实例，类别限定为计算（c）、通用（m）、内存（r）三类，且代数必须大于 2（即第三代以后）。这正是文档中标签体系的典型应用——instance-category、instance-generation这类标签让"按类别+按代数"的粗粒度筛选成为可能。

文档中的其他标签同样可以直接套用，例如：

用kubernetes.io/arch: ["arm64"]锁定 Graviton 实例（对应 a1/c6g/m6g/r6g/t4g 等arm64实例族）；
用karpenter.k8s.aws/instance-hypervisor: ["nitro"]强制使用 Nitro 虚拟化（获得更好的网络与 EBS 性能）；
用karpenter.k8s.aws/instance-encryption-in-transit-supported: ["true"]筛选支持传输中加密的实例（c5a/c6a 等较新 AMD 实例显示为true，而 a1/c1/c3/c4/c5 显示为false）；
GPU 与加速器工作负载可参考 examples/workloads/gpu-nvidia.yaml 与 [examples/workloads/neuron.yaml)，用nvidia.com/gpu、aws.amazon.com/neuron等资源名或instance-gpu-*、instance-accelerator-*标签做精确匹配。

一个实用的阅读技巧：先用instance-category+instance-generation缩小范围，再用instance-cpu/instance-memory精确到规格档位。因为文档按实例族组织且族内按 CPU/内存升序排列，你可以在某一族内横向比较同规格实例的开销差异（例如同为 4 核 16GB 的 c5.xlarge 可调度内存6584Mi，c6i.xlarge 等新代实例往往略高）。

实例族全景与选型速览

文档按字母序收录了 165 个实例族（## xxx Family），从 AWS 实例命名惯例与文档中的标签可以快速归类：

通用型：a1、m1~m8 系列（含 m5a/m5n/m6i/m7g/m8g 等变体）、t1~t4g 突发型；
计算优化型：c1、c3~c8 系列，以及带本地盘的 c5ad/c5d/c6gd/c7gd/c8gd 等；
内存优化型：r3~r8 系列、x1/x1e/x2 系列、以及高内存的 u-3tb1/u-6tb1/u7i-*tb/u7in-*tb 等超大内存实例；
存储优化型：d2/d3/d3en、i2~i8 系列（本地 NVMe，对应instance-local-nvme标签）、h1、im4gn/is4gen；
GPU 实例：g4ad/g4dn/g5/g5g/g6/g6e/g6f/g7e/gr6、p3/p3dn/p4d/p4de/p5/p5e/p5en/p6-b200/p6-b300（资源表含nvidia.com/gpu或amd.com/gpu）；
机器学习加速实例：dl1/dl2q（Habana Gaudi，habana.ai/gaudi）、inf1/inf2（Inferentia）、trn1/trn1n/trn2（Trainium，aws.amazon.com/neuron）；
高性能计算：hpc6a/hpc6id/hpc7a/hpc7g/hpc8a、vt1（视频转码）、f1/f2（FPGA）。

表格中的kubernetes.io/arch标签可以直接用于区分架构：a1、c6g、m6g、r6g、t4g、g5g、x2gd 等带g后缀的实例族为arm64（Graviton），其余绝大多数为amd64。

使用注意事项与限制

数值会随版本漂移：文档是运行生成器时的快照，AWS 新增实例类型、AMI 开销调整都会改变数值。以当前仓库为准，升级 Karpenter 后建议重新生成或核对本页。
metal 实例的特殊性：metal 实例的instance-hypervisor标签为空（裸金属无虚拟化层），instance-size为metal，资源表与同规格最大虚拟实例接近（如 a1.metal 与 a1.4xlarge 一致）。
旧代实例数据缺失：c1/c3/c4 等 Xen 虚拟化老实例的instance-cpu-sustained-clock-speed-mhz为0（AWS 未公布持续主频），instance-ebs-bandwidth、instance-network-bandwidth也只在部分实例上出现，筛选时注意判空。
区域/容量类标签被剔除：topology.kubernetes.io/zone、topology.k8s.aws/zone-id、karpenter.sh/capacity-type因随环境变化不在此表中，但它们依然是 NodePool 可用的合法标签（如on-demand/spot）。
口径区分：标签中的instance-memory/instance-cpu是 AWS 规格值（整数），资源表中的memory/cpu是 Karpenter 扣除开销后的可调度值，二者用途不同——前者用于选型筛选，后者用于容量计算与装箱（bin-packing）。

企业官网建设流程全解析