L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Migrez vers Ampere sur OCI avec des clusters Kubernetes hétérogènes —
Cet article a été initialement publié par Ampère informatique.
En tant que développeur ou administrateur d’applications, si vous concevez et gérez des applications cloud natives sur des instances Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) x86 et que vous vous demandez comment tirer parti du coût réduit et des performances supérieures des instances basées sur OCI Ampere A1 sans Migration complète Lift and Shift vers Arm64, cet article est pour vous.
Dans cet article, nous présenterons une migration incrémentielle d’une application cloud native complète vers les instances OKE Ampere A1. Nous utiliserons WordPress comme exemple d’application de pile LAMP (Linux, Apache, MySQL, PHP). Chaque composant de cette pile d’applications est relativement indépendant des autres et le redéploiement d’un composant (par exemple, la base de données MySQL vers un nœud Ampere) est donc simple.
Nous allons voir étape par étape comment migrer la base de données MySQL sur OKE, avec quasiment aucun temps d’arrêt, depuis VM.Standard3.Flex (Intel) nœuds vers VM.Standard.A1.Flex Nœuds (Ampère). Nous commençons par déployer WordPress à partir d’une charte Helm gérée par Bitnami, avec un pod WordPress Apache/PHP, un pod MySQL principal et un pod MySQL de réplique secondaire, tous exécutés sur des nœuds x86, les données étant stockées sur un volume de blocs OCI et un stockage de fichiers pour persistance. Cette architecture de base de données utilise la réplication asynchrone MySQL où le nœud principal est la source de réplication.
Nous créerons ensuite un pool de nœuds Arm64 et ajouterons des répliques MySQL supplémentaires qui s’exécuteront sur ces nœuds nouvellement créés, ce qui répliquera automatiquement les données et garantira que toutes nos données sont désormais disponibles sur les nœuds MySQL hébergés par Arm64. Enfin, nous ferons de l’un des nœuds hébergés par Arm64 le nœud principal de notre cluster MySQL et arrêterons les nœuds de base de données hébergés par x86. Au final, vous disposez désormais d’un cluster hybride x86/Arm64 avec des conteneurs WordPress fonctionnant sur x86 et MySQL fonctionnant sur Arm64.
Un schéma architectural représentant le déploiement WordPress
Déployer l’application WordPress sur le cluster OKE à 3 nœuds
Nous commençons par créer un cluster OKE à l’aide de la console Web OCI. Le cluster est configuré avec trois nœuds, en utilisant le VM.Standard3.flex forme. Nous utilisons bitnami/wordpress et bitnami/mysql conteneurs pour déployer l’application. Ces deux images sont prises en charge sur x86 ainsi que sur Arm64 et utilisent des graphiques de barre pour un déploiement et des mises à niveau faciles à l’aide des fichiers manifestes Kubernetes.
Des instructions étape par étape pour déployer l’application sont fournies dans le annexe section.
Une fois le cluster créé et l’application déployée, vérifiez que l’interface WordPress et le pod d’application, le pod principal MySQL et le pod secondaire MySQL sont opérationnels sur le cluster OKE :
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Running 0 119s 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Running 0 5m23s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 5m23s 10.244.4.131 10.0.10.214 <none> <none>
Migrer la base de données secondaire MySQL vers l’instance Ampere A1
Ensuite, nous ajouterons les instances Ampere A1 au cluster OKE, puis étendrons la base de données MySQL de l’application WordPress pour qu’elle s’exécute sur les instances A1 en quelques étapes simples. En tant que bonne pratique générale, il est recommandé de tester le processus dans un environnement hors production.
Étape 1 : Ajoutez un pool de nœuds Ampere A1 à votre cluster OKE
À l’aide de la console OCI, mettez à jour votre cluster OKE et ajoutez un nouveau pool de nœuds. Utilisez la même configuration de placement que vos nœuds x86.
Sélectionnez le VM.Standard.A1.Flex forme. Choisissez 2x le nombre d’OCPU comme nœuds x86, par exemple 2 OCPU sur VM.Standard.3.Flex instance équivaut à 4 OCPU sur VM.Standard.A1.Flex exemple. L’unité de mesure Oracle CPU (OCPU) pour les OCPU x86 vaut deux vCPU, mais un Ampere OCPU est un seul vCPU.
Un nouveau pool de nœuds et de nouvelles instances avec des formes Ampere A1 seront ajoutés à votre cluster. Nous allons migrer les pods MySQL vers les nœuds Arm64 nouvellement ajoutés.
$ kubectl get nodes -o wide -l kubernetes.io/arch=amd64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.214 Ready node 40m v1.26.2 10.0.10.214 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
10.0.10.217 Ready node 41m v1.26.2 10.0.10.217 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
10.0.10.78 Ready node 41m v1.26.2 10.0.10.78 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
$ kubectl get nodes -o wide -l kubernetes.io/arch=arm64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.122 Ready node 2m38s v1.26.2 10.0.10.122 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.aarch64 cri-o://1.26.2-142.el8
10.0.10.82 Ready node 2m15s v1.26.2 10.0.10.82 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.aarch64 cri-o://1.26.2-142.el8
Étape 2 : étendre le pod secondaire MySQL à un nœud Ampere A1
Afin de migrer le pod secondaire MySQL, commencez par ajouter une réplique du pod secondaire sur le nœud Arm64. Cette étape est facultative. Nous déploierons plusieurs répliques du pod secondaire MySQL pour garantir la cohérence et la disponibilité des données sur la nouvelle instance Arm64. Si vous ne souhaitez pas créer plusieurs réplicas, vous pouvez passer à l’étape suivante et migrer le pod secondaire MySQL vers Arm64 sans validation supplémentaire.
Vous pouvez étendre les pods secondaires MySQL aux nœuds Ampere A1 sans aucune interruption de l’application Web.
Modifiez le nombre de réplicas pour les pods secondaires dans charts/bitnami-mysql/values.yaml. Mettez également à jour le nodeAffinityPreset valeurs pour permettre aux pods d’être déployés sur les nœuds Arm64 :
secondary:
name: secondary
replicaCount: 2
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- amd64
- arm64
Utilisez la commande helm Upgrade pour installer les mises à jour de votre fichier manifeste :
helm upgrade wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
Vérifiez l’état du pod à l’aide de Kubectl. Vous remarquerez une nouvelle réplique du pod secondaire MySQL « wordpress-mysql-secondary-1 » fonctionnant sur l’un des nœuds Ampere A1 :
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Running 0 24m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Running 0 27m 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 36s 10.244.4.133 10.0.10.214 <none> <none>
wordpress-mysql-secondary-1 1/1 Running 0 2m13s 10.244.5.130 10.0.10.82 <none> <none>
Le MySQL BinLog (Binary Logs) est responsable de la gestion de la réplication. Vérifiez l’état de la réplication en vous connectant à la base de données MySQL :
mysql> show processlist;
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 1638 | Waiting on empty queue | NULL |
| 617 | replicator | 10.244.5.130:46208 | NULL | Binlog Dump | 98 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 630 | replicator | 10.244.4.133:45986 | NULL | Binlog Dump | 68 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 653 | root | localhost | NULL | Query | 0 | init | show processlist |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
Étape 3 : Migrer le pod secondaire MySQL vers un nœud Ampere A1
Comme mentionné précédemment, vous pouvez directement migrer le pod secondaire MySQL vers le nœud Arm64. Le pod MySQL utilise des volumes de blocs OCI qui peuvent être détachés d’une instance et déplacés vers une autre instance sans perte de données. Cette persistance des données vous permet de migrer des données entre instances et garantit que vos données sont stockées en toute sécurité, même lorsqu’elles ne sont pas connectées à une instance. Toutes les données restent intactes jusqu’à ce que vous reformatiez ou supprimiez le volume.
Afin de migrer le pod secondaire MySQL vers le nœud Ampere A1, mettez à jour le graphique de barre, définissez nodeAffinityPreset sur arm64 et supprimez amd64. Dans le même temps, vous pouvez également réinitialiser le replicaCount à 1 :
secondary:
name: secondary
replicaCount: 1
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- arm64
Utilisez la commande helm Upgrade pour installer les mises à jour de votre fichier manifeste MySQL :
helm upgrade wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Running 0 28m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Running 0 31m 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 77s 10.244.5.131 10.0.10.82 <none> <none>
Vous remarquerez que la réplique MySQL sur le nœud x86 est supprimée et qu’une nouvelle réplique est créée sur le nœud Arm64. Vérifiez à nouveau l’état de la réplication à ce stade :
mysql> show processlist;
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 1854 | Waiting on empty queue | NULL |
| 617 | replicator | 10.244.5.130:46208 | NULL | Binlog Dump | 314 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 727 | replicator | 10.244.5.131:45904 | NULL | Binlog Dump | 68 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 752 | root | localhost | NULL | Query | 0 | init | show processlist |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
Vous pouvez maintenant supprimer le nœud x86 qui exécutait l’ancienne réplique pour MySQL secondaire, dans cet exemple le nœud avec l’adresse IP « 10.0.10.214 ». Cette étape ne nécessite aucun temps d’arrêt du service et vous avez maintenant migré avec succès votre pod secondaire MySQL vers l’instance Ampere A1.
Migrer la base de données primaire MySQL vers l’instance Ampere A1
À l’étape précédente, nous avons migré le pod secondaire MySQL du déploiement WordPress vers le nœud Ampere A1. L’étape suivante consiste à migrer le pod principal MySQL vers le deuxième nœud Ampere A1 dans le même cluster OKE.
Remarque : il est recommandé de tester le processus dans un environnement hors production à l’aide d’un instantané de votre base de données de production. Lorsque vous effectuez un basculement de la base de données principale MySQL dans un environnement de production, assurez-vous de disposer d’une sauvegarde complète de la base de données et suivez toutes les étapes recommandées pour le basculement de la base de données.
Afin de basculer le pod principal MySQL, réinitialisez le nodeAffinityPreset dans charts/bitnami-mysql/values.yaml utiliser un nœud avec des étiquettes kubernetes.io/arch=arm64:
primary:
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- arm64
Utilisez la commande helm update pour installer les mises à jour de votre fichier manifeste.
Remarque : cette étape perturbera la connectivité de votre application à la base de données pendant quelques minutes, veuillez prévoir le temps d’arrêt du service.
helm upgrade wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Running 1 (3m19s ago) 37m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Running 0 4m2s 10.244.5.2 10.0.10.122 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 10m 10.244.5.131 10.0.10.82 <none> <none>
$ kubectl get nodes -o wide -l kubernetes.io/arch=arm64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.122 Ready node 21m v1.26.2 10.0.10.122 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.aarch64 cri-o://1.26.2-142.el8
10.0.10.82 Ready node 21m v1.26.2 10.0.10.82 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.aarch64 cri-o://1.26.2-142.el8
$ kubectl get nodes -o wide -l kubernetes.io/arch=amd64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.217 Ready node 61m v1.26.2 10.0.10.217 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
Vous remarquerez que le pod principal MySQL sur le nœud x86 est maintenant supprimé et qu’un nouveau pod est déployé sur le nœud Arm64. Ce pod montera automatiquement le stockage en volume de bloc du pod principal, garantissant ainsi la disponibilité des données après le basculement.
Nous avons maintenant migré avec succès le déploiement WordPress vers un cluster hétérogène Arm64 et x86. Les modules frontend et application de WordPress continuent de s’exécuter sur les instances x86, tandis que les modules principal et secondaire de la base de données MySQL sont désormais migrés vers les instances Arm64 dans un cluster OKE.
Une fois que vous avez validé les fonctionnalités et les performances de votre application dans un cluster hétérogène, vous pouvez ensuite migrer le reste de vos composants d’application vers des instances Arm64 en utilisant un processus similaire et profiter pleinement des avantages prix-performances d’un cluster Ampere A1 sur OKE.
annexe
Instructions détaillées pour déployer l’application WordPress sur un cluster OKE.
Étape 1 : Créer un cluster à 3 nœuds
Créez un cluster OKE en utilisant VM.Standard3.Flex forme. À l’aide de Cloud Shell, configurez le fichier de configuration Kubernetes (kubeconfig) pour le cluster (accès Cloud Shell). Une fois cette étape terminée, vérifiez les détails du cluster à l’aide de kubectl commandes :
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.214 Ready node 9m54s v1.26.2 10.0.10.214 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
10.0.10.217 Ready node 10m v1.26.2 10.0.10.217 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
10.0.10.78 Ready node 9m59s v1.26.2 10.0.10.78 <none> Oracle Linux Server 8.7 5.15.0-6.80.3.1.el8uek.x86_64 cri-o://1.26.2-142.el8
Étape 2 : Déployez l’application WordPress
Téléchargez le fichier values.yaml pour bitnami/wordpress et bitnami/mysql et modifiez-le pour vos besoins de déploiement :
mkdir -p oci_a1_demo/charts/bitnami-mysql
cd oci_a1_demo/charts/bitnami-mysql
wget https://raw.githubusercontent.com/bitnami/charts/main/bitnami/mysql/values.yaml
cd ../../..
mkdir -p oci_a1_demo/charts/bitnami-wordpress
cd oci_a1_demo/charts/bitnami-wordpress
wget https://raw.githubusercontent.com/bitnami/charts/main/bitnami/wordpress/values.yaml
Modifier oci_a1_demo/charts/bitnami-mysql/values.yaml comme indiqué ci-dessous. Les paramètres non affichés ici peuvent être laissés à leurs valeurs par défaut. Le nodeAffinity La valeur est utilisée pour sélectionner les nœuds pour planifier les pods MySQL, nous utilisons le Kubernetes.io/arch étiquette pour différencier les nœuds x86 et Arm64. Ce champ sera mis à jour lors de la migration du déploiement MySQL vers les nœuds Arm64 :
architecture: replication
auth:
rootPassword: "your_db_password"
database: "bitnami_wordpress"
username: "bn_username"
password: ""
primary:
persistence:
enabled: true
storageClass: "oci-bv"
accessModes:
- ReadWriteOnce
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- amd64
secondary:
replicaCount: 1
persistence:
enabled: true
storageClass: "oci-bv"
accessModes:
- ReadWriteOnce
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- amd64
volumePermissions:
enabled: true
Modifier charts/bitnami-wordpress/values.yaml comme indiqué ci-dessous. Les paramètres non affichés ici peuvent être laissés à leurs valeurs par défaut. Utilisez le affinity.podAntiAffinity champs pour garantir que les pods WordPress ne sont pas déployés sur les nœuds sur lesquels des pods MySQL sont en cours d’exécution :
wordpressUsername: user
wordpressPassword: "wordpress_user_password"
replicaCount: 1
service:
type: LoadBalancer
persistence:
enabled: true
storageClass: "fss-wp-storage"
accessModes:
- ReadWriteMany
accessMode: ReadWriteMany
nodeAffinityPreset:
type: "hard"
key: "kubernetes.io/arch"
values:
- amd64
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- mysql
topologyKey: kubernetes.io/hostname
volumePermissions:
enabled: true
mariadb:
enabled: false
externalDatabase:
host: wordpress-mysql-primary
port: 3306
user: "root"
password: " your_db_password"
database: bitnami_wordpress
existingSecret: ""
memcached:
enabled: false
Étape 3 : Configurer les volumes persistants pour les conteneurs MySQL
Le conteneur MySQL utilise des revendications de volume persistantes pour provisionner le stockage pour la base de données. Le service Oracle Cloud Infrastructure Block Volume fournit un stockage par blocs persistant, durable et hautes performances à l’aide du plug-in de volume CSI. Définissez le paramètre « StorageClass » dans le fichier Values.yaml sur « oci-bv » comme indiqué ci-dessus.
Les volumes ne sont accessibles qu’aux instances du même domaine de disponibilité. Nous utiliserons le même domaine de disponibilité lors de l’ajout de nouveaux nœuds Ampere A1 pour migrer la base de données MySQL :
Provisioning_PVCs_on_BlockVolume
Étape 4 : Configurer le stockage du système de fichiers pour les conteneurs WordPress
Le conteneur WordPress est configuré pour utiliser le stockage dynamique du système de fichiers OCI afin de permettre l’accès à plusieurs répliques sur différents nœuds. Le service Oracle Cloud Infrastructure File Storage fournit un système de fichiers réseau durable, évolutif et distribué de niveau entreprise. Les étapes détaillées pour utiliser le plug-in de volume CSI pour connecter des clusters aux systèmes de fichiers dans le service File Storage sont documentées ici :
PVCs_on_FSS-Utilisation-CSI-Volume-Plugin
Comme décrit, créez une cible de montage à l’aide de la console OCI.
Définir une nouvelle classe de stockage qui utilise le fss.csi.oracleclould.com fournisseur en utilisant l’OCID de la cible de montage que vous venez de créer :
$ cat oci_a1_demo/oci-fs-storage-class.yaml
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fss-wp-storage
provisioner: fss.csi.oraclecloud.com
parameters:
availabilityDomain: MBWR:PHX-AD-1
mountTargetOcid: <OCID of mount target>
compartmentOcid: <OCID of compartment>
Remarque : ajoutez des stratégies IAM pour activer le plug-in de volume CSI.
ALLOW any-user to manage file-family in tenancy
ALLOW any-user to use virtual-network-family in tenancy
Créez la classe de stockage à partir du fichier manifeste en utilisant :
kubectl create -f oci-fs-storage-class.yaml
Étape 5 : Déployez les pods MySQL principal et secondaire à l’aide du graphique de barre
cd oci_a1_demo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-mysql-primary-0 1/1 Running 0 2m5s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 2m5s 10.244.4.131 10.0.10.214 <none> <none>
Étape 6 : Déployer les pods d’application WordPress
Une fois les pods MySQL exécutés, utilisez helm pour déployer le frontend WordPress et les pods d’application :
helm install wordpress-demo -f ./charts/bitnami-wordpress/values.yaml bitnami/wordpress
Étape 7 : Vérifier l’état du déploiement
Vérifiez que tous les pods sont déployés et en état d’exécution. Cela prendra quelques minutes.
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Running 0 119s 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Running 0 5m23s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Running 0 5m23s 10.244.4.131 10.0.10.214 <none> <none>
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP,12250/TCP 22d
wordpress-demo LoadBalancer 10.96.215.0 “public ip address” 80:32601/TCP,443:30738/TCP 2m32s
wordpress-mysql-primary ClusterIP 10.96.79.218 <none> 3306/TCP 5m56s
wordpress-mysql-primary-headless ClusterIP None <none> 3306/TCP 5m56s
wordpress-mysql-secondary ClusterIP 10.96.154.29 <none> 3306/TCP 5m56s
wordpress-mysql-secondary-headless ClusterIP None <none> 3306/TCP 5m56s
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-wordpress-mysql-primary-0 Bound csi-d6d15401-9732-4060-9391-fe07993f5f11 50Gi RWO oci-bv 5m31s
data-wordpress-mysql-secondary-0 Bound csi-0cfcbf9f-9af9-4060-9063-f8d0ccb8f4f0 50Gi RWO oci-bv 5m48s
wordpress-demo Bound csi-fss-44851833-384a-4e3e-bad6-6253d37185a1 10Gi RWX fss-wp-storage 2m38s
Le déploiement de WordPress est maintenant terminé. Vous pouvez vous connecter à l’adresse IP externe du service WordPress et consulter le site du blog. Connectez-vous au http://<external-ip>/wp-admin page utilisant les informations d’identification username:user et password:rootmodifiez la configuration WordPress, ajoutez de nouveaux articles, pages, utilisateurs, etc.
Conçus pour le cloud computing durable, les premiers processeurs cloud natifs d’Ampère offrent des performances élevées prévisibles, une évolutivité de la plateforme et une efficacité énergétique sans précédent dans l’industrie.
Parlez à notre expert équipe de vente sur les partenariats ou pour obtenir plus d’informations, ou obtenez un accès d’essai à Ampere Systems via notre Programmes d’accès pour les développeurs.
Source link