Alauda Container Platform

Release Notes

Review release notes with the Kubernetes Support Matrix, Version and Lifecycle, and feature-specific documentation to understand release changes and exact support boundaries.

TOC

4.4.0Features and EnhancementsKubernetes 1.35 and Upgrade ReadinessMore Consistent Platform Installation and UpgradesLog Collection Plugin UpdatesPlatform Image SourcesApplication Image and Workload OperationsMonitoring, Dashboards, and Cost ManagementGlobal Cluster Disaster Recovery EnhancementsAlauda OS Backup and RestoreAccess and AuthorizationImmutable InfrastructureUpcoming Immutable Infrastructure Provider ReleasesKnown IssuesRelated Product Sites

4.4.0

Features and Enhancements

Kubernetes 1.35 and Upgrade Readiness

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 the required checks and acknowledgement procedure, see Prepare for an Upgrade and Upgrade a Global Cluster.

More Consistent Platform Installation and Upgrades

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.

For upgrade procedures, see Upgrade.

Log Collection Plugin Updates

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.

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

Platform Image Sources

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.

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.

Application Image and 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.

  • 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).

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

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

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.

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

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

Global Cluster Disaster Recovery Enhancements

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.

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.

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.

For details, see Global Cluster Disaster Recovery and Global Cluster Disaster Recovery on Immutable Infrastructure.

Alauda OS Backup and Restore

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.

For configuration and recovery steps, see etcd Backup and Restore.

Access and Authorization

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

  • 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).

  • Safer role delegation — The platform prevents users from granting permissions that exceed their own authorization boundary. The console also includes the related ClusterRole capabilities.

Immutable Infrastructure

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:

  • 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 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 Alauda OS and Provider Compatibility for Huawei DCS.
  • 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 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.

Known Issues

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.