Kubernetes v1.23 发布日志深度解读:从 1.23.0 到 1.23.17 的重大变更、安全修复与版本选择
本篇基于仓库中的 CHANGELOG-1.23.md 逐版本拆解 Kubernetes 1.23 版本线(v1.23.0 至 v1.23.17)的发布内容:v1.23.0 的十三个重大主题、升级前必读事项、各补丁版本修复的四个 CVE、Go 工具链演进与镜像仓库迁移时间线,并结合本仓库源码标注每项能力对应的实现位置,帮助你在评估升级路径、排查版本相关行为差异时快速定位依据。
一、v1.23 版本线的整体结构与阅读方法
CHANGELOG-1.23.md 覆盖了 1.23 分支的全部发布:正式版 v1.23.0 到 v1.23.17 共 18 个补丁版本,以及发布过程中的 v1.23.0-alpha.1 至 alpha.4、v1.23.0-beta.0、v1.23.0-rc.0/rc.1 等预发布版本。理解这份 changelog 的通用组织方式,是高效使用它的前提。
每个版本条目都遵循固定的五段式结构:
| 小节 | 内容 |
|---|---|
| Downloads(Source Code / Client / Server / Node Binaries / Container Images) | 各平台二进制包与容器镜像清单,附 sha512 校验和 |
| Changelog since vX.Y.(N-1) | 相对上一版本的变更记录入口 |
| Changes by Kind | 按类型分组的变更清单 |
| Dependencies | 第三方依赖的新增、变更、移除 |
其中 Changes by Kind 的分类固定为:Deprecation(弃用)、API Change、Feature、Documentation、Failing Test、Bug or Regression、Other (Cleanup or Flake)。每条变更末尾标注了归属的 SIG(如 SIG Network、SIG Storage、SIG Node),便于按组件域过滤。
关于下载产物的几点实操要点(适用于本文件列出的全部版本):
- 二进制包按角色分包:
kubernetes-client-*只含 kubectl/kubeadm 等客户端;kubernetes-server-*只含 Linux 平台的 apiserver/controller-manager/scheduler;kubernetes-node-*含 Linux 各架构与 Windows amd64 的节点侧二进制。源码包为kubernetes-src.tar.gz。 - 架构后缀:覆盖 amd64、arm、arm64、ppc64le、s390x(服务端)以及 darwin/windows 客户端组合,全部提供 sha512 值用于下载后校验完整性。
- 容器镜像:全部以 manifest list 形式发布,支持文档列出的五种架构;也可在镜像名后加
-$ARCH后缀直接拉取特定架构(例如 kube-apiserver 的 arm64 变体)。v1.23.15 起发布文档中镜像前缀已由k8s.gcr.io迁移为registry.k8s.io(见后文时间线)。
二、v1.23.0 的十三个重大主题(What's New)
这是整份 changelog 中信息密度最高的章节,官方原文要求升级者逐条阅读。以下完整继承原文主题并补充本仓库中的源码落点。
2.1 FlexVolume 被正式弃用
FlexVolume 自 1.23 起被标记为 deprecated,官方明确推荐以树外(out-of-tree)CSI 驱动替代。FlexVolume 驱动维护者应实现 CSI 驱动并引导用户迁移,FlexVolume 用户应将工作负载迁到 CSI。
2.2 klog 相关标志位弃用
为简化代码库,1.23 将一系列 klog 日志标志标记为 deprecated(后续条目中说明 -v 与 -vmodule 例外),实现代码将在未来版本移除。使用 --logtostderr、--alsologtostderr 等标志的部署需要规划替代方案;changelog 同时提到发行包中包含了 kube-log-runner,可作为被弃用 --log-file 参数的替代手段。
2.3 发布流程达成 SLSA Level 1 供应链合规
Kubernetes 发布流程开始生成 provenance(来源证明)文件,描述 staging 与 release 两个阶段,并在阶段交接时对产物做校验。这是达成 SLSA(Supply-chain Levels for Software Artifacts)第 1 级的最后一块拼图,对需要供应链审计的企业部署方有直接意义。
2.4 IPv4/IPv6 双栈网络毕业至 GA
IPv6DualStack 特性自 1.21 起默认开启,1.23 将其毕业为 stable 并移除了该 feature gate。注意:集群默认具备双栈能力,但 Pod 与 Service 仍默认单栈。启用双栈需要同时满足:节点具备可路由的 IPv4/IPv6 网络接口、CNI 插件支持双栈、Pod 配置为双栈、Service 的 .spec.ipFamilyPolicy 显式设置为 PreferDualStack 或 RequireDualStack。
这一主题带来的控制器参数变更值得单独记录:
- 双栈集群必须同时指定
--node-cidr-mask-size-ipv4和--node-cidr-mask-size-ipv6来设置每节点 IP 掩码,替代原来的--node-cidr-mask-size; - 旧标志与两个新标志互斥;
- 单栈集群可继续用旧标志,也可改用与
--cluster-cidr地址族匹配的新标志。
另外,创建双栈 Service 时 ipFamilyPolicy 变为必填——服务器不再从 ipFamilies 或 clusterIPs 推断该字段,这是相对 beta 行为的破坏性变更;无 selector 且未启用双栈的 Headless Service 现在默认 RequireDualStack 而非 PreferDualStack。
2.5 HorizontalPodAutoscaler v2 毕业至 GA
autoscaling/v2 成为推荐的 HPA API,autoscaling/v2beta2 被弃用;注意 autoscaling/v1 并未因此弃用。本仓库中 v2 版本的类型定义位于 pkg/apis/autoscaling/v2。
2.6 Generic Ephemeral Volume 毕业至 GA
通用临时卷特性无条件启用:任何支持动态供给的存储驱动都可以作为生命周期绑定到 Pod 的临时卷使用,支持全部 StorageClass 参数与 PVC 特性。该版本同时修复了多个配套问题:临时卷可以裸块设备形式创建、节点限制调度过滤器与 kubelet hostPath 检查正确识别临时卷、kubelet 开始上报临时卷的 kubelet_volume_stats_* 指标、临时卷的等待事件文案从 "persistentvolumeclaim not found" 改为更可读的 "waiting for ephemeral volume controller to create the persistentvolumeclaim"。kube-controller-manager 新增 --concurrent-ephemeralvolume-syncs 控制临时卷控制器并发数。
2.7 卷属主变更相关特性毕业至 GA
两个存储特性同时毕业:一是配置卷权限/属主变更策略以跳过挂载时的递归权限修改(加快 Pod 启动),二是允许 CSI 驱动声明 fsGroup 权限支持(CSIVolumeFSGroupPolicy)。changelog 中同时提到 ConfigurableFSGroupPolicy 移入 GA,指标 volume_fsgroup_recursive_apply 更名为 volume_apply_access_control;kubelet 还会在 CSI 驱动声明 VOLUME_MOUNT_GROUP 能力时,把 fsGroup 委托给驱动的 NodeStageVolume/NodePublishVolume 调用(该行为仍由 DelegateFSGroupToCSIDriver gate 控制)。
2.8 PodSecurity 准入控制器毕业至 Beta 并默认开启
PodSecurity 取代已弃用的 PodSecurityPolicy,成为基于 namespace 标签执行 Pod Security Standards 的准入控制器,1.23 起 feature gate 默认开启,准入配置版本提升到 pod-security.admission.config.k8s.io/v1beta1。行为细节上的强化:在 restricted 级别下,设置 runAsUser=0 的 Pod/容器现在在准入阶段就被拒绝(此前是运行时拒绝);豁免的 Pod 会打上 pod-security.kubernetes.io/exempt: user/namespace/runtimeClass 注解,实际生效的策略级别记录在 pod-security.kubernetes.io/enforce-policy 注解;审计违规注解更名为 pod-security.kubernetes.io/audit-violation。本仓库中该准入控制器的实现位于 staging/src/k8s.io/pod-security-admission,其中 policy 目录 下按 check_capabilities_restricted.go、check_hostNamespaces.go 等文件逐条实现了各检查项,admission 目录 则是准入决策入口。
2.9 CRI v1 成为默认
Kubelet 默认使用容器运行时接口 CRI v1;运行时若不支持 v1 则回落到 v1alpha2,两者实现相同、对最终用户无感。本仓库中 v1 API 的 proto 与生成代码位于 staging/src/k8s.io/cri-api/pkg/apis/runtime/v1。changelog 预告 v1alpha2 可能在后续版本移除,同时记录了一个回归修复:dockershim 上报的 CRI 版本被回退为 v1alpha2。
2.10 结构化日志(Structured logging)毕业至 Beta
kubelet 与 kube-scheduler 的多数日志已转换为结构化格式,鼓励用户试用 JSON 输出。配套的关键行为变更:
- JSON 格式日志默认改写往 stderr(与文本格式一致),原来捕获 stdout 的用户需要改为捕获 stderr;
- JSON 日志输出可配置为 info 走 stdout、error 走 stderr,info 可内存缓冲(默认仍是不缓冲的双写 stdout);
- kubelet 的日志详细度与刷新频率可以通过配置文件而不只是命令行标志配置;
client-go在日志级别 9 时会跟踪 HTTP 请求的 DNS 解析、TCP 拨号、TLS 握手、连接池取连接、请求处理等阶段耗时,便于排障。
本仓库中大量迁移记录(kube-scheduler、pkg/proxy 及其各实现、pkg/scheduler 框架插件等迁移到结构化日志)都出现在 v1.23.0 的 Other 分类条目中,可以视作"哪些组件已经结构化"的清单。
2.11 kube-scheduler 简化插件配置:MultiPoint 字段
调度器配置新增 multiPoint 字段:通过它启用的插件会自动注册到该插件实现的所有扩展点。例如一个同时实现 Score 与 Filter 的插件,可以在一处配置同时生效于两个扩展点,整个插件的启停不再需要逐个扩展点手工编辑。本仓库中该字段定义在 pkg/scheduler/apis/config/types.go:MultiPoint 是 KubeSchedulerConfiguration 上的 PluginSet 类型。同版本还引入了 kubescheduler.config.k8s.io/v1beta3:提高了用户可指定优先级插件的权重(TaintTolerations 升至 3,NodeAffinity 与 InterPodAffinity 升至 2),并移除 HealthzBindAddress、MetricsBindAddress 字段;旧版 v1beta1 配置不再被支持,升级前必须把配置文件迁移到 v1beta2 或 v1beta3,legacy policy 配置及其 policy-config-file、policy-configmap、policy-configmap-namespace、use-legacy-policy-config 标志也一并移除。
2.12 CSI Migration 更新
CSI 迁移允许把 kubernetes.io/gce-pd、kubernetes.io/aws-ebs 等树内存储插件替换为对应 CSI 驱动,迁移正常工作时终端用户无感知。1.23 的状态:
- GCE PD、AWS EBS、Azure Disk 的迁移默认开启(
CSIMigrationGCE、CSIMigrationAWS、CSIMigrationAzureDisk默认 ON),仍保持 Beta; - Ceph RBD 与 Portworx 引入 Alpha 级迁移支持。Portworx 的启用方式在 changelog 中给出了具体配置:在 kube-controller-manager 上追加
--feature-gates=CSIMigrationPortworx=true,并在 kubelet 配置的featureGates段设置CSIMigrationPortworx: true。
三、v1.23.0 升级前必读(Urgent Upgrade Notes)
changelog 用"No, really, you MUST read this before you upgrade"作为小标题,下列五条是必须提前处理的升级项:
- kubeadm 移除
--experimental-patches:init|join|upgrade命令不再接受该标志,且--patches不能再与--config混用;节点补丁请改用InitConfiguration.patches/JoinConfiguration.patches配置项。 - JSON 日志改走 stderr:见 2.10 节,日志采集配置需同步调整。
- seccomp 注解将删除:
seccomp.security.alpha.kubernetes.io/pod与container.seccomp.security.alpha.kubernetes.io/[name]自 1.19 起弃用、1.25 删除,应迁移到seccompProfileAPI 字段。 - kube-log-runner 进入发行包:可用于替代被弃用的
--log-file。 - Go 1.17 构建与 X.509 SAN 强制:1.23 使用 go 1.17 构建,该版本移除了通过
GODEBUG=x509ignoreCN=0恢复"把 X.509 证书的 CommonName 当主机名"这一历史行为的能力(该行为自 1.19/go 1.15 起默认禁用)。后果是:准入 webhook、CRD conversion webhook 与聚合 API server 的服务证书必须包含有效的 Subject Alternative Name。若在 1.22 上以GODEBUG=x509ignoreCN=0运行,可检查apiserver_kube_aggregator_x509_missing_san_total与apiserver_webhooks_x509_missing_san_total两个指标是否非零,以判断哪些连接将在 1.23 上失效。
四、已知问题(Known Issues)
v1.23.0 记录了一个已知问题:随 1.22 发布的 etcd v3.5.0 存在数据损坏问题。本版本线随后将 etcd 升级到 3.5.1(v1.23.0 条目内),并在 v1.23.14 升级到 v3.5.5 以彻底绕开 v3.5.0–v3.5.2 区间的损坏风险。仍在 1.23 低补丁版本运行的集群应尽快升级到 1.23.14 或更高版本。
五、1.23 补丁版本线的安全修复时间线
这份 changelog 中最重要的运维价值之一,是精确记录了每个 CVE 在 1.23 线哪个补丁版本被修复。汇总如下:
| 修复版本 | CVE | 标题 | 影响面(1.23 线) | CVSS |
|---|---|---|---|---|
| v1.23.11 | CVE-2022-3172 | 聚合 API server 可致客户端被重定向(SSRF) | kube-apiserver v1.23.0 – v1.23.10 | 5.1(Medium) |
| v1.23.11 | CVE-2021-25749 | Windows 容器 runAsNonRoot 逻辑可被绕过 |
kubelet v1.23.0 – v1.23.10 | 3.4(Low) |
| v1.23.14 | CVE-2022-3162 | 非授权读取 Custom Resources | kube-apiserver v1.23.0 – v1.23.13 | 6.5(Medium) |
| v1.23.14 | CVE-2022-3294 | Node 代理地址未被始终校验 | kube-apiserver v1.23.0 – v1.23.13 | 6.6(Medium) |
| v1.23.17 | CVE-2022-41723 | golang.org/x/net 漏洞(随依赖升级修复) | 依赖升级 v0.7.0 | — |
逐项展开说明:
CVE-2022-3172(聚合 API SSRF):受攻击者控制的聚合 API server 可将客户端流量重定向到任意 URL,导致客户端执行非预期操作或向第三方泄露凭据。changelog 明确写道"该问题没有缓解手段",集群管理员只能保证聚合 API server 本身可信、不向不可信方授予修改 APIService 的权限。技术修复落在 v1.23.11:kube-apiserver 默认不再向后端透传重定向响应,需要旧行为的可用 --aggregator-reject-forwarding-redirect=false 显式打开。
CVE-2021-25749(Windows runAsNonRoot 绕过):Windows 工作负载即使设置了 runAsNonRoot: true 也可能以 ContainerAdministrator 运行。修复方式是当 runAsNonRoot 为 true 时,对 ContainerAdministrator 用户名的检查改为大小写不敏感(v1.23.11 条目)。changelog 给出的检测建议:审计日志中若出现疑似拼写错误的用户名,说明可能有人通过大小写变体绕过限制;若确认被利用应联系 Kubernetes 安全团队。
CVE-2022-3162(Custom Resource 越权读):被授权 list/watch 某命名空间级 CR 的全集群范围后,攻击者可以读取同一 API group 下另一类型 CR 的内容,即使他没有该类型的读权限。修复版本为 v1.23.14。
CVE-2022-3294(Node 代理地址校验绕过):Kubernetes 支持 nodes/proxy,让 kube-apiserver 客户端借道代理访问 Kubelet 端点(进 Pod、取日志等)。kube-apiserver 的一个 bug 使该代理地址的既有校验可以被绕过,认证请求可能被重定向到控制面私有网络内的安全端点。changelog 同时给出两条运维要点:修复可能破坏依赖 nodes/proxy 的客户端——特别是当 kubelet 向控制面通告的是 localhost 或 link-local 地址时;另一个缓解方式是给到集群网络的出口配置 egress proxy。
v1.23.17 的依赖修复:将 golang.org/x/net 升级到 v0.7.0 修复 CVE-2022-41723,同期 x/sys、x/term 升到 v0.5.0、x/text 升到 v0.7.0。
六、工具链与镜像仓库的演进(补丁版本时间线)
除安全外,1.23 补丁线还有两条值得画成时间线的演进:
Go 工具链:
| 版本 | 事件 |
|---|---|
| v1.23.0 | 使用 Go 1.17 系列构建(期间经历 1.16.7 → 1.17.1 → 1.17.2 → 1.17.3 的滚动升级) |
| v1.23.16 | 升级到 Go 1.19.4/1.19.5;kube-apiserver 默认 GOGC=63(近似 go1.17 在高负载 API server 上的 GC 内存表现),默认 GODEBUG=x509sha1=1(对齐 go1.17 对 SHA1 证书的支持) |
| v1.23.17 | 升级到 Go 1.19.6 |
这条时间线解释了 v1.23.16 中那条 "API Change" 的动机:跨大版本升级 Go 后需要显式保留旧 GC/证书行为,避免升级当天出现性能或兼容性回退。
镜像仓库前缀迁移(k8s.gcr.io → registry.k8s.io):
- v1.23.14 及更早的发布条目中,容器镜像前缀仍是
k8s.gcr.io; - v1.23.15 完成切换:发布条目改为
registry.k8s.io;同时 kubeadm 对新建集群默认使用registry.k8s.io,且升级时会自动把使用旧默认值 k8s.gcr.io 的用户迁移过去;kubelet 拉取 pause 镜像的默认前缀也切到registry.k8s.io。
其余值得留意的补丁行为变更:
- v1.23.17:kubelet 的 TCP/HTTP 探针将连接 TIME-WAIT 从默认 60 秒缩到 1 秒,释放 socket、conntrack 表项与临时端口,高频探针场景下更省网络资源;
- v1.23.16:job controller 恢复对
parallelism=1job 的指数退避重建;修复 DeleteCollection 在非空请求体时失败的问题;StatefulSet 在新副本创建失败时也能显示有效状态;client-go 修复自定义 io.Reader body 重试请求时的数据竞争(此后只有无 body 或 string/[]byte/runtime.Object body 的请求可重试); - v1.23.15:修复 CSI ephemeral volume 的卷重建;修复 SSA(Server-Side Apply)对
preserveUnknownFields全未指定 schema 的大对象创建性能问题;依赖 structured-merge-diff/v4 升到 v4.2.3。
七、v1.23.0 关键 API 与行为变更精选
完整清单见 changelog 的 Changes by Kind 章节,此处精选对升级影响最大的一类破坏性变更与高价值特性:
破坏性/兼容性变更:
kubectl --dry-run不再有隐式取值,必须写全--dry-run=(server|client|none);- kube-apiserver 移除
rbac.authorization.k8s.io/v1alpha1(改用 1.8 起就有的 v1)与scheduling.k8s.io/v1alpha1(改用 v1); - kube-scheduler 与 kube-controller-manager 的
--port、--address标志失效(仅允许 0),kube-scheduler 的存活/就绪探针必须走 HTTPS,默认端口变为 10259,抓取 metrics 需要能访问非资源 URL/metrics的专用 ServiceAccount; - 移除多个已 GA 的 feature gate:
NodeLease(1.17 GA)、AllowInsecureBackendProxy(1.21 GA)、ServiceAccountIssuerDiscovery(1.21 GA);BoundServiceAccountTokenVolume、StartupProbe、SupportPodPidsLimit、SupportNodePidsLimit则变为无条件启用,不能再通过--feature-gates指定; - 服务器端引入
fieldValidation=[Strict|Warn|Ignore]请求参数,执行严格的 schema 校验。
高价值新能力:
- PodSpec 引入
OS字段(与node.kubernetes.io/os标签配套),kubelet 会拒绝 OS 与节点标签不匹配的 Pod,并周期性 reconcilekubernetes.io/os、kubernetes.io/arch标签; - 临时容器(Ephemeral Containers)进入 beta、默认可用;
- StatefulSet
minReadySeconds进入 beta;新增StatefulSetAutoDeletePVCgate 支持自动删除 StatefulSet 自动创建的 PVC; - 新增审计策略字段
omitManagedFields,允许在审计日志中省略请求/响应体里的 managedFields; generateName创建冲突时服务端返回可重试的 AlreadyExists 错误;- kube-apiserver 新增一批 LIST 请求成本指标(
apiserver_cache_list_*与apiserver_storage_list_*系列)以及 API Priority and Fairness 的 seat 占用/watch 数直方图; - kube-proxy 修复 1.22 引入的多个 iptables 回归(SessionAffinity 端点失准后亲和性错误断开、无可用端点时流量从 drop 变为 reject 的时机、未使用端点链路不再写入 iptables);health 检查端口监听受
--nodeport-addresses约束; - kube-scheduler 的
--leader-elect*命令行参数恢复生效。
八、验证路径与延伸阅读
读完本文后,可以在本仓库内沿以下路径核对上述各项能力的实现与测试:
- 完整发布记录:CHANGELOG-1.23.md;如需对照 1.22 的行为差异,见 CHANGELOG-1.22.md;
- PodSecurity 准入实现:staging/src/k8s.io/pod-security-admission(含 README 与 policy 检查项实现);
- CRI v1 API 定义:staging/src/k8s.io/cri-api/pkg/apis/runtime/v1;
- HPA v2 API:pkg/apis/autoscaling/v2;
- 调度器 MultiPoint 配置字段:pkg/scheduler/apis/config/types.go;
- 双栈节点 IPAM 相关控制器:pkg/controller/nodeipam;
- 集群脚本与 GCE 测试集群部署(理解 kube-up/upgrade 流程):cluster/gce/upgrade.sh。
版本选择建议(以本文件记录的内容为准):如果你的集群停留在 1.23 线,v1.23.17 是最后一个补丁版本,包含全部四个 CVE 的修复与 Go 1.19.6 构建;至少应不低于 v1.23.14(etcd 3.5.5 + 两个 kube-apiserver CVE),若运行 Windows 工作负载或使用了聚合 API,v1.23.11 是更早的硬性下限。升级前请逐条核对第三节"必读"事项,尤其是 SAN 证书与 JSON 日志输出目标两项。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0623
Hy4-previewHy4 preview 是由腾讯混元团队研发的新一代混合专家(MoE)旗舰模型。模型总参数量 770B,每个 token 激活 49B,主干共包含78层,第一层采用标准 FFN,其余 77 层均为 MoE 结构,每层包含 256 个路由专家与 1 个共享专家,每个 token 激活 top-8 路由专家及共享专家。主干之外原生内置 1 层 MTP(总参数量 10B,激活 0.7B)以支持投机解码。Python00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
GLM-5.3-FlashGLM-5.3-Flash (320B-A18B),是GLM-5系列的首个原生多模态模型。320B总参数,能力超过GLM-5.2Jinja00
Spark-X2.5-4BSpark-X2.5-4B 旨在让强大的 AI 更实用、更高效、更易获得。在广泛日常任务中表现强劲,涵盖对话、写作、翻译、推理、编码、工具调用以及智能体工作流,并在同等规模的开源模型中取得领先成绩。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00