docs(acp): ACP 4.5 + Alauda OS 标准交付规划（单集群 / 多集群）— 中文审阅稿 by chinameok · Pull Request #853 · alauda/knowledge

chinameok · 2026-10-12T10:50:43Z

这是 ACP 4.5 + Alauda OS 标准交付规划的中文审阅稿，覆盖单集群和多集群两种交付方式：要准备的机器、节点池与插件的放置和存储、按顺序排列的操作步骤（每一步链接到产品文档）。

本 PR 删除了此前基于 ACP 4.4 的 5 篇交付文章，改为这一篇新文章。
现在是中文，方便直接在 PR 上评审。评审通过后会改为英文，再转为 Ready for review。
ACP 4.5 GA 前不合并。
文中链接指向尚未上线的 ACP 4.5 文档站，GA 后才能打开。
磁盘规划尚未写入，要等插件清单确认后再补。

🤖 Generated with Claude Code

The production delivery counterpart to Full-Stack Automation with ACP: the reference design (component selection, topologies, node pools and taint scheme, single persistent /var/cpaas disk, per-cluster observability), the end-to-end delivery flow including the DR domain- switch sequencing, the acp-delivery-charts rendering workflow, plugin placement by pool layout, machine configuration order, sizing by derivation from the capacity pages, and evidence-based acceptance. Encodes decisions verified in real ACP 4.3 deliveries. Tracking: AIT-74918 under Epic AIT-74911. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The link checker strips .md/.mdx but not .markdown, so the relative link resolved to a non-existent .markdown.html route and failed the build. Reference the article by title instead; titles are searchable in this knowledge base. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The delivery charts are withdrawn: hand-orchestrating the Cluster API manifests is the product reality on ACP 4.3, and no chart tooling will be maintained for the released lines. Section 3 now points at the product pages that hold the complete manifests (global install Step 4, the DR increments, Huawei DCS "Using YAML"), and keeps only what those pages scatter or deliveries get wrong: naming as a hard requirement on both sides, credentials out of applied manifests, one manifest set per cluster, reading shared values from global via the DCS page's placeholder table, keeping the provider literals, maxSurge 0 for persistent-disk pools, the three DR increments identical on both sides, and a pre-apply checklist. Wherever a product page already states a rule, the article links instead of restating it. The sizing and archive sentences that referred to chart values or rendered output are reworded to match. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The product documentation this article links to adopted the acp/specs platform glossary (alauda/acp-docs#1187, alauda/immutable-infra-docs #221/#222): "traditional OS" is now "non-Alauda OS" and "bootstrap host" is "bootstrap node". Follow the same wording so a reader moving between the article and the linked pages sees one name per concept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…gate R&D confirmed that an Alauda OS global installation does not need two bootstrap nodes — the primary and standby installations can share one. The delivery flow now provisions one bootstrap node for both, the "never reuse one bootstrap node" line is removed, and the single-cluster topology no longer lists "one bootstrap node" as if it distinguished it from the multi-cluster case. Stage 5 also listed "CPU meets x86-64-v2" as a pass criterion for the bootstrap node. The installation guide states that baseline applies to cluster nodes, not to the bootstrap node; the criterion now points at the guide's bootstrap node requirements instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Corrects the previous commit. R&D has now confirmed (2026-10-15) that a disaster-recovery delivery of an Alauda OS global needs two bootstrap nodes, one to install the primary and one to install the standby; the shared-bootstrap reading was a misunderstanding. Stage 5 provisions two again, "Never reuse one bootstrap node for both sides" is back, and the single-cluster notes list one bootstrap node as what sets them apart. Kept from the previous commit: the bootstrap node has no x86-64-v2 pass criterion (that baseline applies to cluster nodes), and the wrapped "bootstrap host" now reads "bootstrap node". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…nifests Replace the ACP 4.3 "orchestrate and link" DCS draft with five ACP 4.4 articles that let a delivery engineer complete a standard delivery by filling in parameter files and applying the given manifests: - How to Deliver ACP with Immutable Infrastructure (common): reference design, parameter files and the render helpers (site.env + one file per cluster, envsubst with an explicit variable list, Bash fallback), delivery flow, platform plugins (Machine Configuration, MetalLB, Ingress NGINX, VictoriaMetrics, ClickHouse + Keeper + Kafka logging), machine configuration, sizing and acceptance commands. - Huawei DCS, Huawei Cloud Stack and Bare Metal: global primary and standby (disaster recovery) plus workload clusters. - VMware vSphere: workload clusters only. Every manifest is assembled from the ACP 4.4 product documentation, uses ${VAR} placeholders documented in a parameter table, keeps credentials out of files and command lines, and is followed by the check that proves the step worked. The articles say they must be validated in a staging environment before a production delivery. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Three corrections to the ACP 4.4 Immutable Infrastructure articles. Local storage is TopoLVM. The reference design replaces the open "choose a StorageClass whose volumes survive node replacement" guidance with the selected system: the console-driven install, the node-local constraint the product states (application-layer replication only, no independent persistence guarantee, ReadWriteOnce), and the StorageClass values this delivery chooses. Two gaps are stated rather than papered over: TopoLVM needs one unformatted disk per node, which only vSphere documents how to provide, and the product's `lvm2` prerequisite assumes a mutable node. The logging stack install is deferred. Its deployment scheme is being revised, so the manifests and checks are removed and the section now points at the Logging Service documentation while keeping the placement, storage and sizing decisions this design already fixes. The log pool, its nodes and its disks stay in the provider manifests. Disaster recovery no longer explains steps with "`cpaas-system` is excluded from synchronization". The rule set works on key prefixes with a maintained deny-list; most objects cross, Secrets included. Each `global` side keeps its own plugins, because `ModuleInfo` objects named `global-` are excluded, and its own machine configuration, which is not synchronized at all — so machine configuration is applied on both sides. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…elivery plan (Chinese review draft) Remove the five ACP 4.4 Immutable Infrastructure delivery articles and add one article that plans the standard delivery of ACP 4.5 on Alauda OS for a single cluster and for multiple clusters: machines, node pools, plugin placement and storage, and the ordered steps, each linking to the product documentation. The article is in Chinese for review and will be translated into English before the pull request leaves Draft. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

