- Notes de publication d'Automation Suite sur Linux
- Notes de publication d'Automation Suite sur EKS/AKS
- Notes de publication d'Automation Suite sur OpenShift
2.2510.2
Notes de version 2.2510.2 pour Automation Suite sous Linux.
Date de publication : 15 avril 2026
exigence cgroup v2 pour la mise à niveau
Automation Suite nécessite désormais des nœuds hôtes pour exécuter cgroup v2. Si votre environnement utilise cgroup v1 (par défaut sur RHEL 8.x), vous devez migrer vers cgroup v2 avant la mise à niveau. Le runtime RKE2 1.35 utilisé par Automation Suite rend obsolète cgroup v1, et Kubelet ne démarrera pas si cgroup v1 est détecté.
Bien que le paramètre failCgroupV1 kubelet puisse contourner temporairement ce contrôle, il peut être obsolète dans les futures versions de Rancher. Il est fortement recommandé de migrer vers cgroup v2 avant d’effectuer la mise à niveau.
Pour plus de détails, consultez Matrice de compatibilité RHEL et Comment migrer vers Cgroup v2.
Validation de la chaîne de certificats TLS
Automation Suite nécessite désormais une chaîne de certificats TLS complète : un certificat de feuille, tous les certificats intermédiaires et l'autorité de certification racine. Auparavant, vous pouviez fournir une chaîne partielle (certificat de feuille et autorité de certification racine uniquement). Vous devez mettre à jour votre bundle d’autorité de certification pour y inclure tous les certificats intermédiaires. Si vous ne le faites pas, la validation TLS échouera.
Pour de plus amples informations, consultez la section Exigences du certificat.
Nouveau champ obligatoire pour les déploiements Disaster Recovery
Nous avons ajouté un nouveau champ type obligatoire dans la section multisite de cluster_config.json. Ce champ est requis lors de la configuration des déploiements de Disaster Recovery et spécifie le type de déploiement. Vous devez le définir sur active-active ou sur active-passive. Ce champ est requis pour les configurations de cluster principal et secondaire.
Pour de plus amples informations, consultez la section Disaster Recovery : configurations actif/passif et actif/actif.
Processus d’hydratation du registre amélioré
Nous avons amélioré le processus d’hydratation du registre afin de récupérer les informations d’identification plus fiables. Les informations d’identification du registre sont désormais récupérées d’abord à partir du fichier cluster_config.json , avec une solution de secours pour les clés secrètes Kubernetes si les informations d’identification ne s’y trouvent pas. Auparavant, le processus s'appuyait uniquement sur la clé secrète du registre Docker dans le cluster Kubernetes, ce qui pouvait échouer si l'espace de noms uipath n'était pas présent ou si la clé secrète attendue n'était pas disponible.
Génération améliorée de packs d'assistance pour RKE2
L’outil de pack d’assistance peut désormais collecter le bundle RKE2 même lorsque RKE2 est en panne. Auparavant, la génération du pack d'assistance échouait si RKE2 n'était pas disponible. Pour de plus amples informations, consultez la section Utiliser le package d'assistance Automation Suite.
Amélioration des messages de vérification des prérequis pour la validation de l’API Magasin d’objets
Les vérifications des prérequis de l’API du magasin d’objets fournissent désormais des messages d’erreur plus clairs, ce qui facilite le diagnostic et la résolution des problèmes de configuration avant l’installation.
Prise en charge des nouvelles versions de RHEL
Nous avons étendu notre prise en charge des systèmes d’exploitation pour inclure les versions RHEL 9.7 et 10.0. Pour plus de détails sur les versions RHEL prises en charge, consultez la section Matrice de compatibilité RHEL.
Prise en charge d'Integration Service pour FIPS 140-2
Integration Service est désormais pris en charge sur les déploiements Automation Suite qui s'exécutent sur des machines compatibles FIPS 140-2. Pour de plus amples informations, consultez la section Sécurité et conformité.
Nouvelle configuration d’Integration Service pour les déploiements cloud souveraineté
Un nouveau champ facultatif queue_config.fqdn_suffix est désormais disponible sous integrationservices dans cluster_config.json. Ce champ est destiné aux déploiements souveraineté ou cloud nationaux où les points de terminaison de file d'attente utilisent un suffixe de nom de domaine complet non standard, tel que AWS China (amazonaws.com.cn), China Azure (core.chinacloudapi.cn), ou Azure US Government (core.usgovcloudapi.net). Si le champ est laissé vide ou omis, les suffixes par défaut seront appliqués.
Pour plus de détails, consultez la section Configuration du suffixe du nom de domaine complet de la file d’attente pour les déploiements cloud souveraineté.
Nouvelles alertes OOM pour la surveillance de la mémoire du conteneur
Automation Suite inclut désormais deux nouvelles alertes Prometheus personnalisées dans le groupe de règles monitoring-oom-alerts pour vous aider à détecter les problèmes de mémoire de conteneur et à y répondre :
KubeContainerOOMKilled: se déclenche immédiatement lorsqu'un conteneur est arrêté en raison du dépassement de sa limite de mémoire (OOM).ContainerMemoryUsageHigh: se déclenche lorsqu'un conteneur utilise plus de 90 % de sa limite de mémoire pendant plus de 15 minutes, servant d'avertissement préalable indiquant que le conteneur peut être arrêté en raison d'une mémoire insuffisante.
Pour de plus amples informations, consultez la section Alertes de ressources Kubernetes.
Extension de la prise en charge des produits pour les déploiements actif/passif et actif/actif
Les solutions prennent désormais en charge les déploiements actif/passif et actif/actif. Pour de plus amples informations, consultez la section Disaster Recovery – actif/passif et actif/actif.
Admin
Rôle de gestion des utilisateurs
Les administrateurs de l'organisation peuvent désormais déléguer des tâches de gestion de l'identité à des utilisateurs non administrateurs via un nouveau rôle personnalisé au niveau de l'Organization. Lorsqu'il est affecté, ce rôle permet aux utilisateurs de gérer les comptes d'utilisateur, les comptes de robot et les groupes locaux au niveau de l'organisation sans accorder les droits d'administrateur complets de l'organisation.
Le rôle prend en charge les autorisations CRUD granulaires par type de ressource et inclut des protections d'élévation de droits intégrées: les utilisateurs dotés de ce rôle ne peuvent pas modifier le groupe d'administrateurs ou interagir avec les comptes d'administrateur existants de l'organisation.
Pour plus de détails, voir Rôle de gestion des utilisateurs.
Résolution de bogues
- Erratum - ajouté le 23 juillet 2026: nous avons corrigé un problème qui empêchait le nettoyage des ensembles Daemon du pack d’assistance sur les nœuds du cluster après la fin d’une demande de collecte de bundles d’assistance. Auparavant, il vous fallait supprimer manuellement les ensembles Daemon sur chaque nœud avant de déclencher une nouvelle demande de pack d'assistance.
- Nous avons résolu un problème qui empêchait les mises à jour du nom de domaine complet de s’effectuer correctement dans les environnements IPv6 et double pile. Le problème affectait à la fois le niveau de l’infrastructure et le niveau du service.
- Nous avons corrigé un problème qui empêchait certains pods AI Center et Document Understanding de démarrer lorsque la vérification du certificat TLS de la base de données était activée.
- Nous avons résolu un problème qui entraînait l’échec de la synchronisation du gestionnaire d’alertes dans ArgoCD en raison d’un caractère non valide dans la balise d’image du gestionnaire d’alertes.
- Nous avons résolu un problème où Orchestrator et les services de plate-forme sur le cluster secondaire dans un déploiement actif/actif ne transmettaient pas les données de surveillance en temps réel d’Insights en raison de problèmes de configuration avec la redirection d’appel du cluster secondaire vers le cluster principal.
- Nous avons corrigé un problème qui empêchait l’utilisation de noms de bases de données personnalisés pour les Solutions. Auparavant, lorsque vous indiquiez un nom de base de données personnalisé, les vérifications des prérequis échouaient.
- Nous avons résolu un problème où la vérification des prérequis validait de manière incorrecte les composants de surveillance et de journalisation. Étant donné que ces composants sont installés après la phase prérequise, nous avons supprimé cette validation, car elle n’était pas nécessaire.
- Cette version inclut les correctifs livrés dans Automation Suite 2.2510+patch2.
Problèmes connus
Conflit de mise à l'échelle horizontale du pod Autoscaler et d'ArgoCD dans les environnements haute disponibilité
Erratum - ajouté le 10 septembre 2026: dans les environnements haute disponibilité, lorsque la charge augmente, l'outil de mise à l'échelle horizontale des pods Mise à l'échelle des charges de travail affectées met à l'échelle les charges de travail affectées tandis que le contrôleur d'application ArgoCD les réduit. Cela se produit parce qu'ArgoCD traite le nombre de répliques défini dans le graphique ou le manifeste Helm comme source de vérité, ce qui entraîne l'augmentation et la réduction des charges de travail sans cesse sans stabiliser.
Pour résoudre le problème, vous devez corriger argocd-cm ConfigMap dans l'espace de noms <argocd> afin qu'ArgoCD ignore les différences de nombre de répliques:
kubectl -n <argocd> patch configmap argocd-cm --type merge -p \
'{"data":{"resource.customizations.ignoreDifferences.argoproj.io_Rollout":"jsonPointers:\n- /spec/replicas\n"}}'
kubectl -n <argocd> patch configmap argocd-cm --type merge -p \
'{"data":{"resource.customizations.ignoreDifferences.argoproj.io_Rollout":"jsonPointers:\n- /spec/replicas\n"}}'
Réappliquez la commande après chaque resynchronisation du graphique ArgoCD ou mise à niveau d'Automation Suite, car les deux écrasent ConfigMap et suppriment le correctif.
Nous avons résolu le problème dans Automation Suite 2.2510.4.
Pods bloqués à l'état Init en raison de l'échec du montage du volume XFS sur les nœuds RHEL 8.x
Erratum - ajouté le 10 septembre 2026: sur les nœuds RHEL 8.x, TopoLVM formate de nouveaux volumes persistants avec des fonctionnalités XFS sur disque (bigtime, inobtcount, nrext64) que le noyau RHEL 8.x et xfsprogs ne prennent pas en charge. Les pods qui demandent un nouveau PVC, tels que les pods de pipeline d'entraînement AI Center, restent bloqués à l'état Init avec une erreur mount failed: wrong fs type, bad option, bad superblock.
Pour résoudre le problème, consultez la section Résolution des problèmes.
La découverte de Kerberos KDC échoue dans les déploiements actif/actif en raison de réponses DNS SRP tronquées
Erratum - ajouté le 10 septembre 2026: dans les déploiements actif/actif d'Automation Suite sur Linux, la découverte KDC Kerberos peut échouer lors de l'installation ou de la mise à niveau, ce qui entraîne des erreurs d'authentification intégrée et de LDAP. Le problème se produit car le service DNS Kubernetes expose uniquement la résolution DNS sur UDP/53. Lorsqu'une recherche Kerberos SRP, telle que _kerberos._tcp ou _kerberos._udp, renvoie une réponse trop volumineuse pour UDP, le client DNS réessaie via TCP/53. Étant donné que le service DNS Kubernetes n’expose pas le protocole TCP/53, la nouvelle tentative échoue.
Pour résoudre le problème, activez TCP/53 sur le service DNS Kubernetes:
-
Modifiez la
rke2-corednsconfiguration du graphique Helm:kubectl -n kube-system edit helmchartconfig rke2-corednskubectl -n kube-system edit helmchartconfig rke2-coredns -
Sous
zonedansspec.valuesContent, ajoutezuse_tcp: true:servers: - zones: - zone: . use_tcp: true port: 53servers: - zones: - zone: . use_tcp: true port: 53
Nous avons résolu le problème dans Automation Suite 2.2510.4.
Studio Desktop ne peut pas charger les connecteurs et activités Integration Service
Erratum - ajouté le 23 juillet 2026: dans Studio Desktop, le panneau Activités ne répertorie pas les connecteurs et activités Integration Service. Le problème est causé par une erreur de configuration du routage dans le service virtuel intsvcs-periodic.
Pour résoudre le problème, consultez la section Studio Desktop ne peut pas charger les connecteurs et activités Integration Service.
Nous avons résolu le problème dans Automation Suite 2.2510.3.
Le redimensionnement d’une partition de disque de données nécessite le chemin d’accès au disque, même lors des exécutions suivantes
Erratum - ajouté le 23 juillet 2026: un problème empêche uipathctl de redimensionner une partition de disque de données existante (telle que les partitions du registre Docker, de la surveillance ou d'Insights) à moins que le chemin d'accès au disque sous-jacent ne soit explicitement fourni à l'aide de l'indicateur --volume . Ce comportement est incorrect, car uipathctl est conçu pour détecter automatiquement le disque associé lors des exécutions suivantes sans nécessiter --volume.
Ce problème est résolu dans Automation Suite 2.2510.3.
Les mises à jour de la configuration de la surveillance ne prennent pas effet
Erratum - ajouté le 23 juillet 2026: un problème empêche les paramètres de section monitoring dans cluster_config.json d’être appliqués à la pile de surveillance.
Ce problème est résolu dans Automation Suite 2.2510.3.
Les vérifications des prérequis échouent lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé
Erratum - ajouté le 23 juillet 2026: un problème entraîne l’échec incorrect de la commande de vérification des prérequis lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé.
Pour résoudre le problème, consultez la section Résolution des problèmes.
Ce problème est résolu dans Automation Suite 2.2510.3.
Les noms de graphique Velero incorrects entraînent l’échec de la mise à niveau
Erratum - ajouté le 23 juillet 2026: un problème entraîne l’échec de la mise à niveau en raison de l’échange des noms de velero et velero-upstream dans helm-charts.json/versions.json.
Avant la mise à niveau, les noms de graphique dans helm-charts.json/versions.json doivent correspondre aux éléments suivants:
{
"name": "velero-upstream",
"ref": "vendor/velero",
"version": "v10.1.3"
},
{
"name": "velero",
"ref": "helm/velero",
"version": "2.2510.2"
}
{
"name": "velero-upstream",
"ref": "vendor/velero",
"version": "v10.1.3"
},
{
"name": "velero",
"ref": "helm/velero",
"version": "2.2510.2"
}
La migration du schéma MessageBus échoue sur les bases de données alimentées à partir d’Automation Suite 2022.10.x ou d’une version antérieure
Erratum - ajouté le 23 juillet 2026: lors de la mise à niveau vers Automation Suite 2.2510.2, la migration du schéma MessageBus échoue si la base de données a été créée à l’origine sur Automation Suite 2022.10.x ou une version antérieure, quel que soit le nombre de versions par lesquelles elle a été mise à niveau depuis. Les bases de données créées à l'origine sur Automation Suite 2023.x ou une version ultérieure ne sont pas affectées.
Pour vérifier si votre base de données est affectée, exécutez la requête suivante:
SELECT * FROM [msgbus].[__EFMigrationsHistory] WHERE MigrationId NOT LIKE '2[0-9][0-9][0-9]%'
SELECT * FROM [msgbus].[__EFMigrationsHistory] WHERE MigrationId NOT LIKE '2[0-9][0-9][0-9]%'
Si la requête renvoie des lignes, supprimez-les avant la mise à niveau:
DELETE FROM [msgbus].[__EFMigrationsHistory] WHERE MigrationId NOT LIKE '2[0-9][0-9][0-9]%'
DELETE FROM [msgbus].[__EFMigrationsHistory] WHERE MigrationId NOT LIKE '2[0-9][0-9][0-9]%'
Fluentd n’exporte pas les journaux dans les environnements IPv6
Dans les environnements IPv6, Fluentbit ne parvient pas à transférer les journaux vers Fluentd car le plug-in d'entrée de transfert Fluentd se connecte par défaut à une adresse IPv4.
Pour résoudre ce problème, vous devez corriger l'application ArgoCD et définir logging-operator.logging.fluentd.forwardInputConfig.bind sur ::. Pour de plus amples informations, consultez la section Résolution des problèmes .
Limitations de l'authentification Kerberos
L’authentification basée sur Kerberos n’est actuellement pas prise en charge pour Integration Service.
Nous travaillons à l’ajout de la prise en charge de Kerberos aux prochaines versions d’Automation Suite.
Pendant ce temps, vous pouvez utiliser d’autres mécanismes d’authentification tels que l’authentification de base ou l’authentification basée sur l’identité de la charge de travail.
Limitations de la prise en charge de FIPS 140-2
Insights ne prend actuellement pas en charge le FIPS. Pour rester conforme aux exigences FIPS 140-2, vous devez désactiver Insights. Si vous avez besoin d'utiliser Insights, vous pouvez le déployer sur un nœud non FIPS dédié.
Pour de plus amples informations, reportez-vous aux sections Sécurité et conformité et Comment déployer Insights dans un cluster compatible FIPS.
Chronologie de l’abandon
Nous vous recommandons de vérifier régulièrement le calendrier d'obsolescence pour toute mise à jour concernant les fonctionnalités qui seront obsolètes et supprimées.
Détails du regroupement
Versions du produit
Le tableau suivant décrit le statut de la version, la version et les notes de publication de tous les produits UiPath déployés sous Automation Suite 2.2510.2.
Légende :
✅ Nouveau : cette version d’Automation Suite comprend une nouvelle version de produit. De nouvelles notes de publication sont disponibles.
◆ Offre groupée : cette version inclut une version du produit précédemment publiée. Aucune nouvelle note de version n'est disponible.
Versions internes des composants tiers
Cette version d'Automation Suite regroupe les composants internes suivants :
| Composant (Component) | Version |
|---|---|
| RKE2 | 1.35.0+rke2r1 |
| ArgoCD | V3.2.6 |
| Gatekeeper | V3.21.0 |
| Ligne | 1.18.7 |
| Ceph | 19.2.3 |
| prometheus-pushgateway | v3.6.0 |
| gestionnaire-certificats | v1.19.3 |
| kube-journalisation/opérateur-journalisation | 6.4.0 |
| kube-loging/config-reloader | 6.4.0 |
| Istio | 1.28.3 |
| velero | 1.16.2 |
| rechargeur | v2.2.7 |
| Prometheus | V3.9.1 |
| Grafana | 12.3.1 |
| opérateur redis | 8.0.10-23 |
| redis-cluster | V8.0.10-81 |
| oauth2-proxy | V7.13.0 |
- exigence cgroup v2 pour la mise à niveau
- Validation de la chaîne de certificats TLS
- Nouveau champ obligatoire pour les déploiements Disaster Recovery
- Processus d’hydratation du registre amélioré
- Génération améliorée de packs d'assistance pour RKE2
- Amélioration des messages de vérification des prérequis pour la validation de l’API Magasin d’objets
- Prise en charge des nouvelles versions de RHEL
- Prise en charge d'Integration Service pour FIPS 140-2
- Nouvelle configuration d’Integration Service pour les déploiements cloud souveraineté
- Nouvelles alertes OOM pour la surveillance de la mémoire du conteneur
- Extension de la prise en charge des produits pour les déploiements actif/passif et actif/actif
- Admin
- Rôle de gestion des utilisateurs
- Résolution de bogues
- Problèmes connus
- Conflit de mise à l'échelle horizontale du pod Autoscaler et d'ArgoCD dans les environnements haute disponibilité
- Pods bloqués à l'état Init en raison de l'échec du montage du volume XFS sur les nœuds RHEL 8.x
- La découverte de Kerberos KDC échoue dans les déploiements actif/actif en raison de réponses DNS SRP tronquées
- Studio Desktop ne peut pas charger les connecteurs et activités Integration Service
- Le redimensionnement d’une partition de disque de données nécessite le chemin d’accès au disque, même lors des exécutions suivantes
- Les mises à jour de la configuration de la surveillance ne prennent pas effet
- Les vérifications des prérequis échouent lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé
- Les noms de graphique Velero incorrects entraînent l’échec de la mise à niveau
- La migration du schéma MessageBus échoue sur les bases de données alimentées à partir d’Automation Suite 2022.10.x ou d’une version antérieure
- Fluentd n’exporte pas les journaux dans les environnements IPv6
- Limitations de l'authentification Kerberos
- Limitations de la prise en charge de FIPS 140-2
- Chronologie de l’abandon
- Détails du regroupement
- Versions du produit
- Versions internes des composants tiers