Cet article répond aux questions fréquemment posées (FAQ) sur Microsoft Azure Red Hat OpenShift.
Installation et mise à niveau
Où puis-je trouver des informations sur les prix et les contrats de niveau de service ?
Pour obtenir des informations sur les prix, consultez Tarifs d’Azure Red Hat OpenShift.
Si vous souhaitez obtenir plus d’informations sur le Contrat de niveau de service, consultez Contrats de niveau de service (SLA) pour les services en ligne.
Quelles sont les régions Azure prises en charge?
Pour obtenir la liste des régions prises en charge pour Azure Red Hat OpenShift 4.x, consultez Régions disponibles.
Quelles tailles de machines virtuelles puis-je utiliser ?
Pour obtenir la liste des tailles de machines virtuelles prises en charge pour Azure Red Hat OpenShift 4, consultez Ressources prises en charge pour Azure Red Hat OpenShift 4.
Quel est le nombre maximal de pods que peut contenir un cluster Azure Red Hat OpenShift ? Quel est le nombre maximal de pods par nœud dans Azure Red Hat OpenShift ?
Le nombre réel de pods pris en charge dépend de la mémoire, de l’UC et des exigences de stockage d’une application.
Azure Red Hat OpenShift 4.x a une limite de 250 pods par nœud et une limite de 250 nœuds de calcul. Ces limites permettent de limiter le nombre maximal de pods pris en charge dans un cluster à 250×250 = 62 500. Ces limites sont les mêmes pour les clusters créés à l’aide du routage défini par l’utilisateur (UDR) et pour ceux qui fonctionnent avec la version 4.11 ou une version ultérieure.
Un cluster peut-il disposer de nœuds de calcul dans plusieurs régions Azure ?
Non. Tous les nœuds d’un cluster Azure Red Hat OpenShift doivent provenir de la même région Azure.
Est-il possible de déployer un cluster sur plusieurs zones de disponibilité ?
Oui. Un cluster peut être déployé sur plusieurs zones de disponibilité automatiquement si votre cluster est déployé dans une région Azure qui prend en charge les zones de disponibilité. Pour plus d’informations, consultez Zones de disponibilité.
Les nœuds de plan de contrôle sont-ils extraits comme ils le sont avec Azure Kubernetes service (AKS) ?
Non. Toutes les ressources, y compris les nœuds du plan de contrôle du cluster, s’exécutent dans votre abonnement client. Ces types de ressources sont placés dans un groupe de ressources en lecture seule.
Le cluster réside-t-il dans un abonnement client ?
L’application managée Azure réside dans un groupe de ressources verrouillé avec l’abonnement client. Les clients peuvent consulter les objets de ce groupe de ressources, mais pas les modifier.
Des éléments d’Azure Red Hat OpenShift sont-ils partagés avec d’autres clients ? Ou est-ce que tout est indépendant ?
Chaque cluster Azure Red Hat OpenShift est dédié à un client donné et se trouve dans l’abonnement du client.
Des nœuds d’infrastructure sont-ils disponibles ?
Oui. ARO vous permet d’utiliser des groupes de machines d’infrastructure pour créer des machines qui hébergent uniquement des composants d’infrastructure, tels que le routeur par défaut, le registre de conteneurs intégré et les composants pour le monitoring et les métriques de cluster. Consultez Déployer des nœuds d’infrastructure dans un cluster ARO pour découvrir plus d’informations.
Comment faire gérer les mises à niveau de cluster ?
Pour plus d’informations sur les mises à niveau, la maintenance et les versions prises en charge, consultez le Guide du cycle de vie du support .
Comment sont mis à jour le système d’exploitation hôte et le logiciel OpenShift ?
Les systèmes d’exploitation hôtes et le logiciel OpenShift sont mis à jour à mesure qu’Azure Red Hat OpenShift consomme des versions mineures et des correctifs de la plateforme de conteneurs OpenShift en amont.
Comment se passe le processus de redémarrage du nœud mis à jour ?
Les nœuds sont redémarrés dans le cadre d’une mise à niveau.
Opérations de cluster
Puis-je utiliser Prometheus pour surveiller mes applications ?
Prometheus est préinstallé et configuré pour les clusters Azure Red Hat OpenShift 4.x. En savoir plus sur la surveillance du cluster.
Puis-je utiliser Prometheus pour surveiller les mesures relatives à la capacité et à l’intégrité du cluster ?
Dans Azure Red Hat OpenShift 4.x : oui.
Les journaux des machines virtuelles sous-jacentes peuvent-ils être diffusés en continu vers un système d’analyse des journaux client ?
Les journaux des machines virtuelles sous-jacentes sont traités par le service géré et ne sont pas exposés aux clients.
Comment un client peut-il accéder aux métriques telles que l’UC ou la mémoire au niveau du nœud, en vue d’effectuer une mise à l’échelle ou un débogage, par exemple ? Je ne peux pas exécuter kubectl sur un cluster Azure Red Hat OpenShift.
Pour les clusters Azure Red Hat OpenShift 4.x, la console Web OpenShift contient toutes les métriques au niveau du nœud. Pour plus d’informations, consultez la documentation Red Hat sur l’affichage des informations des clusters.
Lors du scale-up d’un déploiement, comment les domaines d’erreur Azure sont-ils mappés à l’emplacement pod pour éviter que tous les pods d’un service ne soient rendus hors d’usage par une défaillance dans un domaine d’erreur ?
Par défaut, il existe cinq domaines d’erreur lorsque vous utilisez des Virtual Machine Scale Sets dans Azure. Chaque instance de machine virtuelle d’un groupe identique sera placée dans l’un de ces domaines d’erreur. Cela garantit que les applications déployées sur les nœuds de calcul d’un cluster seront placées dans des domaines d’erreur distincts.
Pour plus d’informations, consultez Choisir le bon nombre de domaines d’erreur pour un groupe de machines virtuelles identiques.
Existe-t-il un moyen de gérer l’emplacement des pods ?
Les clients ont la possibilité d’obtenir des nœuds et d’afficher des étiquettes en tant que client-administrateur. Cela permettra de cibler les machines virtuelles du groupe identique.
Vous devez être prudent avec certaines étiquettes :
- Vous ne devez pas utiliser le nom d’hôte. Le nom d’hôte « tourne » souvent avec les mises à niveau et les mises à jour, et est donc amené à changer.
- Si le client fait une demande concernant certaines étiquettes ou une stratégie de déploiement, il est possible d’y répondre. Toutefois, cela nécessite des efforts d’ingénierie et n’est pas pris en charge pour le moment.
Pour plus d’informations, consultez Contrôle de la sélection élective des pods.
Le registre d’images est-il disponible en externe afin que je puisse utiliser des outils tels que Jenkins ?
Pour les clusters 4.x, vous devez exposer un registre sécurisé et configurer l’authentification. Pour plus d’informations, consultez la documentation Red Hat suivante :
Puis-je déplacer/migrer mon cluster entre des locataires Azure ?
Le déplacement de votre cluster ARO entre tenants n’est actuellement pas pris en charge.
Puis-je déplacer mes clusters ARO de l’abonnement Azure actuel vers un autre ?
Le déplacement de votre cluster ARO et des ressources associées entre des abonnements n’est pas pris en charge.
Puis-je déplacer mes cluster ARO ou mes ressources d'infrastructure ARO vers d'autres groupes de ressources ou changer leur nom ?
Le déplacement ou le changement de nom de votre cluster ARO et des ressources associées ne sont pas pris en charge.
Mise en réseau
Puis-je déployer un cluster dans un réseau virtuel existant ?
Dans les clusters 4.x, vous pouvez déployer un cluster dans un réseau virtuel existant.
La mise en réseau sur les espaces de noms est-elle prise en charge ?
Le client et les administrateurs de projet individuel peuvent personnaliser la mise en réseau sur les espaces de noms (y compris la refuser) par projet à l’aide d’objets NetworkPolicy.
J’essaie de regarder dans le réseau virtuel d’un autre abonnement, mais j’obtiens une erreur Échec du CIDR du réseau virtuel.
Dans l’abonnement comportant le réseau virtuel, veillez à inscrire le fournisseur Microsoft.ContainerService avec la commande suivante : az provider register -n Microsoft.ContainerService --wait.
Est-il possible de spécifier des plages d’adresses IP pour un déploiement sur un réseau virtuel privé, en évitant les conflits avec d’autres réseaux virtuels d’entreprise après le Peering ?
Dans les clusters 4.x, vous pouvez spécifier vos propres plages d’adresses IP.
Le module Réseau défini par logiciel est-il configurable ?
Le réseau défini par logiciel est openshift-ovs-networkpolicy et n’est pas configurable.
Quel équilibrage de charge Azure est utilisé par Azure Red Hat OpenShift ? Est-il de niveau Standard ou De base, et peut-il être configuré ?
Azure Red Hat OpenShift utilise l’équilibreur de charge Azure Standard, qui n’est pas configurable.
Autorisations
Un administrateur peut-il gérer des quotas et des utilisateurs ?
Oui. Un administrateur Azure Red Hat OpenShift peut gérer des utilisateurs et des quotas et dispose en plus d’un accès à tous les projets créés par les utilisateurs.
Puis-je limiter un cluster à certains utilisateurs Microsoft Entra seulement ?
Oui. Vous pouvez désigner les utilisateurs Microsoft Entra pouvant se connecter à un cluster en configurant l’application Microsoft Entra. Pour obtenir des détails, consultez Procédure : Limiter votre application à un ensemble d’utilisateurs.
Puis-je empêcher les utilisateurs de créer des projets ?
Oui. Connectez-vous à votre cluster en tant qu’administrateur, puis exécutez la commande suivante :
oc adm policy \
remove-cluster-role-from-group self-provisioner \
system:authenticated:oauth
Pour plus d’informations, consultez la documentation OpenShift sur la désactivation de l’approvisionnement automatique pour la version de votre cluster :
Quels droits UNIX (dans IaaS) sont disponibles pour les nœuds principaux/d’infrastructure/d’application ?
L’accès aux nœuds est disponible via le rôle Administrateur de cluster. Pour plus d’informations, consultez Vue d’ensemble de RBAC Kubernetes.
De quels droits OCP disposons-nous ? Administrateur de cluster ? Administrateur de projet ?
Le rôle Administrateur de cluster est disponible. Pour plus d’informations, consultez Vue d’ensemble de RBAC Kubernetes.
Quels sont les fournisseurs d’identité disponibles ?
Vous configurez votre fournisseur d’identité. Pour plus d’informations, consultez la documentation Red Hat sur la configuration des fournisseurs d’identité.
Stockage
Les données de mon cluster sont-elles chiffrées ?
Par défaut, les données sont chiffrées au repos. La plateforme de stockage Azure Storage chiffre automatiquement vos données avant de les rendre persistantes et les déchiffre avant la récupération. Pour plus d’informations, consultez Azure Storage Service Encryption pour les données au repos.
Comment les comptes de stockage sont-ils sécurisés ?
Les comptes de stockage sont définis sur accès privé uniquement.
Les comptes de stockage sont chiffrés (nouveaux clusters uniquement). Vous devez recréer les clusters existants.
Les comptes de stockage sont créés avec la version 2 à usage général pour les nouveaux clusters.
Les comptes de stockage v2 à usage général prennent en charge les dernières fonctionnalités du Stockage Azure, et intègrent toutes les fonctionnalités des comptes de stockage v1 à usage général et des comptes de stockage d’objets blob.
L’accès aux comptes de stockage est limité avec les règles de pare-feu via les groupes de sécurité réseau Azure (NSG), qui filtrent le trafic réseau vers et depuis vos comptes de stockage. Pour plus d’informations, consultez Présentation des groupes de sécurité réseau Azure.
La version 1.2 du protocole Transport Layer Security (TLS) assure la sécurité des communications, la confidentialité des données et leur intégrité.
Les données stockées dans etcd sont-elles chiffrées sur Azure Red Hat OpenShift ?
Les données ne sont pas chiffrées par défaut, mais vous avez la possibilité d’activer le chiffrement. Pour plus d’informations, consultez le guide sur le chiffrement d’etcd.
Est-il possible de choisir une solution de stockage persistant, comme OCS ?
Azure Disk (Premium_LRS) est configuré en tant que classe de stockage par défaut. Pour obtenir des fournisseurs de stockage supplémentaires et pour plus d’informations sur la configuration (notamment Azure Files), consultez la documentation Red Hat sur le stockage persistant.
ARO stocke-t-il des données client en dehors de la région du cluster ?
Non. Toutes les données créées dans un cluster ARO sont conservées dans la région du cluster.