WordPress sur Azure Kubernetes Service

Azure Redis géré

Azure Front Door

Azure Kubernetes Service (AKS)

Équilibrage de charge Azure

Azure NetApp Files

Cet article décrit une solution de conteneur qui héberge une installation volumineuse et intensive du stockage de WordPress sur Azure. La solution optimise la scalabilité et la sécurité. Les composants clés incluent Azure Front Door, Azure Kubernetes Service (AKS) et Azure NetApp Files.

Architecture

Le diagramme montre une architecture de déploiement WordPress dans Microsoft Azure, organisée à l’intérieur d’un réseau virtuel décrit par une bordure en pointillés. Sur la gauche, l’Internet public se connecte à Azure Front Door, qui inclut le pare-feu d’applications web Azure. Azure Front Door achemine le trafic vers un équilibreur de charge interne, qui distribue les requêtes entrantes aux composants à l’intérieur du réseau virtuel. Au sein du réseau, plusieurs sous-réseaux sont protégés par des groupes de sécurité réseau (NSG). Le composant central est AKS. Le trafic transite par un contrôleur d’entrée dans les pods WordPress. Ces pods accèdent aux secrets via une interface CSI (Container Storage Interface) connectée à un magasin sécurisé. Un autre sous-réseau contient Azure NetApp Files et est protégé par son propre groupe de sécurité réseau. Sur le côté droit, quatre services se connectent au réseau virtuel via des points de terminaison privés : Azure Container Registry, Azure Key Vault, Azure Database pour MySQL – Serveur flexible et Cache Azure pour Redis. Chaque service communique en toute sécurité au sein du réseau sans exposition directe à Internet.

Téléchargez un fichier Visio de cette architecture.

Notes

Vous pouvez étendre cette solution en implémentant des conseils et des recommandations qui s’appliquent à n’importe quelle méthode d’hébergement WordPress. Pour obtenir des conseils généraux sur le déploiement d’une installation WordPress, consultez WordPress sur Azure.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. Les utilisateurs accèdent au front-end du site web via Azure Front Door avec Azure Web Application Firewall activé.

2. Azure Front Door utilise une instance interne de Azure Load Balancer comme origine. L’équilibreur de charge interne est un composant masqué d’AKS. Azure Front Door récupère toutes les données qui ne sont pas mises en cache.

3. L’équilibreur de charge interne distribue le trafic d’entrée aux pods au sein d’AKS.

4. Azure Key Vault stocke les secrets, y compris la clé privée, qui est un certificat X.509.

5. L’application WordPress utilise un point de terminaison privé pour accéder à une instance de serveur flexible d’Azure Database pour MySQL. L’application WordPress récupère des informations dynamiques dans la base de données.

6. Tout le contenu statique est hébergé dans Azure NetApp Files. La solution utilise le pilote Astra Trident Container Storage Interface (CSI) avec le protocole NFS (Network File System).

Composants

• AKS est un service Kubernetes managé que vous pouvez utiliser pour déployer, gérer et mettre à l’échelle des applications conteneurisées. Dans cette architecture, AKS héberge les conteneurs WordPress et fournit la plateforme d’orchestration qui exécute l’application WordPress conteneurisée pour garantir la haute disponibilité et l’extensibilité.

• Azure Cache pour Redis est un magasin de données en mémoire managé et un service de mise en cache. Dans cette architecture, Azure Cache pour Redis héberge un cache clé-valeur que partagent tous les pods. Les plug-ins d’optimisation des performances WordPress utilisent le cache pour améliorer les temps de réponse.

• Azure Database pour MySQL - Serveur flexible est un service de base de données relationnelle managé basé sur le moteur de base de données MySQL open source. Dans cette architecture, cette base de données stocke les données WordPress.

• Azure DDoS Protection est un service de sécurité réseau qui fournit des fonctionnalités d’atténuation de déni de service distribué (DDoS) améliorées. Dans cette architecture, la protection DDoS permet de se défendre contre les attaques DDoS lorsqu’elles sont combinées avec les meilleures pratiques de conception d’application et activées sur le réseau de périmètre.

