#发版日志

#4.0.11

发布于：2026-07-01

#已修复问题

• 修复 frontend 访问 erebus 时未设置 HTTP 连接超时时间的问题。此前每次访问 erebus 都会创建新的 HTTP client，且连接未配置超时，可能导致 socket 持续泄露并最终耗尽本地临时 TCP 端口，进而造成前端页面无法正常访问。
• 修复了 worker 节点的 chassis UUID 发生变化（如节点删除后重新加入，或 OVS system-id 变更）后，VPC BFD port 对应的 HA Chassis 未自动更新到新 chassis、仍引用旧 chassis UUID，导致 egress gateway 的 BFD 高可用路径异常的问题。

#已知问题

• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.10

发布于：2026-05-27

#已修复问题

• 修复长期运行或创建超过一年的集群中 kubeconfig 客户端证书过期后，可能导致平台页面返回 500、kubectl 命令执行异常以及 Apollo 等组件访问异常的问题。控制器现在会检测并自动续期即将过期的 <cluster>-kubeconfig Secret 客户端证书；控制面节点 /root/.kube/config 会使用有效期约 10 年的客户端证书。
• 修复逐步升级过程中，业务集群历史 kubeconfig Secret 或 ClusterCredential 客户端证书已过期或即将在 30 天内过期时未自动轮换，导致业务集群访问异常的问题。控制器现在会检测并重新签发客户端证书，并更新对应的 Secret/凭据。
• 修复从 3.16.2 升级到 4.0.x 后，升级脚本生成的 apiserver.crt 缺少 Authority Key Identifier (AKI) 扩展，导致新版 Go TLS 客户端（如 Jenkins 流水线）连接 kube-apiserver 失败的问题。升级生成的 apiserver.crt 现在会携带 AKI 信息。
• 修复卸载 Multus 后，Pod 无法正常创建的问题。
• 修复 image-registry 外接 S3 场景下通过环境变量引用 Secret 的安全问题，避免敏感信息暴露。

#已知问题

• 修复 frontend 访问 erebus 时未设置 HTTP 连接超时时间的问题。此前每次访问 erebus 都会创建新的 HTTP client，且连接未配置超时，可能导致 socket 持续泄露并最终耗尽本地临时 TCP 端口，进而造成前端页面无法正常访问。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复了 worker 节点的 chassis UUID 发生变化（如节点删除后重新加入，或 OVS system-id 变更）后，VPC BFD port 对应的 HA Chassis 未自动更新到新 chassis、仍引用旧 chassis UUID，导致 egress gateway 的 BFD 高可用路径异常的问题。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.9

发布于：2026-02-10

#已修复问题

• 修复了 olm-registry pod 持续重启导致 OperatorHub 无法正常使用的问题。该问题由 CIS 合规加固时添加的 `seccompProfile: RuntimeDefault` 安全配置引起，该配置拦截了 CGO 操作所需的 `clone` 系统调用。已调整 seccomp 配置以允许必要的系统调用，同时保持安全合规性。已在 ACP 4.0.9 修复。
• 修复了当集群安装 60+ 个 Operator 时，原生应用创建接口权限校验极慢（10秒以上）的性能问题。已在 ACP 4.0.9 修复。
• 修复了 marketplace 插件在 workload 集群安装失败的问题。已在 ACP 4.0.9 修复。
• 修复 egress gateway 无法路由和 egress gateway 同网段 Pod 流量问题。已在 ACP 4.0.9 修复。

#已知问题

• 修复长期运行或创建超过一年的集群中 kubeconfig 客户端证书过期后，可能导致平台页面返回 500、kubectl 命令执行异常以及 Apollo 等组件访问异常的问题。控制器现在会检测并自动续期即将过期的 <cluster>-kubeconfig Secret 客户端证书；控制面节点 /root/.kube/config 会使用有效期约 10 年的客户端证书。
• 修复逐步升级过程中，业务集群历史 kubeconfig Secret 或 ClusterCredential 客户端证书已过期或即将在 30 天内过期时未自动轮换，导致业务集群访问异常的问题。控制器现在会检测并重新签发客户端证书，并更新对应的 Secret/凭据。
• 修复从 3.16.2 升级到 4.0.x 后，升级脚本生成的 apiserver.crt 缺少 Authority Key Identifier (AKI) 扩展，导致新版 Go TLS 客户端（如 Jenkins 流水线）连接 kube-apiserver 失败的问题。升级生成的 apiserver.crt 现在会携带 AKI 信息。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复卸载 Multus 后，Pod 无法正常创建的问题。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.8

发布于：2026-01-07

#已修复问题

