发版日志
目录
4.2.4已修复问题已知问题4.2.3已修复问题已知问题4.2.2已修复问题已知问题4.2.1已修复问题已知问题4.2.0功能与增强支持 Kubernetes 1.33ACP CLI (ac)托管控制平面(HCP)增强的用户权限管理基于 Kyverno 增强的 Pod 安全策略基于 Envoy Gateway 的下一代 Gateway API基于域名的 Egress Firewall 规则新增 Endpoint Health Checker,加快故障切换新增 Local Storage Operator,简化 Ceph/TopoLVM 管理其他关键变更日志插件生命周期变更增强 namespace 的默认安全级别MinIO 进入维护模式Calico 进入维护模式Ingress Nginx 切换为 Operator弃用和移除的功能Kubernetes 版本升级策略更新ALB 从 v4.2.0 开始弃用Flannel 完全移除已修复问题已知问题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 配置项,但实际不会生效。
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复了向内置镜像仓库推送包含超多数据层(100+)的容器镜像时失败的问题
- 调整了实时日志组件中的部分文案, 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 配置项,但实际不会生效。
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复了在 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 配置项,但实际不会生效。
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复 metis 组件 storage limit 配置太小,在超出限制后导致 metis 容器重启
- 修复了推送超过 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 配置项,但实际不会生效。
- 修复了系统无法正常获取存储设备 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)
托管控制平面(HCP)
已发布:
- Alauda Container Platform Kubeadm Provider
- Alauda Container Platform Hosted Control Plane
- Alauda Container Platform SSH Infrastructure Provider
生命周期: Agnostic(与 ACP 异步发布)
托管控制平面通过将每个集群的控制平面作为容器化组件托管在管理集群中,将控制平面与工作节点解耦。该架构可减少资源占用,加快集群创建和升级速度,并为大规模多集群环境提供更好的可扩展性。
更多信息请参见: About Hosted Control Plane
增强的用户权限管理
我们通过以下增强优化了 RBAC 管理,以提升易用性和可维护性:
-
平台角色管理:
- 基于 UI 的权限自定义已弃用: 平台角色不再支持通过 Web 控制台进行自定义权限配置。所有角色权限都必须通过 YAML 文件配置。
- 保持向后兼容: 现有的平台预置角色以及旧版本中定义的角色仍可完全正常使用。用户可以继续像以前一样将这些角色分配给用户并授予权限。
-
Kubernetes 角色管理:
- 原生 Kubernetes 角色管理: 平台控制台现已提供专门的 Kubernetes Role 和 ClusterRole 资源管理界面,可直接将 Kubernetes 角色与用户关联并分配权限。
- 模块化权限定义: 平台插件资源权限将逐步迁移为独立的 Role 和 ClusterRole 资源,从而提供更好的隔离性和更易管理性。
基于 Kyverno 增强的 Pod 安全策略
我们通过 Kyverno policy engine 强化了 workload 安全能力:
- 即用型安全模板:控制台内置 8 个已验证的安全 policy 模板,覆盖 Pod Security Standards 的各个级别,包括 Privileged、Baseline、Nonroot 和 Restricted
- 一键配置:无需手动编写 YAML,即可在业务视图中基于模板快速创建 policy,并立即在指定 namespace 中生效
基于 Envoy Gateway 的下一代 Gateway API
本次发版引入了基于 Envoy Gateway 的全新 Gateway API 实现。它提供统一的 L7 流量入口,与社区 Gateway API 规范保持一致,并为更丰富的流量策略和生态集成奠定基础。
基于域名的 Egress Firewall 规则
Egress Firewall 现在支持基于域名而非仅基于 IP 地址的 allow/deny 规则。这使得对公共 SaaS 服务和 IP 地址经常变化的外部资源能够进行更精细的出站访问控制。
新增 Endpoint Health Checker,加快故障切换
新增 Endpoint Health Checker,可更快检测节点崩溃和网络分区等故障,并及时移除不健康的 backend。这显著缩短了流量故障切换时长,并降低了服务中断风险。
新增 Local Storage Operator,简化 Ceph/TopoLVM 管理
新引入的 Local Storage(Alauda Build of Local Storage)Operator 极大简化了 Ceph 和 TopoLVM 的部署和磁盘管理。在部署过程中,您可以列出集群中的所有可用磁盘,包括型号、容量和其他关键属性,并选择需要纳管的磁盘。 在磁盘绑定方面,Ceph 和 TopoLVM 现在优先使用 device IDs 而不是挂载路径,以避免因节点重启或设备重新识别导致 device 名称变化而引发的存储问题。
其他关键变更
日志插件生命周期变更
日志相关插件的生命周期状态已从 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
更多信息请参见: About Logging Service
增强 namespace 的默认安全级别
从 v4.2.0 开始,新建 namespace(通过 Web 控制台或 CLI) 的默认 PSA policy 已从 Baseline 改为 Restricted。
- Baseline:禁止已知的权限提升,提供中等安全性
- Restricted:遵循 Pod 安全最佳实践,要求最严格
Restricted policy 对 Pods 的配置要求非常严格。如果您的业务需要 privileged mode、以 root 用户运行、挂载 host path 或使用 host network 等能力,那么这些 workload 在默认使用 Restricted policy 的 namespace 中将无法运行。
影响分析:
- 此变更仅影响新创建的 namespace
- 需要特权能力的 workload(例如 root 用户、hostPath 挂载)将无法直接运行
推荐解决方案:
- 修改应用配置,使其满足 Restricted policy 的安全要求
- 如有必要,手动将 namespace policy 调整回 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 执行失败的问题。