背景#

Kubernetes v1.37（代号 Garhwal）2026-08-26 发布，一共 67 项 enhancement：16 项进 Stable、23 项进 Beta、27 项进 Alpha，1 项弃用。官方 release blog 按 Stable / Beta / Alpha 排（Stable 就是通常说的 GA），这个顺序对 SIG 有意义，对要升级的人帮助不大：一个默认关着的 Beta 和一个默认打开的 Beta，对升级后的集群是两回事。

所以我按「升级之后会发生什么」重新分了四组：升级当天就会碰到的（ACTION REQUIRED 和默认值翻转）、已经在倒计时的弃用、GA 之后可以开始依赖的 API，还有几个还在 Alpha、但改的是探针、驱逐、原地 resize 这些我日常会碰到的对象的。材料来自官方 release blog、完整的 CHANGELOG 和 SIG 的 DRA 专题 blog。feature gate 的默认值我直接对了 v1.37.0 tag 下的 pkg/features/kube_features.go 和 apiserver 那份同名文件，因为 blog 和 CHANGELOG 有一处说法不一致（见下文 PodLevelResourceManagers 那条）。

我写这篇时（2026-09-09），k3s 的 1.37 还只有 rc（v1.37.0-rc3+k3s1，09-03 发），稳定版没出。下面的内容不是升级复盘，是升级前的功课。

升级当天就会碰到的#

两类东西在升级当天就有效果：CHANGELOG 顶部标了 ACTION REQUIRED 的四条，和一批在 1.37 默认从关变开的 Beta gate。前者是硬的，不处理就会有 Pod 起不来或者 kubelet 拒绝启动；后者大多是「行为变了但没人告诉你」。四条 ACTION REQUIRED 里有一条只影响用过 1.36 Workload-aware scheduling alpha API 的集群：scheduling.k8s.io 从 v1alpha2 直接升到 v1alpha3 并删掉 v1alpha2，升级前要清掉所有 v1alpha2 对象。剩下三条分别在下面两个小节里。另有几条没标 ACTION REQUIRED、但同样会让某个组件起不来的，我放在第三个小节。

SELinuxMount 进 GA#

SELinuxMount 在 1.37 进 GA 并默认开启。效果是：只要 CSI driver 在 CSIDriver 对象上声明了 spec.seLinuxMount: true，卷就用 -o context=<label> 挂载，不再递归 relabel。一次 mount 只能带一个 SELinux context，所以同一节点上两个 SELinux label 不同的 Pod 共享同一个卷时，以前靠递归 relabel 能共存，现在第二个会起不来。

CHANGELOG 把它列为第一条 ACTION REQUIRED，并给了一篇 4 月的预告文（见参考资料）。那篇文里的排查办法要先在 kube-controller-manager 上加 --controllers=*,selinux-warning-controller 把这个控制器打开，它不在默认启用的控制器列表里；打开之后 selinux_warning_controller_selinux_volume_conflict 这个指标会列出所有互相冲突的 Pod，kubelet 侧还有 volume_manager_selinux_volume_context_mismatch_warnings_total 记录实际撞上的挂载。要保留老行为，给 Pod 设 securityContext.seLinuxChangePolicy: Recursive；集群级关闭这个 gate 在 1.37 还可以，release blog 明说它到 v1.38 才锁定，还剩一个版本的空间。

没开 SELinux 的集群（比如 Ubuntu 上的 k3s）不受影响，这条可以直接跳过。

kubelet 启动检查变严#

这四条都是 kubelet 侧的改动，其中两条也进了 ACTION REQUIRED。升级节点之前最好把 kubelet 配置过一遍：

  • cAdvisor 旧 flag 会让 kubelet 拒绝启动。 kubelet 内嵌的 cAdvisor 改用了精简的 github.com/google/cadvisor/lib 模块，--containerd（连同 --containerd-namespace）、--storage-driver-*、--event-storage-* 等 18 个早已弃用的 flag 现在不再接受，只留了 --housekeeping-interval。同一次改动还删掉了 /metrics/cadvisor 里的 container_cpu_load_average_10s、container_cpu_load_d_average_10s、container_tasks_state 三个指标族和自定义应用指标。Grafana 面板里若用到这三个系列，升级后会变成空图。
  • eventRecordQPS: 0 现在真的是不限速。 文档一直写 0 表示无限制，实现却不是；1.37 改成和文档一致。原来靠 0 拿到「默认限速」效果的配置，要显式写一个数（比如 50）。
  • static Pod 不能再引用 Secret 和 ConfigMap。 static Pod 不经过 API server，本来就不该读 API 资源，之前是 bug 让 configMapRef / secretRef 这类字段能用。1.37 把 PreventStaticPodAPIReferences 这个逃生 gate 删了，引用直接被拒绝。
  • kubelet 启动时会把生效配置打进日志。 CHANGELOG 把这条也标了 ACTION REQUIRED，理由是日志里会出现配置细节，nodes/logs 这个权限要收紧到可信用户。

