#Примечания к выпуску

#4.1.5

Выпущено: 2026-02-10

#Исправленные проблемы

• 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.1.5.
• 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.1.5.
• Fixed an issue where installing the marketplace plugin on workload clusters would fail. Fixed in ACP 4.1.5.
• After enabling u2o for the Underlay subnet, occasional communication failures may occur between Pods within the subnet and the physical gateway of the subnet.
• Fix the issue where the egress gateway cannot route traffic from Pods in the same subnet as the egress gateway.

#Известные проблемы

• In certain cases, users may find that the operations automatically recorded by the platform in a ResourcePatch resource do not match the actual modifications they made to the component. As a result, when the ResourcePatch controller applies the patch, the component may undergo unexpected changes.
  Workaround: Users should manually modify the ResourcePatch resource to ensure it reflects the intended changes.
• 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.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• 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.
• The temporary files were not deleted after log archiving, preventing disk space from being reclaimed. This issue has been fixed.
• Fixed an issue in dual-stack clusters where, after a Pod was manually configured with an incorrect static IPv6 address, ovn-controller failed to process the correction even after the address was fixed, preventing subsequent IP allocation in the affected subnet.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• 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 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.1.4

Выпущено: 2026-01-07

#Исправленные проблемы

• 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.1.4.
• When a user is automatically disabled by the system due to long-term lack of login, it will be automatically disabled again after being manually activated by the administrator. This issue has been fixed.
• Previously, the status field of an upmachinepool resource stored the associated machine resources without any ordering. This caused the resource to be updated on every reconcile loop, resulting in excessively large audit logs. This issue has now been fixed.
• When the platform has a large number of clusters, the project quota of a single cluster cannot be updated after the quota is set for the project using the batch set project quota function. This issue has been fixed.
• Fix rate limit issues that will prevent pod from starting when more than 100 Pods run on one node.
• Enhanced Ceph disaster recovery guides with comprehensive step-by-step procedures for block storage.
• Fixed an issue where modifying the Pod Security Policy when importing a namespace into a project did not take effect.
• Fixed an issue in the console where updating a Deployment in a specific sequence could cause the container lifecycle configuration to be unintentionally removed.
• Fix race issue in Multus that will prevent pod from starting when node restarts.

#Известные проблемы

• 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.1.5.
• 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.1.5.
• Fixed an issue where installing the marketplace plugin on workload clusters would fail. Fixed in ACP 4.1.5.
• In certain cases, users may find that the operations automatically recorded by the platform in a ResourcePatch resource do not match the actual modifications they made to the component. As a result, when the ResourcePatch controller applies the patch, the component may undergo unexpected changes.
  Workaround: Users should manually modify the ResourcePatch resource to ensure it reflects the intended changes.
• 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.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• 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.
• The temporary files were not deleted after log archiving, preventing disk space from being reclaimed. This issue has been fixed.
• After enabling u2o for the Underlay subnet, occasional communication failures may occur between Pods within the subnet and the physical gateway of the subnet.
• Fix the issue where the egress gateway cannot route traffic from Pods in the same subnet as the egress gateway.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• 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 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.1.3

Выпущено: 2025-11-03

#Исправленные проблемы

• Fixed an issue of endless loading on the Alauda Service Mesh page for unauthorized users.
• Fix the issue where Pod flow tables are not properly cleaned up after enabling u2o, causing access failures.
• Fixed an issue where, after upgrading the platform from v3.x to v4.x, if a business cluster was not upgraded, the metrics created in its new custom monitoring dashboard could not be used by HPA.

#Известные проблемы

• 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.1.5.
• 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.1.4.
• Previously, the status field of an upmachinepool resource stored the associated machine resources without any ordering. This caused the resource to be updated on every reconcile loop, resulting in excessively large audit logs. This issue has now been fixed.
• When the platform has a large number of clusters, the project quota of a single cluster cannot be updated after the quota is set for the project using the batch set project quota function. This issue has been fixed.
• 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.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• 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.
• The temporary files were not deleted after log archiving, preventing disk space from being reclaimed. This issue has been fixed.
• After enabling u2o for the Underlay subnet, occasional communication failures may occur between Pods within the subnet and the physical gateway of the subnet.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• Fix rate limit issues that will prevent pod from starting when more than 100 Pods run on one node.
• Enhanced Ceph disaster recovery guides with comprehensive step-by-step procedures for block storage.
• Fixed an issue in the console where updating a Deployment in a specific sequence could cause the container lifecycle configuration to be unintentionally removed.
• Fix race issue in Multus that will prevent pod from starting when node restarts.
• 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 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.1.2

Выпущено: 2025-10-01

#Исправленные проблемы

• When an Operator or Cluster Plugin included multiple frontend extensions, the left-side navigation of these extensions could become unresponsive. The temporary workaround required users to add the annotation cpaas.io/auto-sync: "false" to the extension’s ConfigMap. This behavior has now been permanently fixed in the code.
• In some cases, installing a new Operator version after uploading it via violet upload would fail unexpectedly. This intermittent issue has been fixed.
• After a global cluster upgrade, monitoring dashboards for all Applications and all kinds of Workloads in non-upgraded worker clusters will not display any data.

#Известные проблемы

• 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.1.4.
• Previously, the status field of an upmachinepool resource stored the associated machine resources without any ordering. This caused the resource to be updated on every reconcile loop, resulting in excessively large audit logs. This issue has now been fixed.
• When the platform has a large number of clusters, the project quota of a single cluster cannot be updated after the quota is set for the project using the batch set project quota function. This issue has been fixed.
• 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.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• 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.
• The temporary files were not deleted after log archiving, preventing disk space from being reclaimed. This issue has been fixed.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• Fixed an issue in the console where updating a Deployment in a specific sequence could cause the container lifecycle configuration to be unintentionally removed.
• Fix race issue in Multus that will prevent pod from starting when node restarts.
• Fix the issue where Pod flow tables are not properly cleaned up after enabling u2o, causing access failures.
• Fixed an issue where, after upgrading the platform from v3.x to v4.x, if a business cluster was not upgraded, the metrics created in its new custom monitoring dashboard could not be used by HPA.
• 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 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.1.1

Выпущено: 2025-09-04

#Исправленные проблемы

#Известные проблемы

• When the platform has a large number of clusters, the project quota of a single cluster cannot be updated after the quota is set for the project using the batch set project quota function. This issue has been fixed.
• 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.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• When an Operator or Cluster Plugin included multiple frontend extensions, the left-side navigation of these extensions could become unresponsive. The temporary workaround required users to add the annotation cpaas.io/auto-sync: "false" to the extension’s ConfigMap. This behavior has now been permanently fixed in the code.
• In some cases, installing a new Operator version after uploading it via violet upload would fail unexpectedly. This intermittent issue has been fixed.
• 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.
• The temporary files were not deleted after log archiving, preventing disk space from being reclaimed. This issue has been fixed.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• Fixed an issue in the console where updating a Deployment in a specific sequence could cause the container lifecycle configuration to be unintentionally removed.
• Fix race issue in Multus that will prevent pod from starting when node restarts.
• Fix the issue where Pod flow tables are not properly cleaned up after enabling u2o, causing access failures.
• Fixed an issue where, after upgrading the platform from v3.x to v4.x, if a business cluster was not upgraded, the metrics created in its new custom monitoring dashboard could not be used by HPA.
• After a global cluster upgrade, monitoring dashboards for all Applications and all kinds of Workloads in non-upgraded worker clusters will not display any data.
• 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 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.1.0

Выпущено: 2025-07-31

#Функции и улучшения

#Неизменяемая инфраструктура

Выпущены:

• Alauda Container Platform DCS Infrastructure Provider
• Alauda Container Platform Kubeadm Provider

Оба плагина имеют жизненный цикл Agnostic и выпускаются асинхронно вместе с Alauda Container Platform (ACP).

• DCS Infrastructure Provider реализует интерфейс Cluster API Infrastructure Provider и интегрируется с Huawei Datacenter Virtualization Solution (DCS).
• Kubeadm Provider устанавливает и настраивает control plane Kubernetes и узлы на виртуальных машинах, предоставленных поставщиком инфраструктуры.

Вместе эти плагина обеспечивают полностью автоматизированное управление кластерами в DCS.

Документация находится в процессе подготовки и будет опубликована в онлайн-документации после выпуска.

#Конфигурация машин

Выпущено: Alauda Container Platform Machine Configuration Жизненный цикл: Agnostic, выпускается асинхронно вместе с ACP.

Machine Configuration управляет обновлением файлов, systemd units и SSH public keys на узлах кластера и предоставляет:

• CRD MachineConfig для записи конфигураций на хосты.
• CRD MachineConfigPool для группировки и управления конфигурациями узлов на основе меток роли.
• При установке кластера автоматически создаются два пула MachineConfigPool по умолчанию — один для узлов control plane и один для worker-узлов. Кроме того, при необходимости пользователи могут создавать собственные MachineConfigPool.

Система непрерывно отслеживает расхождение конфигурации и помечает затронутые узлы как Degraded до устранения проблемы.

Подробную информацию о функции см. в Machine Configuration.

#Шифрование etcd

Выпущено: Alauda Container Platform etcd Encryption Manager Жизненный цикл: Agnostic, выпускается асинхронно вместе с ACP.

Предоставляет периодическую ротацию ключей шифрования данных etcd на рабочих кластерах с использованием AES-GCM для secrets и configmaps. Поддерживает бесшовное повторное шифрование и загрузку ключей без прерывания рабочих нагрузок, сохраняя обратную совместимость с последними 8 ключами.

Подробности см. в Шифрование etcd.

#Ротация сертификатов Kubernetes

Выпущено: Alauda Container Platform Kubernetes Certificates Rotator Жизненный цикл: Agnostic, выпускается асинхронно вместе с ACP.

Обеспечивает автоматическую ротацию сертификатов, используемых компонентами Kubernetes.

Подробности см. в Автоматическая ротация сертификатов Kubernetes.

#Усовершенствование кластера

Выпущено: Alauda Container Platform Cluster Enhancer Жизненный цикл: Aligned.

Новые функции и изменения:

• etcd Backup: Функциональность резервного копирования etcd перенесена из Backup & Recovery в Cluster Enhancer из-за различий в сценариях использования и реализации. Оптимизирован способ развертывания, чтобы избежать конфликтов при изменении конфигурации и обновлениях.
• Event Cleanup: Реализована активная внешняя очистка просроченных событий Kubernetes, чтобы предотвратить их накопление в etcd, снизив нагрузку на etcd и риски нестабильности во время перезапусков.
• Certificate Monitoring: Управление сертификатами преобразовано в мониторинг сертификатов с правилами оповещений и панелями мониторинга, заменив предыдущую функцию управления Certificates. Реализован более эффективный подход к мониторингу, при этом также отслеживаются loopback-сертификаты, используемые kube-apiserver.
• Cluster Monitoring Dashboard Migration: Ресурсы мониторинга кластера перенесены из chart-cpaas-monitor в Cluster Enhancer.
• Cluster Details Chart Migration: Панели мониторинга в сведениях о кластере переключены на пользовательские панели мониторинга.

#Chinese Language Pack

Поддержка китайского языка отделена от платформы и выпущена в виде плагина Chinese Language Pack. После установки платформа по умолчанию использует английский язык; при необходимости поддержки китайского языка пользователи могут установить этот плагин.

#Создание on-premise кластера

Начиная с ACP 4.1, при создании on-premise кластеров поддерживается только последняя версия Kubernetes, предоставляемая платформой, вместо прежней возможности выбора из четырёх версий Kubernetes.

#Logging

• ClickHouse обновлён до версии v25.3.
• В журналы приложений добавлены теги POD IP, что позволяет фильтровать их по POD IP.
• Улучшен сбор логов стандартного вывода: теперь поле timestamp отражает фактическое время вывода лога, а не время компонента сбора, что обеспечивает отображение логов в правильном порядке.

#Monitoring

• Prometheus обновлён до версии v3.4.2.
• Пользовательские переменные теперь поддерживают три типа: Constant, Custom и Textbox.
  • Constant: Фиксированное значение, которое не изменяется.
  • Custom: Значение, выбираемое из предопределённого списка.
  • Textbox: Значение, вводимое пользователем вручную.