• 长期未登录而被系统自动禁用的用户，在管理员手动激活后会被再次自动禁用，导致激活操作无法生效。此问题已经解决。
• 修复手动删除 ovn-db 文件后 ovn-central 无法自动恢复的问题
• 修复由于 ovn-central 竞态问题引发的同时存在两个 leader 的问题。

#已知问题

• 修复长期运行或创建超过一年的集群中 kubeconfig 客户端证书过期后，可能导致平台页面返回 500、kubectl 命令执行异常以及 Apollo 等组件访问异常的问题。控制器现在会检测并自动续期即将过期的 <cluster>-kubeconfig Secret 客户端证书；控制面节点 /root/.kube/config 会使用有效期约 10 年的客户端证书。
• 修复逐步升级过程中，业务集群历史 kubeconfig Secret 或 ClusterCredential 客户端证书已过期或即将在 30 天内过期时未自动轮换，导致业务集群访问异常的问题。控制器现在会检测并重新签发客户端证书，并更新对应的 Secret/凭据。
• 修复了 olm-registry pod 持续重启导致 OperatorHub 无法正常使用的问题。该问题由 CIS 合规加固时添加的 `seccompProfile: RuntimeDefault` 安全配置引起，该配置拦截了 CGO 操作所需的 `clone` 系统调用。已调整 seccomp 配置以允许必要的系统调用，同时保持安全合规性。已在 ACP 4.0.9 修复。
• 修复了当集群安装 60+ 个 Operator 时，原生应用创建接口权限校验极慢（10秒以上）的性能问题。已在 ACP 4.0.9 修复。
• 修复了 marketplace 插件在 workload 集群安装失败的问题。已在 ACP 4.0.9 修复。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复卸载 Multus 后，Pod 无法正常创建的问题。
• 修复 egress gateway 无法路由和 egress gateway 同网段 Pod 流量问题。已在 ACP 4.0.9 修复。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.7

发布于：2025-12-10

#已修复问题

• 在此更新之前，Tekton Pipeline 组件存在 Kubernetes STIG 安全漏洞，其中密钥通过 tekton-hub-api 部署中的环境变量暴露，违反了安全最佳实践。通过此次更新，环境变量中的密钥挂载逻辑已被完全移除，确保 tekton-hub-api 部署不再暴露任何凭据，符合 Kubernetes STIG 安全要求。
• 在此更新之前，Tekton Results 中的 tekton-results-retention-policy-agent 容器在环境变量中包含敏感信息，在容器操作和日志记录场景中存在以明文形式暴露凭据的安全风险。通过此次更新，敏感信息已得到适当保护并从环境变量中移除，以防止凭据泄露，确保 retention-policy-agent 容器在其配置中不再包含明文密码或令牌，从而增强了 Tekton Results 系统的整体安全态势。
• 在此更新之前，tekton-results-postgres-0 中的 PostgreSQL 容器包含带有敏感信息的环境变量，如 PASSWORD、password、TOKEN 和 token，当这些凭据以明文形式暴露时存在安全风险。通过此次更新，敏感环境变量已得到适当保护，不再包含明文密码或令牌，确保敏感凭据得到安全处理，不会在容器环境变量中暴露。
• 在此更新之前，tekton-results-api 容器的环境变量包含敏感信息，当这些凭据以明文形式暴露时存在安全风险。通过此次更新，敏感环境变量已得到适当保护，密码和令牌信息不再以明文形式暴露，增强了 tekton-results-api 组件的安全性。
• 在此更新之前，流水线界面存在多个显示问题，包括文本显示问题、变量完成多行功能用户体验不佳，以及更新触发器时的不稳定行为，其中参数和工作空间有时会出现有时会消失，需要用户重新选择流水线才能使它们出现（包括流水线列表）。通过此次更新，这些显示问题已得到解决。流水线和流水线运行页面现在正确显示，具有改进的文本渲染、增强的变量完成多行功能以提供更好的用户体验，以及稳定的触发器更新行为，其中参数和工作空间一致出现，无需重新选择流水线。
• 之前 upmachinepool 资源的 status 字段会保存对应的 machine 资源，但未进行排序，导致在每次 reconcile 时都被判定为需要更新，从而造成审计数据过大。该问题现已修复。
• 修复了在项目导入命名空间过程中，修改Pod 安全策略配置不生效的问题。
• 修复了在控制台中更新 Deployment 时，特定操作顺序会导致容器 lifecycle 配置意外丢失的问题。

#已知问题

• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复手动删除 ovn-db 文件后 ovn-central 无法自动恢复的问题
• 修复由于 ovn-central 竞态问题引发的同时存在两个 leader 的问题。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.6

发布于：2025-11-03

#已修复问题

• 修复了在平台从 v3.x 升级至 v4.x 后，若业务集群未升级，则其在新自定义监控面板中创建的监控指标无法用于 HPA 的问题。

#已知问题

• 之前 upmachinepool 资源的 status 字段会保存对应的 machine 资源，但未进行排序，导致在每次 reconcile 时都被判定为需要更新，从而造成审计数据过大。该问题现已修复。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复手动删除 ovn-db 文件后 ovn-central 无法自动恢复的问题
• 修复由于 ovn-central 竞态问题引发的同时存在两个 leader 的问题。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 修复了在控制台中更新 Deployment 时，特定操作顺序会导致容器 lifecycle 配置意外丢失的问题。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.5

发布于：2025-09-30

#已修复问题

• 之前从集群卸载 Operator 后，其状态会错误地显示为 Absent，尽管实际状态仍为 Ready。用户需要通过 violet upload 手动重新上传才能恢复。此问题现已修复，Operator 在卸载后将正确显示为 Ready。
• 使用 violet upload 上传 Operator 新版本后，偶尔会出现无法安装新版本的情况。该问题已被修复。
• 当 Operator 或 Cluster Plugin 中包含多个前端扩展时，前端扩展的左侧导航可能会出现点击无反应的问题。此前的临时解决方法是为扩展的 ConfigMap 添加注解 cpaas.io/auto-sync: "false"。该问题现已在代码层面正式修复。

#已知问题

• Redis 哨兵实例从 v5 升级到 v7 时，偶现脑裂的情况，会导致数据丢失。
  解决方案：在跨版本升级前，对 Redis 实例进行数据备份。
• 当集群网络异常， PostgreSQL 实例的主节点 Lable 更新失败时，会导致 PostgreSQL 状态异常，部分新建连接可能会失败。
  临时解决方案：网络恢复正常后，PostgreSQL 实例会自动恢复至正常状态。
• 在此更新之前，流水线界面存在多个显示问题，包括文本显示问题、变量完成多行功能用户体验不佳，以及更新触发器时的不稳定行为，其中参数和工作空间有时会出现有时会消失，需要用户重新选择流水线才能使它们出现（包括流水线列表）。通过此次更新，这些显示问题已得到解决。流水线和流水线运行页面现在正确显示，具有改进的文本渲染、增强的变量完成多行功能以提供更好的用户体验，以及稳定的触发器更新行为，其中参数和工作空间一致出现，无需重新选择流水线。
• 之前 upmachinepool 资源的 status 字段会保存对应的 machine 资源，但未进行排序，导致在每次 reconcile 时都被判定为需要更新，从而造成审计数据过大。该问题现已修复。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。
• Statefulset 的 POD 停止后再启动，平台会以当天 POD 的最早的运行时间为开始时间，以最晚的运行时间为结束时间，而忽略中间没有运行的时间。最终导致该 POD 的计量数据比实际时长多。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 修复手动删除 ovn-db 文件后 ovn-central 无法自动恢复的问题
• 修复由于 ovn-central 竞态问题引发的同时存在两个 leader 的问题。
• 修复了在平台从 v3.x 升级至 v4.x 后，若业务集群未升级，则其在新自定义监控面板中创建的监控指标无法用于 HPA 的问题。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 修复了在控制台中更新 Deployment 时，特定操作顺序会导致容器 lifecycle 配置意外丢失的问题。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.0.4

发布于：2025-09-01

#已修复问题

• 以前在升级集群时，会遗留 CRI（Container Runtime Interface）Pod，从而阻塞集群继续升级到 4.1。该问题已在 4.0.4 中修复。

#已知问题

此次发版无相关问题。

#4.0.3

发布于：2025-07-01

#已修复问题

• 修复了无法删除使用 Calico 的高可用集群 master 节点的问题。

#已知问题

• 以前在升级集群时，会遗留 CRI（Container Runtime Interface）Pod，从而阻塞集群继续升级到 4.1。该问题已在 4.0.4 中修复。
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385

#4.0.2

发布于：2025-06-06

#已修复问题

• 修复了在托管到平台的公有云 Kubernetes 集群（如 ACK）上执行节点 Drain 操作失败并返回 404 的问题。

#已知问题

• 修复了无法删除使用 Calico 的高可用集群 master 节点的问题。
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385

#4.0.1

发布于：2025-05-04

#已修复问题