没标 ACTION REQUIRED、但同样会挡住启动的几条#

CHANGELOG 顶部那四条之外，还有三条在 Changes by Kind 里躺着，踩中了一样是组件起不来：

  • kubeadm 配置文件的 v1beta3 API 删了（#136016，1.31 起就标弃用）。还写 v1beta3 的话，可以用 1.35 的 kubeadm 二进制跑 kubeadm config migrate 转成 v1beta4。同一条还删掉了只为兼容 v1beta3 而留的 PublicKeysECDSA gate，ECDSA key 的支持改由 v1beta4 的 ClusterConfiguration.EncryptionAlgorithm 表达。
  • kube-controller-manager 的 --concurrent-service-syncs flag 删了（#138002，v1.31 起就是 no-op）。flag 还在命令行里的话 KCM 直接拒绝启动。
  • GangScheduling 和 WorkloadAwarePreemption 两个 gate 删了（#139520），功能合进 GenericWorkload。在 feature-gates 里显式写过这两个名字的，得改名叫 GenericWorkload。

默认值翻转的 Beta gate#

这一组最容易被忽略。它们在 release blog 里散在 Beta 小节，但对升级的人来说，「默认从关到开」才是重点。下表挑的是会改变行为、或者值得评估的几项，默认值取 v1.37.0 源码。表里 StaleControllerConsistencyHPA、EtcdRangeStream、WatchListCompression、WebhookRoundTripLoadBalancing、ExcludeAdmissionWebhookVirtualResources 这五个是这一版新开的 gate，一出生就默认 true；其余那些才是从 false 翻过来的。

源码里 1.37 默认 true 的 Beta gate 一共 24 个，表里只有 17 个。漏掉的 7 个也都是这一版新开就默认 true，release blog 一个都没提：HPAGeneration（HPA 的 generation 跟踪）、HPAOptimizedSelectorStore（HPA 重叠检测用的 selector store 优化）、PodLevelResourcesFixDefaulting、PodLevelResourcesFixKubeletQOSClass 这四项更像实现层的修补；另外三项值得多看一眼：HugepageAwareEviction（kubelet 算 memory.available 时扣掉 hugepage 占的内存，修的是 hugepage 把 AvailableBytes 抬高、内存驱逐被拖住的老 bug）、NFTablesNetlink（kube-proxy 直接用 netlink 下发 nftables，不再 fork nft 命令）、NodeControllerLeaseCircuitBreaker（node lifecycle controller 标节点 NotReady 之前，先 GET 一次确认 lease 真的过期了）。