• Azure Front Door est un réseau de distribution de contenu cloud moderne et un équilibreur de charge global. Dans cette architecture, Azure Front Door est le point d’entrée public dans le déploiement WordPress.

• Azure NetApp Files est une solution de stockage gérée, gourmande en performances et sensible à la latence. Dans cette architecture, Azure NetApp Files héberge le contenu WordPress afin que tous les pods aient accès aux données partagées via le stockage de fichiers hautes performances.

• Le réseau virtuel Azure est un service réseau qui permet aux ressources déployées de communiquer entre elles, internet et réseaux locaux. Dans cette architecture, les réseaux virtuels fournissent une isolation et une segmentation.

• Key Vault est un service cloud qui stocke et contrôle l’accès aux secrets, certificats, clés et mots de passe. Dans cette architecture, Key Vault fournit des secrets au cluster AKS si les pods en ont besoin.

• Load Balancer est un équilibreur de charge de couche 4 qui distribue le trafic entrant en fonction des règles et des résultats de la sonde d’intégrité. Dans cette architecture, l’équilibreur de charge distribue le trafic d’Azure Front Door aux pods du contrôleur d’entrée avec une faible latence et un débit élevé.

• Les groupes de sécurité réseau (NSG) sont des fonctionnalités de sécurité qui utilisent des règles de sécurité pour autoriser ou refuser le trafic réseau entrant ou sortant en fonction de l’adresse IP source ou de destination, du port et du protocole. Dans cette architecture, les règles de groupe de sécurité réseau limitent le flux de trafic entre les composants d’application dans les sous-réseaux.

Autres solutions

• Au lieu d’utiliser le service géré Azure Cache pour Redis, vous pouvez utiliser un pod auto-hébergé au sein d’un cluster AKS comme cache.

• Au lieu d’utiliser une solution de stockage managée comme Azure NetApp Files, vous pouvez utiliser une solution auto-hébergée comme le stockage Rook-Ceph. Pour plus d’informations, consultez Utiliser Rook Ceph sur AKS.

• Au lieu d’utiliser AKS, vous pouvez utiliser Azure Container Apps pour héberger des charges de travail WordPress conteneurisées. Container Apps est un service de conteneur serverless managé qui convient aux scénarios plus simples ou à plus petite échelle. Pour les déploiements volumineux, gourmands en stockage et hautement personnalisables, utilisez AKS.

Détails du scénario

Cet exemple de scénario fonctionne le mieux pour les installations volumineuses et intensives de stockage de WordPress. Ce modèle de déploiement peut être mis à l’échelle pour répondre aux pics de trafic vers le site.

Cas d’usage potentiels

• Les blogs à trafic élevé qui utilisent WordPress comme système de gestion de contenu
• Sites web d’entreprise ou de e-commerce qui utilisent WordPress

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Tenez compte des recommandations suivantes lorsque vous déployez la solution :

• Utilisez des pods dans AKS et un équilibreur de charge pour distribuer le trafic d’entrée. Cette approche offre une haute disponibilité même si une défaillance de pod se produit.

• Placez tous les composants réseau derrière Azure Front Door. Cette approche rend les ressources réseau et l’application résilientes aux problèmes qui peuvent autrement perturber le trafic et affecter l’accès utilisateur.

• Utilisez Azure Front Door pour mettre en cache toutes les réponses pour bénéficier d’un petit avantage de disponibilité. Plus précisément, lorsque l’origine ne répond pas, vous pouvez toujours accéder au contenu. Toutefois, la mise en cache ne fournit pas de solution de disponibilité complète.

• Répliquez le stockage Azure NetApp Files entre les régions jumelées pour augmenter la disponibilité. Pour plus d'informations, consultez Comprendre la réplication dans Azure NetApp Files.

• Suivez les options de haute disponibilité qui répondent à vos besoins pour augmenter la disponibilité d’Azure Database pour MySQL.

• Cette solution prend en charge plusieurs régions, la réplication des données et la mise à l’échelle automatique. Les composants distribuent le trafic vers les pods. Les sondes d’intégrité garantissent que seuls les pods sains reçoivent le trafic.

