Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans ce guide, vous allez déployer un cluster PostgreSQL hautement disponible qui couvre plusieurs zones de disponibilité Azure sur AKS avec Azure CLI.
Cet article s’attarde sur les prérequis applicables à la configuration d’un cluster PostgreSQL sur Azure Kubernetes Service (AKS) et offre une vue d’ensemble du processus de déploiement complet et de l’architecture.
Important
Les logiciels open source sont mentionnés dans la documentation et les exemples AKS. Les logiciels que vous déployez sont exclus des contrats de niveau de service AKS, de la garantie limitée et du support Azure. Quand vous utilisez une technologie open source avec AKS, consultez les options de support disponibles auprès des communautés et responsables de projet respectifs pour élaborer un plan.
Microsoft assume la responsabilité de la génération des packages open source que nous déployons sur AKS. Cette responsabilité comprend la maîtrise totale des processus de génération, d’analyse, de signature, de validation et de correction, ainsi que le contrôle des fichiers binaires dans les images conteneur. Pour plus d’informations, consultez Gestion des vulnérabilités pour AKS et Couverture du support AKS.
Prérequis
- Ce guide suppose une compréhension de base des concepts clés de Kubernetes et de PostgreSQL.
- Vous avez besoin des rôles intégrés AzurePropriétaire ou Administrateur d’accès utilisateur et Contributeur dans un abonnement de votre compte Azure.
Utilisez l’environnement Bash dans Azure Cloud Shell. Pour obtenir plus d’informations, consultez Démarrage d’Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour obtenir d’autres options de connexion, consultez S’authentifier auprès d’Azure à l’aide d’Azure CLI.
Quand vous y êtes invité, installez l’extension Azure CLI à la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser et gérer des extensions avec Azure CLI.
Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.
Vous devez également avoir installé les ressources suivantes :
- Azure CLI, version 2.56 ou ultérieure.
- jq version 1.5 ou ultérieure.
- kubectl version 1.21.0 ou ultérieure.
- Helm version 3.0.0 ou ultérieure.
- openssl version 3.3.0 ou ultérieure.
- Visual Studio Code ou équivalent.
- Krew version 0.4.4 ou ultérieure.
- Plug-in kubectl CloudNativePG (CNPG).
Processus de déploiement
Dans ce guide, vous apprendrez comment :
- Utiliser Azure CLI pour créer un cluster AKS multizone.
- Déployer un cluster et une base de données PostgreSQL hautement disponibles en utilisant l’opérateur CNPG.
- Configurer le monitoring pour PostgreSQL à l’aide de Prometheus et de Grafana.
- Déployer un exemple de jeu de données sur une base de données PostgreSQL.
- Effectuer des mises à niveau de cluster PostgreSQL et AKS.
- Simuler une interruption de cluster et un basculement de réplica PostgreSQL.
- Effectuer la sauvegarde et la restauration d’une base de données PostgreSQL.
Architecture de déploiement
Ce diagramme illustre une configuration de cluster PostgreSQL avec un réplica principal et deux réplicas en lecture managés par l’opérateur CloudNativePG (CNPG). L’architecture fournit une base de données PostgreSQL hautement disponible s’exécutant sur un cluster AKS capable de résister à une panne de zone en assurant une basculement entre réplicas.
Les sauvegardes sont stockées sur Stockage Blob Azure, ce qui offre un autre moyen de restaurer la base de données en cas de problème de réplication de streaming à partir du réplica principal.
Vous pouvez choisir d’héberger PostgreSQL sur AKS quand vous avez besoin d’un contrôle total sur la configuration de la base de données, les extensions et l’architecture de déploiement. Il est idéal pour l’intégration étroite avec les outils natifs Kubernetes, l’optimisation des coûts à grande échelle et l’optimisation des performances par le biais de l’allocation de ressources personnalisée, des stratégies de mise en cache et des configurations de stockage adaptées à votre charge de travail.
Remarque
Pour les applications qui nécessitent une séparation des données au niveau de la base de données, vous pouvez ajouter d’autres bases de données avec des commandes postInitSQL et d’autres commandes similaires. Il n’est actuellement pas possible d’ajouter d’autres bases de données de manière déclarative avec l’opérateur CNPG. Découvrez-en plus sur l’opérateur CNPG.
Considérations relatives au stockage
Le type de stockage que vous utilisez peut avoir des effets importants sur les performances de PostgreSQL. Plus loin dans ce guide, vous sélectionnez l’option la mieux adaptée à vos objectifs et besoins en matière de performances.
| Type de stockage | Pilote compatible | Descriptif |
|---|---|---|
| Premium SSD | Pilote CSI de disques Azure | Résilience maximale des données. Azure Premium SSD offre un stockage hautes performances et fonctionne en toute transparence avec le stockage redondant interzone Azure Premium (ZRS). SSD Premium est approvisionné en fonction des tailles spécifiques, qui offrent chacune certains niveaux d’IOPS et de débit. |
| SSD Premium v2 | Pilote CSI de disques Azure | Meilleur prix-performance. Les disques Azure SSD Premium v2 offrent des performances supérieures à celles des disques Azure SSD Premium, à un prix généralement inférieur. Contrairement aux disques SSD Premium, les disques SSD Premium v2 ne présentent pas de tailles dédiées. Vous pouvez définir un disque SSD Premium v2 sur la taille prise en charge de votre choix, et apporter des ajustements granulaires aux performances sans temps d’arrêt. Les disques SSD Premium v2 Azure ont certaines limitations dont vous devez être conscient. Pour obtenir une liste complète, consultez Limitations de SSD Premium v2. |
| NVMe local ou disque SSD temporaire (disques éphémères) | Stockage de conteneurs Azure uniquement | Performances maximales. Les disques éphémères sont des disques NVMe locaux et un stockage SSD temporaire disponible sur certaines familles de machines virtuelles. Ils offrent la latence d’IOPS, de débit et de sous-milliseconde possible la plus élevée pour votre cluster AKS. Vous pouvez également tirer parti des performances élevées des disques éphémères à l’aide d’Azure Container Storage, une solution de stockage Kubernetes managée qui provisionne dynamiquement des volumes persistants pour les charges de travail avec état comme PostgreSQL. Toutefois, étant donné que ces disques résident sur les machines virtuelles locales hébergeant le cluster, les données ne sont pas conservées dans un service de stockage Azure. Par conséquent, toutes les données stockées sur ces disques seront perdues si le cluster est arrêté ou désalloué. Pour résoudre cette limitation, les sections ultérieures de ce guide vous montrent comment configurer des sauvegardes périodiques de vos données PostgreSQL dans stockage Blob Azure. |
Étapes suivantes
Contributeurs
La gestion de cet article est sous la responsabilité de Microsoft. Les contributeurs suivants ont rédigé sa version d’origine :
- Ken Kitty | Responsable de programme technique en chef
- Russell de Pina | Responsable de programme technique en chef
- Adrian Joian | Ingénieur client senior
- Jenny Hayes | Développeuse de contenu confirmée
- Carol Smith | Développeuse de contenu confirmée
- Erin Schaffer | Développeuse de contenu 2
- Adam Sharif | Ingénieur client 2
Accusé de réception
Cette documentation a été développée conjointement avec EnterpriseDB, les mainteneurs de l’opérateur CloudNativePG. Nous remercions Gabriele Bartolini d’avoir examiné les brouillons précédents de ce document et d’offrir des améliorations techniques.