OpenYurt 社区于日前正式发布了 v1.7.0版本，本次发布带来了三项重磅特性，覆盖边缘 OTA 升级、多租户控制面部署和节点自动化纳管。

OTA 升级支持镜像预热：

大幅度降低服务服务中断时间

OpenYurt 此前已通过增强版 DaemonSet 控制器为边缘工作负载提供 OTA（Over-The-Air）升级能力。但在 AI 推理、视频处理等大镜像场景下，镜像拉取与 Pod 重启同步进行：升级触发后，节点先拉镜像、再启动新 Pod，整个过程都计入服务中断时间。在边缘弱网环境下，一个 GB 级镜像可能需要数分钟才能下载完成，对应业务在这段时间内完全不可用。

v1.7.0 引入镜像预热（Image Preheating）能力，把镜像拉取从升级关键路径上移除：镜像可以在升级触发之前异步下发到边缘节点，真正升级时只需重启容器，服务中断时间由"分钟级"压缩到"秒级"。 整体方案包含三部分：

• 新增 Pod Condition： PodNeedUpgrade  标记是否有可升级版本，PodImageReady 标记目标镜像是否已预热完成；
• 新增 ImagePreHeat控制器：监听 Pod 状态变化，按需向目标节点下发镜像预热 Job；
• 新增 OTA 预热 API：POST /openyurt.io/v1/namespaces/{ns}/pods/{podname}/imagepull，节点侧用户可主动触发指定 Pod 的镜像预热。

基于 KOK 架构

提升 IDC 自建 Kubernetes 的运维效率

OpenYurt 长期专注于「云 + 边」协同：边缘节点直接接入云端 Kubernetes，由云端统一管控。但仍有一类用户出于离线持续部署、多租户隔离、数据合规等原因，希望在自己的 IDC 中保留一套独立的 Kubernetes 集群。这类自建集群最大的痛点在于控制面（kube-apiserver / kube-controller-manager / kube-scheduler / etcd）的运维与升级 —— 组件维护、扩缩容、滚动升级都需要人工承担，且缺乏弹性。

v1.7.0 版本引入 KOK（Kubernetes-on-Kubernetes）架构，将"管控集群"与"业务集群"解耦：

• Host-Kubernetes：位于云端，由云厂商托管，负责承载 Tenant-Kubernetes 的控制面 Pod；
• Tenant-Kubernetes：用户在 IDC 自建的业务集群，控制面以 Pod 形态运行在 Host-Kubernetes 上，业务 Pod 运行在 IDC 节点上。

通过这种分层结构，Tenant-Kubernetes 控制面的部署、扩缩容、升级、故障自愈完全交给 Host-Kubernetes 自动完成，用户不再需要手工运维 IDC 控制面；同时业务 Pod 与控制面天然隔离，安全性更高。在 IDC 侧，YurtHub 新增 local  模式，让 worker 节点能够动态感知 Host-Kubernetes 上的 Kube-apiserver Pod 并自动负载均衡，无需在 Kube-apiserver 前再挂一台 LoadBalancer，整体部署依赖大幅简化。

节点自动化纳管能力

过去，如果在 Kubernetes 集群中使用 OpenYurt 的能力，需要使用 Yurtadm 的工具来接入节点，导致已有  Kubernetes 集群的节点难以转为边缘节点，且不兼容 Kops、Kubespray 等第三方工具，大规模部署运维成本高。

为此，社区新增了 YurtNodeConversion 控制器。用户只需为目标节点添加 NodePool label（apps.openyurt.io/nodepool），即可触发自动化节点转换流程；当用户移除该 label 时，也可以触发反向清理流程，将节点恢复为普通 Kubernetes 节点。YurtNodeConversion 控制器会监听节点标签变化，并创建对应 Job，在目标节点侧完成 YurtHub 安装/卸载、服务启停、流量重定向等转换操作。