2.6. Le Red Hat OpenShift Service sur AWS (ROSA) avec la définition de service des avions de contrôle hébergés (HCP)

Le service Red Hat OpenShift sur AWS est facturé directement sur votre compte Amazon Web Services (AWS). La tarification ROSA est basée sur la consommation, avec des engagements annuels ou des engagements de trois ans pour une plus grande réduction. Le coût total de ROSA se compose de deux composantes:

Consultez le Service OpenShift Red Hat sur AWS Pricing page sur le site AWS pour plus de détails.

Les clients peuvent en libre-service leurs clusters, y compris, mais sans s’y limiter:

Ces tâches en libre-service peuvent être exécutées à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

L’ensemble des ROSA dotés de clusters HCP nécessitent un minimum de 2 nœuds ouvriers. La fermeture de l’infrastructure sous-jacente via la console fournisseur de cloud n’est pas prise en charge et peut entraîner une perte de données.

Les régions AWS suivantes sont actuellement disponibles pour ROSA avec HCP.

Les clusters de zones de disponibilité multiples ne peuvent être déployés que dans les régions avec au moins 3 zones de disponibilité. Consultez la section Régions et Zones de Disponibilité dans la documentation AWS.

Chaque nouvelle ROSA avec le cluster HCP est installée dans un cloud privé virtuel préexistant (VPC) dans une seule région, avec la possibilité de déployer jusqu’au nombre total de zones de disponibilité pour la région donnée. Cela permet d’isoler le réseau et les ressources au niveau du cluster, et permet les paramètres VPC fournisseurs de cloud, tels que les connexions VPN et VPC Peering. Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Storage (Amazon EBS), et sont spécifiques à la zone de disponibilité dans laquelle ils sont fournis. Les revendications de volume persistants (PVC) ne se lient pas à un volume tant que la ressource de la gousse associée n’est pas affectée dans une zone de disponibilité spécifique afin d’éviter les pods imprévus. Les ressources spécifiques à la zone de disponibilité ne sont utilisables que par des ressources dans la même zone de disponibilité.

Le service OpenShift Red Hat sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) ne prend pas en charge l’utilisation des zones locales AWS.

Les SLA du service lui-même sont définies à l’annexe 4 de l’Annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).

Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.

Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:

Lorsque vous avez des questions sur une action spécifique qui pourrait amener un cluster à passer à un statut de support limité ou à avoir besoin d’aide supplémentaire, ouvrez un ticket d’assistance.

Le service OpenShift Red Hat sur AWS inclut le support Red Hat Premium, auquel on peut accéder en utilisant le portail client Red Hat.

Consultez les Conditions d’utilisation de Red Hat Production Support pour connaître les délais de réponse du support.

Le support AWS est soumis au contrat de support existant d’un client avec AWS.

Les journaux d’audit en cluster sont disponibles via AWS CloudWatch, si l’intégration est activée. Lorsque l’intégration n’est pas activée, vous pouvez demander les journaux d’audit en ouvrant un dossier d’assistance.

Les journaux d’application envoyés à STDOUT sont collectés par Fluentd et transmis à AWS CloudWatch via la pile de journalisation du cluster, s’il est installé.

Le Red Hat OpenShift Service sur les clusters AWS est livré avec une pile Prometheus intégrée pour la surveillance des clusters, y compris les métriques CPU, mémoire et réseau. Ceci est accessible via la console web. Ces métriques permettent également une mise à l’échelle horizontale de pod basée sur des métriques CPU ou mémoire fournies par un service OpenShift Red Hat sur l’utilisateur AWS.

Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.

Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.

Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.

Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.

Afin d’utiliser un nom d’hôte personnalisé pour un itinéraire, vous devez mettre à jour votre fournisseur DNS en créant un enregistrement de nom canonique (CNAME). L’enregistrement CNAME doit cartographier le nom d’hôte du routeur canonique OpenShift à votre domaine personnalisé. Le nom d’hôte du routeur canonique OpenShift est affiché sur la page Détails de l’itinéraire après la création d’une route. Alternativement, un enregistrement générique CNAME peut être créé une fois pour acheminer tous les sous-domaines d’un nom d’hôte donné vers le routeur du cluster.

Le service OpenShift Red Hat sur AWS inclut les certificats de sécurité TLS nécessaires pour les services internes et externes sur le cluster. Dans le cas des routes externes, il existe deux certificats TLS Wildcard distincts qui sont fournis et installés sur chaque cluster: l’un est pour la console Web et les noms d’hôte par défaut d’itinéraire, et l’autre pour le point de terminaison API. Let's Encrypt est l’autorité de certification utilisée pour les certificats. Les itinéraires à l’intérieur du cluster, tels que le point de terminaison interne de l’API, utilisent les certificats TLS signés par l’autorité de certification intégrée du cluster et exigent le paquet CA disponible dans chaque pod pour faire confiance au certificat TLS.

