#发版日志

#4.2.5

发布日期：2026-06-08

#已修复问题

• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 修复了 underlay 网络下使用 MetalLB + ALB 高可用方案时，创建新的 LoadBalancer 并设置 ExternalTrafficPolicy 为 Local 后，OVN Load_Balancer 表中 ip_port_mapping 字段被新 Service 覆盖，导致已有 ALB 实例从集群外部不可达的问题。
• 修复了向内置镜像仓库推送包含超多数据层（100+）的容器镜像时失败的问题
• 修复了分布式存储中 Ceph 存储池监控条用量计算不准确（按已用逻辑存储量/理论最大可写逻辑数据量计算），导致 OSD 仍有约 50% 可用空间时监控条误报爆红的问题。
• 修复了升级到 4.2.2 后产生大量 OVN 变更请求审计记录、导致审计数据过大的问题。
• 修复了 u2o 模式下不同 underlay 子网之间意外互通的问题，现已实现 underlay 子网间的隔离。
• 修复了添加新节点时 Multus 插件偶现不在该节点上生效的问题。
• 修复 metis 组件 storage limit 配置太小，在超出限制后导致 metis 容器重启
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 修复了 kube-multus-ds 组件的 hostPath 存储卷使用了不安全主机路径的安全合规问题。

#已知问题

• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 修复了 underlay 网络下使用 MetalLB + ALB 高可用方案时，创建新的 LoadBalancer 并设置 ExternalTrafficPolicy 为 Local 后，OVN Load_Balancer 表中 ip_port_mapping 字段被新 Service 覆盖，导致已有 ALB 实例从集群外部不可达的问题。
• 修复了向内置镜像仓库推送包含超多数据层（100+）的容器镜像时失败的问题
• 修复了分布式存储中 Ceph 存储池监控条用量计算不准确（按已用逻辑存储量/理论最大可写逻辑数据量计算），导致 OSD 仍有约 50% 可用空间时监控条误报爆红的问题。
• 修复了升级到 4.2.2 后产生大量 OVN 变更请求审计记录、导致审计数据过大的问题。
• 修复了 u2o 模式下不同 underlay 子网之间意外互通的问题，现已实现 underlay 子网间的隔离。
• 修复了添加新节点时 Multus 插件偶现不在该节点上生效的问题。
• 修复 metis 组件 storage limit 配置太小，在超出限制后导致 metis 容器重启
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.2.4

发布日期：2026-03-27

#已修复问题

• 平台对接 IDP 用户认证登录时，若用户名存在大写字母，ArgoCD 将无法正常获取该用户的权限信息。该问题已在 4.2.4 版本解决。
• 修复了在 image-registry 的 imagePullSecret 自动轮询通过“新建 Secret + 删除旧 Secret”进行轮转、且历史 Pod 仍引用旧 Secret 并在 Secret 过期后才启动的场景下，Pod 无法拉取镜像的问题。
• 修复了在业务应用使用自定义 ServiceAccount 的场景下，imagePullSecret 未自动注入导致镜像拉取失败的问题。
• 修复了推送超过 1GB 的大镜像时，因 Registry Proxy 默认 30 秒超时导致的连接中断及推送失败问题。延长了 Proxy 组件的 HTTP 转发超时时间，并开启流式转发（Streaming），提升大数据量下的传输效率与稳定性。

#已知问题

• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 修复了 underlay 网络下使用 MetalLB + ALB 高可用方案时，创建新的 LoadBalancer 并设置 ExternalTrafficPolicy 为 Local 后，OVN Load_Balancer 表中 ip_port_mapping 字段被新 Service 覆盖，导致已有 ALB 实例从集群外部不可达的问题。
• 修复了向内置镜像仓库推送包含超多数据层（100+）的容器镜像时失败的问题
• 修复了分布式存储中 Ceph 存储池监控条用量计算不准确（按已用逻辑存储量/理论最大可写逻辑数据量计算），导致 OSD 仍有约 50% 可用空间时监控条误报爆红的问题。
• 修复了升级到 4.2.2 后产生大量 OVN 变更请求审计记录、导致审计数据过大的问题。
• 修复了 u2o 模式下不同 underlay 子网之间意外互通的问题，现已实现 underlay 子网间的隔离。
• 修复了添加新节点时 Multus 插件偶现不在该节点上生效的问题。
• 修复 metis 组件 storage limit 配置太小，在超出限制后导致 metis 容器重启
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.2.3

