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

#4.3.1

Выпущено: 2026-05-20

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

• Users using the kubectl top node command to query node usage will be returned an error, this issue has been resolved in version 4.3.1
• Captain now supports configuring the number of HelmRequest workers per cluster, reducing queue blocking caused by problematic charts and improving chart deployment and update efficiency.
• Optimized Archon-Harbor interactions to fix Helm chart publishing failures caused by Harbor probe timeouts.

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

• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• 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.3.0

Выпущено: 2026-04-16

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

#Поддержка Kubernetes 1.34

ACP 4.3 добавляет поддержку Kubernetes 1.34 для сценариев кластеров, управляемых платформой.

Для обновлений до ACP 4.3 совместимыми версиями workload-кластера являются 1.34, 1.33, 1.32 и 1.31. Это требование к совместимой версии определяет, можно ли обновить кластер global, и оно не связано с диапазоном управления сторонними кластерами.

Дополнительные сведения см. в разделе Kubernetes Support Matrix.

#Процесс обновления кластера на основе CVO

ACP 4.3 представляет процесс обновления на основе Cluster Version Operator (CVO) для кластеров global и workload-кластеров.

Ключевые возможности включают:

• Подготовку артефактов обновления и контроллера обновления с помощью bash upgrade.sh
• Выполнение preflight-проверок перед запуском
• Запрос обновлений из Web Console или путем обновления ClusterVersionShadow.spec.desiredUpdate
• Просмотр условий, результатов preflight-проверок, стадий и истории из cvsh.status

ACP CLI также добавляет ориентированные на обновление административные команды, такие как ac adm upgrade, ac adm upgrade status, --to-latest, --to и --allow-explicit-upgrade, для запроса обновлений workload-кластеров и устранения неполадок из текущего контекста.

Руководство по эксплуатации см. в разделе Upgrade.

#Автономное обновление Cluster Plugin

ACP 4.3 добавляет поддержку автономного обновления cluster plugins, использующих жизненный цикл Aligned или Agnostic.

На странице Cluster Plugins теперь отображается жизненный цикл плагина, а подходящие плагины можно обновлять независимо со страницы списка или страницы сведений. Плагины Core по-прежнему обновляются вместе с кластером.

#Кластеры global на базе Alauda OS в Huawei DCS

ACP 4.3 позволяет администраторам создавать кластер global в Huawei DCS с неизменяемой инфраструктурой на базе Alauda OS. Это расширяет модель неизменяемой инфраструктуры от workload-кластеров до сценариев установки платформы в DCS.

Дополнительные сведения см. в разделе About Immutable Infrastructure.

#Поддержка Huawei Cloud Stack в Immutable Infrastructure

ACP 4.3 добавляет поддержку Immutable Infrastructure для Huawei Cloud Stack (HCS). Документация по провайдеру HCS теперь охватывает обзор провайдера, установку, создание кластера, управление узлами, обновления кластера и API провайдера в наборе документации Immutable Infrastructure.

Дополнительные сведения см. в разделе About Immutable Infrastructure.

#Поддержка VMware vSphere в цикле 4.3

ACP 4.3 начинает внедрять поддержку Immutable Infrastructure для VMware vSphere. Работы по провайдеру теперь отслеживаются в наборе документации Immutable Infrastructure, а публичные сведения об установке и окончательное именование плагина все еще публикуются.

Дополнительные сведения см. в разделе About Immutable Infrastructure.

#Новый пункт предварительного просмотра Web Console

ACP Core теперь предоставляет якорь верхней навигации, необходимый для опыта Web Console следующего поколения. Когда Alauda Container Platform Web Console Base установлен в кластере global, пользователи в представлениях Container Platform и Administrator могут открыть новую консоль через пункт Preview Next-Gen Console в отдельной вкладке браузера.

Этот опыт предназначен для постепенной миграции и работает с плагином Web Console Base в глобальном кластере и плагином Web Console Collector в workload-кластерах.

#Базовый уровень containerd 2.0

ACP 4.3 повышает базовый уровень платформенного runtime до containerd 2.0. Перед обновлением сред, которые используют настраиваемую конфигурацию containerd, проверьте операционные процедуры, зависящие от runtime.

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

Для сторонних кластеров ACP 4.3 теперь принимает версии Kubernetes в диапазоне >=1.19.0 <1.35.0.

Этот диапазон управления отделен от совместимых версий Kubernetes, используемых для определения того, можно ли обновить кластер global.

В продуктовой документации по-прежнему публикуются только версии Kubernetes, прошедшие продуктовую проверку для поддержки сторонних кластеров и базовой линии Extend по умолчанию.

Продуктовая проверка для базовой линии Extend охватывает следующие области возможностей:

• Установка и использование Operators
• Установка и использование Cluster Plugins
• Логирование на основе ClickHouse
• Мониторинг на основе VictoriaMetrics

Это не означает, что продуктовая проверка охватывает все конкретные Operators или Cluster Plugins.

Для конкретных Operators или Cluster Plugins, выходящих за рамки этой базовой линии, обратитесь к соответствующей продуктовой документации или в техническую поддержку.