gate 升级后会发生什么 要不要管
MemoryQoS kubelet 开始按 cgroup v2 的 memory.min / memory.low / memory.high 管内存。但 memoryThrottlingFactor 默认 nil（不设 memory.high），memoryReservationPolicy 默认 None（不设 memory.min），所以不改 kubelet 配置的话什么都不会变 想用就显式设这两项；只在 cgroup v2 上有效
HPAScaleToZero HPA 允许 spec.minReplicas: 0，只对 object / external 指标有效；缩到 0 时 status 里多一个 ScaledToZero=True 的 condition 之前用 KEDA 补这个缺口的，可以开始评估原生方案
PersistentVolumeClaimUnusedSinceTime PVC status 多一个 Unused condition，最后一个引用它的 Pod 消失时变 True，lastTransitionTime 就是闲置起点 不删任何东西，只是给清理 PVC 的人一个依据
MaxUnavailableStatefulSet StatefulSet 的 maxUnavailable 重新默认可用。它 1.35 才刚默认打开，随后踩到 kubernetes#137409（首个 revision 有问题的 Pod 永远不会被更新到新 revision），#137904 在 master 上把它关回 off，同样的改动以 #137926 进 1.35.4，#139466 在 1.37 重新打开 1.35 / 1.36 上绕过这个坑的，可以撤掉 workaround
StaleControllerConsistencyHPA HPA controller 加入 stale controller mitigation：自己刚写过的对象，informer cache 没追上之前不再 reconcile，先 requeue 看起来「卡住」的 HPA 可能只是在等 cache
EtcdRangeStream kube-apiserver 初始化 watch cache 时改用 etcd 3.7 的流式 RangeStream RPC，不再用分页的 Range 一个个攒完整个 list 1.37 默认 etcd 已是 3.7.0，托管集群按供应商的来
ConcurrentWatchObjectDecode watch 事件解码从单 goroutine 变成固定 10 个 worker 的池（不可配），每个 cacher 在每个 apiserver 上各一份，且只在 cache 初始化期间生效。CRD 的 conversion webhook 因此最多同时收到 10 个请求，总调用量不变 自己写的 conversion webhook 若限制了并发，要看一眼
WatchListCompression 客户端带 Accept-Encoding: gzip 时，WatchList 响应走 gzip；普通 watch 不受影响 一般不用管
WebhookRoundTripLoadBalancing 开了 --enable-aggregator-routing=true 的 apiserver 会把 admission webhook 请求均匀打到多个 endpoint，不再因为连接复用全压到一个 多副本 webhook 受益
ExcludeAdmissionWebhookVirtualResources admission webhook 不再收到 tokenreviews、subjectaccessreviews 这类虚拟资源，和 ValidatingAdmissionPolicy 的行为对齐 webhook 若依赖这些请求，要留意
ManifestBasedAdmissionControlConfig 允许从磁盘 manifest 加载 webhook 和 CEL policy，从 apiserver 启动那一刻生效、etcd 不可用时也在。gate 开了，但没配 staticManifestsDir 就什么都不发生 想保护 admission 配置本身不被改的，值得看
AllowUnsafeMalformedObjectDeletion 解不开密的对象（比如 encryption key 丢了）可以通过 API 删除，不用直接动 etcd；带 dry-run 只在出事时用得上
NativeHistograms 控制面组件在 scrape 协议是 PrometheusProto 时同时暴露 classic 和 native histogram Prometheus 3.x 用户可以按自己节奏迁移
KubeletInUserNamespace rootless kubelet 进 Beta（KEP-2033）。gate 默认开只是允许这么跑：user namespace 要在起 kubelet 之前就建好，CRI 这些节点组件也得跑在同一个 user namespace 里 不主动用不受影响
PodsAPI kubelet 开始在节点上通过 gRPC API 暴露 Pod 信息（KEP-4188） 节点多了一个读 Pod 信息的入口，收网络策略和 RBAC 基线的看一眼
StorageCapacityScoring 调度器对动态供给的卷按 CSIStorageCapacity 打分 本地盘、大量 PVC 的集群受益
VolumeLimitScaling CSIDriver 新增 preventPodSchedulingIfMissing 字段，节点缺某个必需的 CSI driver 时不再把 Pod 调度上去 有 CSI driver 只装在部分节点的集群要重新看调度预期

有一条要单独说：release blog 说 PodLevelResourceManagers 进 Beta 但默认关闭，CHANGELOG 里 #140573 那条却写 enabled by default。往下翻才看清原因：同一份 CHANGELOG 里还有一条 #141209，「Disabled the PodLevelResourceManagers feature gate by default because of critical issues found before release」，也就是发布前发现严重问题又把默认值关了回去，CHANGELOG 把改前改后两条都留着了。我查了 v1.37.0 源码，1.37 的默认值是 false，以 blog 和源码为准。

已经在倒计时的弃用#

这一组升级当天什么都不会坏，但每一条都带着一个版本号的期限。kube-proxy 那条时间表最明确，单独说；其余几条合在一起。

kube-proxy 的 ipvs 模式#

ipvs 模式是 1.8 为解 iptables 性能瓶颈加的，但内核的 ipvs API 自己实现不了完整的 Service 语义，底下一直还得靠 iptables。KEP-3866 那篇 nftables 提案里有一节标题就叫「The ipvs mode of kube-proxy will not save us」。ipvs 从 1.35 起就标了弃用、启动时打警告；1.37 新增的是 KubeProxyIPVS 这个 gate（当前默认 true，LockToDefault 还没开），按 KEP-5495 的时间表，1.40 它翻成默认 false（还能显式打开），1.43 锁死并删掉 ipvs 的实现。