• 修复 frontend 访问 erebus 时未设置 HTTP 连接超时时间的问题。此前每次访问 erebus 都会创建新的 HTTP client，且连接未配置超时，可能导致 socket 持续泄露并最终耗尽本地临时 TCP 端口，进而造成前端页面无法正常访问。
• 在集群 api-server 压力过大的场景下，kyverno-report-controller 中的 aggregate worker 有概率无法启动，导致合规报告无法正常创建。这会阻止 PolicyReport 资源的创建，使 Web Console 无法展示违规资源信息或只能显示部分报告数据。排查方法是检查 kyverno-report-controller pod 日志中是否存在 "starting worker aggregate-report-controller/worker" 信息以验证其是否正常运行。如未正常运行，临时解决方案是手动重启 kyverno-report-controller。

#已知问题

• 修复了无法删除使用 Calico 的高可用集群 master 节点的问题。
• 修复了在托管到平台的公有云 Kubernetes 集群（如 ACK）上执行节点 Drain 操作失败并返回 404 的问题。
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385

#4.0.0

发布于：2025-04-08

#功能与增强

#安装与升级：模块化架构

我们已全面重构平台架构，以提供前所未有的灵活性、更快的更新速度以及更低的运维开销。

简化安装
现在，平台通过一个轻量级的核心包进行部署，该包仅包含必需组件。基础就绪后，客户可以按需选择所需的 Operator 或集群插件——无论是 DevOps、Service Mesh 还是其他专用功能——并分别下载、上传和安装它们。

定向补丁

• 补丁版本仅包含确实需要修复 bug 的组件。
• 未包含修复的组件保持原样，确保平台其余部分不受影响。
• 客户通过平台内置的标准化升级机制应用补丁，而不是手动更新单个组件，从而使维护和跟踪更加简便。

智能升级

• 升级过程中，仅替换并重启有新代码的组件。
• 未修改的组件保留现有版本和正常运行时间。
• 这可最大限度减少停机时间，并缩短维护窗口，从而带来更平滑的升级体验。

独立的组件版本管理

• 大多数 Operator 都遵循各自独立于核心平台的发版节奏。
• 新功能和修复一经就绪即可上线，无需等待整个平台更新。
• 这种方式加快了交付速度，让客户能更快受益于改进。

#集群：使用 Cluster API 进行声明式集群生命周期管理

本地部署集群现在借助 Kubernetes Cluster API 实现完全声明式操作，包括：

• 集群创建
• 节点扩缩容和加入

这种无缝的 Cluster API 集成可直接融入您的 IaC 流水线，实现对集群生命周期的端到端程序化控制。

#Operator 与扩展：全面的能力可见性

完整的 Operator 目录

OperatorHub 现在会显示所有受支持的 Operator，无论其包是否已上传到平台。此增强功能：

• 即使在 air-gapped 环境中，也能完整展示平台能力
• 消除可用能力与用户已知信息之间的差距
• 降低探索平台能力时的发现成本

版本灵活性

用户现在可以在安装期间选择特定的 Operator 版本，而不再仅限于最新版本，从而更好地控制组件兼容性和升级路径。

Web Console 扩展

Operator 现在支持基于锚点的 Web Console 扩展，允许将面向特定功能的前端镜像包含在 Operator 内，并无缝集成到平台的 Web Console 中。

集群插件增强

对 Operator 可见性、版本选择以及 Web Console 扩展能力的所有改进，同样适用于集群插件，确保在所有平台扩展中提供一致的用户体验。

#日志查询逻辑优化

日志查询页面已优化，以解决用户在使用日志查询功能时遇到的体验和性能问题：

• 原有的单选框已替换为高级搜索组件。现在，您可以像使用 GIT 搜索一样使用日志搜索。
• 日志内容支持独立查询条件
• 时间查询条件的位置已调整。现在，在调整时间范围时，不会重置日志筛选条件。
• 优化了日志查询 API，以提升整体查询性能

#ElasticSearch 升级到 8.17

我们将 ElasticSearch 升级到 8.17，以跟进社区的功能和改进。

#ALB 认证

ALB 现在支持多种认证机制，这使用户可以在 Ingress 层处理认证，而无需在每个后端应用中分别实现。

#ALB 支持 ingress-nginx 注解

本版本在 ALB 中新增对常见 ingress-nginx 注解的支持，包括 keepalive 设置、超时配置和 HTTP 重定向，从而增强与社区 ingress-nginx 的兼容性。

#KubeVirt 热迁移优化

在热迁移过程中，网络中断时间已缩短至 0.5 秒以内，现有 TCP 连接不会断开。
这一优化显著提升了生产环境中虚拟机迁移的稳定性和可靠性。

#LDAP/OIDC 集成优化