• Azure Front Door est un service global qui prend en charge les groupes de machines virtuelles identiques déployés dans une autre région.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Tenez compte des meilleures pratiques suivantes lorsque vous déployez la solution :

• Utilisez Web Application Firewall sur Azure Front Door pour protéger le trafic de réseau virtuel qui transite dans la couche front-end de l’application. Pour plus d’informations, consultez Web Application Firewall sur Azure Front Door.

• N’autorisez pas le trafic Internet sortant à transiter depuis la couche de base de données.

• N’autorisez pas l’accès public au stockage privé et désactivez l’accès public aux ressources. Utilisez des points de terminaison privés pour Azure Database pour MySQL, Azure Cache pour Redis, Key Vault et Azure Container Registry. Pour plus d’informations, consultez Azure Private Link.

Pour plus d’informations, consultez les conseils généraux sur la sécurité et les performances de WordPress et la documentation sur la sécurité Azure.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Tenez compte des considérations de coût suivantes lorsque vous déployez la solution :

• Attentes du trafic (Go/mois) : Votre volume de trafic a le plus grand effet sur votre coût. La quantité de trafic que vous recevez détermine le nombre de nœuds AKS requis et le prix du transfert de données sortant. Le volume de trafic correspond également directement à la quantité de données que votre réseau de distribution de contenu fournit, où les coûts de transfert de données sortants sont moins chers.

• Quantité de données hébergées : Tenez compte de la quantité de données que vous hébergez, car la tarification d’Azure NetApp Files est basée sur la capacité réservée. Pour optimiser les coûts, réservez la capacité minimale requise pour vos données.

• Pourcentage d’écriture : Tenez compte de la quantité de nouvelles données que vous écrivez sur votre site web et du coût pour le stocker. Pour les déploiements multirégions, la quantité de nouvelles données que vous écrivez sur votre site web correspond à la quantité de données mises en miroir dans vos régions.

• Contenu statique et dynamique : Surveillez les performances et la capacité de stockage de votre base de données pour déterminer si une référence SKU moins chère peut prendre en charge votre site. La base de données stocke le contenu dynamique et le réseau de distribution de contenu met en cache le contenu statique.

• Optimisation du cluster AKS : Suivez des conseils généraux pour AKS, tels que des conseils sur la taille des machines virtuelles et les réservations Azure, pour optimiser les coûts de votre cluster AKS. Pour plus d’informations, consultez l’optimisation des coûts AKS.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Ce scénario utilise des pods dans AKS pour héberger le front-end. La fonctionnalité de mise à l’échelle automatique permet au nombre de pods qui exécutent le niveau d’application front-end de mettre automatiquement à l’échelle en réponse à la demande du client. Elles peuvent également être mises à l’échelle en fonction d’une planification définie. Pour plus d’informations, consultez options de mise à l’échelle pour les applications dans AKS.

Important

Pour optimiser les performances, montez un volume persistant qui utilise le protocole NFS version 4.1. L’exemple YAML suivant montre comment configurer un PersistentVolume objet à cet effet. Notez la valeur du champ mountOptions.

kind: PersistentVolume
...
    accessModes:
    - ReadWriteMany
    mountOptions:
    - vers=4.1
    nfs:
      server: xx.xx.xx.xx

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Vaclav Jirovsky | Architecte de solutions Cloud

Autre contributeur :

• Adrian Calinescu | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Documentation du produit :

• Vue d’ensemble d’Azure Front Door
• Vue d’ensemble du pare-feu d’applications web
• Vue d’ensemble d’Azure NetApp Files
• Créer un volume NFS pour Azure NetApp Files
• Configurer Azure NetApp Files pour AKS
• Serveurs flexibles Azure Database pour MySQL
• Vue d’ensemble du réseau virtuel
• Vue d’ensemble de Key Vault
• Vue d’ensemble de Load Balancer
• Vue d’ensemble de la protection DDoS

Modules de formation Microsoft :

• Développer et déployer des applications sur Kubernetes
• Présentation d’Azure NetApp Files
• Implémenter Key Vault
• Présentation du réseau virtuel

Ressources associées