chinameok · 2026-11-13T12:44:05Z

+
+## 一、单集群
+
+global 集群同时承载业务，约 20 个业务 worker，不做容灾。


这里需要说明下，20 个 worker 只供参考，安装后可根据集群的控制平面机器负载情况自行评估按需扩容。并给出产品文档的链接 https://docs.alauda.io/container_platform/4.5/configure/scalability/evaluating_workload.html
由于单集群的场景是 global 用作 workload 集群的场景，所以链接给的是 workload 集群的资源评估文档。
并且，文档中大量的文档链接是错的，并且由于在线文档还没有及时更新，所以你可以根据 github acp-docs 中文档的位置推断出文档站点的链接，并放在本文档中。

chinameok · 2026-11-13T12:49:18Z

+
+| 节点池 | 台数 | CPU | 内存 | 用途 |
+|---|---:|---|---|---|
+| bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 只在安装时使用，装完即可回收 |


如果用户机器资源有限，且用户无法提供镜像仓库，也可以将 bootstrap 机器用作 mirror-registry ，mirror-registry 将作为平台镜像仓库。

chinameok · 2026-11-13T12:51:28Z

+| bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 只在安装时使用，装完即可回收 |
+| control-plane | 3 | 16 核 | 32 GiB | 控制面和平台组件 |
+| infra | 3 | 12 核 | 48 GiB | 监控、日志、Ingress、MetalLB |
+| worker | 约 20 | 按业务定 | 按业务定 | 业务负载 |


worker 这行可以删了，和文档无关，不涉及平台交付资源申请和操作。

chinameok · 2026-11-13T12:52:26Z

+| infra | 3 | 12 核 | 48 GiB | 监控、日志、Ingress、MetalLB |
+| worker | 约 20 | 按业务定 | 按业务定 | 业务负载 |
+
+使用 ARM 节点时，按 [Machines][plan-machines] 中的规则放大规格。


说明下，这是建议，不是强制要求。

chinameok · 2026-11-13T12:52:49Z

+|---|---|---|
+| control-plane | `controlPlane` | `deployMode` 保持默认值 `normal`，不要设成 `base` |
+| infra | `computes[]` 中的一个节点组 | 集群建好后，按 [Create Infra Nodes on Alauda OS Nodes][infra-aos] 在节点池上声明 infra 标签和污点 |
+| worker | `computes[]` 中的一个节点组 | — |


worker 这行可以删了

chinameok · 2026-11-13T12:55:33Z

+| infra | `computes[]` 中的一个节点组 | 集群建好后，按 [Create Infra Nodes on Alauda OS Nodes][infra-aos] 在节点池上声明 infra 标签和污点 |
+| worker | `computes[]` 中的一个节点组 | — |
+
+控制面端点用 Self-built VIP；Huawei Cloud Stack 例外，用 provider 创建的 ELB。各 provider 支持的端点模式见 [Endpoint Modes][endpoint-modes]，字段见 [Installation Reference][install-config]。