同一版还有一条相关的：kube-proxy 在没显式指定 mode 时也会警告，因为 Linux 上的默认模式计划从 iptables 切到 nftables。kubeadm 已经先一步把没填的 mode 显式写成 iptables，避免升级时跟着默认值漂。代价是 1.37 之后用 kubeadm 建的集群，这条命令查出来必然是 mode: iptables，它不再能告诉你当初有没有显式设置，这时候要看的是 kube-proxy 有没有为 mode 未显式指定而打警告。查自己集群当前模式：

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

用 Cilium 之类 CNI 把 kube-proxy 整个替掉的集群不在这条影响范围内。我自己这两套 k3s 都没走到那一步：Cilium 装完之后 kubeProxyReplacement 仍是 false，Service 还是由 kube-proxy 做（K3s 从 Flannel 换到 Cilium 之后冒出来的三个问题 里记着），所以这条对我照样要查。

kube-dns、cgroup v1 和几条小的#

  • kube-dns：CoreDNS 从 1.13 起就是默认 DNS，kube-dns 早就没跟上 EndpointSlice 和 dual-stack。kubernetes/community#8983（2026-05-18 合入）把 kube-dns 标为弃用，并把 node-local-dns 拆成独立仓库维护；release blog 的说法是预计 v1.40 之后不再为 kube-dns 构建新包，而 kubernetes/dns 仓库此刻还没归档（最后一次 push 是 2026-08-17），镜像彻底停更的时间点还在 kubernetes/kubernetes#137556 这个开着的 issue 里讨论。
  • cgroup v1：failCgroupV1 从 1.35 起默认 true，kubelet 在 cgroup v1 节点上直接起不来，除非显式写 failCgroupV1: false。1.37 这个 override 还在，但 MemoryQoS、memory-backed volume 的原地 resize 这些新东西都只在 v2 上有，这条路越走越窄。
  • kubectl run -f：这个 flag 一直被忽略（Pod 只由 NAME 和 --image 生成），1.37 正式弃用。
  • metrics.k8s.io/v1beta1：v1 出来之后，v1beta1 按 API 弃用政策进入过渡期，下一节说。
  • DRA 的 v1alpha1 健康 gRPC API：kubelet 侧升到 v1，v1alpha1 计划 1.40 删除。只和写 DRA driver 的人有关。

GA 之后可以开始依赖的#

16 项 Stable 之外，我把 CHANGELOG 里单独进 GA 的 gate 并进来一起看（下面原地 resize 那一项就是）。和跑业务服务的集群直接相关的是这些。DRA 那四项（extended resource 走 DRA driver、device taints、ResourceClaim 的 device status、标准 numaNode 属性）只在有 GPU 一类特殊设备的集群里有意义，放在最后一段。

metrics.k8s.io/v1#

metrics.k8s.io 在 Beta 待了将近九年，1.37 原样升到 v1，kubectl top 也加了 v1 支持。但 API 定义 GA 不等于实现跟上：我写这篇时 metrics-server 最新是 v0.9.0（2026-07-13 发布），README 的兼容矩阵里 0.9.x 一栏还是 metrics.k8s.io/v1beta1，仓库里「Support v1.metrics.k8s.io APIService」这个 issue（#1786）从 4 月开到现在。所以升了 1.37 之后 HPA 和 kubectl top 走的还是 v1beta1，暂时不用动；等 metrics-server 出 v1 再切。

Pod Certificates 和 ClusterTrustBundles#

两个 KEP 一起进 GA。工作流是：选一个 signer name，部署一个 signer controller 去 watch PodCertificateRequest、给符合条件的 Pod 签发并轮换证书、维护对应的 ClusterTrustBundle；工作负载这边用 podCertificate projected volume 声明要哪个 signer 的证书，用 clusterTrustBundle projected volume 拿信任锚。

signer controller 仍然要自己部署，Kubernetes 管的是申请、投递和授权检查这一段。1.37 在 NodeRestriction admission 里加了一道检查：节点只能替真的挂了对应 signer 的 podCertificate 卷的 Pod 发起 PodCertificateRequest，堵住了节点冒名申请证书的路。v1 API 还删掉了 v1beta1 里已弃用的 PKIXPublicKey 和 ProofOfPossession 字段，客户端若还在设这两个字段，升级前要改。