Le service OpenShift Red Hat sur AWS prend en charge l’utilisation d’autorités de certification personnalisées pour être fiable par les builds lors de l’extraction d’images à partir d’un registre d’images.

Le service OpenShift Red Hat sur AWS (ROSA) avec des plans de contrôle hébergés (HCP) déploie uniquement des équilibreurs de charge à partir du contrôleur d’entrée par défaut. Les autres balanceurs de charge peuvent être déployés en option par un client pour les contrôleurs d’entrée secondaires ou les balanceurs de charge Service.

Les administrateurs de projet peuvent ajouter des annotations d’itinéraire à de nombreuses fins différentes, y compris le contrôle d’entrée grâce à la liste d’autorisations IP.

Les stratégies d’entrée peuvent également être modifiées en utilisant les objets NetworkPolicy, qui exploitent le plugin ovs-networkpolicy. Cela permet un contrôle total de la stratégie réseau d’entrée jusqu’au niveau pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.

L’ensemble du trafic d’entrée de cluster passera par les équilibreurs de charge définis. L’accès direct à tous les nœuds est bloqué par la configuration du cloud.

Le contrôle du trafic par le biais des objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans Red Hat OpenShift Service sur AWS (ROSA) avec des avions de contrôle hébergés (HCP).

Le service Red Hat OpenShift sur AWS permet la configuration d’une connexion réseau privée via des technologies gérées par AWS, telles que:

Dans le cas de Red Hat OpenShift Service sur les clusters AWS qui ont une configuration de réseau cloud privé, un client peut spécifier des serveurs DNS internes disponibles sur cette connexion privée, qui devraient être interrogés pour les domaines explicitement fournis.

Les vérifications réseau s’exécutent automatiquement lorsque vous déployez un service Red Hat OpenShift sur le cluster AWS dans un cloud privé virtuel (VPC) existant ou créez un pool de machines supplémentaire avec un sous-réseau qui est nouveau dans votre cluster. Les vérifications valident votre configuration réseau et mettent en évidence les erreurs, vous permettant de résoudre les problèmes de configuration avant le déploiement.

Il est également possible d’exécuter manuellement les vérifications réseau pour valider la configuration d’un cluster existant.

Les nœuds de travail utilisent le stockage Amazon Elastic Block Store (Amazon EBS) crypté au repos.

Les volumes EBS utilisés pour les PV sont cryptés au repos par défaut.

Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Store (Amazon EBS), qui est Read-Write-Once.

Les PVS ne peuvent être attachés qu’à un seul nœud à la fois et sont spécifiques à la zone de disponibilité dans laquelle ils ont été approvisionnés. Cependant, les PV peuvent être attachés à n’importe quel nœud dans la zone de disponibilité.

Chaque fournisseur de cloud a ses propres limites pour combien de PV peuvent être attachés à un seul nœud. Consultez les limites de type d’instance AWS pour plus de détails.

Le pilote AWS CSI peut être utilisé pour fournir la prise en charge RWX pour Red Hat OpenShift Service sur AWS (ROSA) avec des avions de contrôle hébergés (HCP). L’opérateur communautaire est fourni pour simplifier la configuration. Consultez Amazon Elastic File Storage Setup pour OpenShift Dedicated et Red Hat OpenShift Service sur AWS pour plus de détails.

La mise à l’échelle automatique des nœuds est disponible sur le service Red Hat OpenShift sur AWS. Il est possible de configurer l’option autoscaler pour mettre automatiquement à l’échelle le nombre de machines d’un cluster.

Les clients peuvent créer et exécuter des démons sur Red Hat OpenShift Service sur AWS. Afin de limiter les daemonsets à ne fonctionner que sur les nœuds ouvriers, utilisez le nodeSelector suivant:

spec:
  nodeSelector:
    role: worker

spec:
  nodeSelector:
    role: worker

Dans un cluster de zones de disponibilité multiple, les nœuds de plan de contrôle sont répartis entre les zones de disponibilité et au moins un nœud de travail est requis dans chaque zone de disponibilité.

Les étiquettes de nœuds personnalisés sont créées par Red Hat lors de la création de nœuds et ne peuvent pas être modifiées sur Red Hat OpenShift Service sur les clusters AWS pour le moment. Cependant, les étiquettes personnalisées sont prises en charge lors de la création de nouveaux pools de machines.

