Définition du service Azure Red Hat OpenShift
Les sections suivantes fournissent des définitions relatives au service pour vous aider à gérer votre compte Azure Red Hat OpenShift.
Billing
Les clusters Azure Red Hat OpenShift sont déployés dans l’abonnement Azure d’un client. Un client paie directement à Azure les coûts engendrés par un cluster Azure Red Hat OpenShift.
Les nœuds Azure Red Hat OpenShift s’exécutent sur des machines virtuelles Azure. Ils sont facturés selon les tarifs établis pour les machines virtuelles Linux Azure. Les ressources (calcul, réseau et stockage) consommées par un cluster Azure Red Hat OpenShift sont facturées en fonction de leur utilisation.
Outre les coûts de calcul et d’infrastructure, les nœuds d’application ont un coût supplémentaire pour le composant sous licence Azure Red Hat OpenShift. Ce coût est basé sur le nombre de nœuds d’application et le type d’instance.
Toutes les options d’achat Azure standard, notamment les réservations et le prépaiement Azure, s’appliquent. Les options d’achat Azure standard peuvent être utilisées pour Azure Red Hat OpenShift. Par ailleurs, les options d’achat Azure standard peuvent être utilisées pour les ressources (machines virtuelles, réseau et stockage) consommées par le cluster Azure Red Hat OpenShift.
Pour plus d’informations sur les tarifs, consultez les tarifs d’Azure Red Hat OpenShift.
Cluster libre-service
Les clients peuvent créer et supprimer leurs clusters en utilisant l’interface de ligne de commande Azure (Azure CLI). Les clusters Azure Red Hat OpenShift sont déployés avec un utilisateur kubeadmin dont les informations d’identification sont accessibles à partir d’Azure CLI une fois un cluster déployé.
Vous pouvez effectuer toutes les autres actions relatives à un cluster Azure Red Hat OpenShift, comme la mise à l’échelle des nœuds, en interagissant avec l’API OpenShift à l’aide d’outils tels que la console web OpenShift ou l’interface OpenShift CLI (oc).
Architecture des ressources Azure
Un déploiement Azure Red Hat OpenShift nécessite deux groupes de ressources dans un abonnement Azure. Le premier groupe de ressources est créé par le client et contient les composants du réseau virtuel pour le cluster. La séparation des éléments réseau permet au client de configurer Azure Red Hat OpenShift pour répondre aux exigences et d’ajouter des options d’appairage.
Le deuxième groupe de ressources est créé par le fournisseur de ressources Azure Red Hat OpenShift. Il contient les composants du cluster Azure Red Hat OpenShift, notamment des machines virtuelles, des groupes de sécurité réseau et des équilibreurs de charge. Le client ne peut pas modifier les composants du cluster Azure Red Hat OpenShift situés dans ce groupe de ressources. Pour configurer le cluster, vous devez interagir avec l’API OpenShift à l’aide de la console web OpenShift, de l’interface OpenShift CLI ou d’outils similaires.
Remarque
Le principal de service du fournisseur de ressources ARO nécessite le rôle Contributeur réseau sur le réseau virtuel du cluster ARO. Cela est nécessaire pour que le fournisseur de ressources ARO crée des ressources comme le service ARO Private Link et les équilibreurs de charge.
Opérateurs Red Hat
Il est recommandé qu’un client fournisse un secret d’extraction Red Hat au cluster Azure Red Hat OpenShift durant la création du cluster. Un secret d’extraction Red Hat permet au cluster d’accéder à des registres de conteneurs Red Hat ainsi qu’à d’autres contenus à partir d’OpenShift OperatorHub.
Les clusters Azure Red Hat OpenShift peuvent prendre en charge des applications sans fournir le secret d’extraction Red Hat, mais ils ne peuvent pas installer d’opérateurs à partir d’OperatorHub.
Le secret d’extraction Red Hat peut également être fourni au cluster après le déploiement.
Compute
Les clusters Azure Red Hat OpenShift sont provisionnés avec au moins trois nœuds worker.
Dans les régions constituées de plusieurs zones de disponibilité, un groupe de machines de nœud worker est créé dans chaque zone. Par ailleurs, un nœud worker est provisionné à partir de chaque groupe de machines.
Quand une région Azure ne prend pas en charge les zones de disponibilité, le cluster Azure Red Hat OpenShift provisionne les nœuds worker à partir d’un seul groupe de machines. Les clients peuvent augmenter le nombre de nœuds et l’autorisation dans chaque région.
Les clusters Azure Red Hat OpenShift sont provisionnés avec trois nœuds de plan de contrôle. Ces nœuds sont responsables du magasin clé-valeur etcd et des charges de travail liées à l’API. Le nœud de plan de contrôle ne peut pas être utilisé pour les charges de travail des clients. Les règles de déploiement sont les mêmes pour les nœuds de plan de contrôle et les nœuds worker.
- Dans les régions constituées de plusieurs zones de disponibilité, un groupe de machines de nœud de plan de contrôle est créé dans chaque zone. Un nœud de plan de contrôle est provisionné à partir de chaque groupe de machines.
- Quand une région Azure ne prend pas en charge les zones de disponibilité, le cluster Azure Red Hat OpenShift provisionne les nœuds de plan de contrôle à partir d’un seul groupe de machines.
Types de calcul Azure
Pour obtenir la liste des types et tailles de nœuds worker et de plan de contrôle pris en charge, consultez les tailles de machines virtuelles prises en charge.
Régions Azure
Pour connaître les régions prises en charge par Azure Red Hat OpenShift, consultez les produits disponibles par région.
Dans Azure CLI, exécutez la commande suivante pour afficher la liste des régions disponibles :
az provider show -n Microsoft.RedHatOpenShift --query "resourceTypes[?resourceType == 'OpenShiftClusters']".locations -o yaml
Une fois déployé, un cluster Azure Red Hat OpenShift ne peut pas être déplacé vers une autre région. De même, vous ne pouvez pas transférer les clusters Azure Red Hat OpenShift d’un abonnement à un autre.
Contrat SLA
Pour plus d’informations sur les contrats SLA, consultez le SLA pour Azure Red Hat OpenShift.
Support
Pour contacter le support d’Azure Red Hat OpenShift, vous pouvez :
- Envoyer une demande de support dans le portail Azure
- Envoyer une demande de support dans le portail client Red Hat
Les demandes seront triées et traitées par les ingénieurs du support technique de Microsoft et de Red Hat. Azure Red Hat OpenShift inclut le support Premium de Red Hat. Le support est accessible par le biais du portail Microsoft Azure.
Pour ouvrir des tickets de support directement avec Red Hat, votre cluster doit avoir un secret d’extraction. Vous pouvez l’ajouter lors de la création du cluster ou l’ajouter ou le mettre à jour sur un cluster existant.
Logging
Les sections suivantes fournissent des informations sur la sécurité dans Azure Red Hat OpenShift.
Opérations de cluster et journalisation d’audit
Azure Red Hat OpenShift est déployé avec des services qui maintiennent l’intégrité et les performances du cluster et de ses composants. Ces services incluent les opérations de cluster et les journaux d’audit. Les opérations de cluster et les journaux d’audit sont transférés automatiquement à un système d’agrégation Azure pour le support et la résolution des problèmes. Seul le personnel de support autorisé peut accéder à ces données par le biais de mécanismes approuvés.
Les administrateurs de cluster des clients peuvent déployer une pile de journalisation facultative pour agréger tous les journaux à partir de leur cluster Azure Red Hat OpenShift. Par exemple, les journaux d’audit système des nœuds et les journaux d’infrastructure peuvent être agrégés. Toutefois, ces journaux consomment d’autres ressources de cluster.
Journalisation des applications
Une fois l’accès à OperatorHub.io activé, Azure Red Hat OpenShift inclut une pile de journalisation facultative basée sur Elasticsearch, Fluentd et Kibana (EFK).
La pile de journalisation, Logging Operator, peut être configurée pour répondre aux besoins du client. Toutefois, elle est conçue pour une conservation à court terme afin de faciliter le dépannage des clusters et des applications, et non pour l’archivage des journaux à long terme.
Si la pile de journalisation de cluster est installée, les journaux des applications envoyés à STDOUT sont collectés par Fluentd. Les journaux des applications sont mis à disposition par le biais de la pile de journalisation de cluster. La conservation est définie sur sept jours, mais elle ne dépasse pas 200 Gio de journaux par partition. Pour une conservation à plus long terme, les clients doivent suivre la conception du conteneur side-car dans leurs déploiements. Les clients doivent transférer les journaux au service d’analytique ou d’agrégation de journaux de leur choix.
Surveillance
Les sections suivantes fournissent des informations sur le monitoring dans Azure Red Hat OpenShift.
Métriques de cluster
Azure Red Hat OpenShift est déployé avec des services qui maintiennent l’intégrité et les performances du cluster et de ses composants. Ces services incluent l’envoi en streaming des métriques importantes à un système d’agrégation Azure pour le support et la résolution des problèmes. Seul le personnel de support autorisé peut accéder à ces données par le biais de mécanismes approuvés.
Les clusters Azure Red Hat OpenShift intègrent une pile Prometheus/Grafana pour permettre aux clients de voir le monitoring du cluster. La pile inclut des métriques basées sur le processeur, la mémoire et le réseau.
Ces métriques, accessibles par le biais de la console web, peuvent également être utilisées pour afficher l’état et la capacité/utilisation du cluster dans un tableau de bord Grafana. Ces métriques permettent également la mise à l’échelle horizontale automatique des pods en fonction des métriques de processeur ou de mémoire fournies par un client Azure Red Hat OpenShift.
Network (Réseau)
Les sections suivantes fournissent des informations sur le réseau Azure Red Hat OpenShift.
Certificats validés par le domaine
Par défaut, Azure Red Hat OpenShift inclut les certificats de sécurité TLS nécessaires pour les services internes et externes sur le cluster. Pour les routes externes, un certificat générique TLS (Transport Layer Security) est fourni et installé dans le cluster. Un certificat TLS est également utilisé pour le point de terminaison de l’API OpenShift. DigiCert est l’autorité de certification (CA) utilisée pour ces certificats.
Domaines personnalisés
Durant le déploiement, Azure Red Hat OpenShift vous permet de spécifier un domaine personnalisé pour votre cluster. Le domaine personnalisé est utilisé pour les services de cluster et les applications. Vous devez créer deux enregistrements A DNS dans votre serveur DNS pour le domaine spécifié :
- api, qui pointe vers l’adresse IP du serveur d’API
- *.apps, qui pointe vers l’adresse IP d’entrée
Par défaut, Azure Red Hat OpenShift utilise des certificats auto-signés pour toutes les routes créées sur des domaines personnalisé. Si vous choisissez d’utiliser des domaines personnalisés, connectez-vous au cluster. Ensuite, reportez-vous à la documentation OpenShift afin de configurer une autorité de certification personnalisée pour votre contrôleur d’entrée et une autre pour votre serveur d’API.
Autorités de certification personnalisées pour les builds
Azure Red Hat OpenShift prend en charge l’utilisation d’autorités de certification auxquelles les builds doivent faire confiance lors de l’extraction d’images à partir d’un registre d’images.
Équilibreurs de charge
Azure Red Hat OpenShift est déployé avec deux équilibreurs de charge Azure. Le premier est utilisé pour le trafic d’entrée vers les applications et pour les API OpenShift et Kubernetes. Le second est utilisé pour les communications internes entre les composants du cluster.
Entrée du cluster
Les administrateurs de projet peuvent ajouter des annotations de route à différentes fins, notamment le contrôle d’entrée par le biais d’une liste d’adresses IP autorisées.
Les stratégies d’entrée peuvent être modifiées au moyen d’objets NetworkPolicy qui utilisent le plug-in ovs-networkpolicy. L’utilisation d’objets NetworkPolicy permet un contrôle total sur la stratégie réseau d’entrée jusqu’au niveau du pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.
Le trafic d’entrée de tous les clusters passe par l’équilibreur de charge défini.
Sortie du cluster
Le contrôle du trafic de sortie du pod par le biais des objets EgressNetworkPolicy peut être utilisé pour empêcher ou limiter le trafic sortant dans Azure Red Hat OpenShift. Actuellement, toutes les machines virtuelles doivent avoir un accès Internet sortant.
Configuration réseau dans le cloud
Azure Red Hat OpenShift rend possible la configuration de connexions réseau privées à l’aide de plusieurs technologies managées par un fournisseur de services cloud :
- Connexions de réseau virtuel
- Peering de réseaux virtuels Azure
- Passerelle de réseau virtuel Azure
- Route Azure Express
Aucun service de monitoring de ces connexions réseau privées n’est fourni par Red Hat SRE. Le monitoring de ces connexions est la responsabilité du client.
Utilisateur spécifié par le client
Les clients Azure Red Hat OpenShift peuvent spécifier leurs propres serveurs DNS. Pour plus d’informations, consultez Configurer un DNS personnalisé pour votre cluster Azure Red Hat OpenShift.
Interface réseau de conteneur
Azure Red Hat OpenShift est fourni avec OVN (Open Virtual Network) en tant qu’interface réseau de conteneur (Container Network Interface/CNI). Le remplacement de la CNI n’est pas une opération prise en charge. Pour plus d’informations, consultez Fournisseur de réseau OVN-Kubernetes pour les clusters Azure Red Hat OpenShift.
Stockage
Les sections suivantes fournissent des informations sur le stockage dans Azure Red Hat OpenShift.
Chiffrement des données au repos
Le service Stockage Azure utilise le chiffrement côté serveur (SSE) pour chiffrer automatiquement vos données quand elles sont rendues persistantes dans le cloud. Par défaut, les données sont chiffrées avec des clés managées par la plateforme Microsoft.
Stockage par blocs (RWO)
Les volumes persistants sont sauvegardés par le stockage par blocs sur disques Azure, qui est en lecture/écriture unique (RWO). Des disques de 1024 Gio sont créés de manière dynamique et attachés à chaque nœud de plan de contrôle Azure Red Hat OpenShift. Il s’agit de disques SSD Premium managés par Azure à stockage localement redondant (LRS). Les tailles de disque pour les groupes de machines de nœuds worker par défaut peuvent être configurées durant la création du cluster.
Les clients sont autorisés à créer davantage de groupes de machines pour mieux répondre à leurs besoins.
Les volumes persistants (PV), qui ne peuvent être attachés qu’à un seul nœud à la fois, sont spécifiques à la zone de disponibilité dans laquelle ils ont été provisionnés. Ils peuvent être attachés à n’importe quel nœud de la zone de disponibilité.
Azure limite le nombre de PV de type « stockage par blocs » pouvant être attachés à un seul nœud. Les limites Azure dépendent du type et de la taille de la machine virtuelle que le client sélectionne pour les nœuds worker. Par exemple, pour voir le nombre maximal de disques de données pour la série Dasv4, consultez Dasv4.
Stockage partagé (RWX)
Le stockage partagé pour les clusters Azure Red Hat OpenShift doit être configuré par le client. Pour obtenir un exemple de configuration d’une classe de stockage pour Azure Files, consultez Créer une classe de stockage Azure Files sur Azure Red Hat OpenShift 4.
Plateforme
Les sections suivantes fournissent des informations sur la plateforme Azure Red Hat OpenShift.
Stratégie de sauvegarde de cluster
Important
Il est essentiel d’avoir un plan de sauvegarde pour vos applications et données d’application.
Les sauvegardes d’applications et de données d’application ne sont pas automatisées dans le service Azure Red Hat OpenShift. Pour obtenir un tutoriel sur la sauvegarde manuelle d’une application, consultez Créer une sauvegarde d’application de cluster Azure Red Hat OpenShift 4.
Ressources DaemonSet
Les clients peuvent créer et exécuter DaemonSets sur Azure Red Hat OpenShift. Pour limiter l’exécution de DaemonSets aux nœuds worker, utilisez le nodeSelector suivant :
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
Version d’Azure Red Hat OpenShift
Azure Red Hat OpenShift est exécuté en tant que service. Il permet aux clients de rester à jour avec la dernière version stable d’OpenShift Container Platform. Pour obtenir la stratégie de support et de mise à niveau, consultez le cycle de vie du support pour Azure Red Hat OpenShift 4.
Cycle de vie de support
Pour plus d’informations sur le cycle de vie du support Azure Red Hat OpenShift, consultez le cycle de vie du support pour Azure Red Hat OpenShift 4.
Moteur de conteneur
Azure Red Hat OpenShift s’exécute sur OpenShift 4 et utilise l’implémentation CRI-O de l’interface du runtime de conteneurs Kubernetes comme seul moteur de conteneur disponible.
Système d’exploitation
Azure Red Hat OpenShift s’exécute sur OpenShift 4 en utilisant Red Hat Enterprise Linux CoreOS (RHCOS) comme système d’exploitation pour tous les nœuds de plan de contrôle et worker. Les charges de travail Windows ne sont pas prises en charge sur Azure OpenShift, car la plateforme ne prend actuellement pas en charge les nœuds Worker Windows.
Prise en charge des opérateurs Kubernetes
Azure Red Hat OpenShift prend en charge les opérateurs créés par Red Hat et les éditeurs de logiciels indépendants (ISV) certifiés. Les opérateurs fournis par Red Hat sont pris en charge par Red Hat. Les opérateurs fournis par un ISV sont pris en charge par l’ISV.
Pour utiliser OperatorHub, votre cluster doit être configuré avec un secret d’extraction Red Hat. Pour plus d’informations sur l’utilisation d’OperatorHub, consultez la présentation d’OperatorHub.
Sécurité
Les sections suivantes fournissent des informations sur la sécurité dans Azure OpenShift.
Fournisseur d’authentification
Les clusters Azure Red Hat OpenShift ne sont pas configurés avec des fournisseurs d’authentification.
Les clients doivent configurer leurs propres fournisseurs, comme Microsoft Entra ID. Pour plus d’informations sur la configuration des fournisseurs, consultez les articles suivants :
Conformité aux normes
Pour plus d’informations sur les certifications de conformité réglementaire d’Azure Red Hat OpenShift, consultez les offres de conformité de Microsoft Azure.
Étapes suivantes
Pour plus d’informations, consultez la documentation sur les stratégies de support.