• Principes de conception pour les applications Azure
• Applications cloud évolutives et ingénierie de fiabilité du site

Cet article décrit une solution de conteneur qui héberge une installation volumineuse et intensive du stockage de WordPress sur Azure. La solution optimise la scalabilité et la sécurité. Les composants clés incluent Azure Front Door, Azure Kubernetes Service (AKS) et Azure NetApp Files.

Architecture

Le diagramme montre une architecture de déploiement WordPress dans Microsoft Azure, organisée à l’intérieur d’un réseau virtuel décrit par une bordure en pointillés. Sur la gauche, l’Internet public se connecte à Azure Front Door, qui inclut le pare-feu d’applications web Azure. Azure Front Door achemine le trafic vers un équilibreur de charge interne, qui distribue les requêtes entrantes aux composants à l’intérieur du réseau virtuel. Au sein du réseau, plusieurs sous-réseaux sont protégés par des groupes de sécurité réseau (NSG). Le composant central est AKS. Le trafic transite par un contrôleur d’entrée dans les pods WordPress. Ces pods accèdent aux secrets via une interface CSI (Container Storage Interface) connectée à un magasin sécurisé. Un autre sous-réseau contient Azure NetApp Files et est protégé par son propre groupe de sécurité réseau. Sur le côté droit, quatre services se connectent au réseau virtuel via des points de terminaison privés : Azure Container Registry, Azure Key Vault, Azure Database pour MySQL – Serveur flexible et Cache Azure pour Redis. Chaque service communique en toute sécurité au sein du réseau sans exposition directe à Internet.

Téléchargez un fichier Visio de cette architecture.

Notes

Vous pouvez étendre cette solution en implémentant des conseils et des recommandations qui s’appliquent à n’importe quelle méthode d’hébergement WordPress. Pour obtenir des conseils généraux sur le déploiement d’une installation WordPress, consultez WordPress sur Azure.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. Les utilisateurs accèdent au front-end du site web via Azure Front Door avec Azure Web Application Firewall activé.

2. Azure Front Door utilise une instance interne de Azure Load Balancer comme origine. L’équilibreur de charge interne est un composant masqué d’AKS. Azure Front Door récupère toutes les données qui ne sont pas mises en cache.

3. L’équilibreur de charge interne distribue le trafic d’entrée aux pods au sein d’AKS.

4. Azure Key Vault stocke les secrets, y compris la clé privée, qui est un certificat X.509.

5. L’application WordPress utilise un point de terminaison privé pour accéder à une instance de serveur flexible d’Azure Database pour MySQL. L’application WordPress récupère des informations dynamiques dans la base de données.

6. Tout le contenu statique est hébergé dans Azure NetApp Files. La solution utilise le pilote Astra Trident Container Storage Interface (CSI) avec le protocole NFS (Network File System).

Composants

• AKS est un service Kubernetes managé que vous pouvez utiliser pour déployer, gérer et mettre à l’échelle des applications conteneurisées. Dans cette architecture, AKS héberge les conteneurs WordPress et fournit la plateforme d’orchestration qui exécute l’application WordPress conteneurisée pour garantir la haute disponibilité et l’extensibilité.

• Azure Cache pour Redis est un magasin de données en mémoire managé et un service de mise en cache. Dans cette architecture, Azure Cache pour Redis héberge un cache clé-valeur que partagent tous les pods. Les plug-ins d’optimisation des performances WordPress utilisent le cache pour améliorer les temps de réponse.

• Azure Database pour MySQL - Serveur flexible est un service de base de données relationnelle managé basé sur le moteur de base de données MySQL open source. Dans cette architecture, cette base de données stocke les données WordPress.

• Azure DDoS Protection est un service de sécurité réseau qui fournit des fonctionnalités d’atténuation de déni de service distribué (DDoS) améliorées. Dans cette architecture, la protection DDoS permet de se défendre contre les attaques DDoS lorsqu’elles sont combinées avec les meilleures pratiques de conception d’application et activées sur le réseau de périmètre.

• Azure Front Door est un réseau de distribution de contenu cloud moderne et un équilibreur de charge global. Dans cette architecture, Azure Front Door est le point d’entrée public dans le déploiement WordPress.

• Azure NetApp Files est une solution de stockage gérée, gourmande en performances et sensible à la latence. Dans cette architecture, Azure NetApp Files héberge le contenu WordPress afin que tous les pods aient accès aux données partagées via le stockage de fichiers hautes performances.

• Le réseau virtuel Azure est un service réseau qui permet aux ressources déployées de communiquer entre elles, internet et réseaux locaux. Dans cette architecture, les réseaux virtuels fournissent une isolation et une segmentation.

• Key Vault est un service cloud qui stocke et contrôle l’accès aux secrets, certificats, clés et mots de passe. Dans cette architecture, Key Vault fournit des secrets au cluster AKS si les pods en ont besoin.

• Load Balancer est un équilibreur de charge de couche 4 qui distribue le trafic entrant en fonction des règles et des résultats de la sonde d’intégrité. Dans cette architecture, l’équilibreur de charge distribue le trafic d’Azure Front Door aux pods du contrôleur d’entrée avec une faible latence et un débit élevé.

• Les groupes de sécurité réseau (NSG) sont des fonctionnalités de sécurité qui utilisent des règles de sécurité pour autoriser ou refuser le trafic réseau entrant ou sortant en fonction de l’adresse IP source ou de destination, du port et du protocole. Dans cette architecture, les règles de groupe de sécurité réseau limitent le flux de trafic entre les composants d’application dans les sous-réseaux.

Autres solutions

• Au lieu d’utiliser le service géré Azure Cache pour Redis, vous pouvez utiliser un pod auto-hébergé au sein d’un cluster AKS comme cache.

• Au lieu d’utiliser une solution de stockage managée comme Azure NetApp Files, vous pouvez utiliser une solution auto-hébergée comme le stockage Rook-Ceph. Pour plus d’informations, consultez Utiliser Rook Ceph sur AKS.

• Au lieu d’utiliser AKS, vous pouvez utiliser Azure Container Apps pour héberger des charges de travail WordPress conteneurisées. Container Apps est un service de conteneur serverless managé qui convient aux scénarios plus simples ou à plus petite échelle. Pour les déploiements volumineux, gourmands en stockage et hautement personnalisables, utilisez AKS.

Détails du scénario

Cet exemple de scénario fonctionne le mieux pour les installations volumineuses et intensives de stockage de WordPress. Ce modèle de déploiement peut être mis à l’échelle pour répondre aux pics de trafic vers le site.

Cas d’usage potentiels

• Les blogs à trafic élevé qui utilisent WordPress comme système de gestion de contenu
• Sites web d’entreprise ou de e-commerce qui utilisent WordPress

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Tenez compte des recommandations suivantes lorsque vous déployez la solution :

• Utilisez des pods dans AKS et un équilibreur de charge pour distribuer le trafic d’entrée. Cette approche offre une haute disponibilité même si une défaillance de pod se produit.

• Placez tous les composants réseau derrière Azure Front Door. Cette approche rend les ressources réseau et l’application résilientes aux problèmes qui peuvent autrement perturber le trafic et affecter l’accès utilisateur.

• Utilisez Azure Front Door pour mettre en cache toutes les réponses pour bénéficier d’un petit avantage de disponibilité. Plus précisément, lorsque l’origine ne répond pas, vous pouvez toujours accéder au contenu. Toutefois, la mise en cache ne fournit pas de solution de disponibilité complète.

• Répliquez le stockage Azure NetApp Files entre les régions jumelées pour augmenter la disponibilité. Pour plus d'informations, consultez Comprendre la réplication dans Azure NetApp Files.

• Suivez les options de haute disponibilité qui répondent à vos besoins pour augmenter la disponibilité d’Azure Database pour MySQL.

• Cette solution prend en charge plusieurs régions, la réplication des données et la mise à l’échelle automatique. Les composants distribuent le trafic vers les pods. Les sondes d’intégrité garantissent que seuls les pods sains reçoivent le trafic.

• Azure Front Door est un service global qui prend en charge les groupes de machines virtuelles identiques déployés dans une autre région.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Tenez compte des meilleures pratiques suivantes lorsque vous déployez la solution :