Les sauvegardes de données d’applications et d’applications ne font pas partie du service Red Hat OpenShift sur AWS.

Le service Red Hat OpenShift sur AWS est exécuté en tant que service et est tenu à jour avec la dernière version OpenShift Container Platform. La planification des mises à niveau vers la dernière version est disponible.

Les mises à niveau peuvent être programmées à l’aide du ROSA CLI, rosa ou via OpenShift Cluster Manager.

Consultez le service Red Hat OpenShift sur AWS Life Cycle pour plus d’informations sur la politique et les procédures de mise à niveau.

La prise en charge de Red Hat OpenShift pour les conteneurs Windows n’est pas disponible sur Red Hat OpenShift Service sur AWS pour le moment.

Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise CRI-O comme seul moteur de conteneur disponible.

Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise Red Hat CoreOS comme système d’exploitation pour tous les avions de contrôle et les nœuds de travail.

Les charges de travail Red Hat se réfèrent généralement aux opérateurs fournis par Red Hat mis à disposition par l’intermédiaire de l’opérateur Hub. Les charges de travail Red Hat ne sont pas gérées par l’équipe Red Hat SRE et doivent être déployées sur les nœuds des travailleurs. Ces opérateurs peuvent nécessiter des abonnements supplémentaires à Red Hat et peuvent entraîner des coûts d’infrastructure cloud supplémentaires. Des exemples de ces opérateurs fournis par Red Hat sont:

Les opérateurs inscrits sur le marché OperatorHub devraient être disponibles pour l’installation. Ces opérateurs sont considérés comme des charges de travail des clients et ne sont pas surveillés par Red Hat SRE.

L’authentification pour le cluster peut être configurée en utilisant OpenShift Cluster Manager ou le processus de création de cluster ou en utilisant le ROSA CLI, rosa. La ROSA n’est pas un fournisseur d’identité, et tout accès au cluster doit être géré par le client dans le cadre de sa solution intégrée. L’utilisation de plusieurs fournisseurs d’identité fournis en même temps est prise en charge. Les fournisseurs d’identité suivants sont pris en charge:

Des conteneurs privilégiés sont disponibles pour les utilisateurs ayant le rôle de cluster-admin. L’utilisation de conteneurs privilégiés en tant que cluster-admin est assujettie aux responsabilités et aux notes d’exclusion figurant à l’annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).

En plus des utilisateurs normaux, Red Hat OpenShift Service sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) donne accès à un ROSA avec un groupe spécifique HCP appelé admin dédié. Les utilisateurs du cluster qui sont membres du groupe admin dédié:

L’administrateur de Red Hat OpenShift Service sur AWS (ROSA) avec des plans de contrôle hébergés (HCP) a un accès par défaut au rôle d’administration cluster pour le cluster de votre organisation. Alors qu’ils sont connectés à un compte avec le rôle de cluster-admin, les utilisateurs ont augmenté les autorisations d’exécuter des contextes de sécurité privilégiés.

Par défaut, tous les utilisateurs ont la possibilité de créer, de mettre à jour et de supprimer leurs projets. Cela peut être restreint si un membre du groupe admin dédié supprime le rôle d’auto-fournisseur des utilisateurs authentifiés:

oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

Les restrictions peuvent être annulées en appliquant:

oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

Consultez le tableau de conformité dans Comprendre le processus et la sécurité de ROSA pour obtenir les dernières informations sur la conformité.

Avec Red Hat OpenShift Service sur AWS, AWS fournit une protection DDoS standard sur tous les équilibreurs de charge, appelé AWS Shield. Cela offre une protection de 95 % contre les attaques de niveau 3 et 4 les plus couramment utilisées sur l’ensemble des balanceurs de charge publics utilisés pour Red Hat OpenShift Service sur AWS. Le délai de 10 secondes est ajouté pour les requêtes HTTP arrivant sur le routeur haproxy pour recevoir une réponse ou la connexion est fermée pour fournir une protection supplémentaire.

Dans Red Hat OpenShift Service sur AWS (ROSA) avec des plans de contrôle hébergés (HCP), le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le chiffrement des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.

La base de données etcd est toujours cryptée par défaut. Les clients peuvent choisir de fournir leurs propres clés AWS KMS personnalisées dans le but de chiffrer la base de données etcd.

Le chiffrement etcd chiffrera les ressources suivantes du serveur API Kubernetes et du serveur OpenShift API: