Share via

Considérations relatives à la topologie et à la connectivité réseau pour Azure Red Hat OpenShift

  • Article

Passez en revue les considérations et recommandations relatives à la conception pour la topologie et la connectivité réseau dans le cadre de l’utilisation de l’accélérateur de zone d’atterrissage Azure Red Hat OpenShift.

Remarques relatives à la conception

  • Azure Red Hat OpenShift nécessite un sous-réseau principal et un sous-réseau secondaire.

    • Utilisez le sous-réseau principal pour déployer les nœuds maîtres du cluster.
    • Utilisez le sous-réseau secondaire pour déployer les nœuds Worker du cluster.
    • Le sous-réseau secondaire et le sous-réseau principal doivent tous deux être au moins une route /27.
    • Vous ne pouvez pas modifier le sous-réseau secondaire ou le sous-réseau principal une fois le cluster déployé.
    • Le sous-réseau principal et le sous-réseau secondaire ne peuvent pas être associés à un groupe de sécurité réseau. Le cluster Azure Red Hat OpenShift crée et gère automatiquement un groupe de sécurité réseau.
    • Le sous-réseau secondaire et le sous-réseau principal ne peuvent pas chevaucher les réseaux locaux ou tout autre réseau dans Azure.

  • Planifiez soigneusement les adresses IP et la taille du sous-réseau du réseau virtuel pour prendre en charge la mise à l’échelle du cluster. Vous devrez peut-être ajouter des nœuds.

  • Vous pouvez exposer des services et des routes Azure Red Hat OpenShift en utilisant des équilibreurs de charge publics ou internes. Configurez des équilibreurs de charge internes dans le même sous-réseau que les nœuds secondaires. Dans un cluster de sortie restreint, vous ne pouvez pas utiliser d’équilibreurs de charge publics en raison du routage asymétrique.

  • Azure Red Hat OpenShift utilise CoreDNS pour fournir la résolution de noms aux pods en cours d’exécution dans le cluster.

    • CoreDNS résout directement les domaines internes au cluster.
    • Azure Red Hat OpenShift prend également en charge les serveurs DNS personnalisés dans le réseau virtuel.
    • Les autres domaines sont transférés aux serveurs DNS que vous configurez dans Réseau virtuel Azure. Les serveurs DNS sont soit le programme de résolution Azure DNS par défaut, soit tout serveur DNS personnalisé que vous configurez au niveau du réseau virtuel.
    • Vous pouvez personnaliser le transfert DNS dans Azure Red Hat OpenShift CoreDNS.
    • Si aucun serveur DNS personnalisé n’est configuré dans le réseau virtuel, Azure Red Hat OpenShift utilise le programme de résolution Azure DNS par défaut.

    Pour plus d’informations sur DNS, consultez Configuration DNS des points de terminaison privés Azure.

  • Vous pouvez envoyer le trafic réseau sortant (« sortie ») par le biais du Pare-feu Azure ou d’un cluster d’appliances virtuelles réseau.

  • Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans limitations. Tous les pods d’un projet sont accessibles à partir d’autres pods et points de terminaison réseau. Pour isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy dans le projet pour indiquer les connexions entrantes autorisées. Red Hat OpenShift SDN (Software-Defined Networking) prend en charge l’utilisation d’une stratégie réseau dans son mode d’isolation réseau par défaut.

  • Un maillage de services offre des fonctionnalités axées sur les aspects suivants : gestion du trafic, résilience, stratégie, sécurité, identité forte et observabilité. Pour plus d’informations sur Red Hat OpenShift Service Mesh, consultez Différences entre Service Mesh et Istio.

  • Les mécanismes d’équilibrage de charge global, comme Azure Traffic Manager et Azure Front Door, augmentent la résilience en acheminant le trafic sur plusieurs clusters, éventuellement dans différentes régions Azure.

Clusters privés

Une adresse IP de cluster d’API Azure Red Hat OpenShift peut être publique ou privée. Les clusters privés exposent l’API Azure Red Hat OpenShift sur une adresse IP privée, mais pas sur une adresse publique. Vous ne devez pas accéder à l’API Azure Red Hat OpenShift par le biais de son adresse IP. Au lieu de cela, accédez à l’API Azure Red Hat OpenShift par le biais de son nom de domaine complet (FQDN). Azure DNS fait correspondre le FQDN de l’API Azure Red Hat OpenShift à son adresse IP.

Conformément aux pratiques éprouvées concernant la zone d’atterrissage Azure, la résolution DNS pour les charges de travail Azure est proposée par des serveurs DNS centralisés qui sont déployés dans l’abonnement de connectivité. Les serveurs Azure DNS se trouvent soit dans un réseau virtuel hub, soit dans un réseau virtuel de services partagés connecté à une instance d’Azure Virtual WAN. Les serveurs DNS résolvent conditionnellement les noms spécifiques à Azure et publics avec Azure DNS (adresse IP 168.63.129.16). Les serveurs résolvent les noms privés en utilisant les serveurs DNS d’entreprise. Ce modèle de connectivité est courant, et il est important d’autoriser l’accès privé à d’autres ressources Azure si vous utilisez des points de terminaison privés.

Diagram that shows a network for a private cluster.

Trafic des utilisateurs d’applications vers le cluster

Utilisez des contrôleurs entrants (« entrée ») pour exposer les applications s’exécutant dans les clusters Azure Red Hat OpenShift.

  • Les contrôleurs d’entrée fournissent un routage au niveau de l’application avec pour seul inconvénient une légère augmentation de la complexité.
  • Azure Red Hat OpenShift crée une entrée DNS générique qui simplifie l’accès aux applications exposées dans le cluster. Un exemple d’entrée DNS est *.apps.<cluster-ID>.<region>.aroapp.io. Elle permet à un cluster privé d’acheminer le trafic pour l’application.
  • Azure Red Hat OpenShift offre un contrôleur d’entrée intégré et des routes.
  • Vous pouvez utiliser l’entrée Azure Red Hat OpenShift avec Azure Front Door.
  • Alignez votre configuration avec la conception du filtrage de sortie pour éviter le routage asymétrique. Les UDR peuvent provoquer un routage asymétrique.
  • Si votre scénario nécessite une terminaison TLS, envisagez de gérer les certificats TLS.

Important

Si vous utilisez le Pare-feu Azure pour restreindre le trafic de sortie et créez une UDR pour forcer tout le trafic de sortie, veillez à créer une règle DNAT (Destination Network Address Translation) appropriée dans le Pare-feu Azure pour autoriser correctement le trafic d’entrée. L’utilisation du Pare-feu Azure avec une UDR perturbe la configuration d’entrée en raison d’un routage asymétrique Le problème se produit si le sous-réseau Azure Red Hat OpenShift a une route par défaut qui conduit à l’adresse IP privée du pare-feu alors que vous utilisez un équilibreur de charge public (service d’entrée ou Kubernetes de type Load Balancer). Dans ce cas, le trafic d’équilibreur de charge entrant est reçu par le biais de son adresse IP publique, mais le chemin de retour passe par l’adresse IP privée du pare-feu. Le pare-feu étant avec état, il supprime le paquet de retour dans la mesure où le pare-feu ne détecte pas de session établie. Pour découvrir comment intégrer un Pare-feu Azure avec votre équilibreur de charge d’entrée ou de service, voir Intégrer un pare-feu Azure avec Azure Standard Load Balancer.

Les étapes suivantes décrivent le flux si vous utilisez Azure Front Door avec un contrôleur d’entrée et un cluster privé Azure Red Hat OpenShift :

  1. Les clients de l’Internet public résolvent le nom DNS de l’application qui pointe vers Azure Front Door.
  2. Azure Front Door utilise le service Azure Private Link pour accéder à l’adresse IP privée de l’équilibreur de charge du réseau interne Azure et accéder à une application dans le contrôleur d’entrée Azure Red Hat OpenShift.

Ces étapes décrivent le flux d’une application non-web qui accède à un cluster privé Azure Red Hat OpenShift :

  1. Les clients de l’Internet public résolvent le nom DNS de l’application qui pointe vers l’adresse IP publique du Pare-feu Azure ou d’une appliance virtuelle réseau.
  2. Le Pare-feu Azure ou l’appliance virtuelle réseau transfère le trafic (DNAT) au cluster privé Azure Red Hat OpenShift en utilisant l’adresse IP privée de l’équilibreur de charge du réseau interne Azure pour accéder à l’application dans le contrôleur d’entrée Azure Red Hat OpenShift.

Trafic des pods Azure Red Hat OpenShift vers les services back-end

Les pods s’exécutant à l’intérieur du cluster Azure Red Hat OpenShift peuvent avoir besoin d’accéder aux services back-end comme Stockage Azure, Azure Key Vault, Azure SQL Database et Azure Cosmos DB. Vous pouvez utiliser des points de terminaison de service de réseau virtuel et Azure Private Link pour sécuriser la connectivité à ces services gérés par Azure.

Si vous utilisez des points de terminaison privés Azure pour le trafic back-end, vous pouvez utiliser Azure DNS Private Zones pour la résolution DNS des services Azure. Dans la mesure où les programmes de résolution DNS pour l’ensemble de l’environnement se trouvent dans le réseau virtuel hub (ou dans le réseau virtuel de services partagés si vous utilisez le modèle de connectivité Virtual WAN), créez ces zones privées dans l’abonnement de connectivité. Pour créer l’enregistrement A nécessaire pour résoudre le FQDN du service privé, vous pouvez associer la zone DNS privée dans l’abonnement à la connectivité au point de terminaison privé dans l’abonnement de l’application. Cette opération nécessite des autorisations spécifiques dans ces abonnements.

Vous pouvez créer manuellement les enregistrements A, mais l’association de la zone DNS privée au point de terminaison privé produit une configuration moins sujette aux erreurs.

La connectivité back-end des pods Azure Red Hat OpenShift aux services PaaS (Platform as a Service) Azure exposés par le biais de points de terminaison privés suit cette séquence :

  1. Les pods Azure Red Hat OpenShift résolvent le nom de domaine complet d’Azure PaaS en utilisant les serveurs DNS centraux dans l’abonnement de connectivité, qui sont définis come des serveurs DNS personnalisés dans le réseau virtuel Azure Red Hat OpenShift.
  2. L’adresse IP résolue est l’adresse IP privée des points de terminaison privés, qui sont accessibles directement à partir des pods Azure Red Hat OpenShift.

Par défaut, le trafic entre les pods Azure Red Hat OpenShift et les points de terminaison privés ne passe pas par l’instance du Pare-feu Azure dans le réseau virtuel hub (ou le hub virtuel sécurisé, si vous utilisez un WAN virtuel), même si le cluster Azure Red Hat OpenShift est configuré pour le filtrage de sortie avec le Pare-feu Azure. Le point de terminaison privé crée une route /32 dans les sous-réseaux du réseau virtuel d’application dans lequel Azure Red Hat OpenShift est déployé.

Recommandations de conception

  • Si votre stratégie de sécurité vous oblige à utiliser une adresse IP privée pour l’API Azure Red Hat OpenShift, déployez un cluster Azure Red Hat OpenShift privé.
  • Utilisez Azure DDoS Protection afin de protéger le réseau virtuel que vous utilisez pour le cluster Azure Red Hat OpenShift, sauf si vous utilisez le Pare-feu Azure ou le pare-feu d’applications web dans un abonnement centralisé.
  • Utilisez la configuration DNS liée à la configuration réseau globale avec Azure Virtual WAN ou une architecture hub-and-spoke, des zones Azure DNS et votre propre infrastructure DNS.
  • Utilisez Azure Private Link pour sécuriser les connexions réseau et une connectivité IP privée aux autres services Azure managés qui prennent en charge Private Link, comme Stockage Azure, Azure Container Registry, Azure SQL Database et Azure Key Vault.
  • Utilisez un contrôleur d’entrée pour fournir une sécurité et un routage HTTP avancés et offrir un point de terminaison unique pour les applications.
  • Toutes les applications web que vous configurez pour utiliser une entrée doivent s’appuyer sur le chiffrement TLS et interdire l’accès par le biais du protocole HTTP non chiffré.
  • Utilisez Azure Front Door avec Web Application Firewall pour publier de manière sécurisée des applications Azure Red Hat OpenShift sur Internet.
  • Si votre stratégie de sécurité vous oblige à inspecter tout le trafic Internet sortant généré dans le cluster Azure Red Hat OpenShift, sécurisez le trafic réseau de sortie avec le Pare-feu Azure ou une appliance virtuelle réseau tierce déployée dans le réseau virtuel hub managé. Pour plus d’informations, consultez Contrôler le trafic de sortie vers un cluster Azure Red Hat OpenShift.
  • Utilisez le niveau Azure Load Balancer Standard au lieu du niveau De base pour les applications non-web.

Étapes suivantes