#Release Notes

#4.3.2

Issued: 2026-07-04

#Important Compatibility Notice

#Huawei DCS Provider and Alauda OS

For Huawei DCS clusters that use the Alauda OS image for ACP v4.3.2 or later, install Huawei DCS Provider v1.0.21 or later. This requirement also applies to ACP v4.4.0 and 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. For the complete compatibility requirement, see Alauda OS and Provider Compatibility for Huawei DCS.

#Fixed Issues

• When the login and ticket validation endpoints of the CAS server used different path prefixes, the CAS connector did not send validation requests to the configured validation address, so ticket validation failed and single sign-on could not be completed. This issue is fixed in v4.3.2.
• On nodes running containerd 2.x, the NVIDIA runtime configuration still referenced the legacy runtime, so GPU workloads could not be created. This issue is fixed in v4.3.2.
• During prolonged operation, the frontend component leaked HTTP connections continuously, which could exhaust local ephemeral TCP ports and make frontend pages unreachable. This issue is fixed in v4.3.2.
• In large business clusters, VictoriaMetrics vmselect could generate high disk I/O while processing recording rule queries, increasing disk usage pressure and affecting monitoring query performance. This issue was fixed in ACP v4.3.2.
• When the control plane of a workload cluster with five control-plane nodes was scaled out, some requests intermittently returned HTTP 401 and the cluster node list failed to load. This issue is fixed in v4.3.2.
• When Image Registry used NFS RWX shared storage, a new Pod created after a Pod was deleted or rebuilt stayed in ContainerCreating for a long time because volume ownership and permissions were processed recursively across the entire volume. The registry stayed unavailable and high-availability recovery took far longer than expected. This issue is fixed in v4.3.2.
• When Image Registry was installed from YAML with S3 storage enabled, keeping the persistence configuration in the same YAML prevented the corresponding ModuleInfo from being generated in the global cluster, so the installation could not continue. This issue is fixed in v4.3.2.
• When Image Registry ran with multiple replicas on NFS RWX shared storage and was exposed through an ALB2 or nginx Ingress without session affinity at the ingress layer, requests belonging to the same push were distributed across different registry replicas, so image pushes failed randomly with blob upload unknown or manifest blob unknown. This issue is fixed in v4.3.2.

#Known Issues

• Platform installation may stall indefinitely at the "Install Kubernetes" step without reporting a failure, while the underlying cluster is actually healthy and the installer keeps retrying. No reliable workaround is currently available; a temporary recovery that was verified is undone again at a later stage.
• In an active/standby disaster-recovery architecture, the reclamation logic on the monitoring storage side may delete the monitoring rules on the standby cluster as a group, silently disabling the corresponding alerting and recording rules. Avoiding this requires a change to the monitoring deployment architecture.
• When monitoring was deployed on a cluster that had log storage installed but no log collector, monitoring could report no data at all. This issue is fixed in v4.4.0, and monitoring now collects and reports data normally in this scenario.
• When a project has both a project administrator and a namespace administrator, deleting the project administrator may also remove the namespace administrator's permissions, with no indication in the console. An administrator must re-grant the affected user's role.
• During an upgrade of an active/standby disaster-recovery deployment, both sides may update base information concurrently, leaving the workload cluster's module information inconsistent, after which the upgrade script reports a failure. No confirmed workaround is currently available.
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• After a new cluster is added, opening that cluster's Pods page may raise an unknown-error dialog and the page does not render its workloads. Restarting the related platform component restores the page; this requires platform operator privileges.
• When VPC Egress Gateway ran with multiple replicas, some namespaces could lose all connectivity to external networks, and the connections did not recover automatically until the affected workload containers were restarted. This issue is fixed in v4.3.3.
• In environments that use an NFSv3 server where rpc.statd is not running on the node, deleting a PVC could fail, leaving backend directories and storage space unreclaimed and causing zombie processes to accumulate. This issue is fixed in v4.3.3.
• When a VPC Egress Gateway used a dual-stack internal subnet together with an IPv4-only external subnet, the gateway init container restarted repeatedly and the gateway never became ready. This issue is fixed in v4.4.0.
• The local-storage device discovery component updates its resources at a high frequency, continuously generating a large volume of audit logs on clusters with many nodes. No workaround is currently available.
• After an object storage pool is deleted and then created again, the new pool enters an abnormal state and a subsequent delete stays in "Deleting" indefinitely. A cluster administrator can identify the residual pool from the storage component logs and remove it manually.
• The first port update after a gateway is created causes the gateway to restart, interrupting traffic passing through it; after the gateway log level has been changed, the next port update triggers the restart again. Schedule port changes during a maintenance window.
• Application creation failure triggered by the defaultMode field in YAML.
  Affected Path: Alauda Container Platform → Application Management → Application List → Create from YAML. Submitting YAML containing the defaultMode field (typically used for ConfigMap/Secret volume mount permissions) triggers validation errors and causes deployment failure.
  Workaround: Manually remove all defaultMode declarations before application creation.
• When deploying or upgrading a cluster, the Kube-OVN network control-plane components may restart repeatedly and the cluster deployment does not complete. No workaround is currently available.
• When pre-delete post-delete hook is set in helm chart.
  When the delete template application is executed and the chart is uninstalled, the hook execution fails for some reasons, thus the application cannot be deleted. It is necessary to investigate the cause and give priority to solving the problem of hook execution failure.

#4.3.1

Issued: 2026-05-20

#Fixed Issues

• The kubectl top node command returned an error when querying node resource usage. This issue has been resolved in version 4.3.1.
• Fixed an issue where the apiserver.crt generated during cluster upgrade lacked the Authority Key Identifier (AKI) extension. Newer Go TLS validation could reject the certificate and cause Jenkins pipelines to fail when connecting to the Kubernetes API server. This is fixed in v4.3.1, where upgrade-generated certificates now include AKI.
• In the container platform's left navigation, the Chinese label for the Logs entry under Observability was translated inaccurately and appeared as "记录" instead of the correct term "日志". This issue is fixed in v4.3.1.
• Captain processed HelmRequests with a single worker per cluster, so one problematic or slow chart could block the queue and delay deployment and updates of other charts in that cluster. The ability to configure the number of HelmRequest workers per cluster is available in v4.3.1, which reduces such queue blocking and improves chart deployment and update efficiency.
• Publishing a Helm chart to the Application Catalog reported an error because the platform's probe to the Harbor repository took too long and timed out. This issue is fixed in v4.3.1, where the probe interaction with Harbor is faster.

#Known Issues

• When the login and ticket validation endpoints of the CAS server used different path prefixes, the CAS connector did not send validation requests to the configured validation address, so ticket validation failed and single sign-on could not be completed. This issue is fixed in v4.3.2.
• On nodes running containerd 2.x, the NVIDIA runtime configuration still referenced the legacy runtime, so GPU workloads could not be created. This issue is fixed in v4.3.2.
• During prolonged operation, the frontend component leaked HTTP connections continuously, which could exhaust local ephemeral TCP ports and make frontend pages unreachable. This issue is fixed in v4.3.2.
• In large business clusters, VictoriaMetrics vmselect could generate high disk I/O while processing recording rule queries, increasing disk usage pressure and affecting monitoring query performance. This issue was fixed in ACP v4.3.2.
• When the control plane of a workload cluster with five control-plane nodes was scaled out, some requests intermittently returned HTTP 401 and the cluster node list failed to load. This issue is fixed in v4.3.2.
• Platform installation may stall indefinitely at the "Install Kubernetes" step without reporting a failure, while the underlying cluster is actually healthy and the installer keeps retrying. No reliable workaround is currently available; a temporary recovery that was verified is undone again at a later stage.
• In an active/standby disaster-recovery architecture, the reclamation logic on the monitoring storage side may delete the monitoring rules on the standby cluster as a group, silently disabling the corresponding alerting and recording rules. Avoiding this requires a change to the monitoring deployment architecture.
• When monitoring was deployed on a cluster that had log storage installed but no log collector, monitoring could report no data at all. This issue is fixed in v4.4.0, and monitoring now collects and reports data normally in this scenario.
• When a project has both a project administrator and a namespace administrator, deleting the project administrator may also remove the namespace administrator's permissions, with no indication in the console. An administrator must re-grant the affected user's role.
• During an upgrade of an active/standby disaster-recovery deployment, both sides may update base information concurrently, leaving the workload cluster's module information inconsistent, after which the upgrade script reports a failure. No confirmed workaround is currently available.
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• After a new cluster is added, opening that cluster's Pods page may raise an unknown-error dialog and the page does not render its workloads. Restarting the related platform component restores the page; this requires platform operator privileges.
• When VPC Egress Gateway ran with multiple replicas, some namespaces could lose all connectivity to external networks, and the connections did not recover automatically until the affected workload containers were restarted. This issue is fixed in v4.3.3.
• In environments that use an NFSv3 server where rpc.statd is not running on the node, deleting a PVC could fail, leaving backend directories and storage space unreclaimed and causing zombie processes to accumulate. This issue is fixed in v4.3.3.
• When a VPC Egress Gateway used a dual-stack internal subnet together with an IPv4-only external subnet, the gateway init container restarted repeatedly and the gateway never became ready. This issue is fixed in v4.4.0.
• When Image Registry used NFS RWX shared storage, a new Pod created after a Pod was deleted or rebuilt stayed in ContainerCreating for a long time because volume ownership and permissions were processed recursively across the entire volume. The registry stayed unavailable and high-availability recovery took far longer than expected. This issue is fixed in v4.3.2.
• When Image Registry was installed from YAML with S3 storage enabled, keeping the persistence configuration in the same YAML prevented the corresponding ModuleInfo from being generated in the global cluster, so the installation could not continue. This issue is fixed in v4.3.2.
• When Image Registry ran with multiple replicas on NFS RWX shared storage and was exposed through an ALB2 or nginx Ingress without session affinity at the ingress layer, requests belonging to the same push were distributed across different registry replicas, so image pushes failed randomly with blob upload unknown or manifest blob unknown. This issue is fixed in v4.3.2.
• The local-storage device discovery component updates its resources at a high frequency, continuously generating a large volume of audit logs on clusters with many nodes. No workaround is currently available.
• After an object storage pool is deleted and then created again, the new pool enters an abnormal state and a subsequent delete stays in "Deleting" indefinitely. A cluster administrator can identify the residual pool from the storage component logs and remove it manually.
• The first port update after a gateway is created causes the gateway to restart, interrupting traffic passing through it; after the gateway log level has been changed, the next port update triggers the restart again. Schedule port changes during a maintenance window.
• Application creation failure triggered by the defaultMode field in YAML.
  Affected Path: Alauda Container Platform → Application Management → Application List → Create from YAML. Submitting YAML containing the defaultMode field (typically used for ConfigMap/Secret volume mount permissions) triggers validation errors and causes deployment failure.
  Workaround: Manually remove all defaultMode declarations before application creation.
• When deploying or upgrading a cluster, the Kube-OVN network control-plane components may restart repeatedly and the cluster deployment does not complete. No workaround is currently available.
• When pre-delete post-delete hook is set in helm chart.
  When the delete template application is executed and the chart is uninstalled, the hook execution fails for some reasons, thus the application cannot be deleted. It is necessary to investigate the cause and give priority to solving the problem of hook execution failure.

#4.3.0

Issued: 2026-04-16

#Features and Enhancements

#Support for Kubernetes 1.34

ACP 4.3 adds support for Kubernetes 1.34 for platform-managed cluster scenarios.

For upgrades to ACP 4.3, the workload-cluster compatible 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 management range.

For more information, see Kubernetes Support Matrix.

#CVO-Based Cluster Upgrade Workflow

ACP 4.3 introduces a Cluster Version Operator (CVO)-based upgrade workflow for both global and workload clusters.

Key capabilities include:

• 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

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

For operational guidance, see Upgrade.

#Standalone Cluster Plugin Upgrade

ACP 4.3 adds standalone upgrade support for cluster plugins that use the Aligned or Agnostic life cycle.

The Cluster Plugins page now shows the plugin life cycle, and eligible plugins can be upgraded independently from the list page or details page. Core plugins continue to follow cluster upgrades.

#Alauda OS-Based Global Clusters on Huawei DCS

ACP 4.3 allows administrators to create the global cluster on Huawei DCS with Alauda OS-based immutable infrastructure. This extends the immutable operating model from workload clusters to platform installation scenarios on DCS.

For more information, see About Immutable Infrastructure.

#Huawei Cloud Stack Support in Immutable Infrastructure

ACP 4.3 adds Immutable Infrastructure support for Huawei Cloud Stack (HCS). The HCS provider documentation now covers provider overview, installation, cluster creation, node management, cluster upgrades, and provider APIs in the Immutable Infrastructure documentation set.

For more information, see About Immutable Infrastructure.

#VMware vSphere Support in the 4.3 Cycle

ACP 4.3 begins introducing Immutable Infrastructure support for VMware vSphere. The provider work is now tracked in the Immutable Infrastructure documentation set, while the public installation details and finalized plugin naming are still being published.

For more information, see About Immutable Infrastructure.

#New Web Console Preview Entry

ACP Core now provides the top-navigation anchor required by the next-generation Web Console experience. When Alauda Container Platform Web Console Base 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.

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.

#Containerd 2.0 Baseline

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

#Expanded Third-Party Cluster Management Range

For third-party clusters, ACP 4.3 now accepts Kubernetes versions in the range >=1.19.0 <1.35.0.

This management range is separate from the compatible Kubernetes versions used to determine whether the global cluster can be upgraded.

Product documentation continues to publish only the Kubernetes versions that have passed product validation for third-party cluster support and the default Extend baseline.

Product validation for the Extend baseline covers the following 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 specific Operators or Cluster Plugins outside this baseline, refer to the relevant product documentation or contact technical support.

For more information, see Kubernetes Support Matrix and Import Standard Kubernetes Cluster.

#Expanded Monitoring Plugin Configuration

ACP 4.3 expands the configuration options for the monitoring plugins, making it easier to adapt monitoring deployments to infra-node placement and different storage layouts.

For ACP Monitoring with VictoriaMetrics, administrators can now:

• Configure plugin-level node selectors and tolerations for workload placement on dedicated infra nodes
• Configure the data storage directory for VictoriaMetrics when Storage Type is LocalVolume
• Remove the previous three-node limit for VictoriaMetrics deployments

For ACP Monitoring with Prometheus, administrators can now configure plugin-level node selectors and tolerations, so monitoring workloads can be scheduled to dedicated infra nodes through plugin configuration.

For operational guidance, see Installation and Planning Infra Nodes for Monitoring.

#StatefulSet Cross-Cluster Application Disaster Recovery Solution

This release introduces cross-cluster disaster recovery capabilities for stateful applications. Built on an Active-Passive dual-center architecture, it combines Alauda Build of VolSync asynchronous data sync and GitOps configuration distribution to achieve minute-level RTO failover.

Key Highlights:

• The primary cluster handles all read/write traffic; the standby cluster maintains a warm data replica via periodic rsync snapshots (RPO > 0).
• Supports three operational scenarios: planned migration, emergency failover, and failback.
• The standby cluster runs with replicas=0 by default; storage and compute resources remain in cold standby, handling no business traffic.
• Suitable for workloads without strict zero-data-loss requirements (RPO = 0). For financial or transactional core applications, use native database replication instead.

For more details, see: Cross-Cluster Application Disaster Recovery for Stateful Applications

#Alauda Container Platform Registry - Image Management Enhancements

This release introduces ac images and ac adm prune images commands, enabling full lifecycle management of Registry images from the command line.

• ac get images: List images in the registry. Results are scoped to namespaces the current user has permissions for, with support for namespace filtering and multiple output formats (table, json, yaml, wide).
• ac delete images: Delete one or more image tags by registry path. Built-in namespace permission checks; runs in dry-run mode by default to preview the impact, and requires --confirm to perform actual deletion.
• ac adm prune images: Admin command to prune image manifests that are not referenced by any cluster Pod. Flexible pruning policies include retention duration, retention count, allowlist, and --all scope. Optionally triggers Registry GC after pruning. Also supports scheduled cleanup via CronJob.

For more details, see: Cluster Image Registry Cleanup: Administrator Guide for Manual and Scheduled Tasks

#Alauda Container Platform Project Application Essential (Alpha)

This release introduces the Alauda Container Platform Project Application Essential plugin, built on the brand-new Next-Gen Console frontend framework. Deployed on the global cluster, it delivers cross-cluster application orchestration and full lifecycle management from a project-centric perspective, fully respecting user permissions.

Key Highlights:

• Cross-cluster orchestration: Unified deployment of applications to multiple member clusters within a single project.
• Full lifecycle management: Supports create, update, scale, rollback, delete, with real-time sync of application status across clusters.
• Project isolation: All operations scoped to the project boundary, ensuring natural isolation between projects.
• Permission-aware: Strictly enforces RBAC permissions, displaying only resources the user is authorized to access.

#Underlay and Egress Gateway Enhancements

ACP 4.3 expands core CNI networking capabilities around underlay access and egress gateway operations.

Key enhancements include:

• Better high-availability and fast-switching design for egress gateway workloads, reducing service impact during node maintenance or failover.
• Resource protection guidance and platform support for egress gateway Pods, helping reduce the risk of node resource contention under traffic spikes or replica growth.
• Support for configuring taints for egress gateway workloads, allowing better placement isolation on dedicated nodes.
• Support for managing VLAN sub-interfaces for underlay NICs.
• Added YAML editing support for subnet resources.
• Added support for node selector settings for centralized gateways.
• Added subnet CRD support for centralized gateway scenarios.

These enhancements make ACP more adaptable to complex enterprise networking environments and simplify migration from earlier exposure models to underlay-based designs.

#Gateway API Enhancements

ACP 4.3 strengthens Gateway API as a key Layer 7 load balancing capability in the platform.

Key enhancements include:

• Support for host-network-based gateway deployment scenarios.
• Support for exposing services through metalLB + Envoy Gateway proxy + underlay, so business traffic can avoid the management network.
• Support for custom VIP addresses for Gateway API, helping keep service exposure addresses stable across rebuilds or lifecycle changes.

#Stateful Application Disaster Recovery with PVC-Based Protection

ACP 4.3 introduces stronger disaster recovery capabilities for stateful workloads, including PVC-based disaster recovery and support for VolSync-based backup and restore workflows for storage-backed applications such as MinIO.

This enhancement improves cross-cluster recovery readiness for stateful applications and provides a more practical protection path for storage-heavy production environments.

#Ceph Storage Management Enhancements

ACP 4.3 improves storage operations and Ceph-based workload support.

Key enhancements include:

• Added support for placing disks into different Ceph pools from the UI.
• Improved operational support for Ceph disk replacement scenarios.

These changes improve day-2 storage operations and make Ceph-based environments easier to manage in production.

#Virtualization Platform Enhancements

ACP 4.3 delivers several important virtualization-related improvements.

Key enhancements include:

• Improved VM creation and display workflows.
• Added support for Astra Linux in virtualization-related scenarios.
• Added support for multi-NIC and NIC hot-plug capabilities for virtual machines.

These enhancements improve virtualization usability and expand guest workload compatibility in enterprise environments.

#Deprecated and Removed Features

#Decommissioning of Operation Statistics

The metering and billing plugins are now generally available and fully cover the capabilities previously provided by the Operations Statistics feature. Therefore, the top-level Operations Statistics entry under Platform Management will be removed.

• For newly deployed platforms, Operations Statistics components are no longer installed. If you need metering or billing capabilities, use the Cost Management plugin.
• For upgraded platforms, metering collection by Operations Statistics stops after the upgrade, while historical data remains available. If you need data cleanup or migration, submit a support request.

#Fixed Issues

• Fixed an issue where the olm-registry pod would continuously restart, preventing the OperatorHub from functioning properly. This was caused by the `seccompProfile: RuntimeDefault` security configuration added during CIS compliance hardening, which blocked the `clone` syscall required by CGO operations. The seccomp profile has been adjusted to allow necessary syscalls while maintaining security compliance. Fixed in ACP 4.3.0.
• Fixed a performance issue where the permission validation during native application creation became extremely slow (10+ seconds) when the cluster had 60+ operators installed. Fixed in ACP 4.3.0.
• When using the etcd backup feature provided by Alauda Container Platform Cluster Enhancer, if users configure to back up etcd to S3 storage, the plugin fails to retrieve the Secret object referenced in secretRef. The root cause was that the plugin lacked the necessary RBAC permissions to read Secrets, resulting in S3 authentication information retrieval failure. This issue has been fixed in ACP 4.3.0.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule had two issues: alert notifications did not differentiate between clusters when triggered, and the rule monitored customer secrets instead of only platform certificates. These issues are fixed in v4.3.0.
• The ephemeral-storage limit configured for the metis component was too small, so the metis container restarted repeatedly once its usage exceeded the limit. This issue is fixed in v4.3.0, where the limit has been raised to an appropriate value.
• When a workload used its own custom ServiceAccount, the platform did not inject the imagePullSecret into that ServiceAccount automatically, so the workload could not pull images from the cluster registry. This issue is fixed in v4.3.0.
• When the image-registry imagePullSecret was rotated automatically by creating a new Secret and deleting the old one, existing Pods that still referenced the old Secret could not pull images once they started after that Secret had expired. This issue is fixed in v4.3.0.
• When the namespace creation page was opened, a slow page request could leave no cluster selected by default, which in turn caused other requests on the page to fail. Refreshing the page repeatedly would then occasionally leave the project quota unavailable. This issue is fixed in v4.3.0.
• On the real-time log page for scheduled job execution records, the English message shown when logging finished, Logging has ended, did not clearly convey its meaning. This issue is fixed in v4.3.0, where the message now reads End of logs.
• When a ConfigMap was edited on Windows, line breaks were handled differently than on macOS, so copied and pasted content could end up incorrectly formatted. This issue is fixed in v4.3.0, and line-break behavior is now consistent on both platforms.

#Known Issues

• In large business clusters, VictoriaMetrics vmselect could generate high disk I/O while processing recording rule queries, increasing disk usage pressure and affecting monitoring query performance. This issue was fixed in ACP v4.3.2.
• Platform installation may stall indefinitely at the "Install Kubernetes" step without reporting a failure, while the underlying cluster is actually healthy and the installer keeps retrying. No reliable workaround is currently available; a temporary recovery that was verified is undone again at a later stage.
• In an active/standby disaster-recovery architecture, the reclamation logic on the monitoring storage side may delete the monitoring rules on the standby cluster as a group, silently disabling the corresponding alerting and recording rules. Avoiding this requires a change to the monitoring deployment architecture.
• The kubectl top node command returned an error when querying node resource usage. This issue has been resolved in version 4.3.1.
• Fixed an issue where the apiserver.crt generated during cluster upgrade lacked the Authority Key Identifier (AKI) extension. Newer Go TLS validation could reject the certificate and cause Jenkins pipelines to fail when connecting to the Kubernetes API server. This is fixed in v4.3.1, where upgrade-generated certificates now include AKI.
• When a project has both a project administrator and a namespace administrator, deleting the project administrator may also remove the namespace administrator's permissions, with no indication in the console. An administrator must re-grant the affected user's role.
• During an upgrade of an active/standby disaster-recovery deployment, both sides may update base information concurrently, leaving the workload cluster's module information inconsistent, after which the upgrade script reports a failure. No confirmed workaround is currently available.
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• After a new cluster is added, opening that cluster's Pods page may raise an unknown-error dialog and the page does not render its workloads. Restarting the related platform component restores the page; this requires platform operator privileges.
• When VPC Egress Gateway ran with multiple replicas, some namespaces could lose all connectivity to external networks, and the connections did not recover automatically until the affected workload containers were restarted. This issue is fixed in v4.3.3.
• When Image Registry was installed from YAML with S3 storage enabled, keeping the persistence configuration in the same YAML prevented the corresponding ModuleInfo from being generated in the global cluster, so the installation could not continue. This issue is fixed in v4.3.2.
• When Image Registry ran with multiple replicas on NFS RWX shared storage and was exposed through an ALB2 or nginx Ingress without session affinity at the ingress layer, requests belonging to the same push were distributed across different registry replicas, so image pushes failed randomly with blob upload unknown or manifest blob unknown. This issue is fixed in v4.3.2.
• The local-storage device discovery component updates its resources at a high frequency, continuously generating a large volume of audit logs on clusters with many nodes. No workaround is currently available.
• After an object storage pool is deleted and then created again, the new pool enters an abnormal state and a subsequent delete stays in "Deleting" indefinitely. A cluster administrator can identify the residual pool from the storage component logs and remove it manually.
• The first port update after a gateway is created causes the gateway to restart, interrupting traffic passing through it; after the gateway log level has been changed, the next port update triggers the restart again. Schedule port changes during a maintenance window.
• Application creation failure triggered by the defaultMode field in YAML.
  Affected Path: Alauda Container Platform → Application Management → Application List → Create from YAML. Submitting YAML containing the defaultMode field (typically used for ConfigMap/Secret volume mount permissions) triggers validation errors and causes deployment failure.
  Workaround: Manually remove all defaultMode declarations before application creation.
• When deploying or upgrading a cluster, the Kube-OVN network control-plane components may restart repeatedly and the cluster deployment does not complete. No workaround is currently available.
• When pre-delete post-delete hook is set in helm chart.
  When the delete template application is executed and the chart is uninstalled, the hook execution fails for some reasons, thus the application cannot be deleted. It is necessary to investigate the cause and give priority to solving the problem of hook execution failure.