#Release Notes

#4.2.5

Issued: 2026-06-08

#Fixed Issues

• When the control plane was scaled out on a workload cluster with five control plane nodes, some requests intermittently returned HTTP 401 and the cluster node list failed to load. This issue is fixed in v4.2.5.
• 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.2.5.
• In an underlay network using the MetalLB + ALB high-availability architecture, creating a new LoadBalancer with ExternalTrafficPolicy set to Local overwrote the ip_port_mapping field in the OVN Load_Balancer table, and existing ALB instances then became unreachable from outside the cluster. This issue is fixed in v4.2.5.
• Pushing a container image with a large number of layers (over 100) to the built-in image registry failed. This issue is fixed in v4.2.5.
• On the distributed storage page under platform management, the Ceph storage pool usage bar was calculated as used logical storage divided by the maximum logical data the OSDs could theoretically still accept. As a result, the bar turned red even when about 50% of the OSD space was still available, which could be mistaken for a need to expand capacity. This issue is fixed in v4.2.5.
• After upgrading to v4.2.2, a large number of OVN change-request audit records were generated, causing the audit data to grow excessively. This issue is fixed in v4.2.5.
• 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 captain workers per cluster is available in v4.2.5, which reduces such queue blocking and improves chart deployment and update efficiency.
• In u2o mode, different underlay subnets could unexpectedly reach each other. This issue is fixed in v4.2.5, where underlay subnets are isolated from one another so that cross-subnet access can be controlled by policies on the external physical network.
• After a new node was added to a cluster, the Multus plugin occasionally did not take effect on that node. This issue is fixed in v4.2.5.
• 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.2.5, where the limit has been raised to an appropriate value.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.

#Known Issues

• When the control plane was scaled out on a workload cluster with five control plane nodes, some requests intermittently returned HTTP 401 and the cluster node list failed to load. This issue is fixed in v4.2.5.
• 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 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 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.2.5.
• 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.
• 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.2.6.
• In an underlay network using the MetalLB + ALB high-availability architecture, creating a new LoadBalancer with ExternalTrafficPolicy set to Local overwrote the ip_port_mapping field in the OVN Load_Balancer table, and existing ALB instances then became unreachable from outside the cluster. This issue is fixed in v4.2.5.
• Pushing a container image with a large number of layers (over 100) to the built-in image registry failed. This issue is fixed in v4.2.5.
• On the distributed storage page under platform management, the Ceph storage pool usage bar was calculated as used logical storage divided by the maximum logical data the OSDs could theoretically still accept. As a result, the bar turned red even when about 50% of the OSD space was still available, which could be mistaken for a need to expand capacity. This issue is fixed in v4.2.5.
• After upgrading to v4.2.2, a large number of OVN change-request audit records were generated, causing the audit data to grow excessively. This issue is fixed in v4.2.5.
• 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 captain workers per cluster is available in v4.2.5, which reduces such queue blocking and improves chart deployment and update efficiency.
• In u2o mode, different underlay subnets could unexpectedly reach each other. This issue is fixed in v4.2.5, where underlay subnets are isolated from one another so that cross-subnet access can be controlled by policies on the external physical network.
• 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 a new node was added to a cluster, the Multus plugin occasionally did not take effect on that node. This issue is fixed in v4.2.5.
• 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.2.5, where the limit has been raised to an appropriate value.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• 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.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.2.4

Issued: 2026-03-27

#Fixed Issues

• When the platform interfaces with IDP user authentication login, if the user name has capital letters, ArgoCD will not be able to get the permission information of the user. This issue has been resolved in version 4.2.4.
• The imagePullSecret of image-registry was rotated automatically by creating a new Secret and deleting the old one, so Pods that still referenced the old Secret failed to pull images once that Secret had expired. For example, if a Pod had been running for more than an hour and one of its containers restarted and had to pull its image again, the pull failed. This issue is fixed in v4.2.4.
• When a workload used its own custom ServiceAccount, the imagePullSecret was not injected into that ServiceAccount automatically, so the workload could not pull images from the cluster registry. This issue is fixed in v4.2.4.
• Pushing images larger than 1 GB failed because the Registry Proxy's default 30-second forwarding timeout interrupted the connection before the push completed. This issue is fixed in v4.2.4, where the HTTP forwarding timeout of the proxy component is extended and streaming forwarding is enabled, improving throughput and stability for large transfers.

