Repository navigation
Conversation
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>
| | 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 | 按业务定 | 按业务定 | 业务负载 | |
There was a problem hiding this comment.
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] | 运行安装程序;也可兼作平台镜像仓库 | |
There was a problem hiding this comment.
这里把 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、镜像仓库 | |
There was a problem hiding this comment.
12 核是不是不对?你怎么算的?这里不应该是 16 核吗?
| |---|---:|---|---|---| | ||
| | bootstrap | 1 | 见 [Bootstrap Node][bootstrap-hw] | 见 [Bootstrap Node][bootstrap-hw] | 运行安装程序;也可兼作平台镜像仓库 | | ||
| | control-plane | 3 | 16 核 | 32 GiB | 控制面和平台组件 | | ||
| | infra | 3 | 16 核 | 32 GiB | global 自己的监控和日志 | |
There was a problem hiding this comment.
少了 ingress ,为什么内核要求反而更高了。
只是少了 ingress ,为什么内存要求少了这么多?
| | 节点池 | 台数 | CPU | 内存 | 用途 | | ||
| |---|---:|---|---|---| | ||
| | control-plane | 3 | 8 核 | 16 GiB | 控制面和平台组件 | | ||
| | infra | 3 | 12 核 | 48 GiB | 监控、日志、Ingress、镜像仓库 | |
There was a problem hiding this comment.
这里的 infra 规格理论上和单集群的 infra 一样,不应该不一样吧。
| |---|---:|---|---|---| | ||
| | control-plane | 3 | 8 核 | 16 GiB | 控制面和平台组件 | | ||
| | ingress | 2 | 4 核 | 8 GiB | Ingress | | ||
| | monitor | 3 | 12 核 | 48 GiB | 监控 | |
|
|
||
| (b) 约 150 个业务 worker,非业务节点分池: | ||
|
|
||
| | 节点池 | 台数 | CPU | 内存 | 用途 | |
There was a problem hiding this comment.
核对下 ingress , monitor 和 log 的资源需求大小,感觉不太对
| | monitor | 3 | 12 核 | 48 GiB | 监控 | | ||
| | log | 3 | 12 核 | 48 GiB | 日志 | | ||
|
|
||
| **客户没有商业存储时,还需要两个集群** |
There was a problem hiding this comment.
错了。这句话是不对的。
如果 workload 集群有存储需求,建议集群部署中小规模的 ceph ,参考 openshift 的存储资源规划。我们的资源要求不应该比 openshift 要求的多。
devops 建议单独准备集群,并且依赖的存储和中间件安装在 devops 集群。
| | 应用入口 VIP(workload) | 客户有商业负载均衡时用商业负载均衡;没有时用 MetalLB | — | | ||
| | 镜像仓库(业务镜像,workload) | ACP Registry | 存储集群的 Ceph RGW | | ||
| | workload 上其他需要持久卷的组件 | 以 External Mode 接入存储集群 | Ceph RBD | | ||
| | 虚拟机(如交付) | — | Ceph RBD | |
| | 应用入口(workload) | Ingress NGINX | — | | ||
| | 应用入口 VIP(workload) | 客户有商业负载均衡时用商业负载均衡;没有时用 MetalLB | — | | ||
| | 镜像仓库(业务镜像,workload) | ACP Registry | 存储集群的 Ceph RGW | | ||
| | workload 上其他需要持久卷的组件 | 以 External Mode 接入存储集群 | Ceph RBD | |
There was a problem hiding this comment.
错误。
如果客户希望用 Alauda Storage 作为商业存储的替代,专门大规模使用,需要找产研评估下。
| | 功能 | 选型 | 存储 | | ||
| |---|---|---| | ||
| | 监控 | VictoriaMetrics,每个集群各装一套 | TopoLVM | | ||
| | 日志 | ClickHouse + Kafka,每个集群各装一套 | TopoLVM | |
There was a problem hiding this comment.
日志不用下 kafka 这个不是选型,并且未来可能日志可以支持不需要 kafka
|
|
||
| **装在 infra 上的插件** | ||
|
|
||
| | 集群 | 节点池 | 插件 | |
There was a problem hiding this comment.
这么写看不清。
如果你想写清楚哪个节点上有哪些,分 3 个表是否更清晰?
There was a problem hiding this comment.
单独整理下磁盘需求,等我 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>
这是 ACP 4.5 + Alauda OS 标准交付规划的中文审阅稿,覆盖单集群和多集群两种交付方式:要准备的机器、节点池与插件的放置和存储、按顺序排列的操作步骤(每一步链接到产品文档)。
🤖 Generated with Claude Code