From 248983c7c6864a9fb781a5231d7ec8e09a82b69b Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 10:13:44 +0800 Subject: [PATCH 01/14] docs: add ACP 4.4 release notes --- docs/en/overview/release_notes.mdx | 89 +++++++++++++----------------- 1 file changed, 37 insertions(+), 52 deletions(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index 3a1a6a825..6636f48e1 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -6,91 +6,76 @@ weight: 100 Review release notes with the [Kubernetes Support Matrix](./kubernetes-support-matrix.mdx), [Version and Lifecycle](./version-and-lifecycle.mdx), and feature-specific documentation to understand release changes and exact support boundaries. -## 4.3.0 +## 4.4.0 -### Release Baseline +### Features and Enhancements - 4.3 adds Kubernetes 1.34 support for platform-managed cluster creation and changes the upgrade prerequisite model so workload clusters can remain within the documented compatible-version range before the `global` cluster upgrade. +#### Kubernetes 1.35 and Upgrade Readiness -For 4.3, the compatible workload-cluster versions are 1.34, 1.33, 1.32, and 1.31. This compatible-version requirement determines whether the `global` cluster can be upgraded and is separate from the third-party cluster accepted onboarding range. + 4.4 upgrades the platform baseline to **Kubernetes 1.35**. Before upgrading, verify every production node meets the new Kubernetes requirements: the kernel must be version 5.8 or later, and the node must use cgroup v2. The upgrade preflight check blocks the upgrade until an administrator confirms that these checks are complete. -For more information, see [Kubernetes Support Matrix](./kubernetes-support-matrix.mdx). +For the required checks and acknowledgement procedure, see [Prepare for an Upgrade](../upgrade/pre-upgrade.mdx) and [Upgrade a Global Cluster](../upgrade/upgrade_global_cluster.mdx). -### Features And Enhancements +#### More Consistent Platform Installation and Upgrades -#### Kubernetes 1.34 Support + 4.4 improves installation and upgrade reliability. On a new `global` cluster, the upgrade-management component is installed automatically. Platform components are also installed in a fixed dependency order, reducing installation and upgrade failures when optional platform services are installed independently. - 4.3 supports Kubernetes 1.34 for platform-managed cluster creation. +For upgrade procedures, see [Upgrade](../upgrade/index.mdx). -For upgrades to 4.3, workload clusters must remain within the compatible versions 1.34, 1.33, 1.32, and 1.31. +#### Log Collection with Vector -#### CVO-Based Cluster Upgrade Workflow +The independently delivered Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. The ACP 4.4-compatible Log Collection plugin is released separately after the ACP 4.4 platform release; install it when the matching plugin package is available. - 4.3 introduces a Cluster Version Operator (CVO)-based upgrade workflow for both `global` and workload clusters. +For Logging Service information, see [About Logging Service](../observability/log/intro.mdx). -Key capabilities include: +#### External Image Registry Recommendation -- Preparing upgrade artifacts and the upgrade controller with `bash upgrade.sh`. -- Running preflight checks before execution. -- Requesting upgrades from the Web Console or by updating `ClusterVersionShadow.spec.desiredUpdate`. -- Inspecting conditions, preflight results, stages, and history from `cvsh.status`. +For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. -The CLI also introduces upgrade-oriented administrator commands such as `ac adm upgrade`, `ac adm upgrade status`, `--to-latest`, `--to`, and `--allow-explicit-upgrade` for requesting and troubleshooting workload cluster upgrades from the current context. +The platform built-in registry remains supported, but it is no longer the recommended default for new production environments. -For operational guidance, see [Upgrade](../upgrade/index.mdx). +#### Monitoring, Dashboards, and Cost Management -#### Standalone Cluster Plugin Upgrade +- **Perses Monitoring Dashboards** — Create and manage metric dashboards with the Perses dashboard experience, import supported Perses or Grafana dashboard JSON, and migrate existing `MonitorDashboard` resources when needed. Existing Monitoring Dashboards remain available during the transition. For details, see [Perses Monitoring Dashboards](../observability/monitor/functions/manage_perses_dashboard.mdx). - 4.3 adds standalone upgrade support for Cluster Plugins that use the `Aligned` or `Agnostic` lifecycle. +- **Fleet Monitoring** — Platform administrators can see connected clusters, monitoring-data freshness, resource capacity and utilization, and project quota allocation and usage in one multi-cluster view. Fleet Monitoring complements, rather than replaces, detailed monitoring and troubleshooting of an individual cluster. For details, see [Fleet Monitoring](../observability/monitor/functions/fleet_monitoring.mdx). -The **Cluster Plugins** page shows the plugin lifecycle, and eligible plugins can be upgraded independently from the list page or details page. `Core` plugins continue to follow cluster upgrades. +- **VictoriaMetrics for Cost Management** — Cost Management and metering can use VictoriaMetrics as their metrics data source. Queries are scoped to the relevant cluster, helping ensure that cost and resource-usage data is returned for the correct cluster in multi-cluster environments. For details, see [Cost Management](../costmanagement/cost_management.mdx). -For lifecycle details, see [Core and Extensions](./core-and-extensions.mdx) and [Cluster Plugin](../extend/cluster_plugin.mdx). +#### Global Cluster Disaster Recovery Enhancements -#### Alauda OS-Based Global Clusters +Global Cluster Disaster Recovery remains supported for both traditional operating system deployments and Alauda OS-based Immutable Infrastructure deployments. In 4.4, the synchronization path is more resilient and covers more of the `global` cluster lifecycle. This capability protects the `global` control plane; it does not protect application data. - 4.3 allows administrators to create the `global` cluster with Alauda OS-based immutable infrastructure in supported provider scenarios. This extends the immutable operating model from workload clusters to platform installation scenarios. +The standby cluster now preserves the active cluster's update order, including when recovery takes long enough for the active etcd to compact its history. The DR configuration can adapt when platform components change without replacing the DR service. The standby cluster also receives global-cluster upgrade state and workload-cluster lifecycle information, so it has the information required to take over more safely. -For more information, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx). +Before a DR switchover, or before a DR-aware `global` cluster upgrade removes the synchronizer, continue to validate that the active and standby clusters are consistent. This prevents stale standby data from causing incorrect recovery actions. -#### Immutable Infrastructure Provider Updates +For details, see [Global Cluster Disaster Recovery](../install/global_dr.mdx) and . - 4.3 expands Immutable Infrastructure coverage during the 4.3 cycle. Provider-specific Immutable Infrastructure guidance covers provider overview, installation, cluster creation, node management, cluster upgrades, and provider APIs. +#### Alauda OS Backup and Restore -For more information, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx). +Clusters that use Alauda OS can now use **Cluster Enhancer** for etcd backup and restore. You can run scheduled or on-demand backups, retain them on the control plane nodes, and optionally keep an additional copy in S3-compatible object storage. This protects cluster configuration data; an etcd restore overwrites the existing etcd data and must be performed according to the documented recovery procedure. -#### New Web Console Preview Entry +For configuration and recovery steps, see [etcd Backup and Restore](../configure/backup/etcd.mdx). - Core provides the top-navigation anchor required by the next-generation Web Console experience. When the Web Console Base plugin is installed on the `global` cluster, users in the **Container Platform** and **Administrator** views can open the new console through a **Preview Next-Gen Console** entry in a separate browser tab. +#### Access and Authorization -The experience is designed for gradual migration and works with the Web Console Base plugin on the `global` cluster and the Web Console Collector plugin on workload clusters. +- **Violet API-token publishing** — `violet`, the CLI used to package and publish plugins, now accepts a platform API token when publishing a package to the platform. Administrators and automation can publish without an interactive login. Download `violet` from the Customer Portal. For details, see [Upload Packages](../extend/upload_package.mdx). -#### Containerd 2.0 Baseline +- **In-platform CLI downloads** — Users can download ACP CLI packages from the web console for Linux (`amd64` and `arm64`), macOS (`amd64` and `arm64`), and Windows (`amd64`). - 4.3 upgrades the platform runtime baseline to containerd 2.0. Review runtime-dependent operational procedures before upgrading environments that rely on customized containerd configuration. +- **Safer role delegation** — The platform prevents users from granting permissions that exceed their own authorization boundary. The console also includes the related ClusterRole capabilities. -For runtime and architecture boundaries, see [Version and Lifecycle](./version-and-lifecycle.mdx). +#### Immutable Infrastructure -#### Expanded Third-Party Cluster Accepted Onboarding Range + 4.4 continues to expand the documented Immutable Infrastructure path for Alauda OS, the supported operating system for immutable nodes in the documented provider scenarios. The following capabilities are available in their supported provider scenarios: -For third-party clusters, 4.3 accepts Kubernetes versions in the range `>=1.19.0 <1.35.0`. +- **Bare Metal cluster lifecycle** — Create and manage both `global` and workload clusters on supported Bare Metal environments. The `global` cluster path includes Global Cluster Disaster Recovery. +- **Control plane and storage resilience** — Improve control-plane availability through provider placement rules or a self-built control-plane VIP where no load balancer is available, and preserve declared local disks when nodes are replaced during a rolling upgrade. +- **Network and host configuration** — Configure multiple network interfaces for node traffic isolation where supported. On Huawei Cloud Stack, a node can retain both its short hostname and its FQDN. +- **Safer Huawei DCS virtual-machine operations** — Stop a virtual machine before deleting its node, and remove the boot CD-ROM attachment after startup so it does not prevent later VM migration. -This range is separate from the compatible Kubernetes versions used to determine whether the `global` cluster can be upgraded. It is an onboarding gate and does not mean every Kubernetes version, provider, operation, capability, or Extension in the range has complete product validation. - -Product validation for the default Extend baseline covers these capability areas: - -- Installing and using Operators. -- Installing and using Cluster Plugins. -- ClickHouse-based logging. -- VictoriaMetrics-based monitoring. - -This does not mean that all specific Operators or Cluster Plugins are covered by product validation. - -For more information, see [Kubernetes Support Matrix](./kubernetes-support-matrix.mdx), [Cluster Management Models](./cluster-management-models.mdx), and [Import Clusters](../configure/clusters/managed/import/overview.mdx). - -### Fixed Issues - -No fixed issues are currently published for this release. +For your provider and exact supported version, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx) and its provider release notes. ### Known Issues From 56bcdfec220de2264f53e57359a651555fffcaef Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 11:10:47 +0800 Subject: [PATCH 02/14] docs: announce 4.4 component updates --- docs/en/overview/release_notes.mdx | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index 6636f48e1..de0923de9 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -22,18 +22,21 @@ For the required checks and acknowledgement procedure, see [Prepare for an Upgra For upgrade procedures, see [Upgrade](../upgrade/index.mdx). -#### Log Collection with Vector +#### Log Collection Plugin Updates -The independently delivered Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. The ACP 4.4-compatible Log Collection plugin is released separately after the ACP 4.4 platform release; install it when the matching plugin package is available. +The following updates are delivered by independently versioned Log Collection plugin releases. The matching plugin release can be published after the ACP 4.4 platform release; install it when the package is available. Its product documentation and release notes will provide the detailed configuration and upgrade procedure. -For Logging Service information, see [About Logging Service](../observability/log/intro.mdx). +- **Vector log collection** — The Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. +- **OpenSearch log storage** — The matching plugin release replaces its embedded Elasticsearch service with a connection to a customer-provided OpenSearch service. New log data is written to OpenSearch. Existing Elasticsearch data is not automatically migrated and can be retained as read-only historical data. The plugin release documentation will describe supported historical-data handling and the upgrade procedure. -#### External Image Registry Recommendation +#### External Image Registries For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. The platform built-in registry remains supported, but it is no longer the recommended default for new production environments. +The next separately versioned component release in the ACP 4.4 delivery cycle will allow Alauda OS-based Workload Clusters to use a third-party registry independently of the Global Cluster registry. This lets you place the image source nearer to a Workload Cluster in geographically separated environments. The related product documentation and release notes will identify supported scenarios and configuration after the component release is available. + #### Monitoring, Dashboards, and Cost Management - **Perses Monitoring Dashboards** — Create and manage metric dashboards with the Perses dashboard experience, import supported Perses or Grafana dashboard JSON, and migrate existing `MonitorDashboard` resources when needed. Existing Monitoring Dashboards remain available during the transition. For details, see [Perses Monitoring Dashboards](../observability/monitor/functions/manage_perses_dashboard.mdx). @@ -77,6 +80,13 @@ For configuration and recovery steps, see [etcd Backup and Restore](../configure For your provider and exact supported version, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx) and its provider release notes. +#### Upcoming Immutable Infrastructure Provider Releases + +The following updates are planned for separately versioned provider releases in the ACP 4.4 delivery cycle. Upgrading ACP to 4.4.0 alone does not install them; use the matching provider release when it becomes available. Provider product documentation and release notes will publish the detailed support boundaries and procedures. + +- **VMware vSphere fixed-address node lifecycle** — The VMware vSphere Provider update improves MachineConfigPool health and bootstrap diagnostics, persistent and ephemeral disk handling, and rolling-update safeguards for fixed-address nodes. A virtual machine that an administrator intentionally powers off for maintenance can remain powered off. +- **Alauda OS node storage stability** — Provider updates improve the Alauda OS node storage layout by keeping kubelet data on a separate disk and aligning pod-log storage with the container runtime. The provider release notes will identify the supported provider paths. + ### Known Issues No known issues are currently published for this release. From f04e7ff8bed1526869caa0a793661ed62e8759ec Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 15:46:42 +0800 Subject: [PATCH 03/14] docs: clarify Alauda OS DCS provider requirement --- docs/en/overview/release_notes.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index de0923de9..a7fbf1923 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -76,6 +76,7 @@ For configuration and recovery steps, see [etcd Backup and Restore](../configure - **Bare Metal cluster lifecycle** — Create and manage both `global` and workload clusters on supported Bare Metal environments. The `global` cluster path includes Global Cluster Disaster Recovery. - **Control plane and storage resilience** — Improve control-plane availability through provider placement rules or a self-built control-plane VIP where no load balancer is available, and preserve declared local disks when nodes are replaced during a rolling upgrade. - **Network and host configuration** — Configure multiple network interfaces for node traffic isolation where supported. On Huawei Cloud Stack, a node can retain both its short hostname and its FQDN. +- **Huawei DCS Provider requirement for Alauda OS** — Alauda OS-based DCS clusters require Huawei DCS Provider version `v1.0.21` or later. This version writes the kubelet systemd drop-in in the writable `/etc` hierarchy, so the configured `node-ip` takes effect on multi-NIC nodes and the node can bootstrap successfully on Alauda OS. - **Safer Huawei DCS virtual-machine operations** — Stop a virtual machine before deleting its node, and remove the boot CD-ROM attachment after startup so it does not prevent later VM migration. For your provider and exact supported version, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx) and its provider release notes. From bae9911961af0385c33bccc13eb9ab7c71f1a513 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 16:19:52 +0800 Subject: [PATCH 04/14] docs: clarify Alauda OS storage update --- docs/en/overview/release_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index a7fbf1923..ef55235db 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -86,7 +86,7 @@ For your provider and exact supported version, see [About Immutable Infrastructu The following updates are planned for separately versioned provider releases in the ACP 4.4 delivery cycle. Upgrading ACP to 4.4.0 alone does not install them; use the matching provider release when it becomes available. Provider product documentation and release notes will publish the detailed support boundaries and procedures. - **VMware vSphere fixed-address node lifecycle** — The VMware vSphere Provider update improves MachineConfigPool health and bootstrap diagnostics, persistent and ephemeral disk handling, and rolling-update safeguards for fixed-address nodes. A virtual machine that an administrator intentionally powers off for maintenance can remain powered off. -- **Alauda OS node storage stability** — Provider updates improve the Alauda OS node storage layout by keeping kubelet data on a separate disk and aligning pod-log storage with the container runtime. The provider release notes will identify the supported provider paths. +- **Alauda OS node storage stability** — A matching provider release will configure a dedicated disk for kubelet data and place pod logs in the container runtime's storage path. This reduces Btrfs I/O pressure that can otherwise affect node stability. ### Known Issues From f817800cb82c5603c2c8e3b6795ef6fbb60ccbb2 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 16:32:54 +0800 Subject: [PATCH 05/14] docs: correct DCS storage release note --- docs/en/overview/release_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index ef55235db..ccaaa1821 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -75,6 +75,7 @@ For configuration and recovery steps, see [etcd Backup and Restore](../configure - **Bare Metal cluster lifecycle** — Create and manage both `global` and workload clusters on supported Bare Metal environments. The `global` cluster path includes Global Cluster Disaster Recovery. - **Control plane and storage resilience** — Improve control-plane availability through provider placement rules or a self-built control-plane VIP where no load balancer is available, and preserve declared local disks when nodes are replaced during a rolling upgrade. +- **Alauda OS node storage on Huawei DCS** — Huawei DCS Provider `v1.0.16` or later supports dedicated `/var/lib/kubelet` and `/var/lib/containerd` disks. When disks are declared as persistent, the provider detaches and reattaches them during rolling node replacement, reducing Btrfs I/O pressure on the system disk and protecting declared node-local data. - **Network and host configuration** — Configure multiple network interfaces for node traffic isolation where supported. On Huawei Cloud Stack, a node can retain both its short hostname and its FQDN. - **Huawei DCS Provider requirement for Alauda OS** — Alauda OS-based DCS clusters require Huawei DCS Provider version `v1.0.21` or later. This version writes the kubelet systemd drop-in in the writable `/etc` hierarchy, so the configured `node-ip` takes effect on multi-NIC nodes and the node can bootstrap successfully on Alauda OS. - **Safer Huawei DCS virtual-machine operations** — Stop a virtual machine before deleting its node, and remove the boot CD-ROM attachment after startup so it does not prevent later VM migration. @@ -86,7 +87,6 @@ For your provider and exact supported version, see [About Immutable Infrastructu The following updates are planned for separately versioned provider releases in the ACP 4.4 delivery cycle. Upgrading ACP to 4.4.0 alone does not install them; use the matching provider release when it becomes available. Provider product documentation and release notes will publish the detailed support boundaries and procedures. - **VMware vSphere fixed-address node lifecycle** — The VMware vSphere Provider update improves MachineConfigPool health and bootstrap diagnostics, persistent and ephemeral disk handling, and rolling-update safeguards for fixed-address nodes. A virtual machine that an administrator intentionally powers off for maintenance can remain powered off. -- **Alauda OS node storage stability** — A matching provider release will configure a dedicated disk for kubelet data and place pod logs in the container runtime's storage path. This reduces Btrfs I/O pressure that can otherwise affect node stability. ### Known Issues From 02ee9e07dfbc9aed06532065ef1740b4af754ad5 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 17:22:41 +0800 Subject: [PATCH 06/14] docs: clarify DCS Alauda OS provider compatibility --- docs/en/overview/release_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index ccaaa1821..dcdf2012f 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -77,7 +77,7 @@ For configuration and recovery steps, see [etcd Backup and Restore](../configure - **Control plane and storage resilience** — Improve control-plane availability through provider placement rules or a self-built control-plane VIP where no load balancer is available, and preserve declared local disks when nodes are replaced during a rolling upgrade. - **Alauda OS node storage on Huawei DCS** — Huawei DCS Provider `v1.0.16` or later supports dedicated `/var/lib/kubelet` and `/var/lib/containerd` disks. When disks are declared as persistent, the provider detaches and reattaches them during rolling node replacement, reducing Btrfs I/O pressure on the system disk and protecting declared node-local data. - **Network and host configuration** — Configure multiple network interfaces for node traffic isolation where supported. On Huawei Cloud Stack, a node can retain both its short hostname and its FQDN. -- **Huawei DCS Provider requirement for Alauda OS** — Alauda OS-based DCS clusters require Huawei DCS Provider version `v1.0.21` or later. This version writes the kubelet systemd drop-in in the writable `/etc` hierarchy, so the configured `node-ip` takes effect on multi-NIC nodes and the node can bootstrap successfully on Alauda OS. +- **Huawei DCS Provider compatibility for Alauda OS** — For Huawei DCS clusters that use the Alauda OS image for ACP `v4.3.2` or later, including ACP `v4.4.0` and later, install Huawei DCS Provider `v1.0.21` or later. Select the Alauda OS image from the OS Support Matrix row for the same ACP release. Do not pair DCS Provider `v1.0.21` or later with an Alauda OS image for an ACP release earlier than `v4.3.2`. See . - **Safer Huawei DCS virtual-machine operations** — Stop a virtual machine before deleting its node, and remove the boot CD-ROM attachment after startup so it does not prevent later VM migration. For your provider and exact supported version, see [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx) and its provider release notes. From 720ae58dbff949af95a792eef2f78a8403c68d97 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Wed, 5 Aug 2026 19:37:06 +0800 Subject: [PATCH 07/14] docs: add application updates to 4.4 release notes --- docs/en/overview/release_notes.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index dcdf2012f..27b8b6c3e 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -37,6 +37,20 @@ The platform built-in registry remains supported, but it is no longer the recomm The next separately versioned component release in the ACP 4.4 delivery cycle will allow Alauda OS-based Workload Clusters to use a third-party registry independently of the Global Cluster registry. This lets you place the image source nearer to a Workload Cluster in geographically separated environments. The related product documentation and release notes will identify supported scenarios and configuration after the component release is available. +#### Operator-managed Registry v2 + +Registry v2 is an optional integrated image registry managed by the Image Registry Operator. Administrators can install it from OperatorHub and configure storage, external access, namespace-scoped pull and push permissions, and managed ServiceAccount pull secrets. It also supports scheduled image pruning with a configured retention policy; run registry garbage collection separately when you need to reclaim unreferenced storage. + +Registry v2 is available for clusters that use an integrated registry. The legacy Registry Cluster Plugin remains available for existing legacy deployments, and the external-registry recommendation above is unchanged. For installation, configuration, access, and cleanup procedures, see [Registry v2 administration](../configure/registry/registry_v2/index.mdx). + +#### Application Workload Operations + +- **Policy-based workload rebalancing** — Install the **Alauda Build of Descheduler** Cluster Plugin when workloads need to be rebalanced after changes in utilization, node configuration, affinity, taints, or topology. The plugin evicts eligible Pods according to the configured policies; for Pods managed by a controller, the default scheduler places the replacements after an eviction. It is not installed by default, does not schedule replacement Pods itself, and respects PodDisruptionBudgets. For installation, policy, and verification guidance, see [Workload Rebalancing (Descheduler)](../developer/building_application/operation_maintaining/descheduler.mdx). + +- **In-place Pod resource resizing** — ACP 4.4 provides guidance for using the Kubernetes Pod `resize` subresource to adjust CPU and memory requests and limits on a running Pod when the target cluster supports it. Use `kubectl` or an API client that supports the subresource. This is not a general web-console editing feature, and `resizePolicy` determines whether a container must restart; VPA `InPlaceOrRecreate` can still fall back to Pod recreation. For prerequisites, examples, and limitations, see [Adjust Pod Resource Levels Without Pod Disruption](../developer/building_application/application_workloads/resize_pod_resources_in_place.mdx). + +- **PodDisruptionBudget operational guidance** — New operational and API guidance explains how to use `minAvailable` or `maxUnavailable` to protect replicated workloads during voluntary disruptions such as node drain, maintenance, and upgrades. PodDisruptionBudgets do not protect workloads from involuntary failures such as node hardware faults. For examples and API details, see [Using PodDisruptionBudgets](../developer/building_application/operation_maintaining/pod_disruption_budget.mdx). + #### Monitoring, Dashboards, and Cost Management - **Perses Monitoring Dashboards** — Create and manage metric dashboards with the Perses dashboard experience, import supported Perses or Grafana dashboard JSON, and migrate existing `MonitorDashboard` resources when needed. Existing Monitoring Dashboards remain available during the transition. For details, see [Perses Monitoring Dashboards](../observability/monitor/functions/manage_perses_dashboard.mdx). From 26c9b4bb99f39b908d0992d50b698ba9534b57c4 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 10:07:46 +0800 Subject: [PATCH 08/14] docs: clarify registry deployment choices --- docs/en/overview/release_notes.mdx | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index 27b8b6c3e..fb5187cbc 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -29,7 +29,9 @@ The following updates are delivered by independently versioned Log Collection pl - **Vector log collection** — The Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. - **OpenSearch log storage** — The matching plugin release replaces its embedded Elasticsearch service with a connection to a customer-provided OpenSearch service. New log data is written to OpenSearch. Existing Elasticsearch data is not automatically migrated and can be retained as read-only historical data. The plugin release documentation will describe supported historical-data handling and the upgrade procedure. -#### External Image Registries +#### Image Registry Deployment Choices + +##### External Registries for New Production Deployments For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. @@ -37,11 +39,11 @@ The platform built-in registry remains supported, but it is no longer the recomm The next separately versioned component release in the ACP 4.4 delivery cycle will allow Alauda OS-based Workload Clusters to use a third-party registry independently of the Global Cluster registry. This lets you place the image source nearer to a Workload Cluster in geographically separated environments. The related product documentation and release notes will identify supported scenarios and configuration after the component release is available. -#### Operator-managed Registry v2 +##### Optional Integrated Registry v2 -Registry v2 is an optional integrated image registry managed by the Image Registry Operator. Administrators can install it from OperatorHub and configure storage, external access, namespace-scoped pull and push permissions, and managed ServiceAccount pull secrets. It also supports scheduled image pruning with a configured retention policy; run registry garbage collection separately when you need to reclaim unreferenced storage. +For deployments that use an ACP-hosted integrated registry instead of an external registry, Registry v2 is an optional image registry managed by the Image Registry Operator. Administrators can install it from OperatorHub and configure storage, external access, namespace-scoped pull and push permissions, and managed ServiceAccount pull secrets. It also supports scheduled image pruning with a configured retention policy; run registry garbage collection separately when you need to reclaim unreferenced storage. -Registry v2 is available for clusters that use an integrated registry. The legacy Registry Cluster Plugin remains available for existing legacy deployments, and the external-registry recommendation above is unchanged. For installation, configuration, access, and cleanup procedures, see [Registry v2 administration](../configure/registry/registry_v2/index.mdx). +Registry v2 is available for clusters that choose this ACP-hosted deployment model. The legacy Registry Cluster Plugin remains available for existing legacy deployments. For installation, configuration, access, and cleanup procedures, see [Registry v2 administration](../configure/registry/registry_v2/index.mdx). #### Application Workload Operations From 92b667e9519ce2a89b3f169e9836eb60bc7817e5 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 10:37:26 +0800 Subject: [PATCH 09/14] docs: separate application registry from platform registry --- docs/en/overview/release_notes.mdx | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index fb5187cbc..e59d207c3 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -29,9 +29,7 @@ The following updates are delivered by independently versioned Log Collection pl - **Vector log collection** — The Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. - **OpenSearch log storage** — The matching plugin release replaces its embedded Elasticsearch service with a connection to a customer-provided OpenSearch service. New log data is written to OpenSearch. Existing Elasticsearch data is not automatically migrated and can be retained as read-only historical data. The plugin release documentation will describe supported historical-data handling and the upgrade procedure. -#### Image Registry Deployment Choices - -##### External Registries for New Production Deployments +#### External Image Registries For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. @@ -39,13 +37,9 @@ The platform built-in registry remains supported, but it is no longer the recomm The next separately versioned component release in the ACP 4.4 delivery cycle will allow Alauda OS-based Workload Clusters to use a third-party registry independently of the Global Cluster registry. This lets you place the image source nearer to a Workload Cluster in geographically separated environments. The related product documentation and release notes will identify supported scenarios and configuration after the component release is available. -##### Optional Integrated Registry v2 - -For deployments that use an ACP-hosted integrated registry instead of an external registry, Registry v2 is an optional image registry managed by the Image Registry Operator. Administrators can install it from OperatorHub and configure storage, external access, namespace-scoped pull and push permissions, and managed ServiceAccount pull secrets. It also supports scheduled image pruning with a configured retention policy; run registry garbage collection separately when you need to reclaim unreferenced storage. - -Registry v2 is available for clusters that choose this ACP-hosted deployment model. The legacy Registry Cluster Plugin remains available for existing legacy deployments. For installation, configuration, access, and cleanup procedures, see [Registry v2 administration](../configure/registry/registry_v2/index.mdx). +#### Application Image and Workload Operations -#### Application Workload Operations +- **Operator-managed Registry v2 for application images** — ACP provides an Operator-managed integrated registry for application developers and workloads to push, pull, and manage application images. Administrators install it from OperatorHub and configure storage, namespace-scoped access, and managed ServiceAccount pull secrets. Workloads use the in-cluster Registry service; administrators can expose it to developer machines and CI when required. It supports scheduled image pruning with a configured retention policy; run registry garbage collection separately when you need to reclaim unreferenced storage. The legacy Registry Cluster Plugin remains available for existing legacy deployments. For installation, configuration, access, and cleanup procedures, see [Registry v2 administration](../configure/registry/registry_v2/index.mdx). - **Policy-based workload rebalancing** — Install the **Alauda Build of Descheduler** Cluster Plugin when workloads need to be rebalanced after changes in utilization, node configuration, affinity, taints, or topology. The plugin evicts eligible Pods according to the configured policies; for Pods managed by a controller, the default scheduler places the replacements after an eviction. It is not installed by default, does not schedule replacement Pods itself, and respects PodDisruptionBudgets. For installation, policy, and verification guidance, see [Workload Rebalancing (Descheduler)](../developer/building_application/operation_maintaining/descheduler.mdx). From 0a7b4a2e424ee9f20adad58d736dfbe941f4b053 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 11:31:47 +0800 Subject: [PATCH 10/14] docs: add related product site directory --- docs/en/overview/release_notes.mdx | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index e59d207c3..22b735985 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -101,3 +101,34 @@ The following updates are planned for separately versioned provider releases in ### Known Issues No known issues are currently published for this release. + +## Related Product Sites + +The following product sites provide component-specific documentation, compatibility information, upgrade guidance, and, where published, release notes. Their versions and release schedules are independent of ACP 4.4. + +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- From 06ae5d9abd99fe3972d756433b5c2e60aaf9612c Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 11:47:33 +0800 Subject: [PATCH 11/14] docs: clarify independent product site timing --- docs/en/overview/release_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index 22b735985..eb13c0b65 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -104,7 +104,7 @@ No known issues are currently published for this release. ## Related Product Sites -The following product sites provide component-specific documentation, compatibility information, upgrade guidance, and, where published, release notes. Their versions and release schedules are independent of ACP 4.4. +The following product sites provide component-specific documentation, compatibility information, upgrade guidance, and, where published, release notes. Their versions and release schedules are independent of ACP 4.4, so product documentation and release notes can be published after the ACP 4.4 platform release. - - From 89fd77852e08a7eae90f3d4d8782343cc7b6bad8 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 11:50:17 +0800 Subject: [PATCH 12/14] docs: omit Service Mesh v1 from 4.4 sites --- docs/en/overview/release_notes.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index eb13c0b65..3c80fea75 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -106,7 +106,6 @@ No known issues are currently published for this release. The following product sites provide component-specific documentation, compatibility information, upgrade guidance, and, where published, release notes. Their versions and release schedules are independent of ACP 4.4, so product documentation and release notes can be published after the ACP 4.4 platform release. -- - - - From 3704d99690a1dbaba4937c5622267a46b7803989 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 12:04:33 +0800 Subject: [PATCH 13/14] docs: clarify platform registry scope --- docs/en/overview/release_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index 3c80fea75..d6234099c 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -29,7 +29,7 @@ The following updates are delivered by independently versioned Log Collection pl - **Vector log collection** — The Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. - **OpenSearch log storage** — The matching plugin release replaces its embedded Elasticsearch service with a connection to a customer-provided OpenSearch service. New log data is written to OpenSearch. Existing Elasticsearch data is not automatically migrated and can be retained as read-only historical data. The plugin release documentation will describe supported historical-data handling and the upgrade procedure. -#### External Image Registries +#### External Registries for Platform Images For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. From 0a88f987ee5de466a0914d63a54607554d053a93 Mon Sep 17 00:00:00 2001 From: Chao Zhou Date: Thu, 6 Aug 2026 12:05:58 +0800 Subject: [PATCH 14/14] docs: describe platform image source strategy --- docs/en/overview/release_notes.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx index d6234099c..426231428 100644 --- a/docs/en/overview/release_notes.mdx +++ b/docs/en/overview/release_notes.mdx @@ -29,9 +29,9 @@ The following updates are delivered by independently versioned Log Collection pl - **Vector log collection** — The Log Collection plugin moves to **Vector** as the log collector. Vector provides a higher-performance collection path for large log volumes and a migration path from the previous collector. - **OpenSearch log storage** — The matching plugin release replaces its embedded Elasticsearch service with a connection to a customer-provided OpenSearch service. New log data is written to OpenSearch. Existing Elasticsearch data is not automatically migrated and can be retained as read-only historical data. The plugin release documentation will describe supported historical-data handling and the upgrade procedure. -#### External Registries for Platform Images +#### Platform Image Sources -For new production deployments, 4.4 recommends using an external image registry: either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. +For new production deployments, 4.4 changes the recommended platform image-source strategy: use an external image registry, either your organization's existing registry or a separately deployed registry. Use it as the central image source for the platform, managed clusters, and plugins. The platform built-in registry remains supported, but it is no longer the recommended default for new production environments.