发布日期：2026-03-16

#已修复问题

• 在4.2.2版本中，平台无法自动同步对接的 LDAP 服务器中的数据，此问题已在4.2.3版本修复。
• 在 4.2.2 版本中，创建项目设置配额以及已有项目更新配额均无法生效，此问题已在4.2.3版本修复。
• 修复了容器组列表页面执行批量删除操作时，因“权限不足”导致任务失败的问题。恢复了核心管理组件缺失的批量操作相关 RBAC 权限。
• 增强了 Multus CNI 的安全性，支持以非特权用户身份运行服务。
• 修复在 v4.2.2 存在的 Argo Rollouts 插件部署失败的问题

#已知问题

• 平台对接 IDP 用户认证登录时，若用户名存在大写字母，ArgoCD 将无法正常获取该用户的权限信息。该问题已在 4.2.4 版本解决。
• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 修复了 underlay 网络下使用 MetalLB + ALB 高可用方案时，创建新的 LoadBalancer 并设置 ExternalTrafficPolicy 为 Local 后，OVN Load_Balancer 表中 ip_port_mapping 字段被新 Service 覆盖，导致已有 ALB 实例从集群外部不可达的问题。
• 修复了升级到 4.2.2 后产生大量 OVN 变更请求审计记录、导致审计数据过大的问题。
• 修复 metis 组件 storage limit 配置太小，在超出限制后导致 metis 容器重启
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 修复了在 image-registry 的 imagePullSecret 自动轮询通过“新建 Secret + 删除旧 Secret”进行轮转、且历史 Pod 仍引用旧 Secret 并在 Secret 过期后才启动的场景下，Pod 无法拉取镜像的问题。
• 修复了在业务应用使用自定义 ServiceAccount 的场景下，imagePullSecret 未自动注入导致镜像拉取失败的问题。
• 修复了推送超过 1GB 的大镜像时，因 Registry Proxy 默认 30 秒超时导致的连接中断及推送失败问题。延长了 Proxy 组件的 HTTP 转发超时时间，并开启流式转发（Streaming），提升大数据量下的传输效率与稳定性。
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.2.2

发布日期：2026-02-11

#已修复问题

• 修复了安装 Alauda Container Platform Cluster Enhancer 插件后 etcd 没有定时备份的问题。该问题由升级时创建的 BroadcastJob 缺少 scheduledTimeAnnotation 注解引起，导致 AdvancedCronJob 无法计算下次触发时间。修复后当注解缺失时会使用任务创建时间作为备用方案，确保定时备份正常执行。已在 ACP 4.2.2 修复。
• 修复了 olm-registry pod 持续重启导致 OperatorHub 无法正常使用的问题。该问题由 CIS 合规加固时添加的 `seccompProfile: RuntimeDefault` 安全配置引起，该配置拦截了 CGO 操作所需的 `clone` 系统调用。已调整 seccomp 配置以允许必要的系统调用，同时保持安全合规性。已在 ACP 4.2.2 修复。
• 修复了当集群安装 60+ 个 Operator 时，原生应用创建接口权限校验极慢（10秒以上）的性能问题。已在 ACP 4.2.2 修复。
• 修复了系统无法正常获取存储设备 DeviceID 的缺陷，该缺陷曾导致 Web 控制台将存储设备的状态错误地标记为“不推荐”。
• 修复 egress gateway 无法路由和 egress gateway 同网段 Pod 流量问题

#已知问题

• 平台对接 IDP 用户认证登录时，若用户名存在大写字母，ArgoCD 将无法正常获取该用户的权限信息。该问题已在 4.2.4 版本解决。
• 在4.2.2版本中，平台无法自动同步对接的 LDAP 服务器中的数据，此问题已在4.2.3版本修复。
• 在 4.2.2 版本中，创建项目设置配额以及已有项目更新配额均无法生效，此问题已在4.2.3版本修复。
• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 修复了 underlay 网络下使用 MetalLB + ALB 高可用方案时，创建新的 LoadBalancer 并设置 ExternalTrafficPolicy 为 Local 后，OVN Load_Balancer 表中 ip_port_mapping 字段被新 Service 覆盖，导致已有 ALB 实例从集群外部不可达的问题。
• 修复了升级到 4.2.2 后产生大量 OVN 变更请求审计记录、导致审计数据过大的问题。
• 修复 metis 组件 storage limit 配置太小，在超出限制后导致 metis 容器重启
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 修复了推送超过 1GB 的大镜像时，因 Registry Proxy 默认 30 秒超时导致的连接中断及推送失败问题。延长了 Proxy 组件的 HTTP 转发超时时间，并开启流式转发（Streaming），提升大数据量下的传输效率与稳定性。
• 修复了容器组列表页面执行批量删除操作时，因“权限不足”导致任务失败的问题。恢复了核心管理组件缺失的批量操作相关 RBAC 权限。
• 修复在 v4.2.2 存在的 Argo Rollouts 插件部署失败的问题
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.2.1

发布日期：2026-01-09

#已修复问题

• 在升级 Global 集群时存在一个偶发问题，导致 Web Console 的左侧导航栏中无法看到 Marketplace 菜单。此问题已在 ACP 4.2.1 中修复。
• 当使用 Alauda Container Platform Cluster Enhancer 提供的 etcd 备份功能时，如果用户配置将 etcd 备份到 S3 存储，插件无法获取 secretRef 中引用的 Secret 对象。原因是插件缺少读取 Secret 的 RBAC 权限，导致 S3 认证信息获取失败。此问题已在 ACP 4.2.1 中修复。
• 在使用 Global Cluster Disaster Recovery 方案时，安装 Alauda Container Platform etcd Synchronizer 后，Standby Cluster 的 Web Console 无法登录。原因是 etcd Synchronizer 没有正确忽略 k8sadmin-* 相关的 Secret 对象，导致 Standby Cluster 的认证信息被覆盖。此问题已在 ACP 4.2.1 中修复。
• 修复了连接 MinIO 时无法通过 SkipSSLVerify 参数跳过 HTTPS 证书校验的问题。

#已知问题

• 平台对接 IDP 用户认证登录时，若用户名存在大写字母，ArgoCD 将无法正常获取该用户的权限信息。该问题已在 4.2.4 版本解决。
• 修复了安装 Alauda Container Platform Cluster Enhancer 插件后 etcd 没有定时备份的问题。该问题由升级时创建的 BroadcastJob 缺少 scheduledTimeAnnotation 注解引起，导致 AdvancedCronJob 无法计算下次触发时间。修复后当注解缺失时会使用任务创建时间作为备用方案，确保定时备份正常执行。已在 ACP 4.2.2 修复。
• 修复了 olm-registry pod 持续重启导致 OperatorHub 无法正常使用的问题。该问题由 CIS 合规加固时添加的 `seccompProfile: RuntimeDefault` 安全配置引起，该配置拦截了 CGO 操作所需的 `clone` 系统调用。已调整 seccomp 配置以允许必要的系统调用，同时保持安全合规性。已在 ACP 4.2.2 修复。
• 修复了当集群安装 60+ 个 Operator 时，原生应用创建接口权限校验极慢（10秒以上）的性能问题。已在 ACP 4.2.2 修复。
• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在某些情况下，用户会发现平台自动在 ResourcePatch 资源中记录的操作与用户实际对组件做的修改不一致，导致 ResourcePatch 控制器 apply 时，引发组件的非预期更改。
  临时解决方案： 用户需手动修改 ResourcePatch 资源，使其与预期变更保持一致。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 修复了双栈集群中 Pod 手动配置了错误的固定 IPv6 地址后，即使更正为正确地址，ovn-controller 仍未正确处理、导致对应子网段后续 IP 无法正常分配的问题。
• 修复了系统无法正常获取存储设备 DeviceID 的缺陷，该缺陷曾导致 Web 控制台将存储设备的状态错误地标记为“不推荐”。
• 修复 egress gateway 无法路由和 egress gateway 同网段 Pod 流量问题
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。

#4.2.0

发布日期：2025-12-09

#功能与增强

#支持 Kubernetes 1.33

ACP 现已支持 Kubernetes 1.33，为您带来来自 Kubernetes 社区的最新上游功能、性能改进和安全增强。

#ACP CLI (ac)