Resilient watchcache initialization#

这项从 1.34 开始分两个 gate 往 GA 走，1.37 把最后一个 WatchCacheInitializationPostStartHook 锁定。效果是 apiserver 启动或恢复时，watch cache 预热期间不再让 list / watch 请求压向 etcd，而是有界地放行一部分、其余直接回 HTTP 429。这对集群是好事，但对客户端是个契约变化：自己写的 controller、operator 要正确处理 429，尊重 Retry-After，做指数退避。client-go 的 REST client 默认会按 Retry-After 重试 429；用别的语言直接打 REST API 的要自己补。

KYAML#

KYAML 是 YAML 的一个严格子集：对象用花括号、数组用方括号、字符串一律双引号，缩进不再决定结构。每个 KYAML 文件都是合法 YAML，任何版本的 kubectl、任何现有工具链都能直接吃；反过来也不用把现有 manifest 改成 KYAML。1.37 起 kubectl get -o kyaml 是稳定的输出格式。它解决的是 YAML 在 Helm 模板和 CI 里那两类老问题：缩进错位和隐式类型转换（on 变 true、1.10 变 1.1 那种）。

StorageVersionMigration#

storagemigration.k8s.io/v1 默认启用。CRD 把 storage version 从 v1beta1 换到 v1 之后，etcd 里的老对象不会自己改写，以前要 kubectl get 加 kubectl replace 手撸一遍，或者部署 out-of-tree 的 kube-storage-version-migrator。现在创建一个 StorageVersionMigration 对象，内置 controller 会把存量对象重写到当前 storage version；1.37 还给它的 condition 加了进度（处理了多少个对象）。换 encryption-at-rest 的 key 之后要重写存量数据，也是同一个机制。

HPA 的可配置 tolerance#

HPA 默认的 10% 容差（指标和目标的比值在 0.9 到 1.1 之间不动）以前是控制器级的全局参数，1.33 引入的 spec.behavior.scaleUp.tolerance / scaleDown.tolerance 在 1.37 进 GA 并锁定，可以按 HPA 单独配、扩缩两个方向配不同的值。缩容想更稳、扩容想更灵敏的，这是原生的做法。

init container 的原地 resize 进 GA#

InPlacePodVerticalScalingInitContainers 在 1.37 进 GA 并 LockToDefault，管的是非 sidecar 的 init container：sidecar 形态（restartPolicy: Always）本来就归主 gate InPlacePodVerticalScaling 管，那一项 1.35 就 GA 了。这个 gate 在 1.36 已经是 Beta 且默认打开，1.37 做的是再进 GA 并 LockToDefault，源码注释写着 1.40 要把这个 gate 删掉，往后就关不回去。原地 resize 的链路和状态机我在 VPA InPlace Resize 那篇 里写过；这一版真正的新东西在 Alpha 里，下一节说。

DRA 的四项#

一句话：Pod 里 example.com/gpu: 1 这种 extended resource 请求现在可以由 DRA driver 直接满足，不用再并行跑一个 device plugin，这是把存量 GPU 工作负载迁到 DRA 的过渡桥。device taints、ResourceClaim 的 status.devices（网络设备可以回报接口名、MAC、IP）、resource.kubernetes.io/numaNode 标准属性一起进 GA。不用这类设备的集群，这一段只需要得出一个结论：没有任何东西需要你改。

还在 Alpha 的改动#

