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

#4.1.2

#Исправленные ошибки

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

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

• 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

#Исправленные ошибки

• Fixed an issue where running `violet push` before upgrading caused functional components to become abnormal, blocking the upgrade. The command has been enhanced to separate image push and CR creation, allowing users to push only images without creating CRs.

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

• 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

#Новые возможности и улучшения

#Immutable Infrastructure

Выпущено:

• 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 устанавливает и настраивает контрольную плоскость Kubernetes и узлы на ВМ, предоставленных инфраструктурным провайдером.

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

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

#Machine Configuration

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

Machine Configuration управляет обновлениями файлов, системными юнитами systemd и публичными SSH-ключами на узлах кластера, предоставляя:

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

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

Подробности о функционале см. в разделе Machine Configuration.

#etcd Encryption

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

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

Подробности см. в разделе etcd Encryption.

#Kubernetes Certificates Rotator

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

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

Подробности см. в разделе Automated Kubernetes Certificate Rotation.

#Cluster Enhancement

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

Новые возможности и изменения:

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

#Китайский языковой пакет

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

#Создание On-Premise кластера

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

#Логирование

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

#Мониторинг

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

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

• Квоты проектов теперь поддерживают пользовательские квоты ресурсов и квоты по классам хранения.
• Плагин предоставляет новые метрики: 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. При развертывании Pod в таком Namespace автоматически устанавливаются RunAsUser и fsGroup для всех контейнеров Pod на основе предопределённых политик безопасности Namespace. Пользователи и группы динамически выделяются из разрешённого диапазона UID/GID для данного Namespace.

Основные возможности и преимущества:

• Повышенная безопасность: Принудительный запуск контейнеров от имени непривилегированных пользователей с ограничением диапазонов UID/GID эффективно снижает риски побега из контейнера и повышения привилегий, соблюдая принцип наименьших привилегий.

• Упрощённое управление: Разработчикам не нужно вручную указывать UID/GID в каждой конфигурации контейнера или Pod. После настройки Namespace все Pod автоматически наследуют и применяют правильные настройки безопасности.

• Обеспечение соответствия: Помогает заказчикам лучше соответствовать внутренним политикам безопасности и внешним требованиям комплаенса, гарантируя запуск контейнеризованных приложений в регулируемой среде.

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

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

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

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

Основные возможности и преимущества:

• Blue-Green Deployment: Обеспечивает обновления без простоев, развертывая новые версии параллельно с текущей продуктивной средой. После тщательного тестирования трафик можно мгновенно или плавно переключить с старой версии на новую.

• Canary Deployment: Постепенно вводит новые версии, направляя небольшой процент (например, 5%) производственного трафика на них, позволяя наблюдать за производительностью и стабильностью. На основе предопределённых метрик (например, ошибок или задержек) система может автоматически увеличить трафик или откатить изменения при обнаружении проблем, ограничивая влияние возможных сбоев.

• Платформенно-сертифицированный Argo Rollout Chart: Вы можете скачать open-source Argo Rollouts из сообщества или выбрать сертифицированную платформой версию через Alauda Cloud.

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

Для обеспечения более безопасного и удобного управления образами мы углубили интеграцию нашего лёгкого реестра образов с существующей системой прав пользователей платформы.

Основные возможности и преимущества:

• Глубокая интеграция с системой пользователей платформы: Реестр образов тесно интегрирован с аутентификацией пользователей и механизмами RBAC платформы. Разработчики, тестировщики и администраторы могут использовать свои существующие учётные данные платформы без дополнительной настройки или отдельного управления аккаунтами. Платформа автоматически сопоставляет права пользователей в Namespace с соответствующими правами доступа к образам в реестре. Например, пользователи могут только загружать и скачивать образы в «конкретных Namespaces», к которым у них есть доступ.

• Удобство работы через CLI: Поддерживаются операции pull и push образов через CLI-инструменты, значительно повышая эффективность и удобство работы.

Внимание:

• Поддерживается только установка Alauda Container Platform Registry через решение.

#Решение автоскейлинга на базе KEDA

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

Основные возможности и преимущества:

• Масштабирование на основе событий: KEDA поддерживает более 70 типов скейлеров для автоматического масштабирования приложений (например, Deployments, Jobs и др.). Помимо традиционного использования CPU и памяти, может мониторить метрики, такие как длина очереди сообщений (Kafka, RabbitMQ), количество подключений к базе данных, скорость HTTP-запросов и пользовательские метрики.

• Платформенно-сертифицированный оператор KEDA: Скачивайте и устанавливайте сертифицированную платформой версию через Alauda Cloud.

Решения:

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

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

Наша платформа теперь предлагает новое решение для аварийного восстановления приложений между кластерами на базе GitOps, значительно повышающее устойчивость и доступность приложений.

Основные возможности и преимущества:

• Разнообразные модели 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 зависимости также синхронизированы с последними версиями сообщества, исправлены многочисленные известные проблемы и уязвимости, что обеспечивает улучшенную стабильность и надёжность системы.

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

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

• Миграция с высокой доступностью: Автоматический перенос виртуальных машин на здоровые узлы при сбоях узлов, обеспечивая непрерывность бизнеса.

• Клонирование виртуальных машин: Быстрое создание новых виртуальных машин на основе существующих, значительно повышая эффективность развертывания.

• Шаблоны виртуальных машин: Поддержка преобразования существующих виртуальных машин в шаблоны для быстрого массового развертывания аналогично настроенных сред.

• Доверенные вычисления (vTPM): Виртуальные машины теперь поддерживают функции доверенных вычислений, повышая общую безопасность.

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

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

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

• Мультикластерный доступ: Поддержка одновременного доступа к нескольким различным кластерам Ceph или MinIO, обеспечивая более эффективное централизованное управление.

• Тонкое управление квотами: Гибкая настройка квот для разных категорий хранения, оптимизируя использование ресурсов.

• Расширенное управление правами доступа: Поддержка создания различных прав доступа пользователей, включая режимы чтения-записи, только чтения и только записи.

• Поддержка анонимного доступа: Драйвер Ceph COSI теперь поддерживает анонимный доступ, позволяя быстро организовать внешний HTTP-доступ через конфигурацию Ingress.

#ALB переходит в режим поддержки

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

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

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

• Выделение экземпляров gateway на основе портов

• Перенаправление трафика по IP и диапазонам IP

• Алгоритм балансировки нагрузки EWMA

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

• Просмотры мониторинга на уровне правил

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

Внедрён самый популярный в сообществе контроллер Ingress для замены существующих сценариев Ingress на базе ALB.

Основные возможности и преимущества:

• Совместимость с основными практиками сообщества для избежания недопонимания

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

• Исправления проблем безопасности

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

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

• Активной-активной высокой доступностью через ECMP для горизонтального масштабирования пропускной способности

• Переключением менее чем за 1 секунду через BFD

• Повторным использованием underlay режима, IP Egress Gateway отделены от узлов

• Тонким управлением маршрутизацией через селекторы Namespace и Pod

• Гибким планированием Egress Gateway через селекторы узлов

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

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

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

• Стандартный API сообщества (заменяет внутренние API)

• Нет конфликтов с NetworkPolicy (приоритет выше NetworkPolicy)

• Поддержка настройки приоритетов

Подробнее: Red Hat Blog on AdminNetworkPolicy

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

#Удаление Docker Runtime

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

#Удаление Template Application

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