新的 ACP CLI (ac) 让您可以通过流畅的命令行体验在 ACP 上开发、构建、部署和运行应用。

主要能力包括：

• 与 kubectl 兼容的命令
• 与 ACP 平台环境集成的认证
• 跨多个环境的统一会话管理
• 用于平台访问和跨环境工作流的 ACP 专属扩展

完整功能详情请参见： ACP CLI (ac)

#Hosted Control Plane (HCP)

已发布：

• Alauda Container Platform Kubeadm Provider
• Alauda Container Platform Hosted Control Plane
• Alauda Container Platform SSH Infrastructure Provider

生命周期： Agnostic（与 ACP 异步发布）

Hosted Control Plane 通过将每个集群的控制平面作为容器化组件托管在管理集群中，将控制平面与工作节点解耦。该架构可降低资源消耗，加快集群创建和升级，并为大规模多集群环境提供更好的可扩展性。

更多信息请参见： 关于 Hosted Control Plane

#增强的用户权限管理

我们通过以下增强优化了 RBAC 管理，以提升易用性和可维护性：

• 平台角色管理：

  • 基于 UI 的权限自定义已弃用： 平台角色不再支持通过 Web 控制台进行自定义权限配置。所有角色权限都必须通过 YAML 文件进行配置。
  • 保持向后兼容： 现有的平台预置角色以及旧版本中定义的角色仍可完全正常使用。用户可以继续像以前一样将这些角色分配给用户并授予权限。

• Kubernetes 角色管理：

  • 原生 Kubernetes 角色管理： 平台控制台现已提供专门的 Kubernetes Role 和 ClusterRole 资源管理界面，支持将 Kubernetes 角色直接关联到用户并分配权限。
  • 模块化权限定义： 平台插件资源权限将逐步迁移为独立的 Role 和 ClusterRole 资源，从而提供更好的隔离性和更便捷的管理。

#借助 Kyverno 增强 Pod 安全策略

我们通过 Kyverno policy engine 增强了工作负载安全能力：

• 即用型安全模板：控制台内置 8 个经过验证的安全策略模板，覆盖 Pod Security Standards 的各个级别，包括 Privileged、Baseline、Nonroot 和 Restricted
• 一键配置：无需手动编写 YAML，即可在业务视图中基于模板快速创建策略，并立即在指定命名空间中生效

#由 Envoy Gateway 驱动的下一代 Gateway API

本版本引入了一个基于 Envoy Gateway 的全新 Gateway API 实现。它提供统一的 L7 流量入口，保持与社区 Gateway API 规范一致，并为更丰富的流量策略和生态集成奠定基础。

#Egress Firewall 的基于域名规则

Egress Firewall 现已支持基于域名而不仅仅是 IP 地址的允许/拒绝规则。这使得对公共 SaaS 服务以及 IP 地址频繁变化的外部资源可以进行更细粒度的出站访问控制。

#新的 Endpoint Health Checker，可实现更快故障切换

我们引入了新的 Endpoint Health Checker，用于更快检测 node 崩溃和网络分区等故障，并及时移除不健康的后端。这显著缩短了流量故障切换时长，并降低了服务中断风险。

#新的 Local Storage Operator，便于更轻松地管理 Ceph/TopoLVM

新引入的 Local Storage（Alauda Build of Local Storage）Operator 大幅简化了 Ceph 和 TopoLVM 的部署与磁盘管理。在部署过程中，您可以列出集群中所有可用磁盘，包括型号、容量及其他关键属性，并选择要纳入管理的磁盘。 在磁盘绑定方面，Ceph 和 TopoLVM 现在更倾向于使用 device ID，而不是挂载路径，从而避免因 node 重启或设备重新检测后设备名称变化而导致的存储问题。

#其他主要变更

#日志插件生命周期变更

日志相关插件的生命周期状态已从 Aligned 更改为 Agnostic（与 ACP 异步发布）。

受影响的插件：

• Alauda Container Platform Log Essentials（本版本新增）
• Alauda Container Platform Log Storage for ClickHouse
• Alauda Container Platform Log Storage for Elasticsearch
• Alauda Container Platform Log Collector

更多信息请参见： 关于 Logging Service

#命名空间默认安全级别增强

