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

#4.1.5

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

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

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

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

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

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

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

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

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

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

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

• Uploading multiple packages from a folder using violet upload previously failed when disk space became insufficient. Violet now proactively cleans up uploaded packages in time, preventing these errors.
• Uploading multiple packages from a folder using violet upload previously failed when disk space became insufficient. Violet now proactively cleans up uploaded packages in time, preventing these errors.
• 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.
• Previously, after uninstalling an Operator, the Operator status was incorrectly displayed as Absent, even though the Operator was actually Ready. Users had to manually re-upload the Operator using violet upload. This issue has now been resolved, and the Operator correctly appears as Ready after uninstallation.

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

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

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

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

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

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

#Machine Configuration

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

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

• CRD MachineConfig для записи конфигураций на хосты.
• CRD MachineConfigPool для группировки и управления конфигурациями узлов на основе ролей.
• При установке кластера автоматически создаются два стандартных MachineConfigPool — для control plane и для worker узлов. Пользователи также могут создавать кастомные 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), значительно повышающее устойчивость и доступность приложений.

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

• Разнообразные модели DR: Гибкая поддержка Active-Active (AA-DR) для глобальных задач с высокой конкуренцией; Active-Standby Dual-Active (AS-DR) для оптимизации использования ресурсов; Active-Passive (AP-DR) для строгого обеспечения согласованности данных.

• Автоматическая синхронизация GitOps: Использование GitOps в сочетании с ApplicationSet и Kustomize для автоматической синхронизации конфигураций между кластерами, обеспечивая готовность DR-среды.

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

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

• Упрощённый процесс переключения: Чётко определены шаги обнаружения сбоев, перенаправления трафика, повышения статуса и восстановления сервиса для эффективного и упорядоченного переключения при аварии.

Примечание:

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

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

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

• 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 Driver теперь поддерживает анонимный доступ, позволяя быстро организовать внешний 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 Applications обновлены до "Helm Chart Application" перед обновлением.