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

#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
• Выполнение предварительных проверок перед запуском
• Запрос обновлений из Web Console или путем обновления ClusterVersionShadow.spec.desiredUpdate
• Просмотр условий, результатов предварительных проверок, этапов и истории из cvsh.status

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

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

#Обновление плагинов кластеров без зависимости от кластера

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

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

#Кластеры global на основе MicroOS в Huawei DCS

ACP 4.3 позволяет администраторам создавать кластер global в Huawei DCS с неизменяемой инфраструктурой на основе MicroOS. Это расширяет модель неизменяемой эксплуатации с 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.

#Новый пункт Preview Next-Gen Console в Web Console

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

Этот сценарий предназначен для постепенной миграции и работает с плагином Web Console Base в кластере global и плагином 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.

#Расширенная конфигурация плагинов мониторинга

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

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

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

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

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

#Решение для аварийного восстановления stateful applications между кластерами на основе StatefulSet

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

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

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

Подробнее см. здесь: 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: административная команда для удаления манифестов образов, на которые не ссылается ни один 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, он обеспечивает межкластерную оркестрацию applications и полное управление жизненным циклом с точки зрения проекта с полным учетом прав пользователя.

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

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

#Улучшения underlay и egress gateway

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти изменения повышают эффективность day-2 операций с хранилищем и упрощают эксплуатацию сред на основе Ceph в production.

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

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

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

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

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

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

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

Плагины metering и billing теперь находятся в общем доступе и полностью покрывают возможности, ранее предоставлявшиеся функцией 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 the issue where pushing container images with a large number of data layers (over 100) to the built-in image repository failed.
• 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.

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

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