Skip to content

docs(acp): ACP 4.5 + Alauda OS 标准交付规划(单集群 / 多集群)— 中文审阅稿 - #853

Draft
chinameok wants to merge 12 commits into
mainfrom
docs/acp-standard-delivery-dcs
Draft

chinameok wants to merge 12 commits into
mainfrom
docs/acp-standard-delivery-dcs

Conversation

@chinameok

@chinameok chinameok commented Oct 12, 2026 •

Copy link
Copy Markdown
Contributor

这是 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>
@chinameok 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
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 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
| 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 | 按业务定 | 按业务定 | 业务负载 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- 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>

| 节点池 | 台数 | CPU | 内存 | 用途 |
|---|---:|---|---|---|
| bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 运行安装程序;也可兼作平台镜像仓库 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这里把 4 c 8gb 写出来吧。
见 [Bootstrap Node][bootstrap-hw] 可以放备注里面。

|---|---:|---|---|---|
| bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 运行安装程序;也可兼作平台镜像仓库 |
| control-plane | 3 | 16 核 | 32 GiB | 控制面和平台组件 |
| infra | 3 | 12 核 | 48 GiB | 监控、日志、Ingress、镜像仓库 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

12 核是不是不对?你怎么算的?这里不应该是 16 核吗?

|---|---:|---|---|---|
| bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 运行安装程序;也可兼作平台镜像仓库 |
| control-plane | 3 | 16 核 | 32 GiB | 控制面和平台组件 |
| infra | 3 | 16 核 | 32 GiB | global 自己的监控和日志 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

少了 ingress ,为什么内核要求反而更高了。
只是少了 ingress ,为什么内存要求少了这么多?

| 节点池 | 台数 | CPU | 内存 | 用途 |
|---|---:|---|---|---|
| control-plane | 3 | 8 核 | 16 GiB | 控制面和平台组件 |
| infra | 3 | 12 核 | 48 GiB | 监控、日志、Ingress、镜像仓库 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这里的 infra 规格理论上和单集群的 infra 一样,不应该不一样吧。

|---|---:|---|---|---|
| control-plane | 3 | 8 核 | 16 GiB | 控制面和平台组件 |
| ingress | 2 | 4 核 | 8 GiB | Ingress |
| monitor | 3 | 12 核 | 48 GiB | 监控 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

只是监控需要这么多资源?


(b) 约 150 个业务 worker,非业务节点分池:

| 节点池 | 台数 | CPU | 内存 | 用途 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

核对下 ingress , monitor 和 log 的资源需求大小,感觉不太对

| monitor | 3 | 12 核 | 48 GiB | 监控 |
| log | 3 | 12 核 | 48 GiB | 日志 |

**客户没有商业存储时,还需要两个集群**

@chinameok chinameok Nov 14, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

错了。这句话是不对的。
如果 workload 集群有存储需求,建议集群部署中小规模的 ceph ,参考 openshift 的存储资源规划。我们的资源要求不应该比 openshift 要求的多。
devops 建议单独准备集群,并且依赖的存储和中间件安装在 devops 集群。

| 应用入口 VIP(workload) | 客户有商业负载均衡时用商业负载均衡;没有时用 MetalLB | — |
| 镜像仓库(业务镜像,workload) | ACP Registry | 存储集群的 Ceph RGW |
| workload 上其他需要持久卷的组件 | 以 External Mode 接入存储集群 | Ceph RBD |
| 虚拟机(如交付) | — | Ceph RBD |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

虚拟机删除

| 应用入口(workload) | Ingress NGINX | — |
| 应用入口 VIP(workload) | 客户有商业负载均衡时用商业负载均衡;没有时用 MetalLB | — |
| 镜像仓库(业务镜像,workload) | ACP Registry | 存储集群的 Ceph RGW |
| workload 上其他需要持久卷的组件 | 以 External Mode 接入存储集群 | Ceph RBD |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

错误。
如果客户希望用 Alauda Storage 作为商业存储的替代,专门大规模使用,需要找产研评估下。

| 功能 | 选型 | 存储 |
|---|---|---|
| 监控 | VictoriaMetrics,每个集群各装一套 | TopoLVM |
| 日志 | ClickHouse + Kafka,每个集群各装一套 | TopoLVM |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

日志不用下 kafka 这个不是选型,并且未来可能日志可以支持不需要 kafka


**装在 infra 上的插件**

| 集群 | 节点池 | 插件 |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这么写看不清。
如果你想写清楚哪个节点上有哪些,分 3 个表是否更清晰?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

单独整理下磁盘需求,等我 review 后,再商量放文档哪里。
我要知道机器需要多大磁盘,为什么需要这么多,都是哪些组件分别需要用多少。

…e 4.5 delivery plan

- State the bootstrap node size (4 cores, 8 GB) and move the link to a note.
- Replace the separate storage cluster with an in-cluster Ceph for workload
  clusters that need storage, and keep DevOps tools with their storage and
  middleware in a dedicated DevOps cluster. Remove virtual machines.
- List ClickHouse alone as the logging choice.
- Split the infra plugin list into one table per cluster layout.
- Point the bootstrap link to its hardware section.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch was successfully deployed

1 active deployment
translate — 3d6c7511 Deployed Nov 14, 2026 by chinameok via build #2793
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants