Stratégie de prise en charge d’Azure Red Hat OpenShift 4.0

Article
08/29/2024

Certaines configurations pour les clusters Azure Red Hat OpenShift 4 peuvent affecter la prise en charge de votre cluster. Azure Red Hat OpenShift 4 permet aux administrateurs de clusters d’apporter des modifications aux composants de cluster internes, mais les modifications ne sont pas toutes prises en charge. La stratégie de prise en charge ci-dessous partage les modifications qui enfreignent la stratégie et invalident la prise en charge de Microsoft et Red Hat.

Remarque

Les fonctionnalités marquées Technology Preview dans OpenShift Container Platform ne sont pas prises en charge dans Azure Red Hat OpenShift.

Exigences de configuration de cluster

Compute

Le cluster doit comporter au minimum trois nœuds Worker et trois nœuds Maître.
Ne réduisez pas les nœuds Worker du cluster à la valeur zéro, et ne tentez pas d’arrêter le cluster. La désallocation ou la mise hors tension d’une machine virtuelle dans le groupe de ressources de cluster n’est pas prise en charge.
Ne créez pas plus de 250 nœuds de Worker dans un cluster. Il est possible de créer jusqu’à 250 nœuds dans un cluster. Pour plus d’informations, consultez Configurer plusieurs adresses IP par équilibreur de charge de cluster ARO.
Si vous utilisez des nœuds d’infrastructure, n’exécutez pas de charges de travail non désignées sur celles-ci. Cela pourrait affecter le contrat de niveau de service et la stabilité du cluster. Il est également recommandé de disposer de trois nœuds d’infrastructure, un dans chaque zone de disponibilité. Pour plus d’informations, consultez Déployer des nœuds d’infrastructure dans un cluster Azure Red Hat OpenShift (ARO).
Les nœuds de calcul non RHCOS ne sont pas pris en charge. Par exemple, vous ne pouvez pas utiliser un nœud de calcul RHEL.
N’essayez pas de supprimer, remplacer, ajouter ou modifier un nœud maître. Il s’agit d’une opération au risque élevé qui peut entraîner des problèmes avec etcd, une perte de réseau permanente et une perte d’accès et de facilité de gestion par ARO SRE. Si vous pensez qu’un nœud maître doit être remplacé ou supprimé, contactez le support avant d’apporter des modifications.
Assurez-vous qu’un quota de machines virtuelles suffisant est disponible au cas où les nœuds du plan de contrôle devraient être mis à l’échelle en conservant au moins le double du nombre de processeurs virtuels de votre plan de contrôle actuel.

Opérateurs

Tous les opérateurs de cluster OpenShift doivent rester dans un état managé. La liste des opérateurs de cluster peut être retournée en exécutant oc get clusteroperators.

Gestion des charges de travail

N’ajoutez pas de teintes qui empêchent les composants OpenShift par défaut d’être planifiés.
Pour éviter les interruptions résultant de la maintenance du cluster, les charges de travail en cluster doivent être configurées avec des pratiques de haute disponibilité, y compris, mais sans s’y limiter, l’affinité et à l’anti-affinité de pod, les budgets d’interruption de pod et la mise à l’échelle adéquate.
N’exécutez pas de charges de travail supplémentaires sur les nœuds de plan de contrôle. Bien qu’elles puissent être planifiées sur les nœuds de plan de contrôle, elles entraînent des problèmes supplémentaires d’utilisation et de stabilité des ressources qui peuvent affecter l’ensemble du cluster.
L’exécution de charges de travail personnalisées (y compris les opérateurs installés à partir d’Operator Hub ou d’autres opérateurs fournis par Red Hat) dans les nœuds d’infrastructure n’est pas prise en charge.

Journalisation et supervision

Ne supprimez pas et ne modifiez pas le service Prometheus du cluster par défaut, sauf pour modifier la planification de l’instance Prometheus par défaut.
Ne supprimez pas et ne modifiez pas le Alertmanager svc du cluster par défaut, le récepteur par défaut ou les règles d’alerte par défaut, sauf pour ajouter d’autres récepteurs pour notifier des systèmes externes.
Ne supprimez pas ou ne modifiez pas la journalisation du service Azure Red Hat OpenShift (pods MDSD).

Réseau et sécurité

Le groupe de sécurité réseau fourni par ARO ne peut pas être modifié ni remplacé. Toute tentative de modification ou de remplacement sera annulée.
Toutes les machines virtuelles du cluster doivent disposer d’un accès Internet sortant direct, du moins aux points de terminaison Azure Resource Manager (ARM), et de la journalisation des services (Geneva). Aucune forme de proxy HTTPS n’est prise en charge.
Le service Azure Red Hat OpenShift accède à votre cluster par le biais du service de liaison privée. Ne supprimez pas et ne modifiez pas l’accès au service.
La migration depuis SDN OpenShift vers OVN n’est pas prise en charge.