#Known Issues

• When the control plane was scaled out on a workload cluster with five control plane nodes, some requests intermittently returned HTTP 401 and the cluster node list failed to load. This issue is fixed in v4.2.5.
• 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 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 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.2.5.
• 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.
• 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.2.6.
• In an underlay network using the MetalLB + ALB high-availability architecture, creating a new LoadBalancer with ExternalTrafficPolicy set to Local overwrote the ip_port_mapping field in the OVN Load_Balancer table, and existing ALB instances then became unreachable from outside the cluster. This issue is fixed in v4.2.5.
• Pushing a container image with a large number of layers (over 100) to the built-in image registry failed. This issue is fixed in v4.2.5.
• On the distributed storage page under platform management, the Ceph storage pool usage bar was calculated as used logical storage divided by the maximum logical data the OSDs could theoretically still accept. As a result, the bar turned red even when about 50% of the OSD space was still available, which could be mistaken for a need to expand capacity. This issue is fixed in v4.2.5.
• After upgrading to v4.2.2, a large number of OVN change-request audit records were generated, causing the audit data to grow excessively. This issue is fixed in v4.2.5.
• 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 captain workers per cluster is available in v4.2.5, which reduces such queue blocking and improves chart deployment and update efficiency.
• In u2o mode, different underlay subnets could unexpectedly reach each other. This issue is fixed in v4.2.5, where underlay subnets are isolated from one another so that cross-subnet access can be controlled by policies on the external physical network.
• 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 a new node was added to a cluster, the Multus plugin occasionally did not take effect on that node. This issue is fixed in v4.2.5.
• 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.2.5, where the limit has been raised to an appropriate value.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• 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.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.2.3

Issued: 2026-03-16

#Fixed Issues

• In version 4.2.2, the platform was unable to automatically synchronize data from the connected LDAP server. This issue has been fixed in version 4.2.3.
• In version 4.2.2, both creating project settings quotas and updating quotas for existing projects failed to take effect. This issue has been fixed in version 4.2.3.
• Deleting multiple Pods at once from the Pods list page failed with an "insufficient permissions" message, while deleting a single Pod succeeded. This issue is fixed in v4.2.3, where the RBAC permissions required for batch operations were added to the core management component so that batch deletion works as expected.
• Multus CNI services previously had to run as a privileged user, which did not meet the hardening requirement that services run as a non-privileged user. Support for running Multus CNI services as a non-privileged user is available in v4.2.3.
• The Argo Rollouts plugin failed to deploy on v4.2.2. This issue is fixed in v4.2.3.

#Known Issues

• 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 the platform interfaces with IDP user authentication login, if the user name has capital letters, ArgoCD will not be able to get the permission information of the user. This issue has been resolved in version 4.2.4.
• 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 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.2.5.
• 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.
• 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.2.6.
• In an underlay network using the MetalLB + ALB high-availability architecture, creating a new LoadBalancer with ExternalTrafficPolicy set to Local overwrote the ip_port_mapping field in the OVN Load_Balancer table, and existing ALB instances then became unreachable from outside the cluster. This issue is fixed in v4.2.5.
• After upgrading to v4.2.2, a large number of OVN change-request audit records were generated, causing the audit data to grow excessively. This issue is fixed in v4.2.5.
• 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.
• 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.2.5, where the limit has been raised to an appropriate value.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• The imagePullSecret of image-registry was rotated automatically by creating a new Secret and deleting the old one, so Pods that still referenced the old Secret failed to pull images once that Secret had expired. For example, if a Pod had been running for more than an hour and one of its containers restarted and had to pull its image again, the pull failed. This issue is fixed in v4.2.4.
• When a workload used its own custom ServiceAccount, the imagePullSecret was not injected into that ServiceAccount automatically, so the workload could not pull images from the cluster registry. This issue is fixed in v4.2.4.
• Pushing images larger than 1 GB failed because the Registry Proxy's default 30-second forwarding timeout interrupted the connection before the push completed. This issue is fixed in v4.2.4, where the HTTP forwarding timeout of the proxy component is extended and streaming forwarding is enabled, improving throughput and stability for large transfers.
• 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.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.2.2