LDAP/OIDC 集成表单字段已调整，主要包括移除不必要/重复的字段以及优化字段描述。
LDAP/OIDC 集成现在支持通过 YAML 进行配置，允许在 YAML 文件中进行用户属性映射。

#Source to Image (S2I) 支持

• 新增 Alauda Container Platform Builds operator，用于从源代码自动构建镜像
• 支持 Java/Go/Node.js/Python 语言栈
• 通过源代码仓库简化原生应用部署

#本地 Registry 解决方案

• ACP Registry 提供了轻量级 Docker Registry，并具备企业级功能
• 提供开箱即用的镜像管理能力
• 简化原生应用交付

#GitOps 模块重构

• 将 ACP GitOps 解耦为独立的集群插件架构
• 将 Argo CD 升级到 v2.14.x 版本
• 增强基于 GitOps 的原生应用生命周期管理

#命名空间级监控

• 在命名空间级别引入动态监控仪表板
• 提供 Applications/Workloads/Pods 指标可视化

#Crossplane 集成

• 发布 Alauda Build of Crossplane 发行版
• 通过 XRD 组合实现以应用为中心的资源交付

#虚拟化更新

• 升级到 KubeVirt 1.4，以增强虚拟化能力
• 优化镜像处理，加快虚拟机部署
• 优化 VM 热迁移，现在可直接从 UI 发起，并可查看迁移状态
• 改进绑定网络，支持双栈（IPv4/IPv6）
• 新增 vTPM 支持，以增强 VM 安全性

#Ceph 存储更新

• 带有 stretch cluster 的 Metro-DR 可在可用区之间实现实时数据同步
• 基于存储池镜像的 Regional-DR 增强数据保护

#TopoLVM 更新

• 新增对多路径设备部署的支持，提升灵活性和稳定性

#已修复问题

• 以前，Operator 上架新版本后，用户需等待 10 分钟才能安装新版本。现在等待时间已缩短至 2 分钟，使用户能更快地安装 Operator 的新版本。

• 在单节点多张卡的gpu节点上，gpu-manager 偶尔会存在，针对使用 vgpu 的应用调度不成功问题。
• 使用pgpu插件时，需要将gpu节点上的默认 runtimeclass设置为nvidia。如果不设置，可能会导致应用无法正常请求gpu资源。
• 在单张 GPU 卡上，使用 gpu-manager 无法同时创建基于 vllm、mlserver 的多个推理服务
  在 AI 平台上，使用 gpu-manager 创建多个推理服务时，会出现该问题；在容器平台上，使用 gpu-manager 创建多个智能应用时，不会出现该问题。
• 使用mps时，当节点资源不足时，pod会无限重启。

#已知问题

• 修复了无法删除使用 Calico 的高可用集群 master 节点的问题。
• 在从 3.18.0 升级到 4.0.1 时，如果 global 集群使用内置镜像仓库且开启了 protect-secret-files 开关，执行升级脚本可能会超时报错。此问题已在 ACP 4.1.0 修复。
• 偶发情况下，Pod 可能卡在 Terminating 状态且无法被 containerd 删除。尽管 containerd 执行了删除操作，但容器仍处于伪运行状态。containerd 日志显示 "OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown"，而容器状态显示为 Running。此问题在 containerd 1.7.23 版本中极少发生（仅观察到一次），触发时只影响单个 Pod。如遇此情况，可通过重启 containerd 作为临时解决方法。这是 containerd 社区已知问题，详见 https://github.com/containerd/containerd/issues/6080。
• 将集群升级到 Kubernetes 1.31 时，集群中的所有 Pod 将会重启。这是由于 Kubernetes 1.31 中对 Pod Spec 字段的变更所导致，无法避免。更多详情，请参阅 Kubernetes 问题报告：https://github.com/kubernetes/kubernetes/issues/129385
• 在集群 api-server 压力过大的场景下，kyverno-report-controller 中的 aggregate worker 有概率无法启动，导致合规报告无法正常创建。这会阻止 PolicyReport 资源的创建，使 Web Console 无法展示违规资源信息或只能显示部分报告数据。排查方法是检查 kyverno-report-controller pod 日志中是否存在 "starting worker aggregate-report-controller/worker" 信息以验证其是否正常运行。如未正常运行，临时解决方案是手动重启 kyverno-report-controller。
• 修复了通过 UI 界面创建的 Secret 仅包含 Username 和 Password，而缺少 auth 认证信息，与 kubectl create 行为不一致的问题。该问题曾导致依赖完整认证信息的构建工具（如 buildah）出现认证失败。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。

此次发版无相关问题。

• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。