Дополнительные сведения см. в разделах Kubernetes Support Matrix и Import Standard Kubernetes Cluster.

#Расширенная конфигурация monitoring plugin

ACP 4.3 расширяет параметры конфигурации для monitoring plugins, упрощая адаптацию развертываний мониторинга к размещению на infra-узлах и различным схемам хранения.

Для ACP Monitoring с VictoriaMetrics администраторы теперь могут:

• Настраивать node selectors и tolerations на уровне плагина для размещения workload на выделенных infra-узлах
• Настраивать каталог хранения данных для VictoriaMetrics, когда Storage Type имеет значение LocalVolume
• Удалить прежнее ограничение в три узла для развертываний VictoriaMetrics

Для ACP Monitoring с Prometheus администраторы теперь могут настраивать node selectors и tolerations на уровне плагина, чтобы workload мониторинга можно было размещать на выделенных infra-узлах через конфигурацию плагина.

Руководство по эксплуатации см. в разделах Installation и Planning Infra Nodes for Monitoring.

#Решение по межкластерному аварийному восстановлению приложений StatefulSet

В этом выпуске представлены возможности межкластерного аварийного восстановления для stateful-приложений. Построенное на архитектуре Active-Passive с двумя центрами, решение сочетает асинхронную синхронизацию данных Alauda Build of VolSync и распространение конфигурации через GitOps, обеспечивая переключение с RTO на уровне минут.

Ключевые особенности:

• Основной кластер обрабатывает весь трафик read/write; резервный кластер поддерживает теплую реплику данных посредством периодических снимков rsync (RPO > 0).
• Поддерживаются три операционных сценария: плановая миграция, аварийное переключение и возврат на основной кластер.
• Резервный кластер по умолчанию работает с replicas=0; ресурсы хранения и вычислений остаются в cold standby и не обрабатывают бизнес-трафик.
• Подходит для workload, для которых не требуется строгое отсутствие потери данных (RPO = 0). Для финансовых или транзакционных core-приложений используйте вместо этого встроенную репликацию базы данных.

Подробнее см.: Cross-Cluster Application Disaster Recovery for Stateful Applications

#Alauda Container Platform Registry — улучшения управления образами

В этом выпуске представлены команды ac images и ac adm prune images, позволяющие управлять полным жизненным циклом образов Registry из командной строки.

• ac get images: выводит список образов в registry. Результаты ограничены пространствами имен, к которым у текущего пользователя есть права, с поддержкой фильтрации по namespace и нескольких форматов вывода (table, json, yaml, wide).
• ac delete images: удаляет один или несколько тегов образов по пути в registry. Встроенные проверки прав для namespace; по умолчанию выполняется в режиме dry-run для предварительного просмотра последствий, а для фактического удаления требуется --confirm.
• ac adm prune images: административная команда для очистки image manifests, на которые не ссылается ни один Pod кластера. Гибкие политики очистки включают срок хранения, количество сохраняемых объектов, allowlist и область --all. При необходимости запускает Registry GC после очистки. Также поддерживает плановую очистку через CronJob.

Подробнее см.: Cluster Image Registry Cleanup: Administrator Guide for Manual and Scheduled Tasks

#Плагин Alauda Container Platform Project Application Essential (Alpha)

В этом выпуске представлен плагин Alauda Container Platform Project Application Essential, построенный на совершенно новом frontend framework Next-Gen Console. Развернутый в кластере global, он обеспечивает межкластерную оркестрацию приложений и полное управление жизненным циклом с позиции проекта, полностью учитывая права пользователя.

Ключевые особенности:

• Межкластерная оркестрация: единое развертывание приложений в нескольких member clusters в рамках одного проекта.
• Полное управление жизненным циклом: поддерживаются create, update, scale, rollback, delete с синхронизацией состояния приложений между кластерами в реальном времени.
• Изоляция проекта: все операции ограничены границами проекта, что обеспечивает естественную изоляцию между проектами.
• Учет прав доступа: строго соблюдаются разрешения RBAC, отображаются только те ресурсы, к которым у пользователя есть доступ.

#Улучшения Underlay и Egress Gateway

ACP 4.3 расширяет базовые сетевые возможности CNI в части доступа underlay и операций egress gateway.

Ключевые улучшения включают:

• Более надежную схему высокой доступности и быстрого переключения для workload egress gateway, снижающую влияние на сервисы во время обслуживания узла или отказа.
• Рекомендации по защите ресурсов и поддержку платформы для Pod egress gateway, помогающие снизить риск конкуренции за ресурсы узла при всплесках трафика или увеличении числа реплик.
• Поддержку настройки taints для workload egress gateway, что позволяет лучше изолировать размещение на выделенных узлах.
• Поддержку управления VLAN-подинтерфейсами для underlay NIC.
• Добавленную поддержку редактирования YAML для ресурсов subnet.
• Добавленную поддержку настроек node selector для централизованных gateways.
• Добавленную поддержку CRD subnet для сценариев централизованного gateway.