Issued: 2026-02-11

#Fixed Issues

• Fixed etcd backup failure after installing Alauda Container Platform Cluster Enhancer plugin. The issue was caused by BroadcastJobs created during upgrade missing the scheduledTimeAnnotation, preventing the AdvancedCronJob from calculating the next trigger time. The fix now uses the job creation timestamp as a fallback when the annotation is missing, ensuring scheduled backups continue to run properly. Fixed in ACP 4.2.2.
• 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.2.2.
• 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.2.2.
• In the discovered device list of local device management, the system failed to retrieve the DeviceID of storage devices, so eligible devices were incorrectly marked as "Not Recommended". This issue is fixed in v4.2.2, and such devices are now shown as recommended.
• When the target ipBlocks configured on an egress gateway fell within the CIDR range of the internal subnet that the gateway used, the egress rule did not take effect, and traffic from Pods in the same subnet as the egress gateway was not routed correctly. This issue is fixed in v4.2.2.

#Known Issues

• 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 the platform interfaces with IDP user authentication login, if the user name has capital letters, ArgoCD will not be able to get the permission information of the user. This issue has been resolved in version 4.2.4.
• 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.
• In version 4.2.2, the platform was unable to automatically synchronize data from the connected LDAP server. This issue has been fixed in version 4.2.3.
• In version 4.2.2, both creating project settings quotas and updating quotas for existing projects failed to take effect. This issue has been fixed in version 4.2.3.
• 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 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.2.5.
• 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.
• 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.2.6.
• In an underlay network using the MetalLB + ALB high-availability architecture, creating a new LoadBalancer with ExternalTrafficPolicy set to Local overwrote the ip_port_mapping field in the OVN Load_Balancer table, and existing ALB instances then became unreachable from outside the cluster. This issue is fixed in v4.2.5.
• After upgrading to v4.2.2, a large number of OVN change-request audit records were generated, causing the audit data to grow excessively. This issue is fixed in v4.2.5.
• 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.
• 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.2.5, where the limit has been raised to an appropriate value.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• Pushing images larger than 1 GB failed because the Registry Proxy's default 30-second forwarding timeout interrupted the connection before the push completed. This issue is fixed in v4.2.4, where the HTTP forwarding timeout of the proxy component is extended and streaming forwarding is enabled, improving throughput and stability for large transfers.
• Deleting multiple Pods at once from the Pods list page failed with an "insufficient permissions" message, while deleting a single Pod succeeded. This issue is fixed in v4.2.3, where the RBAC permissions required for batch operations were added to the core management component so that batch deletion works as expected.
• The Argo Rollouts plugin failed to deploy on v4.2.2. This issue is fixed in v4.2.3.
• 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.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.2.1

Issued: 2026-01-09

#Fixed Issues

• When upgrading the Global cluster, there was an intermittent issue that caused the Marketplace menu to be missing from the left navigation in the Web Console. This issue has been fixed in ACP 4.2.1.
• 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.2.1.
• When using the Global Cluster Disaster Recovery solution, after installing Alauda Container Platform etcd Synchronizer, the Web Console of the Standby Cluster was unable to login. The root cause was that etcd Synchronizer did not properly ignore k8sadmin-* related Secret objects, causing the authentication information of the Standby Cluster to be overwritten. This issue has been fixed in ACP 4.2.1.
• When MinIO was accessed over HTTPS, the SkipSSLVerify parameter failed to skip HTTPS certificate verification, so bucket claims created with the MinIO object storage class stayed in an unavailable state. This issue is fixed in v4.2.1.

#Known Issues