Alpha 默认全关。挑出来的这几条，改的都是探针、驱逐、原地 resize、StatefulSet、节点维护状态这些日常会碰到的对象，前八条是 1.37 新开的 gate：

  • httpGet 探针的 protocol 字段（H2CContainerProbe，KEP-5999）：只在 H2C 上提供健康端点的服务，以前 kubelet 用 HTTP/1.1 探不到，得另开一个 HTTP/1.1 端口或者改 exec 探针。现在 httpGet 可以写 protocol: HTTP2。Spring Boot 开 H2C 的配置和取舍见 这篇。
  • gRPC 探针支持 TLS（GRPCContainerProbeTLS，KEP-4939）：gRPC 探针以前只能明文，服务端强制 TLS 的就用不了。
  • EvictionRequest API（EvictionRequestAPI，KEP-4563）：新增 EvictionRequest 资源和 Pod 的 spec.evictionResponders 字段，发起驱逐的一方（node drain、descheduler、autoscaler）和响应的一方（应用自己的 controller）通过它协调优雅驱逐，而不是 PDB 那种只能说「现在不行」的机制。
  • 调度器为 Deferred 的 in-place resize 做抢占（InPlacePodVerticalScalingSchedulerPreemption，KEP-5836）：resize 请求在节点上放不下时 kubelet 标 Deferred，以前只能等；现在控制面可以抢占低优先级 Pod，给高优先级 Pod 的 resize 腾地方。
  • memory-backed emptyDir 的 sizeLimit 原地改（InPlacePodVerticalScalingMemoryBackedVolumes，KEP-6030）：medium: Memory 的 emptyDir 是 tmpfs，占的是容器内存；以前改 sizeLimit 要重建 Pod，现在走 /resize 子资源，kubelet 直接调 tmpfs 挂载。
  • StatefulSet 的 Recreate 更新策略（StatefulSetRecreateStrategy，KEP-3541）：和 Deployment 的 Recreate 一样，先删光、等全部终止，再按 podManagementPolicy 重建。
  • Node 的生命周期 condition（NodeLifecycleConditions，KEP-5683）：DrainInProgress、Drained、MaintenancePlanned、MaintenanceInProgress、GracefulNodeShutdownInProgress 五个标准 condition。以前每个组件都从 taint、label、annotation 里各自猜节点在什么阶段。CHANGELOG 里只有加这五个 condition 的 API 那一条（#139993），没看到配套的控制器改动，gate 也默认关着，1.37 里大概用不上。
  • Pod 级 checkpoint / restore（KEP-5823）：CRI 加了 CheckpointPod / RestorePod 两个 RPC，容器运行时也要实现才能用。
  • kubelet 的 defaultPodSysctls（DefaultPodSysctls）：节点级给所有 Pod 设默认 sysctl，Pod 自己的 securityContext.sysctls 可以覆盖。同一版还把 net.ipv4.tcp_slow_start_after_idle 和 net.ipv4.tcp_notsent_lowat 加进了 safe sysctl 白名单，这两个不需要 gate。

Workload-aware scheduling（gang scheduling、workload-aware preemption、CompositePodGroup）是 1.37 改动最多的一块，核心的 Workload 和 PodGroup 两个类型升到 scheduling.k8s.io/v1beta1，新加的 CompositePodGroup 在 scheduling.k8s.io/v1alpha3；GenericWorkload gate 1.37 默认仍是关的，而且只对 AI/ML 训练这类要整组调度的负载有意义，我这里不展开。

小结#

按我自己升级前会做的顺序：

  1. 集群开了 SELinux 的，先按 4 月那篇预告文在 1.36 上把共享卷的 Pod 找出来；没开的跳过。
  2. 过一遍 kubelet 配置：删 cAdvisor 旧 flag，eventRecordQPS 若是 0 改成显式值，static Pod 里别引用 Secret / ConfigMap，nodes/logs 权限收紧。
  3. 再查三个容易被漏掉的：kubeadm 配置文件是不是还在 v1beta3、KCM 命令行里有没有 --concurrent-service-syncs、feature-gates 里有没有写 GangScheduling / WorkloadAwarePreemption。
  4. Grafana 面板里搜上面被删掉的那三个 cadvisor 指标族，用到了就换掉。
  5. 查 kube-proxy 模式：ipvs 的开始规划迁 nftables；mode 没显式写的补上。
  6. 默认翻转的 gate 里，MemoryQoS 不配就不生效，HPAScaleToZero 和 PersistentVolumeClaimUnusedSinceTime 是新能力不是行为变化；会自己变的集中在 apiserver 那几项（EtcdRangeStream、ConcurrentWatchObjectDecode、WebhookRoundTripLoadBalancing、ExcludeAdmissionWebhookVirtualResources），自建控制面的看一眼 conversion webhook 的并发上限，webhook 还能不能收到 tokenreviews / subjectaccessreviews 也是这一次变的，再留意节点上多出来的 PodsAPI。
  7. metrics.k8s.io/v1 等 metrics-server 跟上再说；Pod Certificates 和 KYAML 可以开始试。

参考资料#