Gestion de cluster

Ne supprimez pas ou ne modifiez pas le secret d’extraction de cluster « arosvc.azurecr.io ».
Ne créez pas d’objets MachineConfig et ne modifiez pas les objets existants, sauf si cela est explicitement pris en charge dans la documentation Azure Red Hat OpenShift.
Ne créez pas d’objets KubeletConfig et ne modifiez pas les objets existants, sauf si cela est explicitement pris en charge dans la documentation Azure Red Hat OpenShift.
Ne définissez pas d’options unsupportedConfigOverrides. La définition de ces options empêche les mises à niveau de versions mineures.
Ne placez pas de stratégies au sein de votre groupe d’administration ou d’abonnement qui empêchent les SRE d’effectuer une maintenance normale sur le cluster Azure Red Hat OpenShift. Par exemple, n’exigez pas d’identification sur le groupe de ressources du cluster managé par Azure Red Hat OpenShift RP.
Ne contournez pas l’affectation de refus configurée dans le cadre du service et n’effectuez pas de tâches administratives normalement interdites par l’affectation de refus.
OpenShift s’appuie sur la possibilité de baliser automatiquement les ressources Azure. Si vous avez configuré une stratégie de balisage, n’appliquez pas plus de 10 balises définies par l’utilisateur aux ressources du groupe de ressources managé.

Gestion des incidents

Un incident est un événement qui entraîne une dégradation ou une panne des services Azure Red Hat OpenShift. Les incidents sont déclenchés par un membre de l’équipe CEE (engagement et expérience client) par le biais d’un cas de support, directement via le système centralisé de surveillance et d’alerte, ou via un membre de l’équipe d’ingénierie de fiabilité des sites (SRE) ARO.

Selon l’impact sur le service et le client, l’incident est classé en termes de gravité.

Le flux de travail général de la gestion d’un nouvel incident est décrit ci-dessous :

Un premier répondeur SRE est averti d’un nouvel incident et commence une enquête initiale.
Après l’enquête initiale, l’incident est affecté à un responsable d’incident, qui coordonne les efforts de récupération.
Le responsable de l’incident gère toutes les communications et la coordination autour de la récupération, y compris les notifications pertinentes ou les mises à jour des cas de support.
L’incident est récupéré.
L’incident est documenté et une analyse de la cause racine (RCA) est effectuée dans les 5 jours ouvrables suivant l’incident.
Un brouillon RCA est partagé avec le client dans les 7 jours ouvrables suivant l’incident.

Tailles de machine virtuelle prises en charge

Azure Red Hat OpenShift 4 prend en charge les instances de nœuds sur les tailles de machine virtuelle suivantes :

Nœuds de plan de contrôle

Série	Taille	Processeurs virtuels	Mémoire : Gio
Dsv3	Standard_D8s_v3	8	32
Dsv3	Standard_D16s_v3	16	64
Dsv3	Standard_D32s_v3	32	128
Dsv4	Standard_D8s_v4	8	32
Dsv4	Standard_D16s_v4	16	64
Dsv4	Standard_D32s_v4	32	128
Dsv5	Standard_D8s_v5	8	32
Dsv5	Standard_D16s_v5	16	64
Dsv5	Standard_D32s_v5	32	128
Dasv4	Standard_D8as_v4	8	32
Dasv4	Standard_D16as_v4	16	64
Dasv4	Standard_D32as_v4	32	128
Dasv5	Standard_D8as_v5	8	32
Dasv5	Standard_D16as_v5	16	64
Dasv5	Standard_D32as_v5	32	128
Easv4	Standard_E8as_v4	8	64
Easv4	Standard_E16as_v4	16	128
Easv4	Standard_E20as_v4	20	160
Easv4	Standard_E32as_v4	32	256
Easv4	Standard_E48as_v4	48	384
Easv4	Standard_E64as_v4	64	512
Easv4	Standard_E96as_v4	96	672
Easv5	Standard_E8as_v5	8	64
Easv5	Standard_E16as_v5	16	128
Easv5	Standard_E20as_v5	20	160
Easv5	Standard_E32as_v5	32	256
Easv5	Standard_E48as_v5	48	384
Easv5	Standard_E64as_v5	64	512
Easv5	Standard_E96as_v5	96	672
Eisv3	Standard_E64is_v3	64	432
Eis4	Standard_E80is_v4	80	504
Eids4	Standard_E80ids_v4	80	504
Eisv5	Standard_E104is_v5	104	672
Eidsv5	Standard_E104ids_v5	104	672
Esv4	Standard_E8s_v4	8	64
Esv4	Standard_E16s_v4	16	128
Esv4	Standard_E20s_v4	20	160
Esv4	Standard_E32s_v4	32	256
Esv4	Standard_E48s_v4	48	384
Esv4	Standard_E64s_v4	64	504
Esv5	Standard_E8s_v5	8	64
Esv5	Standard_E16s_v5	16	128
Esv5	Standard_E20s_v5	20	160
Esv5	Standard_E32s_v5	32	256
Esv5	Standard_E48s_v5	48	384
Esv5	Standard_E64s_v5	64	512
Esv5	Standard_E96s_v5	96	672
Fsv2	Standard_F72s_v2	72	144
Mms*	Standard_M128ms	128	3892

*Standard_M128ms' ne prend pas en charge le chiffrement sur l’hôte

Nœuds worker

Usage général

Série	Taille	Processeurs virtuels	Mémoire : Gio
Dasv4	Standard_D4as_v4	4	16
Dasv4	Standard_D8as_v4	8	32
Dasv4	Standard_D16as_v4	16	64
Dasv4	Standard_D32as_v4	32	128
Dasv4	Standard_D64as_v4	64	256
Dasv4	Standard_D96as_v4	96	384
Dasv5	Standard_D4as_v5	4	16
Dasv5	Standard_D8as_v5	8	32
Dasv5	Standard_D16as_v5	16	64
Dasv5	Standard_D32as_v5	32	128
Dasv5	Standard_D64as_v5	64	256
Dasv5	Standard_D96as_v5	96	384
Dsv3	Standard_D4s_v3	4	16
Dsv3	Standard_D8s_v3	8	32
Dsv3	Standard_D16s_v3	16	64
Dsv3	Standard_D32s_v3	32	128
Dsv4	Standard_D4s_v4	4	16
Dsv4	Standard_D8s_v4	8	32
Dsv4	Standard_D16s_v4	16	64
Dsv4	Standard_D32s_v4	32	128
Dsv4	Standard_D64s_v4	64	256
Dsv5	Standard_D4s_v5	4	16
Dsv5	Standard_D8s_v5	8	32
Dsv5	Standard_D16s_v5	16	64
Dsv5	Standard_D32s_v5	32	128
Dsv5	Standard_D64s_v5	64	256
Dsv5	Standard_D96s_v5	96	384

Mémoire optimisée

Série	Taille	Processeurs virtuels	Mémoire : Gio
Easv4	Standard_E4as_v4	4	32
Easv4	Standard_E8as_v4	8	64
Easv4	Standard_E16as_v4	16	128
Easv4	Standard_E20as_v4	20	160
Easv4	Standard_E32as_v4	32	256
Easv4	Standard_E48as_v4	48	384
Easv4	Standard_E64as_v4	64	512
Easv4	Standard_E96as_v4	96	672
Easv5	Standard_E8as_v5	8	64
Easv5	Standard_E16as_v5	16	128
Easv5	Standard_E20as_v5	20	160
Easv5	Standard_E32as_v5	32	256
Easv5	Standard_E48as_v5	48	384
Easv5	Standard_E64as_v5	64	512
Easv5	Standard_E96as_v5	96	672
Esv3	Standard_E4s_v3	4	32
Esv3	Standard_E8s_v3	8	64
Esv3	Standard_E16s_v3	16	128
Esv3	Standard_E32s_v3	32	256
Esv4	Standard_E4s_v4	4	32
Esv4	Standard_E8s_v4	8	64
Esv4	Standard_E16s_v4	16	128
Esv4	Standard_E20s_v4	20	160
Esv4	Standard_E32s_v4	32	256
Esv4	Standard_E48s_v4	48	384
Esv4	Standard_E64s_v4	64	504
Esv5	Standard_E4s_v5	4	32
Esv5	Standard_E8s_v5	8	64
Esv5	Standard_E16s_v5	16	128
Esv5	Standard_E20s_v5	20	160
Esv5	Standard_E32s_v5	32	256
Esv5	Standard_E48s_v5	48	384
Esv5	Standard_E64s_v5	64	512
Esv5	Standard_E96s_v5	96	672
Edsv5	Standard_E96ds_v5	96	672
Eisv3	Standard_E64is_v3	64	432
Eis4	Standard_E80is_v4	80	504
Eids4	Standard_E80ids_v4	80	504
Eisv5	Standard_E104is_v5	104	672
Eidsv5	Standard_E104ids_v5	104	672

Optimisé pour le calcul

Série	Taille	Processeurs virtuels	Mémoire : Gio
Fsv2	Standard_F4s_v2	4	8
Fsv2	Standard_F8s_v2	8	16
Fsv2	Standard_F16s_v2	16	32
Fsv2	Standard_F32s_v2	32	64
Fsv2	Standard_F72s_v2	72	144

Mémoire et stockage optimisé

Série	Taille	Processeurs virtuels	Mémoire : Gio
Mms*	Standard_M128ms	128	3892