这里说下，用户如果有商业负载均衡，产品也支持使用商业负载均衡作为平台访问的 vip 。并不是只能使用自建 vip 。
用户自己决策。
tips: 平台流量一般不大，商业负载均衡可能性能过剩。

chinameok · 2026-11-13T12:57:15Z

+| 功能 | 插件 | 装在 | 存储 |
+|---|---|---|---|
+| 应用入口 | Alauda Container Platform Ingress Controller | infra | — |
+| 应用入口 VIP | Alauda Container Platform Load Balancer（MetalLB） | infra | — |


当用户有商业负载均衡时，建议用商业负载均衡，而不是 metallb 。

chinameok · 2026-11-13T12:58:34Z

+
+global 集群同时承载业务，约 20 个业务 worker，不做容灾。
+
+### 1. 准备机器


这个章节应该叫做资源需求

chinameok · 2026-11-13T12:59:07Z

+
+使用 ARM 节点时，按 [Machines][plan-machines] 中的规则放大规格。
+
+### 2. 安装规划


这个章节叫做方案选型比较好

chinameok · 2026-11-13T12:59:53Z

+
+### 2. 安装规划
+
+**节点池**


节点池和控制平面端点建议放到资源需求里面

chinameok · 2026-11-13T13:08:54Z

+| 日志采集 | Alauda Container Platform Log Collector | 所有节点 | — |
+| 监控 API、日志查询 | Alauda Container Platform Observability Essentials、Alauda Container Platform Log Essentials | control-plane | — |
+| 本地块存储 | Alauda Container Platform Storage Essentials、Alauda Container Platform LVM Volume Provisioner（TopoLVM） | 有 TopoLVM 盘的节点 | — |
+| 镜像仓库（业务镜像） | Alauda Container Platform Registry | 待定 | TopoLVM，单副本 |


建议放 infra

chinameok · 2026-11-13T13:09:21Z

+| 监控 API、日志查询 | Alauda Container Platform Observability Essentials、Alauda Container Platform Log Essentials | control-plane | — |
+| 本地块存储 | Alauda Container Platform Storage Essentials、Alauda Container Platform LVM Volume Provisioner（TopoLVM） | 有 TopoLVM 盘的节点 | — |
+| 镜像仓库（业务镜像） | Alauda Container Platform Registry | 待定 | TopoLVM，单副本 |
+| 应用备份 | Alauda Container Platform Data Backup Essentials、Alauda Container Platform Data Backup（Velero） | control-plane | 客户提供的集群外对象存储 |


从里面删除，应用备份不进 sop

chinameok · 2026-11-13T13:16:33Z

+
+控制面端点用 Self-built VIP；Huawei Cloud Stack 例外，用 provider 创建的 ELB。各 provider 支持的端点模式见 [Endpoint Modes][endpoint-modes]，字段见 [Installation Reference][install-config]。
+
+**插件、位置与存储**


这里应该先放功能选型和存储选型。比如日志用 clickhouse ，监控用 victoriametrics
然后再放插件清单，并且插件只放 infra 的插件，用户知道这些插件是会装在 infra 的。
https://gitlab-ce.alauda.cn/alauda-ai/alauda-ai-base/-/blob/main/base/knowledge/base/acp/operator-list-4.5.md 可以从 Location 字段知道哪些是安装在 infra 的

chinameok · 2026-11-13T13:19:34Z

+| 镜像仓库（业务镜像） | Alauda Container Platform Registry | 待定 | TopoLVM，单副本 |
+| 应用备份 | Alauda Container Platform Data Backup Essentials、Alauda Container Platform Data Backup（Velero） | control-plane | 客户提供的集群外对象存储 |
+
+- 单集群不部署 Ceph，所有需要持久卷的组件都用 TopoLVM。镜像仓库因此只有一个副本，所在节点故障时不可用。


这句话没有用。可以删了吧

chinameok · 2026-11-13T13:20:01Z

+| 应用备份 | Alauda Container Platform Data Backup Essentials、Alauda Container Platform Data Backup（Velero） | control-plane | 客户提供的集群外对象存储 |
+
+- 单集群不部署 Ceph，所有需要持久卷的组件都用 TopoLVM。镜像仓库因此只有一个副本，所在节点故障时不可用。
+- 客户提供不了集群外对象存储时，不交付应用备份。etcd 备份只保存在本地 `/var/cpaas/backup`，见 [etcd 备份][etcd-backup]。


etcd 备份应该在操作步骤，sop 建议用户安装后安装 etcd 备份的插件。

chinameok · 2026-11-13T13:20:10Z

