Déploiement de Red Hat OpenShift Service on AWS

De nombreuses entreprises choisissent Red Hat OpenShift comme plateforme commune pour développer et exécuter toutes leurs applications. Ce faisant, elles évitent les environnements hétérogènes qui peuvent créer beaucoup de complexité. Non seulement elles peuvent créer et exécuter de nouvelles applications cloud-native sur Red Hat OpenShift, mais elles peuvent aussi y migrer leurs applications existantes.

L'un des principaux avantages de l'utilisation d'OpenShift est que les développeurs n'ont qu'à apprendre à maîtriser une interface, sans avoir à se soucier des détails sous-jacents de la plateforme. La productivité peut ainsi augmenter de manière significative.

Red Hat OpenShift Service on AWS (ROSA)

Certains clients qui décident d'adopter OpenShift souhaitent aller encore plus loin dans la simplification de leur environnement. Ils préfèrent ne pas se soucier de fournir l'infrastructure pour leurs clusters et de gérer ces derniers. Ils souhaitent que leurs équipes soient productives dès le premier jour et se concentrent uniquement sur le développement d'applications. Ils peuvent alors se tourner vers Red Hat OpenShift Service on AWS (ROSA).

ROSA est entièrement hébergé dans le cloud public Amazon Web Services (AWS). Sa maintenance est assurée conjointement par Red Hat et AWS. Ainsi, le plan de contrôle et les nœuds de calcul sont entièrement gérés par une équipe Red Hat d'ingénieurs de la fiabilité des sites (SRE), avec une assistance conjointe de Red Hat et Amazon. Cela couvre l'installation, la gestion, la maintenance et les mises à niveau sur tous les nœuds.

Options de déploiement de ROSA

Il existe deux façons principales de déployer ROSA : dans un cluster public et dans un cluster PrivateLink. Dans les deux cas, nous recommandons de le déployer dans plusieurs zones de disponibilité pour assurer la résilience et la haute disponibilité. 

Les clusters publics sont principalement utilisés pour les charges de travail sans exigences de sécurité strictes. Le cluster sera déployé dans un cloud privé virtuel (VPC) à l'intérieur d'un sous-réseau privé (qui contiendra les nœuds de plan de contrôle, les nœuds d'infrastructure et les nœuds de calcul où les applications s'exécutent). Il sera cependant toujours accessible depuis Internet. En plus du VPC, vous aurez donc besoin d'un sous-réseau public. 

Les équilibreurs de charge AWS (Elastic et Network Load Balancer) déployés sur ce sous-réseau public permettent à l'équipe SRE et aux utilisateurs qui accèdent aux applications (c'est-à-dire au trafic entrant dans le cluster) de se connecter. Dans le cas des utilisateurs, un équilibreur de charge redirigera leur trafic vers le service de routage exécuté sur les nœuds d'infrastructure, puis le transférera vers l'application souhaitée exécutée sur l'un des nœuds de calcul. L'équipe SRE utilisera un compte AWS dédié pour se connecter aux nœuds de contrôle et d'infrastructure via différents équilibreurs de charge. 

Figure 1. Cluster public ROSA

Pour les charges de travail de production soumises à des exigences de sécurité plus strictes, nous vous recommandons de déployer un cluster PrivateLink. Dans ce cas, le VPC dans lequel réside le cluster possède uniquement un sous-réseau privé, ce qui signifie qu'il n'est pas accessible à partir de l'Internet public. 

L’équipe SRE utilise un compte AWS dédié qui se connecte à un équilibreur de charge AWS via un point de terminaison AWS PrivateLink. L’équilibreur de charge redirige le trafic vers les nœuds de contrôle ou d’infrastructure selon les besoins. (Une fois que le cluster AWS PrivateLink est créé, le client doit approuver l'accès à partir du compte AWS de l'équipe SRE.) Les utilisateurs se connectent à un équilibreur de charge AWS qui les redirige vers le service de routage sur les nœuds d'infrastructure. De là, ils sont envoyés au nœud de calcul où est exécutée l'application à laquelle ils veulent accéder.

Dans les mises en œuvre de clusters PrivateLink, les clients souhaitent généralement rediriger le trafic sortant du cluster vers leur infrastructure sur site ou vers d’autres VPC dans le cloud AWS. Pour ce faire, ils peuvent utiliser AWS Transit Gateway ou AWS Direct Connect, de sorte qu'il n'y ait pas besoin de déployer un sous-réseau public dans le VPC où réside le cluster. Même s'ils doivent rediriger le trafic sortant vers Internet, ils peuvent se connecter (via AWS Transit Gateway) à un VPC qui possède un sous-réseau public avec une passerelle NAT AWS et une passerelle Internet AWS.

Figure 2. Cluster privé ROSA avec PrivateLink

Dans les mises en œuvre publiques et PrivateLink, le cluster peut interagir avec d’autres services AWS à l’aide de points de terminaison de VPC AWS pour communiquer avec le VPC à l’endroit où se trouve le cluster avec les services souhaités.

Connexion au cluster

Il est recommandé à l'équipe SRE de se connecter aux clusters ROSA et d'effectuer des tâches d'administration en utilisant le service AWS Security Token Service (STS). Il faut appliquer le concept de moindre privilège afin de n'attribuer que les rôles qui sont strictement nécessaires pour accomplir une tâche. Le jeton est temporaire et à usage unique. Ainsi, si une tâche similaire doit être réeffectuée après son expiration, un nouveau jeton doit être demandé.

L'utilisation de STS s'étend à la connexion du cluster ROSA à d'autres services AWS tels qu'EC2 (par exemple, si de nouveaux serveurs doivent être mis en service pour le cluster) ou EBS (lorsqu'un stockage persistant est nécessaire).

Synthèse

L'adoption de méthodologies DevOps et la modernisation du déploiement des applications à l'aide d'une plateforme Kubernetes d'entreprise telle qu'OpenShift s'appliquent à tous les types de clients. Ils peuvent choisir de l'héberger sur site et de la gérer eux-mêmes, mais s'ils préfèrent ne pas le faire, ils peuvent se tourner vers ROSA. Grâce aux nombreux services AWS capables d'interagir avec les clusters ROSA, les clients peuvent tirer le meilleur parti de leur plateforme.

En savoir plus

• Mise en œuvre de Red Hat OpenShift Service on AWS