Partager via

Conseils sur la base de référence des opérations pour Azure Red Hat OpenShift

  • Article

Azure Red Hat OpenShift fournit des clusters OpenShift hautement scalables et complètement managés à la demande. En concevant correctement votre solution sans négliger la gestion et le monitoring, vous pouvez œuvrer à l’excellence opérationnelle et à la réussite des clients.

Remarques relatives à la conception

Tenez compte des facteurs suivants :

  • Passez en revue la matrice de responsabilités d’Azure Red Hat OpenShift pour comprendre comment les responsabilités des clusters sont partagées entre Microsoft, Red Hat et les clients.
  • Tenez compte des limites des machines virtuelles Azure et des régions prises en charge. Veillez à disposer de suffisamment de capacité pour déployer des ressources.
  • Tenez compte des moyens d’isoler les charges de travail de manière logique dans un cluster et physiquement dans des clusters distincts.
  • Tenez compte des moyens d’aider Kubernetes à comprendre l’intégrité de vos charges de travail.
  • Tenez compte des différentes tailles de machines virtuelles et de l’effet de l’utilisation de chacune d’elles.
  • Sachez comment monitorer et journaliser Azure Red Hat OpenShift pour obtenir des insights sur l’intégrité de vos ressources et pour prévoir des problèmes potentiels. Le cluster et les applications qui s’exécutent dessus peuvent générer de nombreux événements. Utilisez des alertes pour vous aider à faire la différence entre les entrées de journal à des fins historiques et les entrées nécessitant une action immédiate.
  • Tenez compte des mises à jour et des mises à niveau système importantes. Les mises à jour correctives critiques sont appliquées automatiquement aux clusters par les ingénieurs SRE (Site Reliability Engineers) d’Azure Red Hat OpenShift. Les clients qui le souhaitent sont libres d’installer des mises à jour correctives à l’avance.
  • Tenez compte des limitations de ressources du cluster et des charges de travail individuelles.
  • Tenez compte des différences entre l’outil de mise à l’échelle automatique horizontale des pods (HPA) et la mise à l’échelle automatique des clusters.
  • Passez en revue le cycle de vie du support et prenez connaissance de la stratégie de prise en charge des versions. Azure Red Hat OpenShift prend uniquement en charge les versions mineures actuelle et précédente en disponibilité générale de Red Hat OpenShift Container Platform. Les demandes de support nécessitent que le cluster se trouve dans une version prise en charge.
  • Passez en revue les exigences de configuration du cluster pour maintenir la prise en charge du cluster.
  • Examinez le réseau entre espaces de noms pour sécuriser le trafic au sein du cluster avec une stratégie réseau.

Recommandations de conception

  • Azure Red Hat OpenShift possède un riche écosystème d’opérateurs que vous pouvez utiliser pour exécuter et automatiser les activités opérationnelles avec efficacité et précision.
  • Ajoutez des sondes d’intégrité à vos pods pour monitorer l’intégrité des applications. Vérifiez que les pods contiennent livenessProbe et readinessProbe. Utilisez des sondes de démarrage pour déterminer le point où l’application a démarré.
  • Utilisez des tailles de machines virtuelles suffisamment grandes pour contenir plusieurs instances de conteneurs afin de bénéficier des avantages d’une densité accrue, mais pas trop importantes car votre cluster ne pourra pas gérer la charge de travail d’un nœud défaillant.
  • Réglementez les fonctions du cluster avec des plug-ins d’admission, qui sont couramment utilisés pour appliquer la stratégie de sécurité, les limitations des ressources ou les exigences de configuration.
  • Utilisez des demandes et des limites de pods pour gérer les ressources de calcul au sein d’un cluster. Les demandes et les limites de pods informent le planificateur Kubernetes, qui affecte des ressources de calcul à un pod. Limitez la consommation de ressources dans un projet en utilisant des plages de limites.
  • Optimisez les valeurs de demande de processeur et de mémoire, et maximisez l’efficacité des ressources de cluster avec l’outil de mise à l’échelle automatique verticale des pods (VPA).
  • La console Web OpenShift contient toutes les métriques au niveau du nœud. Établissez un processus de monitoring en utilisant l’intégration à Prometheus ou Container Insights.
    • Prometheus est préinstallé et configuré pour les clusters Azure Red Hat OpenShift 4.x.
    • Vous pouvez activer Container Insights en intégrant le cluster à Kubernetes avec Azure Arc.
    • La journalisation OpenShift déploie des agrégateurs de journaux, le stockage et des composants de visualisation.
  • Automatisez le processus de livraison d’applications par le biais de pratiques DevOps et de solutions CI/CD comme Pipelines/GitOps fournies par OpenShift Container Platform.
  • Définissez ClusterAutoScaler et MachineAutoScaler pour mettre à l’échelle les machines quand votre cluster manque de ressources pour prendre en charge davantage de déploiements.
  • Déployez des contrôles d’intégrité pour réparer automatiquement les machines endommagées dans un pool de machines.
  • Mettez à l’échelle les pods pour répondre à la demande avec l’outil de mise à l’échelle automatique horizontale des pods (HPA).
  • Utilisez un système d’alerte pour fournir des notifications quand des actions directes sont nécessaires : alertes de métrique Container Insights ou interface utilisateur d’alerte intégrée.

Continuité d’activité et récupération d’urgence (BCDR)

Votre organisation doit concevoir des fonctionnalités de niveau plateforme Azure Red Hat OpenShift appropriées pour répondre à ses besoins spécifiques. Ces services d’application ont des exigences relatives à l’objectif de délai de récupération (RTO) et à l’objectif de point de récupération (RPO). Il y a de nombreux aspects à prendre en compte pour la reprise d’activité après sinistre. La première étape consiste à définir un contrat de niveau de service (SLA) pour votre infrastructure et votre application. Découvrez le contrat SLA pour Azure Red Hat OpenShift. Consultez la section Détails du contrat de niveau de service pour plus d’informations sur les calculs de temps d’activité mensuels.

Considérations relatives à la conception pour BCDR

Tenez compte des facteurs suivants :

  • Le cluster Azure Red Hat OpenShift doit utiliser plusieurs groupes de machines afin de fournir le niveau minimal de disponibilité pour votre application.
  • Définissez des requêtes et limites de ressources. La définition de ces limites permet à Kubernetes de :
    • Affecter efficacement des ressources de processeur et de mémoire aux pods.
    • Avoir une densité de conteneurs supérieure sur un nœud.
    • Accroître la fiabilité en réduisant les coûts moyennant une meilleure utilisation du matériel.
  • Répartir les nœuds entre toutes les zones disponibles pour une disponibilité plus élevée.
    • Choisissez une région qui prend en charge les zones de disponibilité.
    • Pour bénéficier d’une offre zonale complète, toutes les dépendances de service doivent également prendre en charge les zones. Si un service dépendant ne prend pas en charge les zones, une défaillance de zone peut entraîner un échec du service. Passez en revue les types de disques utilisés lors de la répartition de la charge de travail entre les zones.
    • Pour bénéficier d’une disponibilité supérieure à celle des zones de disponibilité, exécutez plusieurs clusters dans différentes régions jumelées. Si une ressource Azure prend en charge la géoredondance, indiquez l’emplacement de la région secondaire du service redondant.
  • Créez systématiquement des sauvegardes pour les applications et les données.
    • Un service sans état peut être répliqué efficacement.
    • S’il vous faut stocker l’état dans le cluster, sauvegardez fréquemment les données dans la région jumelée.
  • Mettez à niveau et gérez vos clusters.
  • Pour la connectivité réseau en cas de basculement :
    • S’il vous faut répartir le trafic entre les régions, envisagez d’utiliser Azure Front Door.
  • Pour les basculements planifiés et non planifiés :
    • Lors de la configuration de chaque service Azure, choisissez des fonctionnalités qui prennent en charge la récupération d’urgence. Par exemple, si Azure Container Registry est choisi, activez-le pour la géoréplication. En cas de défaillance d’une région, vous pouvez toujours extraire des images depuis la région répliquée.
  • Tenez à jour les fonctionnalités d’ingénierie DevOps pour atteindre les objectifs de niveau de service.

Recommandations relatives à la conception pour BCDR

Voici les meilleures pratiques pour votre conception :

  • Les clusters Azure Red Hat OpenShift sont provisionnés avec trois nœuds de plan de contrôle et trois nœuds Worker ou plus. Vérifiez que le cluster est créé dans une région qui prend en charge les zones de disponibilité afin que les nœuds soient répartis entre les zones.
  • Pour bénéficier d’une haute disponibilité, déployez ces nœuds dans différentes zones de disponibilité. Étant donné que vous avez besoin de différents groupes de machines pour chaque zone de disponibilité, créez au moins trois groupes de machines.
  • 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.
  • Créez des groupes de machines d’infrastructure pour contenir les composants d’infrastructure. Appliquez des étiquettes Kubernetes spécifiques à ces machines, puis mettez à jour les composants d’infrastructure pour qu’ils s’exécutent uniquement sur ces machines.
  • Dans la mesure du possible, supprimez l’état du service à l’intérieur des conteneurs. Au lieu de cela, utilisez une plateforme Azure en tant que service (PaaS) qui prend en charge la réplication multirégion.
  • Les déploiements doivent spécifier les exigences en matière de ressources de pod. Le planificateur peut ensuite planifier comme il se doit le pod. La fiabilité est considérablement amoindrie lorsque les pods ne sont pas planifiés.
  • Au sein du déploiement, configurez plusieurs réplicas afin de gérer les interruptions, telles que les défaillances matérielles. Pour les événements planifiés tels que les mises à jour et les mises à niveau, un budget d’interruption permet de s’assurer de la présence du nombre de réplicas de pods requis pour gérer la charge d’application attendue.
  • Utilisez des contraintes de topologie de pod pour planifier automatiquement des pods sur les nœuds dans tout le cluster.
  • Vos applications peuvent utiliser le stockage pour leurs données et doivent garantir la disponibilité dans toutes les régions si nécessaire :
  • Créez une sauvegarde d’application et planifiez la restauration :
  • Estimez les limites des ressources de pod. Testez et établissez une ligne de base. Dans un premier temps, utilisez des valeurs similaires pour les demandes et les limites. Ajustez ensuite progressivement ces valeurs jusqu’à établir un seuil susceptible de provoquer une instabilité dans le cluster. Les limites de pod peuvent être spécifiées dans vos manifestes de déploiement. L’outil de mise à l’échelle automatique verticale des pods (VPA) optimise les valeurs de demande de processeur et de mémoire et peut maximiser l’efficacité des ressources de cluster.
    • Les fonctionnalités intégrées peuvent gérer les défaillances et les interruptions dans l’architecture du service. Ces configurations permettent de simplifier la conception et l’automatisation du déploiement. Quand une organisation définit une norme pour le SLA, le RTO et le RPO, elle peut utiliser des services intégrés à Kubernetes et Azure pour atteindre ses objectifs métier.
  • Envisagez de mettre en place des stratégies « blue/green » ou « canary » pour déployer les nouvelles versions d’une application.
  • Définissez la priorité des pods/des budgets d’interruption des pods pour limiter le nombre de réplicas de pod que le cluster est autorisé à mettre hors service dans le cadre d’opérations de maintenance, garantissant ainsi la disponibilité.
  • Appliquez des quotas de ressources sur les espaces de noms de service. Le quota de ressources sur un espace de noms permet de s’assurer que les requêtes et les limites de pod sont correctement définies sur un déploiement.
    • La définition de quotas de ressources au niveau du cluster peut provoquer un problème lors du déploiement de services partenaires ne disposant pas de demandes ou limites appropriées.
  • Stockez vos images conteneur dans Azure Container Registry et géorépliquez le registre dans chaque région.
  • Utilisez plusieurs régions et emplacements de Peering pour la connectivité Azure ExpressRoute. Si une panne affectant une région Azure ou un emplacement de fournisseur de peering se produit, une architecture réseau hybride redondante peut contribuer à garantir la continuité de la connectivité intersite.
  • Interconnecter des régions avec l’appairage de réseaux virtuels mondiaux. Si les clusters doivent communiquer entre eux, il est possible de connecter les deux réseaux virtuels entre eux via l’appairage de réseau virtuel. Cette technologie interconnecte les réseaux virtuels entre eux pour fournir une bande passante élevée à travers le réseau principal de Microsoft, même entre différentes régions géographiques.
  • Utilisez le protocole anycast basé sur Split TCP, Azure Front Door, pour connecter rapidement vos utilisateurs finaux au point de présence (POP) Front Door le plus proche. Voici d’autres fonctionnalités d’Azure Front Door :
    • Arrêt TLS
    • Domaine personnalisé
    • Pare-feu d’applications web
    • Réécrire URL
    • Affinité de session

Étapes suivantes

Découvrez-en plus sur les considérations et recommandations relatives à la conception pour l’automatisation de plateforme et DevOps dans vos zones d’atterrissage Azure.