• 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 the platform interfaces with IDP user authentication login, if the user name has capital letters, ArgoCD will not be able to get the permission information of the user. This issue has been resolved in version 4.2.4.
• 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.
• Fixed etcd backup failure after installing Alauda Container Platform Cluster Enhancer plugin. The issue was caused by BroadcastJobs created during upgrade missing the scheduledTimeAnnotation, preventing the AdvancedCronJob from calculating the next trigger time. The fix now uses the job creation timestamp as a fallback when the annotation is missing, ensuring scheduled backups continue to run properly. Fixed in ACP 4.2.2.
• 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.2.2.
• 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.2.2.
• 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.2.5.
• 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.
• 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.2.6.
• 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.
• In dual-stack clusters, after a Pod was manually assigned an incorrect static IPv6 address in its YAML, ovn-controller still did not process the change correctly even after the address was updated to a valid one, and subsequent IP addresses in the affected subnet could no longer be allocated. This issue is fixed in v4.2.5.
• In the discovered device list of local device management, the system failed to retrieve the DeviceID of storage devices, so eligible devices were incorrectly marked as "Not Recommended". This issue is fixed in v4.2.2, and such devices are now shown as recommended.
• When the target ipBlocks configured on an egress gateway fell within the CIDR range of the internal subnet that the gateway used, the egress rule did not take effect, and traffic from Pods in the same subnet as the egress gateway was not routed correctly. This issue is fixed in v4.2.2.
• 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.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.2.0

Issued: 2025-12-09

#Features and Enhancements

#Support for Kubernetes 1.33

ACP now supports Kubernetes 1.33, delivering the latest upstream features, performance improvements, and security enhancements from the Kubernetes community.

#ACP CLI (ac)

The new ACP CLI (ac) enables you to develop, build, deploy, and run applications on ACP with a seamless command-line experience.

Key capabilities include:

• kubectl-compatible commands
• Integrated authentication with ACP platform environments
• Unified session management across multiple environments
• ACP-specific extensions for platform access and cross-environment workflows

For full feature details, see: ACP CLI (ac)

#Hosted Control Plane (HCP)

Released:

• Alauda Container Platform Kubeadm Provider
• Alauda Container Platform Hosted Control Plane
• Alauda Container Platform SSH Infrastructure Provider

Lifecycle: Agnostic (released asynchronously with ACP)

Hosted Control Plane decouples the control plane from worker nodes by hosting each cluster's control plane as containerized components within a management cluster. This architecture reduces resource usage, speeds up cluster creation and upgrades, and provides improved scalability for large multi-cluster environments.

For more information, see: About Hosted Control Plane

#Enhanced User Permission Management

We've optimized RBAC management with the following enhancements to improve usability and maintainability:

• Platform Role Management:

  • UI-based permission customization deprecated: Platform roles no longer support custom permission configuration through the web console. All role permissions must be configured via YAML files.
  • Backward compatibility maintained: Existing platform preset roles and roles defined in previous versions remain fully functional. Users can continue to assign these roles to users and grant permissions as before.

• Kubernetes Role Management:

  • Native Kubernetes role management: A dedicated management interface for Kubernetes Role and ClusterRole resources is now available in the platform console, enabling direct association of Kubernetes roles with users and permission assignment.
  • Modular permission definitions: Platform plugin resource permissions will be progressively migrated to independent Role and ClusterRole resources, providing better isolation and easier management.

#Enhanced Pod Security Policies with Kyverno

We've strengthened workload security capabilities through the Kyverno policy engine:

• Ready-to-Use Security Templates: 8 validated security policy templates built into the console, covering Pod Security Standards levels including Privileged, Baseline, Nonroot, and Restricted
• One-Click Configuration: Quickly create policies from templates in the business view without manual YAML writing, effective immediately in specified namespaces

#Next-Generation Gateway API powered by Envoy Gateway

This release introduces a new Gateway API implementation based on Envoy Gateway. It provides a unified L7 traffic entry, stays aligned with the community Gateway API specification, and lays the foundation for richer traffic policies and ecosystem integrations.

#Domain-Based Rules for Egress Firewall

Egress Firewall now supports allow/deny rules based on domain names instead of only IP addresses. This enables fine-grained outbound access control for public SaaS services and external resources whose IP addresses change frequently.

#New Endpoint Health Checker for Faster Failover

A new Endpoint Health Checker is introduced to detect failures such as node crashes and network partitions more quickly and to remove unhealthy backends in time. This significantly shortens traffic failover duration and reduces the risk of service interruption.

