#ACP 4.0

#小版本: 4.0.0

#特性与增强

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

我们彻底重新设计了平台的架构，以提供前所未有的灵活性、更快速的更新和更低的运营成本。

核心包安装

我们的平台现在支持通过精简的核心包进行安装，该包仅包含基本组件。在安装好这个基础后，用户可以有选择地下载、上传和安装他们所需的 Operator 或集群插件——无论是 DevOps、Service Mesh 还是其他专用功能。

有针对性的修复

平台修复现在以显著提高的效率进行交付：

• 关键修复的交付时间从一个月减少到两周
• 平台更新现在仅包含需要修复的组件
• 在更新过程中，稳定组件保持不变，最大限度地减少系统影响

智能升级

平台升级经过革命性改进，以最小化运营影响：

• 没有代码更改的组件在升级过程中保持版本稳定
• 版本迁移时仅更新已更改的组件
• 系统重启仅限于那些需要更改的组件

独立组件版本管理

许多平台 Operator 现在遵循独立发布周期，使我们能够更快速地交付新功能，而无需等待完整的平台发布周期。

#集群：增强的基础设施即代码

基于 YAML 的集群管理

本地集群现在完全支持基于 YAML 的操作，包括：

• 集群创建
• 节点添加
• 配置管理

此增强功能无缝集成到基础设施即代码（IaC）工作流程中，使程序化的集群生命周期管理成为可能。

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

完整的 Operator 目录

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

• 提供对平台能力的全面可见性，即使在隔离网络环境中
• 消除了可用性与用户已知信息之间的信息差距
• 减少了在探索平台功能时的发现摩擦

版本灵活性

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

Web 控制台扩展

Operator 现在支持基于锚点的 Web 控制台扩展，允许功能特定的前端图像包含在 Operator 中，并无缝集成到平台的 Web 控制台。

集群插件增强

所有的 Operator 可见性、版本选择和 Web 控制台扩展功能的改进同样适用于集群插件，确保所有平台扩展一致的用户体验。

#日志查询逻辑优化

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

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

#ElasticSearch 升级到 8.17

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

#ALB 认证

ALB 现在支持多种认证机制，使用户能够在 Ingress 层处理认证，而不是在每个后端应用中实现。

#ALB 支持 ingress-nginx 注解

此版本新增对 ALB 中常用 ingress-nginx 注解的支持，包括保持活动设置、超时配置和 HTTP 重定向，增强了与社区 ingress-nginx 的兼容性。

#Kubevirt 现场迁移优化

在现场迁移过程中，网络中断时间已减少到不足 0.5 秒，现有 TCP 连接将不会断开。此优化显著提高了生产环境中虚拟机迁移的稳定性和可靠性。

#LDAP/OIDC 集成优化

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

#源码至镜像 (S2I) 支持

• 新增 ACP Builds Operator，用于从源代码自动构建镜像
• 支持 Java/Go/Node.js/Python 语言栈
• 简化通过源代码库的应用部署

#本地注册解决方案

• ACP Registry 提供轻量级 Docker 注册中心，具备企业级功能
• 提供即开即用的镜像管理能力
• 简化应用交付

#GitOps 模块重构

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

#命名空间级监控

• 引入命名空间级的动态监控仪表板
• 提供应用/工作负载/Pods 指标可视化

#Crossplane 集成

• 发布 Alauda Build of Crossplane 发行版
• 通过 XRD 组合实现应用中心的配置

#虚拟化更新

• 升级至 KubeVirt 1.4，以增强虚拟化能力
• 优化镜像处理，以加快虚拟机配置速度
• 优化虚拟机现场迁移，现在可以直接从 UI 发起并显示迁移状态
• 改进绑定网络，支持双栈（IPv4/IPv6）
• 新增 vTPM 支持，以增强虚拟机安全性

#Ceph 存储更新

• 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会无限重启。

#已知问题

• 偶发情况下，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。

• 当单容器的日志量过大时(标准输出或者文件日志)，会出现一个日志文件达到了rotate的阈值，触发了rotate，但是其中的日志内容还没有采集完毕，从而导致新老日志文件同时采集，日志顺序混乱。