Red Hat OpenShift sur AWS (ROSA) est une plateforme applicative clé-en-main qui permet de créer et de déployer des applications plus rapidement et à l’échelle d’AWS – permettant aux utilisateurs de se concentrer sur l’innovation plutôt que sur la gestion de l’infrastructure. Red Hat annonce la dernière évolution de ROSA, grâce à la mise à disposition générale de plans de contrôle hébergés (HCP) dans le cadre de ce service.

En se fondant sur le projet HyperShift, la solution ROSA avec HCP offre des plans de contrôle dotés d’un degré de disponibilité élevé et isolés au sein d’un compte de service ROSA sur AWS. En enlevant au client la responsabilité du plan de contrôle, les utilisateurs bénéficient d’une efficacité opérationnelle supplémentaire, en plus des fonctionnalités ROSA dont ils jouissent d’ores et déjà, et ils sont donc en mesure de faire des économies substantielles, soulgne Red Hat.

ROSA avec HCP permet aux entreprises et aux développeurs de :

• Déployer des applications sur une seule zone de disponibilité (AZ), sur deux AZ ou sur toutes les AZ dans une région sans avoir à s’inquiéter du degré de disponibilité du plan de contrôle, qui est toujours distribué sur de multiples zones de disponibilité.
• Provisionner rapidement un plan de contrôle dédié et isolé pour chaque cluster, qui peut soit être rendu disponible publiquement, soit être rendu accessible de manière privée via un endpoint PrivateLink AWS dédié au sein du VPC AWS.

Les administrateurs de clusters et de cloud bénéficient eux aussi des avantages de l’architecture ROSA avec HCP :

• Plusieurs ressources sont déplacées hors de portée des limites du cluster et reposent désormais sur une source unique de vérité provisionnée via le CLI rosa ou OpenShift Cluster Manager (OCM).
• Tous les APIs machine sont gérés de manière externalisée via le CLI rosa ou OCM comme des objets MachinePool.
• Les ressources API nœud sont toujours disponible au sein des clusters, y compris la capacité d’étiqueter et de teinter les nœuds existants.
• Les composants OAuth ne sont plus exposés de manière interne au sein du cluster.
• Les limites de sécurité sont renforcées grâce au découplage des plans de contrôle et des workloads.
• Un ensemble limité de politiques AWS concernant les autorisations qui s’appuie sur des politiques managées AWS approuvées et publiées destinées à réduire la complexité des prérequis et à améliorer la sécurité par défaut en facilitant le contrôle des autorisations basé sur des balises (tags).
• La séparation entre les mises à niveau du plan de contrôle et du nœud autogéré, qui permet une cadence de mise à jour du plan de contrôle cohérente et axée sur la sécurité sans influencer les nœuds autogérés, afin d’offrir aux développeurs d’applications davantage de temps et un degré de flexibilité supérieur lorsqu’il s’agit de déterminer le moment où les nœuds seront mis à niveau.

Grâce à la séparation du plan de contrôle et du nœud autogéré, un endpoint AWS PrivateLink fournit une communication dans un seul sens qui part du compte AWS vers un répartiteur de charge réseau interne. Le kubelet de chaque nœud autogéré établit une communication directe avec l’API Server de Kubernetes piloté par le répartiteur de charge. 

Toutes les opérations de gestion et de maintenance effectuées sur le cluster ROSA interviennent au sein du compte de service ROSA, sans avoir besoin d’accéder à l’infrastructure AWS. La politique de support managé pour AWS de Red Hat prévoit des autorisations d’accès nécessaires à l’infrastructure AWS basées sur les balises pour les scénarios de dépannage d’urgence.

Le trafic lié aux applications au sein du réseau reste sur le compte AWS, précédé d’un équilibreur de charges distinct. ROSA avec plans de contrôle hébergés est paramétré par défaut pour précéder le routeur d’application d’un équilibreur de charge réseau, mais il est toujours possible d’avoir recours à un répartiteur de charge traditionnel.