#New Local Storage Operator for Easier Ceph/TopoLVM Management

The newly introduced Local Storage (Alauda Build of Local Storage) Operator greatly simplifies deployment and disk management for Ceph and TopoLVM. During deployment, you can list all available disks across the cluster, including model, capacity, and other key attributes, and select which disks to bring under management. For disk binding, Ceph and TopoLVM now prefer using device IDs rather than mount paths, preventing storage issues caused by device name changes after node reboot or device re-detection.

#Other Key Changes

#Lifecycle Change for Logging Plugins

The lifecycle status for logging-related plugins has been changed from Aligned to Agnostic (released asynchronously with ACP).

Affected plugins:

• Alauda Container Platform Log Essentials (new in this release)
• Alauda Container Platform Log Storage for ClickHouse
• Alauda Container Platform Log Storage for Elasticsearch
• Alauda Container Platform Log Collector

For more information, see: About Logging Service

#Enhanced Default Security Level for Namespaces

Starting from v4.2.0, the default PSA policy for newly created namespaces (via web console or CLI) is changed from Baseline to Restricted.

• Baseline: Prohibits known privilege escalations, provides moderate security
• Restricted: Follows Pod security best practices with strictest requirements

Impact Analysis:

• This change only affects newly created namespaces
• Workloads requiring privileged capabilities (e.g., root user, hostPath mounts) will not run directly

Recommended Solutions:

• Modify your application configuration to meet the security requirements of the Restricted policy
• Manually set the namespace policy back to Baseline if necessary

#MinIO in Maintenance Mode

The MinIO (Alauda Build of MinIO) has entered maintenance mode. Only security fixes will be provided in the future, and no new features are planned. Existing MinIO clusters can continue to run, while new object storage requirements should prefer Ceph Object as the recommended solution.

#Calico in Maintenance Mode

The Calico (Alauda Container Platform Networking for Calico) CNI plugin has entered maintenance mode. We will only address security-related issues, and it is no longer the default recommended network option. Existing Calico clusters remain supported, while new clusters should use kube-ovn as the standard CNI.

#Ingress Nginx Switched to Operator

The Ingress Nginx (Alauda Build of Ingress Nginx) has been migrated from a cluster plug-in to an Operator-based deployment and management model. Existing Ingress resources will continue to work after the upgrade, and subsequent operations are expected to be carried out through the Operator. Although the upstream community version of Ingress Nginx is no longer updated, we will continue to provide bug fixes and security patches for this distribution.

#Deprecated and Removed Features

#Kubernetes Version Upgrade Policy Update

Starting from ACP 4.2, upgrading the Kubernetes version is no longer optional. When performing a cluster upgrade, the Kubernetes version must be upgraded together with other platform components. This change ensures version consistency across the cluster and reduces future maintenance windows.

#ALB Deprecated Starting from v4.2.0

The ALB (Alauda Container Platform Ingress Gateway) is marked as deprecated as of v4.2.0. New clusters and new users should adopt the Envoy Gateway–based Gateway API as the primary option. Existing clusters using ALB will keep working after the upgrade, but we strongly recommend planning and executing a migration to the Gateway API for long-term support and feature evolution.

#Flannel Fully Removed

The Flannel (Alauda Container Platform Networking for Flannel) CNI plugin has been completely removed from the platform. Clusters still using Flannel must migrate to kube-ovn before upgrading to this release or any later version. Please plan and complete the migration in advance to avoid service disruption caused by switching the CNI.

#Fixed Issues