Эти улучшения делают ACP более гибкой для сложных корпоративных сетевых сред и упрощают миграцию от ранних моделей экспонирования к решениям на основе underlay.

#Улучшения Gateway API

ACP 4.3 усиливает Gateway API как ключевую возможность балансировки нагрузки уровня Layer 7 на платформе.

Ключевые улучшения включают:

• Поддержку сценариев развертывания gateway на основе host-network.
• Поддержку экспонирования сервисов через metalLB + Envoy Gateway proxy + underlay, чтобы бизнес-трафик мог обходить management network.
• Поддержку пользовательских VIP-адресов для Gateway API, что помогает сохранять стабильными адреса экспонирования сервисов при пересборках или изменениях жизненного цикла.

#Аварийное восстановление stateful-приложений с защитой на основе PVC

ACP 4.3 представляет более мощные возможности аварийного восстановления для stateful-workload, включая аварийное восстановление на основе PVC и поддержку рабочих процессов резервного копирования и восстановления на основе VolSync для приложений, использующих хранилище, таких как MinIO.

Это улучшение повышает готовность к межкластерному восстановлению для stateful-приложений и предоставляет более практичный путь защиты для production-сред с большим объемом хранилища.

#Улучшения управления хранилищем Ceph

ACP 4.3 улучшает операции с хранилищем и поддержку workload на основе Ceph.

Ключевые улучшения включают:

• Добавлена поддержка размещения дисков в разных Ceph pool из UI.
• Улучшена эксплуатационная поддержка сценариев замены дисков Ceph.

Эти изменения улучшают day-2 операции с хранилищем и упрощают управление средами на базе Ceph в production.

#Улучшения платформы виртуализации

ACP 4.3 поставляет несколько важных улучшений, связанных с виртуализацией.

Ключевые улучшения включают:

• Улучшенные рабочие процессы создания и отображения VM.
• Добавлена поддержка Astra Linux в сценариях, связанных с виртуализацией.
• Добавлена поддержка возможностей multi-NIC и hot-plug NIC для виртуальных машин.

Эти улучшения повышают удобство использования виртуализации и расширяют совместимость гостевых workload в корпоративных средах.

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

#Вывод из эксплуатации Operation Statistics

Плагины metering и billing теперь доступны в GA и полностью покрывают возможности, ранее предоставлявшиеся функцией Operations Statistics. Поэтому верхнеуровневый пункт Operations Statistics в разделе Platform Management будет удален.

• Для новых развертываний платформы компоненты Operations Statistics больше не устанавливаются. Если вам нужны возможности metering или billing, используйте плагин Cost Management.
• Для обновленных платформ сбор данных metering через Operations Statistics прекращается после обновления, при этом исторические данные остаются доступными. Если вам требуется очистка или миграция данных, отправьте запрос в службу поддержки.

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

• Fixed an issue where the olm-registry pod would continuously restart, preventing the OperatorHub from functioning properly. This was caused by the `seccompProfile: RuntimeDefault` security configuration added during CIS compliance hardening, which blocked the `clone` syscall required by CGO operations. The seccomp profile has been adjusted to allow necessary syscalls while maintaining security compliance.Fixed in ACP 4.3.0.
• Fixed a performance issue where the permission validation during native application creation became extremely slow (10+ seconds) when the cluster had 60+ operators installed.Fixed in ACP 4.3.0.
• When using the etcd backup feature provided by Alauda Container Platform Cluster Enhancer, if users configure to back up etcd to S3 storage, the plugin fails to retrieve the Secret object referenced in secretRef. The root cause was that the plugin lacked the necessary RBAC permissions to read Secrets, resulting in S3 authentication information retrieval failure. This issue has been fixed in ACP 4.3.0.
• When using Alauda Container Platform Monitoring for VictoriaMetrics with multiple clusters sharing the same Storage, the alert rule cpaas-certificates-rule has two issues: alert notifications do not differentiate between clusters when triggered, and the rule monitors customer secrets instead of only platform certificates.
• Fix metis component storage limit configuration is too small and causes metis container to restart after exceeding the limit
• Fixed an issue where imagePullSecret was not automatically injected when workloads used custom ServiceAccounts, resulting in image pull failures.
• Fixed an issue where Pods could not pull images when image-registry imagePullSecret auto-rotation used “create new Secret + delete old Secret”, and legacy Pods still referenced the old Secret but started only after it had expired.
• Fixed an exception triggered under specific scenarios during namespace creation. When entering the namespace creation page, if the page request response is slow, the default selected cluster information may not be available upon initial page access, triggering errors in other page interfaces and causing the project quotas on the page to fail to display correctly.
• The text in the real-time logging component has been adjusted: Logging has ended => End of logs
• Fixed an issue where line breaks were inconsistent between Windows and Mac when editing configmaps.

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

• Users using the kubectl top node command to query node usage will be returned an error, this issue has been resolved in version 4.3.1
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• When using violet push to upload a chart package, the push operation may complete successfully, but the package does not appear in the public-charts repository.
  Workaround: Push the chart package again.
• 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.