2.3. Le Red Hat OpenShift Service sur la définition de service AWS

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.

Les clusters de zone de disponibilité unique nécessitent un minimum de 3 nœuds d’avion de contrôle, 2 nœuds d’infrastructure et 2 nœuds ouvriers déployés dans une seule zone de disponibilité.

Les clusters de zones de disponibilité multiples nécessitent un minimum de 3 nœuds de plan de contrôle, 3 nœuds d’infrastructure et 3 nœuds ouvriers.

Considérez les limites suivantes lors du déploiement et de la gestion des charges de travail:

Il est possible que Red Hat vous avise et redimensionne le plan de contrôle ou les nœuds d’infrastructure si le service OpenShift Red Hat sur les composants AWS est affecté.

Les nœuds d’avion de contrôle et d’infrastructure sont déployés et gérés par Red Hat. Ces nœuds sont automatiquement redimensionnés en fonction de l’utilisation des ressources. Lorsque vous avez besoin de redimensionner ces nœuds pour répondre aux demandes des clusters, ouvrez un cas de support.

Consultez la section de support de Red Hat Operator suivante pour plus d’informations sur les charges de travail de Red Hat qui doivent être déployées sur les nœuds des travailleurs.

Les régions AWS suivantes sont actuellement disponibles pour Red Hat OpenShift 4 et sont prises en charge pour Red Hat OpenShift Service sur AWS.

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 nouveau Red Hat OpenShift Service sur AWS cluster est installé dans un cloud privé virtuel (VPC) créé par un installateur ou préexistant dans une seule région, avec la possibilité de se déployer dans une seule zone de disponibilité (Single-AZ) ou sur plusieurs zones de disponibilité (Multi-AZ). 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 prend en charge l’utilisation des zones locales AWS, qui sont des zones de disponibilité centralisées de métropole où les clients peuvent placer des charges de travail d’application sensibles à la latence. Les zones locales sont des extensions de régions AWS qui ont leur propre connexion Internet. Consultez la documentation AWS Comment fonctionnent les 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 utilise jusqu’à cinq balanceurs de charge différents:

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 d’objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans Red Hat OpenShift Service sur AWS.

Le trafic public sortant du plan de contrôle et des nœuds d’infrastructure est nécessaire pour maintenir la sécurité de l’image de cluster et la surveillance des clusters. Cela nécessite que l’itinéraire 0.0.0.0/0 appartient uniquement à la passerelle Internet; il n’est pas possible d’acheminer cette plage sur des connexions privées.

Les clusters OpenShift 4 utilisent les passerelles NAT pour présenter une IP publique statique pour tout trafic public sortant du cluster. Chaque zone de disponibilité dans laquelle un cluster est déployé reçoit une passerelle NAT distincte, de sorte que jusqu’à 3 adresses IP statiques uniques peuvent exister pour le trafic egress de cluster. Le trafic qui reste à l’intérieur du cluster, ou qui ne va pas vers l’Internet public, ne passera pas par la passerelle NAT et aura une adresse IP source appartenant au nœud d’origine du trafic. Les adresses IP des nœuds sont dynamiques; par conséquent, un client ne doit pas compter sur la liste blanche des adresses IP individuelles lors de l’accès aux ressources privées.

Les clients peuvent déterminer leurs adresses IP statiques publiques en exécutant un pod sur le cluster, puis en interrogeant un service externe. À titre d’exemple:

oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

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.

Le plan de contrôle, l’infrastructure et les nœuds de travail utilisent le stockage Amazon Elastic Block Store (Amazon EBS) chiffré.

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 le support RWX pour Red Hat OpenShift Service sur AWS. 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 donne accès à un groupe spécifique ROSA 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 a un accès par défaut au rôle d’administration du 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, le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le cryptage des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.

Il est également possible d’activer le chiffrement etcd, qui chiffre les valeurs clés dans etcd, mais pas les clés. Lorsque vous activez le cryptage etcd, les ressources suivantes du serveur API Kubernetes et OpenShift API sont cryptées:

La fonction de chiffrement etcd n’est pas activée par défaut et ne peut être activée qu’au moment de l’installation du cluster. Bien que le chiffrement etcd soit activé, les valeurs clés etcd sont accessibles à toute personne ayant accès aux nœuds de plan de contrôle ou aux privilèges cluster-admin.