• The status field of an upmachinepool resource stored its associated machine resources without a stable order, so the resource was treated as changed on every reconcile loop and produced an excessive volume of audit data. This issue is fixed in v4.2.0.
• On a platform with a large number of clusters, once a project quota had been set through the batch quota setting feature, the quota for that project could no longer be updated for an individual cluster. This issue is fixed in v4.2.0.
• Previously, when creating a cluster-level Instance in OperatorHub, the web console automatically injected a metadata.namespace field, which caused a 404 error. This issue has been fixed in ACP 4.2.0.
• Users that had been automatically disabled for long-term inactivity were disabled again shortly after an administrator manually activated them, so the activation never took effect. This issue is fixed in v4.2.0.
• After an Operator was uninstalled from a cluster, its status was incorrectly shown as Absent even though the Operator was still Ready, and it had to be re-uploaded manually with violet upload to recover. This issue is fixed in v4.2.0, and the Operator now correctly shows as Ready after uninstallation.
• After a new Operator version was uploaded with violet upload, that version could occasionally not be selected or installed. This issue is fixed in v4.2.0.
• When an Operator or Cluster Plugin contained multiple frontend extensions, clicking the left-side navigation entries of those extensions could produce no response. The temporary workaround was to add the annotation cpaas.io/auto-sync: "false" to the extension's ConfigMap. This issue is fixed in v4.2.0, and that workaround is no longer needed.
• Previously, if a cluster contained nodes with an empty Display Name, users were unable to filter nodes by typing in the node selector dropdown on the node details page. This issue has been fixed in ACP 4.2.0.
• After log archiving completed, the temporary files were not deleted, so the disk space they occupied was not reclaimed. This issue is fixed in log-v4.2.0.
• Uploading multiple packages from a folder with violet upload failed because the disk ran out of space. This issue is fixed in v4.2.0, where violet promptly cleans up each package after it has been uploaded, so the error no longer occurs.
• When a namespace was imported into a project, changing the pod security policy level during the import (for example, from Baseline to Restricted) did not take effect, and the namespace detail page still showed the original level after the import finished. This issue is fixed in v4.2.0, and the level selected during import is now applied correctly.
• When the platform was upgraded from v3.x to v4.x and the global cluster was upgraded while a workload cluster was not, the monitoring dashboards for workloads such as Applications and Deployments in that cluster did not appear. This issue is fixed in v4.2.0.
• When upgrading in environments running Kubernetes versions earlier than 1.30, the KubeVirt Operator could fail to deploy. This issue is fixed in v4.2.0.
• Image Registry credentials created in the console stored only the user name and password, without the auth field that kubectl create secret docker-registry generates. Image build tools that depend on the complete credential, such as buildah, reported a permission error when pushing images with it. This issue is fixed in v4.2.0, and credentials created in the console now carry the same complete authentication data as those created from the command line.

#Known Issues

• 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 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.
• 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.2.5.
• When upgrading the Global cluster, there was an intermittent issue that caused the Marketplace menu to be missing from the left navigation in the Web Console. This issue has been fixed in ACP 4.2.1.
• 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.2.1.
• When using the Global Cluster Disaster Recovery solution, after installing Alauda Container Platform etcd Synchronizer, the Web Console of the Standby Cluster was unable to login. The root cause was that etcd Synchronizer did not properly ignore k8sadmin-* related Secret objects, causing the authentication information of the Standby Cluster to be overwritten. This issue has been fixed in ACP 4.2.1.
• 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.
• 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.2.6.
• 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 MinIO was accessed over HTTPS, the SkipSSLVerify parameter failed to skip HTTPS certificate verification, so bucket claims created with the MinIO object storage class stayed in an unavailable state. This issue is fixed in v4.2.1.
• After Envoy Gateway is deployed in a dual-stack cluster, the IPv4 address of a UDPRoute is unreachable. No workaround is currently available.
• 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.
• If a Custom Application includes an alert resource whose metrics expression uses customized metrics, deploying the application to a namespace whose name differs from the original—whether after exporting it as a chart or application YAML, importing the chart into the platform, or creating the application directly from the YAML — will cause the deployment to fail.
  
  This issue can be resolved by manually updating the metrics expression in the alert resource within the chart or YAML file, changing the namespace tag value to match the target deployment namespace.
• The default pool .mgr created by ceph-mgr uses the default Crush Rule, which may fail to properly select OSDs in a stretched cluster. To resolve this, the .mgr pool must be created using CephBlockPool. However, due to timing uncertainties, ceph-mgr might attempt to create the .mgr pool before the Rook Operator completes its setup, leading to conflicts.
  ​If encountering this issue, restart the rook-ceph-mgr Pod​ to trigger reinitialization.
  ​If unresolved, manually clean up the conflicting .mgr pool and redeploy the cluster to ensure proper creation order.
• 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.