+
+- 单集群不部署 Ceph，所有需要持久卷的组件都用 TopoLVM。镜像仓库因此只有一个副本，所在节点故障时不可用。
+- 客户提供不了集群外对象存储时，不交付应用备份。etcd 备份只保存在本地 `/var/cpaas/backup`，见 [etcd 备份][etcd-backup]。
+- 不安装：Alauda Container Platform Basic Monitoring、Alauda Container Platform Gateway API Controller、Alauda Storage（Ceph）、DevOps 工具。需要 DevOps 工具时，改用多集群方式交付。


这句话可以删了

chinameok · 2026-11-13T13:21:16Z

+- 客户提供不了集群外对象存储时，不交付应用备份。etcd 备份只保存在本地 `/var/cpaas/backup`，见 [etcd 备份][etcd-backup]。
+- 不安装：Alauda Container Platform Basic Monitoring、Alauda Container Platform Gateway API Controller、Alauda Storage（Ceph）、DevOps 工具。需要 DevOps 工具时，改用多集群方式交付。
+
+### 3. 操作步骤


操作步骤安装最新的 acp-docs release-4.5 内容放，因为结构有调整。
链接你可以通过文件位置推断产品文档链接是什么

- Rename the sections to resource requirements and solution selection, and move node pools and the control plane endpoint into the requirements. - Drop the business worker rows; mark the sizes as recommendations and point to the workload cluster sizing page for scaling after installation. - Allow the bootstrap node to host mirror-registry, a commercial load balancer for the control plane endpoint, and a commercial load balancer instead of MetalLB for application ingress. - List feature and storage choices first, then the plugins that run on infra nodes; place the registry on infra. - Remove application backup; add the etcd backup plugin as an install step. - Reorder the steps to follow the 4.5 installation flow, including publishing the Common Extensions, and apply the same changes to the multi-cluster part. - Link index pages by directory and check every link against release-4.5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

chinameok had a problem deploying to translate October 12, 2026 10:50 — with GitHub Actions Failure

chinameok temporarily deployed to translate October 13, 2026 04:04 — with GitHub Actions Inactive

chinameok temporarily deployed to translate October 13, 2026 06:36 — with GitHub Actions Inactive

chinameok temporarily deployed to translate October 13, 2026 10:32 — with GitHub Actions Inactive

chinameok temporarily deployed to translate October 15, 2026 06:08 — with GitHub Actions Inactive

chinameok temporarily deployed to translate October 15, 2026 06:17 — with GitHub Actions Inactive

Merge branch 'main' into docs/acp-standard-delivery-dcs

3154b6e

chinameok temporarily deployed to translate October 15, 2026 07:33 — with GitHub Actions Inactive

chinameok temporarily deployed to translate October 15, 2026 16:50 — with GitHub Actions Inactive

chinameok changed the title ~~How to Deliver ACP on Huawei DCS with Immutable Infrastructure~~ docs(acp): deliver ACP 4.4 on Immutable Infrastructure — common article + DCS / HCS / Bare Metal / vSphere with complete manifests Oct 15, 2026

chinameok temporarily deployed to translate October 18, 2026 03:14 — with GitHub Actions Inactive

chinameok changed the title ~~docs(acp): deliver ACP 4.4 on Immutable Infrastructure — common article + DCS / HCS / Bare Metal / vSphere with complete manifests~~ docs(acp): ACP 4.5 + Alauda OS 标准交付规划（单集群 / 多集群）— 中文审阅稿 Nov 13, 2026

chinameok deployed to translate November 13, 2026 04:46 — with GitHub Actions Active

chinameok commented Nov 13, 2026

View reviewed changes

chinameok deployed to translate November 13, 2026 13:39 — with GitHub Actions Active


		## 一、单集群

		global 集群同时承载业务，约 20 个业务 worker，不做容灾。


		global 集群同时承载业务，约 20 个业务 worker，不做容灾。

		### 1. 准备机器


		使用 ARM 节点时，按 [Machines][plan-machines] 中的规则放大规格。

		### 2. 安装规划


		控制面端点用 Self-built VIP；Huawei Cloud Stack 例外，用 provider 创建的 ELB。各 provider 支持的端点模式见 [Endpoint Modes][endpoint-modes]，字段见 [Installation Reference][install-config]。

		插件、位置与存储

Conversation

chinameok commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chinameok Nov 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chinameok Nov 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chinameok Nov 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

chinameok commented Oct 12, 2026 •

edited

Loading

chinameok Nov 13, 2026 •

edited

Loading

chinameok Nov 13, 2026 •

edited

Loading

chinameok Nov 13, 2026 •

edited

Loading