• Stat Chart теперь поддерживает режим Graph, который отображает под статистикой кривую тренда за выбранный период.
• Value Mapping теперь поддерживает регулярные выражения и специальные значения.
• Панели теперь можно копировать, что позволяет дублировать панель в пределах текущей панели мониторинга.

#Управление арендатором

• Квоты проектов теперь поддерживают пользовательские квоты ресурсов и квоты storage class.
• Плагин предоставляет новые метрики: cpaas_project_resourcequota и cpaas_project_resourcequota_aggregated, которые можно использовать для отображения квот проектов на панелях мониторинга.
  • cpaas_project_resourcequota: Доступна в каждом кластере.
  • cpaas_project_resourcequota_aggregated: Доступна в кластере global и агрегирует данные из всех кластеров.
• Пользовательские роли теперь имеют дополнительные ограничения, позволяя назначать разрешения только в пределах соответствующего типа роли:
  • Platform Role: Может назначать все разрешения.
  • Project Role: Может назначать только разрешения в пределах области предустановленной роли платформы project-admin-system.
  • Namespace Role: Может назначать только разрешения в пределах области предустановленной роли платформы namespace-admin-system.
  • Нельзя назначать разрешения, которыми текущий пользователь не обладает.

#Автоматизированное решение для распределения UID/GID для безопасного выполнения Pod

В Kubernetes можно настроить выделенный диапазон User ID (UID) и Group ID (GID) для каждого namespace. Когда пользователи развертывают Pods в таком namespace, мы автоматически задаём RunAsUser и fsGroup для всех контейнеров внутри Pod на основе предопределённых политик безопасности namespace. Эти пользователи и группы будут динамически назначаться из диапазона UID/GID, авторизованного для этого конкретного namespace.

Основные возможности и ценность:

• Повышенная безопасность: За счёт принудительного запуска контейнеров от непривилегированных пользователей и ограничения диапазонов UID/GID это решение эффективно снижает риски безопасности, такие как container escape и повышение привилегий, в соответствии с принципом наименьших привилегий.
• Упрощённое управление: Разработчикам больше не нужно вручную указывать UID/GID в конфигурации каждого контейнера или Pod. После настройки namespace все развёрнутые в нём Pods автоматически наследуют и применяют корректные параметры безопасности.
• Обеспечение соответствия требованиям: Это помогает клиентам лучше соблюдать внутренние политики безопасности и внешние требования соответствия, обеспечивая работу контейнеризованных приложений в регулируемой среде.

Использование:

• Добавьте метку security.cpaas.io/enabled в ваш Namespace.

#Продуктовое решение на основе Argo Rollouts

Наше продуктовое решение, построенное на open-source Argo Rollouts, предоставляет пользователям детальный контроль над процессами выпуска. Благодаря реализации поэтапных и управляемых стратегий развертывания оно минимизирует сбои в работе бизнеса или отказы, которые могут возникать при запуске новых функций или версий, значительно снижая риски выпуска.

Основные возможности и ценность:

• Blue-Green Deployment: Обеспечивает обновления без простоя за счёт развертывания новых версий рядом с существующей production-средой. После тщательного тестирования трафик можно мгновенно или быстро переключить со старой версии на новую.
• Canary Deployment: Позволяет постепенно вводить новые версии, направляя на них небольшой процент, например 5%, production-трафика, чтобы оценить их производительность и стабильность. На основе заранее определённых метрик, таких как уровень ошибок или задержка, система может автоматически увеличивать трафик или выполнять откат при обнаружении проблем, ограничивая влияние потенциальных неполадок.
• Platform-Certified Argo Rollout Chart: Вы можете напрямую загрузить community open-source Argo Rollouts либо выбрать platform-certified версию, доступную через Alauda Cloud.

#Alauda Container Platform Registry: глубокая интеграция с правами пользователей платформы

Чтобы обеспечить более безопасное и удобное управление образами, мы углубили интеграцию нашего lightweight image registry с существующей системой прав пользователей платформы.

Основные возможности и ценность:

• Глубокая интеграция с пользовательской системой платформы: Image registry бесшовно интегрирован с механизмами аутентификации пользователей и Role-Based Access Control (RBAC) платформы. Разработчики, тестировщики и администраторы могут напрямую использовать свои существующие учётные данные платформы, что устраняет необходимость в дополнительной настройке или отдельном управлении учётными записями. Платформа автоматически сопоставляет права пользователя в Namespace с соответствующими правами доступа к образам в registry. Например, пользователи могут выполнять push и pull образов только в "определённых Namespaces", к которым у них есть доступ.
• Более удобные операции из командной строки: Поддерживаются операции pull и push образов через CLI-инструменты, что значительно повышает эффективность и удобство работы.

Предупреждение:

• Поддерживается только установка Alauda Container Platform Registry с помощью этого решения.

#Решение автоматического масштабирования на основе KEDA

Чтобы приложения могли интеллектуально реагировать на фактическую нагрузку, наша платформа предлагает решение автоматического масштабирования, построенное на KEDA (Kubernetes Event-driven Autoscaling).

Основные возможности и ценность:

• Эластичное масштабирование на основе событий: KEDA поддерживает более 70 типов scaler-ов для автоматического масштабирования приложений, таких как Deployments, Jobs и т. д. Помимо традиционного использования CPU и памяти, оно может отслеживать такие метрики, как длина очереди сообщений, например Kafka и RabbitMQ, количество соединений с базой данных, скорость HTTP-запросов и пользовательские метрики.
• Platform-Certified KEDA Operator: Загрузите и установите platform-certified версию через Alauda Cloud.

Решения:

• Продукт предоставляет два решения: автоматическое масштабирование на основе метрик Prometheus и масштабирование до нуля.

#Решение аварийного восстановления приложений между кластерами (Alpha)

Теперь наша платформа предлагает новое GitOps-решение для аварийного восстановления приложений между кластерами (DR), предназначенное для значительного повышения устойчивости и доступности приложений.

Основные возможности и ценность:

• Разнообразные модели DR: Гибко поддерживает Active-Active (AA-DR) для глобальных сценариев с высокой нагрузкой и высокой конкуренцией; Active-Standby Dual-Active (AS-DR) для оптимизации использования ресурсов; а также Active-Passive (AP-DR) для строгого обеспечения согласованности данных.
• Автоматизированная GitOps-синхронизация: Использует возможности GitOps в сочетании с ApplicationSet и Kustomize для автоматической синхронизации конфигурации между кластерами, обеспечивая постоянную готовность среды DR.
• Гибкое управление трафиком: Использует DNS и GSLB-функциональность, предоставляемую сторонними системами, для интеллектуального перенаправления трафика на основе проверки состояния и быстрого переключения при отказе, минимизируя прерывания сервиса.
• Многомерная синхронизация данных: Решение предоставляет рекомендации по различным методам, включая синхронизацию на уровне базы данных, хранилища и приложения, чтобы обеспечить конечную согласованность данных между кластерами и заложить основу для непрерывности бизнеса.
• Упрощённый процесс переключения при отказе: Чётко определены подробные шаги для обнаружения отказа, перенаправления трафика, повышения состояния и восстановления сервиса, что обеспечивает эффективное и упорядоченное переключение во время аварии.

Примечание:

• Аспект синхронизации данных в решении аварийного восстановления тесно связан с особенностями бизнеса клиента и объёмом данных, поэтому может существенно различаться. Следовательно, фактическая реализация требует специальной настройки, адаптированной к конкретному сценарию клиента.

#Комплексное обновление зависимых компонентов для повышения стабильности и безопасности

В этот выпуск включены обновления следующих основных компонентов:

• KubeVirt обновлён до v1.5.2
• Ceph обновлён до 18.2.7
• MinIO обновлён до RELEASE.2025-06-13T11-33-47Z

Другие open-source-зависимости также синхронизированы с их последними community-версиями, что устраняет множество известных проблем и уязвимостей безопасности, обеспечивая повышение стабильности и надёжности системы.

#Расширенные возможности виртуализации для повышения непрерывности бизнеса и безопасности

На основе практических требований к приложениям в средах виртуализации в этом обновлении реализовано несколько ключевых улучшений:

• Миграция при высокой доступности: Автоматически переносит виртуальные машины на здоровые узлы при отказе узла, обеспечивая непрерывность бизнеса.
• Клонирование виртуальных машин: Быстро создаёт новые виртуальные машины на основе существующих, значительно повышая эффективность развертывания.
• Шаблоны виртуальных машин: Поддерживается преобразование существующих виртуальных машин в шаблоны для быстрого пакетного развёртывания сред с похожей конфигурацией.
• Доверенные вычисления (vTPM): Теперь виртуальные машины поддерживают функции доверенных вычислений, повышая общий уровень безопасности.

Подробные инструкции и рекомендации по этим новым функциям обновлены в руководстве пользователя.

#Служба объектного хранилища на основе COSI v2 обеспечивает более гибкое и эффективное управление хранилищем

Container Object Storage Interface (COSI) обновлён до версии v2 (alpha), что принесло следующие улучшения:

• Многокластерный доступ: Поддерживает одновременный доступ к нескольким различным кластерам хранилища Ceph или MinIO, обеспечивая более эффективное централизованное управление.
• Тонкое управление квотами: Позволяет гибко задавать квоты для различных категорий хранилища, оптимизируя использование ресурсов.
• Расширенное управление правами: Поддерживает создание различных прав доступа пользователей, включая режимы read-write, read-only и write-only.
• Поддержка анонимного доступа: Ceph COSI Driver теперь поддерживает анонимный доступ, обеспечивая быстрый внешний HTTP-доступ через конфигурацию Ingress.

#ALB переходит в режим обслуживания

План на будущее:

• Для пользователей ingress напрямую используйте ingress-nginx
• Будущие новые функции будут поддерживаться только на GatewayAPI
• Избегайте упоминания ALB, если нет веских требований к возможностям, доступным только в ALB, например выделения портов проекта

В настоящее время в GatewayAPI не поддерживаются следующие эксклюзивные функции ALB:

• Выделение экземпляров gateway на основе портов
• Перенаправление трафика на основе IP и диапазонов IP
• Алгоритм EWMA для балансировки нагрузки
• Использование WAF
• Представления мониторинга на уровне правил

#Использование ingress-nginx для предоставления возможностей Ingress

Представлена наиболее распространённая в сообществе реализация Ingress controller, чтобы заменить существующие сценарии Ingress на базе ALB.

Основные возможности и ценность:

• Совместимость с общепринятыми практиками сообщества, что позволяет избежать неоднозначностей в коммуникации
• Ingress UI поддерживает пользовательские annotations для использования богатых расширенных возможностей ingress-nginx
• Исправления проблем безопасности

Kube-OVN поддерживает новый высокодоступный многоактивный Egress Gateway

Новый механизм Egress устраняет ограничения предыдущих централизованных gateway. Новый Egress Gateway предоставляет:

• Высокую доступность Active-Active через ECMP для горизонтального масштабирования пропускной способности
• Переключение менее чем за 1 секунду через BFD
• Повторное использование режима underlay, при этом IP-адреса Egress Gateway отделены от Nodes
• Тонкий контроль маршрутизации через Namespace selectors и Pod selectors
• Гибкое планирование Egress Gateway через Node selectors

#Поддержка кластерных сетевых политик типа AdminNetworkPolicy

Kube-OVN поддерживает новый API кластерной сетевой политики сообщества. Этот API позволяет администраторам кластера применять сетевые политики без необходимости настраивать их в каждом Namespace.

Преимущества по сравнению с предыдущими кластерными сетевыми политиками:

• Стандартный API сообщества, заменяющий внутренние API
• Отсутствие конфликтов с NetworkPolicy (более высокий приоритет, чем у NetworkPolicy)
• Поддержка настроек приоритета

Подробнее: Блог Red Hat об AdminNetworkPolicy

#Устаревшие и удалённые функции

#Удаление Docker Runtime

• Ранее платформа предоставляла образы Docker runtime, хотя это не было runtime по умолчанию для новых кластеров. Начиная с ACP 4.1 образы Docker runtime больше не предоставляются по умолчанию.

#Удаление Template Application

• Точка входа Application → Template Application официально удалена. Перед обновлением убедитесь, что все Template Applications переведены в Helm Chart Application.