从 v4.2.0 开始，通过 Web 控制台或 CLI 新建的命名空间，其默认 PSA 策略已从 Baseline 更改为 Restricted。

• Baseline：禁止已知的权限提升，提供中等安全性
• Restricted：遵循 Pod 安全最佳实践，要求最严格

影响分析：

• 此变更仅影响新创建的命名空间
• 需要特权能力的工作负载（例如 root 用户、hostPath 挂载）将无法直接运行

建议的解决方案：

• 修改应用配置，使其满足 Restricted 策略的安全要求
• 如有必要，手动将命名空间策略改回 Baseline

#MinIO 进入维护模式

MinIO（Alauda Build of MinIO）已进入 维护模式。未来仅提供安全修复，不再规划新功能。现有 MinIO 集群可以继续运行，而新的对象存储需求建议优先选择 Ceph Object 作为推荐方案。

#Calico 进入维护模式

Calico（Alauda Container Platform Networking for Calico）CNI 插件已进入 维护模式。我们将仅处理与安全相关的问题，它也不再是默认推荐的网络选项。现有 Calico 集群仍受支持，而新集群应使用 kube-ovn 作为标准 CNI。

#Ingress Nginx 已切换为 Operator

Ingress Nginx（Alauda Build of Ingress Nginx）已从集群插件迁移为基于 Operator 的部署和管理模型。升级后现有 Ingress 资源将继续可用，后续操作预计通过 Operator 完成。尽管上游社区版本的 Ingress Nginx 已不再更新，我们仍将继续为该发行版提供 bug 修复和安全补丁。

#已弃用和已移除的功能

#Kubernetes 版本升级策略更新

从 ACP 4.2 开始，升级 Kubernetes 版本 不再是可选项。在执行集群升级时，Kubernetes 版本必须与其他平台组件一起升级。 此变更可确保整个集群的版本一致性，并减少未来的维护窗口。

#ALB 自 v4.2.0 起弃用

ALB（Alauda Container Platform Ingress Gateway）自 v4.2.0 起标记为弃用。新集群和新用户应优先采用基于 Envoy Gateway 的 Gateway API 作为主要方案。现有使用 ALB 的集群在升级后仍可继续工作，但我们强烈建议尽快规划并执行向 Gateway API 的迁移，以获得长期支持和功能演进。

#Flannel 已完全移除

Flannel（Alauda Container Platform Networking for Flannel）CNI 插件已从平台中完全移除。仍在使用 Flannel 的集群必须在升级到此版本或更高版本之前迁移到 kube-ovn。请提前规划并完成迁移，以避免因切换 CNI 而导致的服务中断。

#已修复问题

• 之前 upmachinepool 资源的 status 字段会保存对应的 machine 资源，但未进行排序，导致在每次 reconcile 时都被判定为需要更新，从而造成审计数据过大。该问题现已修复。
• 平台集群数量较多时，若使用批量设置项目配额功能为项目设置了配额后，将无法对单个集群的项目配额进行更新，此问题已修复。
• 之前在 OperatorHub 中创建集群级别的 Instance 时，由于 web console 自动添加了 metadata.namespace 字段，导致出现 404 报错。此问题已在 ACP 4.2.0 修复。
• 长期未登录而被系统自动禁用的用户，在管理员手动激活后会被再次自动禁用，导致激活操作无法生效。此问题已经解决。
• 之前从集群卸载 Operator 后，其状态会错误地显示为 Absent，尽管实际状态仍为 Ready。用户需要通过 violet upload 手动重新上传才能恢复。此问题现已修复，Operator 在卸载后将正确显示为 Ready。
• 使用 violet upload 上传 Operator 新版本后，偶尔会出现无法安装新版本的情况。该问题已被修复。
• 当 Operator 或 Cluster Plugin 中包含多个前端扩展时，前端扩展的左侧导航可能会出现点击无反应的问题。此前的临时解决方法是为扩展的 ConfigMap 添加注解 cpaas.io/auto-sync: "false"。该问题现已在代码层面正式修复。
• 之前当集群中存在 Display Name 为空的节点时，用户在节点详情页面打开面包屑的节点下拉筛选框，会无法通过输入内容来筛选节点。此问题已在 ACP 4.2.0 修复。
• 日志归档结束后未删除临时文件，导致磁盘无法得到释放，此问题已修复
• 使用 violet upload 对文件夹中的多个 package 进行上传时，以前会因磁盘空间不足而失败。现已优化为自动及时清理已上传的 package，避免出现该错误。
• 修复了在项目导入命名空间过程中，修改Pod 安全策略配置不生效的问题。
• 修复了 global 集群升级而 Workload 集群未升级时，Workload 集群内 Application、Deployment 等负载监控面板无法显示的问题。
• 修复了在低于 1.30 版本的 Kubernetes 环境中进行升级时，KubeVirt Operator 可能部署失败的问题。
• 修复了通过 UI 界面创建的 Secret 仅包含 Username 和 Password，而缺少 auth 认证信息，与 kubectl create 行为不一致的问题。该问题曾导致依赖完整认证信息的构建工具（如 buildah）出现认证失败。

#已知问题

• 当使用 Alauda Container Platform Monitoring for VictoriaMetrics 且多个集群共享同一个 Storage 时，告警策略 cpaas-certificates-rule 存在两个问题：告警触发时无法区分来自哪个集群，以及该策略会监控客户的 secret 而非仅监控平台证书。
• 在升级 Global 集群时存在一个偶发问题，导致 Web Console 的左侧导航栏中无法看到 Marketplace 菜单。此问题已在 ACP 4.2.1 中修复。
• 当使用 Alauda Container Platform Cluster Enhancer 提供的 etcd 备份功能时，如果用户配置将 etcd 备份到 S3 存储，插件无法获取 secretRef 中引用的 Secret 对象。原因是插件缺少读取 Secret 的 RBAC 权限，导致 S3 认证信息获取失败。此问题已在 ACP 4.2.1 中修复。
• 在使用 Global Cluster Disaster Recovery 方案时，安装 Alauda Container Platform etcd Synchronizer 后，Standby Cluster 的 Web Console 无法登录。原因是 etcd Synchronizer 没有正确忽略 k8sadmin-* 相关的 Secret 对象，导致 Standby Cluster 的认证信息被覆盖。此问题已在 ACP 4.2.1 中修复。
• 使用 violet push 推送 chart package 时，虽然 push 显示成功，但该 package 在 public-charts 仓库中可能无法看到。
  临时解决方案： 重新 push 一次。
• 虽然安装平台的页面中提供了 global 集群的 label 和 annotation 配置项，但实际不会生效。
• 调整了实时日志组件中的部分文案， Logging has ended => End of logs
• 修复了连接 MinIO 时无法通过 SkipSSLVerify 参数跳过 HTTPS 证书校验的问题。
• 如果自定义应用包含告警资源，且该告警资源中的指标表达式使用了自定义指标，那么当将该应用导出为 Chart 或应用 YAML 后，无论是通过导入 Chart 至平台，还是直接使用应用 YAML 创建应用，只要将其部署到与原应用命名空间名称不同的环境中，都会导致应用部署失败。
  
  解决方法为：手动修改 Chart 或 YAML 文件中告警资源内的指标表达式，将其中的命名空间标签值改为目标部署环境的命名空间。
• ceph-mgr 创建的默认存储池 .mgr 会使用默认的 Crush Rule，在延伸集群中不能正常选出 osd，所以必须使用 CephBlockPool 创建名为 .mgr 的存储池，但是因为时序上的不确定导致 mgr 可能先于 Rook Operator 去创建 .mgr 存储池导致出现该问题。
  遇到该问题后可以尝试重启 rook-ceph-mgr 的 pod，如果不能恢复需要清理后重新部署。
• 通过 YAML 创建应用时使用 defaultMode 字段导致应用创建失败。
  操作路径：容器平台 → 应用管理 → 应用列表 → 通过 YAML 创建（Create from YAML），当提交的 YAML 文件中包含 defaultMode 字段（通常用于 ConfigMap/Secret 的卷挂载权限配置）时，应用创建会失败并返回校验错误。
  解决方案：创建应用前手动移除 YAML 中所有 defaultMode 声明。
• 当 Helm Chart 中设置了 pre-delete post-delete hook。
  执行删除模板应用，卸载 Chart 时，遇到某些原因导致 hook 执行失败，进而导致应用无法删除。需要排查原因，并优先解决 hook 执行失败的问题。