• Utilisez Web Application Firewall sur Azure Front Door pour protéger le trafic de réseau virtuel qui transite dans la couche front-end de l’application. Pour plus d’informations, consultez Web Application Firewall sur Azure Front Door.

• N’autorisez pas le trafic Internet sortant à transiter depuis la couche de base de données.

• N’autorisez pas l’accès public au stockage privé et désactivez l’accès public aux ressources. Utilisez des points de terminaison privés pour Azure Database pour MySQL, Azure Cache pour Redis, Key Vault et Azure Container Registry. Pour plus d’informations, consultez Azure Private Link.

Pour plus d’informations, consultez les conseils généraux sur la sécurité et les performances de WordPress et la documentation sur la sécurité Azure.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Tenez compte des considérations de coût suivantes lorsque vous déployez la solution :

• Attentes du trafic (Go/mois) : Votre volume de trafic a le plus grand effet sur votre coût. La quantité de trafic que vous recevez détermine le nombre de nœuds AKS requis et le prix du transfert de données sortant. Le volume de trafic correspond également directement à la quantité de données que votre réseau de distribution de contenu fournit, où les coûts de transfert de données sortants sont moins chers.

• Quantité de données hébergées : Tenez compte de la quantité de données que vous hébergez, car la tarification d’Azure NetApp Files est basée sur la capacité réservée. Pour optimiser les coûts, réservez la capacité minimale requise pour vos données.

• Pourcentage d’écriture : Tenez compte de la quantité de nouvelles données que vous écrivez sur votre site web et du coût pour le stocker. Pour les déploiements multirégions, la quantité de nouvelles données que vous écrivez sur votre site web correspond à la quantité de données mises en miroir dans vos régions.

• Contenu statique et dynamique : Surveillez les performances et la capacité de stockage de votre base de données pour déterminer si une référence SKU moins chère peut prendre en charge votre site. La base de données stocke le contenu dynamique et le réseau de distribution de contenu met en cache le contenu statique.

• Optimisation du cluster AKS : Suivez des conseils généraux pour AKS, tels que des conseils sur la taille des machines virtuelles et les réservations Azure, pour optimiser les coûts de votre cluster AKS. Pour plus d’informations, consultez l’optimisation des coûts AKS.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Ce scénario utilise des pods dans AKS pour héberger le front-end. La fonctionnalité de mise à l’échelle automatique permet au nombre de pods qui exécutent le niveau d’application front-end de mettre automatiquement à l’échelle en réponse à la demande du client. Elles peuvent également être mises à l’échelle en fonction d’une planification définie. Pour plus d’informations, consultez options de mise à l’échelle pour les applications dans AKS.

Important

Pour optimiser les performances, montez un volume persistant qui utilise le protocole NFS version 4.1. L’exemple YAML suivant montre comment configurer un PersistentVolume objet à cet effet. Notez la valeur du champ mountOptions.

kind: PersistentVolume
...
    accessModes:
    - ReadWriteMany
    mountOptions:
    - vers=4.1
    nfs:
      server: xx.xx.xx.xx

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Vaclav Jirovsky | Architecte de solutions Cloud

Autre contributeur :

• Adrian Calinescu | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Documentation du produit :

• Vue d’ensemble d’Azure Front Door
• Vue d’ensemble du pare-feu d’applications web
• Vue d’ensemble d’Azure NetApp Files
• Créer un volume NFS pour Azure NetApp Files
• Configurer Azure NetApp Files pour AKS
• Serveurs flexibles Azure Database pour MySQL
• Vue d’ensemble du réseau virtuel
• Vue d’ensemble de Key Vault
• Vue d’ensemble de Load Balancer
• Vue d’ensemble de la protection DDoS

Modules de formation Microsoft :

• Développer et déployer des applications sur Kubernetes
• Présentation d’Azure NetApp Files
• Implémenter Key Vault
• Présentation du réseau virtuel

Ressources associées

• Principes de conception pour les applications Azure
• Applications cloud évolutives et ingénierie de fiabilité du site