#Release Notes

#4.0.11

Issued: 2026-07-01

#Fixed Issues

• 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.0.11.
• 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.0.11.
• After a worker node's chassis UUID changed, for example when the node was removed and rejoined or when the OVS system-id changed, the HA Chassis of the VPC BFD port was not updated to the new chassis and still referenced the old chassis UUID, which broke the BFD high-availability path of the egress gateway. This issue is fixed in v4.0.11, where the HA Chassis is updated to the new chassis automatically.

#Known Issues

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

Issued: 2026-05-27

#Fixed Issues

• In long-running clusters, or clusters created more than a year earlier, expired kubeconfig client certificates could cause platform pages to return HTTP 500, kubectl commands to fail, and components such as Apollo to become unreachable. This issue is fixed in v4.0.10, where the controller detects and automatically renews client certificates that are about to expire in the <cluster>-kubeconfig Secret, and /root/.kube/config on control-plane nodes now uses a client certificate valid for about 10 years.
• When post-processing of one image failed during warmup, image-loader stopped warming up the remaining images. Frontend plugin images were therefore left unwarmed, which could prevent plugins from loading and make frontend pages unavailable. This issue is fixed in v4.0.10.
• During a rolling upgrade, existing kubeconfig Secrets or ClusterCredential client certificates of a workload cluster were not rotated automatically when they had already expired or were due to expire within 30 days, which broke access to the workload cluster. This issue is fixed in v4.0.10, where the controller detects this condition, reissues the client certificates, and updates the corresponding Secret or credential.
• After upgrading from 3.16.2 to 4.0.x, the apiserver.crt generated during the upgrade lacked the Authority Key Identifier (AKI) extension, so newer Go TLS clients such as Jenkins pipelines rejected the certificate and could not connect to the Kubernetes API server. This issue is fixed in v4.0.10, where apiserver.crt certificates generated during the upgrade include the AKI extension.
• After Multus was uninstalled, Pods could no longer be created. This issue is fixed in v4.0.10.
• In deployments where image-registry used external S3 storage, its resources referenced Secrets through environment variables, which risked exposing sensitive information. This issue is fixed in v4.0.10, and those resources no longer pass Secrets as environment variables.

#Known Issues

• 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.0.11.
• 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.0.11.
• 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.
• After a worker node's chassis UUID changed, for example when the node was removed and rejoined or when the OVS system-id changed, the HA Chassis of the VPC BFD port was not updated to the new chassis and still referenced the old chassis UUID, which broke the BFD high-availability path of the egress gateway. This issue is fixed in v4.0.11, where the HA Chassis is updated to the new chassis automatically.
• 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.
• 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.
• 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.0.9

Issued: 2026-02-10

#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.0.9.
• 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.0.9.
• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• Fixed an issue where installing the marketplace plugin on workload clusters would fail. Fixed in ACP 4.0.9.
• Fix the issue where the egress gateway cannot route traffic from Pods in the same subnet as the egress gateway. Fixed in ACP 4.0.9.

#Known Issues

• In long-running clusters, or clusters created more than a year earlier, expired kubeconfig client certificates could cause platform pages to return HTTP 500, kubectl commands to fail, and components such as Apollo to become unreachable. This issue is fixed in v4.0.10, where the controller detects and automatically renews client certificates that are about to expire in the <cluster>-kubeconfig Secret, and /root/.kube/config on control-plane nodes now uses a client certificate valid for about 10 years.
• When post-processing of one image failed during warmup, image-loader stopped warming up the remaining images. Frontend plugin images were therefore left unwarmed, which could prevent plugins from loading and make frontend pages unavailable. This issue is fixed in v4.0.10.
• During a rolling upgrade, existing kubeconfig Secrets or ClusterCredential client certificates of a workload cluster were not rotated automatically when they had already expired or were due to expire within 30 days, which broke access to the workload cluster. This issue is fixed in v4.0.10, where the controller detects this condition, reissues the client certificates, and updates the corresponding Secret or credential.
• After upgrading from 3.16.2 to 4.0.x, the apiserver.crt generated during the upgrade lacked the Authority Key Identifier (AKI) extension, so newer Go TLS clients such as Jenkins pipelines rejected the certificate and could not connect to the Kubernetes API server. This issue is fixed in v4.0.10, where apiserver.crt certificates generated during the upgrade include the AKI extension.
• 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.
• After Multus was uninstalled, Pods could no longer be created. This issue is fixed in v4.0.10.
• 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.
• 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.
• 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.0.8

Issued: 2026-01-07

#Fixed Issues

• When an external ElasticSearch was connected over an http address, log queries could fail and the log page reported the error "cannot assign requested address". This issue is fixed in v4.0.8.
• 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.0.8.
• After an ovn-db database file was deleted manually, ovn-central could not start because the database file was empty, and it kept crashing without recovering on its own. This issue is fixed in v4.0.8, and ovn-central now recovers automatically in this situation.
• A race condition in ovn-central could leave the OVN northbound database with two leaders at the same time. The nodes then held inconsistent data, and cluster network changes such as creating Pods, creating subnets, or updating network policies failed. This issue is fixed in v4.0.8.

#Known Issues

• In long-running clusters, or clusters created more than a year earlier, expired kubeconfig client certificates could cause platform pages to return HTTP 500, kubectl commands to fail, and components such as Apollo to become unreachable. This issue is fixed in v4.0.10, where the controller detects and automatically renews client certificates that are about to expire in the <cluster>-kubeconfig Secret, and /root/.kube/config on control-plane nodes now uses a client certificate valid for about 10 years.
• During a rolling upgrade, existing kubeconfig Secrets or ClusterCredential client certificates of a workload cluster were not rotated automatically when they had already expired or were due to expire within 30 days, which broke access to the workload cluster. This issue is fixed in v4.0.10, where the controller detects this condition, reissues the client certificates, and updates the corresponding Secret or credential.
• 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.0.9.
• 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.0.9.
• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• Fixed an issue where installing the marketplace plugin on workload clusters would fail. Fixed in ACP 4.0.9.
• 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.
• After Multus was uninstalled, Pods could no longer be created. This issue is fixed in v4.0.10.
• Fix the issue where the egress gateway cannot route traffic from Pods in the same subnet as the egress gateway. Fixed in ACP 4.0.9.
• 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.
• 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.
• 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.0.7

Issued: 2025-12-10

#Fixed Issues

• Before this update, the Tekton Pipeline component had a Kubernetes STIG security vulnerability, where secrets were exposed through environment variables in the tekton-hub-api deployment, violating security best practices. With this update, the secret mounting logic in environment variables has been completely removed to ensure that the tekton-hub-api deployment no longer exposes any credentials, complying with Kubernetes STIG security requirements.
• Before this update, the tekton-results-retention-policy-agent container in Tekton Results included sensitive information in environment variables, posing a security risk of exposing credentials in plaintext during container operations and logging scenarios. With this update, sensitive information has been properly secured and removed from environment variables to prevent credential leakage, ensuring that the retention-policy-agent container no longer contains plaintext passwords or tokens in its configuration, thereby enhancing the overall security posture of the Tekton Results system.
• Before this update, the PostgreSQL container in tekton-results-postgres-0 contained environment variables with sensitive information such as PASSWORD, password, TOKEN, and token, which posed a security risk when these credentials were exposed in plain text. With this update, the sensitive environment variables have been properly secured and no longer contain plain text passwords or tokens, ensuring that sensitive credentials are handled securely and not exposed in container environment variables.
• Before this update, the environment variables of the tekton-results-api container contained sensitive information, posing security risks when these credentials were exposed in plain text. With this update, sensitive environment variables have been properly protected, and passwords and token information are no longer exposed in plain text, enhancing the security of the tekton-results-api component.
• Before this update, the pipeline interface experienced multiple display issues including text display problems, poor user experience with variable completion multi-line functionality, and unstable behavior when updating triggers where parameters and workspace would sometimes appear and sometimes disappear, requiring users to reselect the pipeline to make them appear (including the Pipeline list). With this update, these display issues have been resolved. The pipeline and pipelinerun pages now display correctly with improved text rendering, enhanced variable completion multi-line functionality for better user experience, and stable trigger update behavior where parameters and workspace consistently appear without requiring pipeline reselection.
• 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.0.7.
• 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.0.7, and the level selected during import is now applied correctly.
• After a container lifecycle configuration was added to a Deployment in the web console, updating the Deployment again once the Pod had started (for example, to change only a label) unintentionally removed that lifecycle configuration. This issue is fixed in v4.0.7, and later updates no longer discard an existing lifecycle configuration.

#Known Issues

• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• When an external ElasticSearch was connected over an http address, log queries could fail and the log page reported the error "cannot assign requested address". This issue is fixed in v4.0.8.
• 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.
• After an ovn-db database file was deleted manually, ovn-central could not start because the database file was empty, and it kept crashing without recovering on its own. This issue is fixed in v4.0.8, and ovn-central now recovers automatically in this situation.
• A race condition in ovn-central could leave the OVN northbound database with two leaders at the same time. The nodes then held inconsistent data, and cluster network changes such as creating Pods, creating subnets, or updating network policies failed. This issue is fixed in v4.0.8.
• 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.
• 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.
• 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.0.6

Issued: 2025-11-03

#Fixed Issues

• When the platform was upgraded from v3.x to v4.x and the global cluster was upgraded while a workload cluster was not, metrics created in the new custom monitoring dashboard on that cluster could not be used by HPA, so scaling rules based on those metrics never took effect. This issue is fixed in v4.0.6.

#Known Issues

• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• When an external ElasticSearch was connected over an http address, log queries could fail and the log page reported the error "cannot assign requested address". This issue is fixed in v4.0.8.
• 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.0.7.
• 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.
• After an ovn-db database file was deleted manually, ovn-central could not start because the database file was empty, and it kept crashing without recovering on its own. This issue is fixed in v4.0.8, and ovn-central now recovers automatically in this situation.
• A race condition in ovn-central could leave the OVN northbound database with two leaders at the same time. The nodes then held inconsistent data, and cluster network changes such as creating Pods, creating subnets, or updating network policies failed. This issue is fixed in v4.0.8.
• 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.
• After a container lifecycle configuration was added to a Deployment in the web console, updating the Deployment again once the Pod had started (for example, to change only a label) unintentionally removed that lifecycle configuration. This issue is fixed in v4.0.7, and later updates no longer discard an existing lifecycle configuration.
• 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.
• 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.0.5

Issued: 2025-09-30

#Fixed Issues

• After an Operator was uninstalled from a cluster, its status was incorrectly shown as Absent even though the Operator was still Ready, and users had to re-upload it manually with violet upload to restore the correct status. This issue is fixed in v4.0.5, 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.0.5.
• 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.0.5, and that workaround is no longer needed.

#Known Issues

• When upgrading a Redis Sentinel instance from v5 to v7, occasional brain split incidents may occur, potentially leading to data loss.
  Solution: Back up the Redis instance data before performing a cross-version upgrade.
• When cluster network anomalies occur, failure to update the primary node label of a PostgreSQL instance may result in abnormal instance status, potentially causing partial new connection failures.
• Before this update, the pipeline interface experienced multiple display issues including text display problems, poor user experience with variable completion multi-line functionality, and unstable behavior when updating triggers where parameters and workspace would sometimes appear and sometimes disappear, requiring users to reselect the pipeline to make them appear (including the Pipeline list). With this update, these display issues have been resolved. The pipeline and pipelinerun pages now display correctly with improved text rendering, enhanced variable completion multi-line functionality for better user experience, and stable trigger update behavior where parameters and workspace consistently appear without requiring pipeline reselection.
• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• When an external ElasticSearch was connected over an http address, log queries could fail and the log page reported the error "cannot assign requested address". This issue is fixed in v4.0.8.
• 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.0.7.
• 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.
• After an ovn-db database file was deleted manually, ovn-central could not start because the database file was empty, and it kept crashing without recovering on its own. This issue is fixed in v4.0.8, and ovn-central now recovers automatically in this situation.
• A race condition in ovn-central could leave the OVN northbound database with two leaders at the same time. The nodes then held inconsistent data, and cluster network changes such as creating Pods, creating subnets, or updating network policies failed. This issue is fixed in v4.0.8.
• When the platform was upgraded from v3.x to v4.x and the global cluster was upgraded while a workload cluster was not, metrics created in the new custom monitoring dashboard on that cluster could not be used by HPA, so scaling rules based on those metrics never took effect. This issue is fixed in v4.0.6.
• 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.
• After a container lifecycle configuration was added to a Deployment in the web console, updating the Deployment again once the Pod had started (for example, to change only a label) unintentionally removed that lifecycle configuration. This issue is fixed in v4.0.7, and later updates no longer discard an existing lifecycle configuration.
• 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.
• 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.0.4

Issued: 2025-09-01

#Fixed Issues

• Previously, upgrading the cluster would leave behind CRI (Container Runtime Interface) Pods, which blocked further upgrades to version 4.1. This issue has been fixed in version 4.0.4.

#Known Issues

No issues in this release.

#4.0.3

Issued: 2025-07-01

#Fixed Issues

• In a highly available cluster that used the Calico network, master nodes could not be deleted. This issue is fixed in v4.0.3.

#Known Issues

• Previously, upgrading the cluster would leave behind CRI (Container Runtime Interface) Pods, which blocked further upgrades to version 4.1. This issue has been fixed in version 4.0.4.

#4.0.2

Issued: 2025-06-06

#Fixed Issues

• Draining a node on a public cloud Kubernetes cluster managed by the platform, such as ACK, failed with a 404 error. This issue is fixed in v4.0.2.

#Known Issues

• In a highly available cluster that used the Calico network, master nodes could not be deleted. This issue is fixed in v4.0.3.

#4.0.1

Issued: 2025-05-04

#Fixed Issues

• 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.0.11.
• Under heavy cluster api-server load, the aggregate worker in kyverno-report-controller could fail to start, so compliance reports were not created properly: PolicyReport resources were missing and the web console showed no policy violation information, or only part of the report data. This issue is fixed in v4.0.1.

#Known Issues

• In a highly available cluster that used the Calico network, master nodes could not be deleted. This issue is fixed in v4.0.3.
• Draining a node on a public cloud Kubernetes cluster managed by the platform, such as ACK, failed with a 404 error. This issue is fixed in v4.0.2.

#4.0.0

Issued: 2025-04-08

#Features and Enhancements

#Installation and Upgrade: Modular Architecture

We've completely redesigned our platform's architecture to provide unprecedented flexibility, faster updates, and reduced operational overhead.

Streamlined Installation Our platform is now deployed via a lean core package containing only the essential components. Once the foundation is in place, customers can pick and choose exactly which Operators or cluster plugins they need—whether DevOps, Service Mesh, or other specialized features—and download, upload, and install them individually.

Targeted Patches

• Patch releases include only those components that actually require bug fixes.
• Components without fixes remain exactly as they are, ensuring the rest of the platform stays untouched.
• Customers apply patches through the platform's built-in, standardized upgrade mechanism—rather than manually updating individual components—making maintenance and tracking far more straightforward.

Intelligent Upgrades

• During an upgrade, only components with new code are replaced and restarted.
• Unmodified components retain their existing versions and uptime.
• This minimizes downtime and shortens the maintenance window for a smoother upgrade experience.

Independent Component Versioning

• Most Operators follow their own release schedules, separate from the core platform.
• New features and fixes go live as soon as they're ready—no need to wait for a full-platform update.
• This approach accelerates delivery and lets customers benefit from improvements faster.

#Clusters: Declarative Cluster Lifecycle Management with Cluster API

On-premises clusters now leverage the Kubernetes Cluster API for fully declarative operations, including:

• Cluster creation
• Node scaling and joining

This seamless Cluster API integration fits directly into your IaC pipelines, enabling end-to-end, programmatic control over your cluster lifecycle.

#Operator & Extension: Comprehensive Capability Visibility

Complete Operator Catalog

The OperatorHub now displays all supported Operators regardless of whether their packages have been uploaded to the platform. This enhancement:

• Provides full visibility into platform capabilities even in air-gapped environments
• Eliminates information gaps between what's available and what's known to users
• Reduces discovery friction when exploring platform capabilities

Version Flexibility

Users can now select specific Operator versions during installation rather than being limited to only the latest version, providing greater control over component compatibility and upgrade paths.

Web Console Extensions

Operators now support anchor-based Web Console extensions, allowing functionality-specific frontend images to be included within Operators and seamlessly integrated into the platform's Web Console.

Cluster Plugin Enhancements

All improvements to Operator visibility, version selection, and Web Console extension capabilities also apply to cluster plugins, ensuring consistent user experience across all platform extensions.

#Log query logic optimization

The log query page has been optimized to solve the experience and performance problems users encounter when using the log query function:

• The original radio box has been replaced with the advanced search component. Now you can use the log search as you use the GIT search.
• Independent query conditions for log content
• The location of the time query criteria has been adjusted. Now you will not reset your log filter criteria when you adjust the time range.
• Optimized the log query API to improve the overall query performance

#ElasticSearch upgrade to 8.17

We upgraded the version of ElasticSearch to 8.17 to follow up the functions and improvements of the community.

#ALB authentication

ALB now support various authentication mechanism, which allows user to handle authentication at Ingress level instead of implementing it in each backend application.

#ALB supports ingress-nginx annotations

This release adds support for common ingress-nginx annotations in ALB, including keepalive settings, timeout configurations, and HTTP redirects, enhancing compatibility with the community ingress-nginx.

#Kubevirt live migration optimization

During the live migration process, the network interruption time has been reduced to less than 0.5 seconds, and existing TCP connections will not be disconnected. This optimization significantly improves the stability and reliability of virtual machine migrations in production environments.

#LDAP/OIDC integration optimization

The LDAP/OIDC integration form fields have been adjusted, mainly including removal of unnecessary/duplicate fields and optimization of field descriptions. LDAP/OIDC integration now supports configuration through YAML, allowing user attribute mapping within the YAML file.

#Source to Image (S2I) Support

• Added Alauda Container Platform Builds operator for automated image building from source code
• Supports Java/Go/Node.js/Python language stacks
• Streamlines application deployment via source code repositories

#On-prem Registry Solution

• ACP Registry delivered lightweight Docker Registry with enterprise-ready features
• Provides out-of-the-box image management capabilities
• Simplifies application delivery

#GitOps Module Refactoring

• Decoupled ACP GitOps into standalone cluster plugin architecture
• Upgraded Argo CD to v2.14.x version
• Enhanced GitOps-based application lifecycle management

#Namespace-level Monitoring

• Introduced dynamic monitoring dashboards at namespace level
• Provides Applications/Workloads/Pods metrics visualization

#Crossplane Integration

• Released Alauda Build of Crossplane distribution
• Implements app-centric provisioning via XRD compositions

#Virtualization Updates

• Upgraded to KubeVirt 1.4 for enhanced virtualization capabilities
• Optimized image handling for faster VM provisioning
• Optimized VM live migration, now initiable directly from the UI with visible migration status
• Improved binding networking with dual-stack (IPv4/IPv6) support
• Added vTPM support to enhance VM security

#Ceph Storage Updates

• Metro-DR with stretch cluster enables real-time data synchronization across availability zones
• Regional-DR with pool-based mirroring enhances data protection

#TopoLVM Updates

• Added support for multipath device deployment, improving flexibility and stability

#Fixed Issues

• After a new Operator version was published, users had to wait about 10 minutes before that version could be installed. This was improved in v4.0.0, where the wait is reduced to 2 minutes so that new Operator versions can be installed sooner.

• On gpu nodes with multiple cards on a single node, gpu-manager occasionally exists, with unsuccessful scheduling issues for applications using vgpu.
• When using the pgpu plugin, you need to set the default runtimeclass on the gpu node to nvidia. if you don't, it may cause the application to not be able to request gpu resources properly.
• On a single GPU card, gpu-manager cannot create multiple inference services based on vllm, mlserver at the same time.
  On AI platforms, this issue occurs when gpu-manager is used to create multiple inference services; on container platforms, this issue does not occur when gpu-manager is used to create multiple smart applications.
• With mps, pods restart indefinitely when nodes are low on resources.

#Known Issues

• In a highly available cluster that used the Calico network, master nodes could not be deleted. This issue is fixed in v4.0.3.
• Under heavy cluster api-server load, the aggregate worker in kyverno-report-controller could fail to start, so compliance reports were not created properly: PolicyReport resources were missing and the web console showed no policy violation information, or only part of the report data. This issue is fixed in v4.0.1.
• 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.0.4, and credentials created in the console now carry the same complete authentication data as those created from the command line.
• 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.

No issues in this release.

• When the Docking to External ElasticSearch feature was in use, upgrading from any version to 4.0.x caused the Log Storage for Elasticsearch component to fail to upgrade. This issue is fixed in v4.0.9.
• When an external ElasticSearch was connected over an http address, log queries could fail and the log page reported the error "cannot assign requested address". This issue is fixed in v4.0.8.
• 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.