This text was initially printed by Ampere Computing.
As a developer or software administrator, in case you design and handle cloud-native functions on Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) x86 situations and you’re questioning learn how to leverage the decrease value and better efficiency of OCI Ampere A1 based mostly situations with out a full carry and shift migration to Arm64, this put up is for you.
On this put up, we are going to showcase an incremental migration of a full stack cloud-native software to OKE Ampere A1 situations. We are going to use WordPress for instance LAMP (Linux, Apache, MySQL, PHP) stack software. Every element on this software stack is comparatively impartial of the others, and so redeploying anyone element — for instance, the MySQL database to an Ampere node — is simple.
We’ll take a step-by-step have a look at learn how to migrate the MySQL database on OKE, with virtually no downtime, from VM.Standard3.Flex (Intel) nodes to VM.Customary.A1.Flex (Ampere) nodes. We start by deploying WordPress from a Bitnami maintained Helm chart, with one Apache/PHP WordPress pod, a main MySQL pod, and one secondary reproduction MySQL pod, all working on x86 nodes, with knowledge being saved on OCI block quantity and file storage for persistence. This database structure makes use of MySQL asynchronous replication the place the first node is the replication supply.
We are going to then create an Arm64 node pool and add further MySQL replicas that may run on these newly created nodes, which is able to robotically replicate the information and be sure that all of our knowledge is now accessible on the Arm64-hosted MySQL nodes. Lastly, we are going to make one of many Arm64-hosted nodes the first node for our MySQL cluster and shut down the x86-hosted database nodes. In the long run, you now have a hybrid x86/Arm64 cluster with WordPress containers working on x86, and MySQL working on Arm64.
An architectural diagram representing the WordPress deployment
Deploy WordPress Software on OKE 3-Node Cluster
We begin by creating an OKE cluster utilizing the OCI internet console. The cluster is ready up with three nodes, utilizing the VM.Standard3.flex form. We use bitnami/wordpress and bitnami/mysql containers for deploying the applying. Each these photographs are supported on x86 in addition to Arm64 and use helm charts for simple deployment and upgrades utilizing Kubernetes manifest information.
Step-by-step directions for deploying the applying are offered within the Appendix part.
As soon as the cluster is created and the applying deployed, confirm the WordPress frontend and software pod, MySQL main pod and MySQL secondary pod are up and working on the OKE cluster:
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Operating 0 119s 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Operating 0 5m23s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 0 5m23s 10.244.4.131 10.0.10.214 <none> <none>
Migrate MySQL Secondary Database to Ampere A1 Occasion
Subsequent, we are going to add Ampere A1 situations to the OKE cluster after which lengthen the WordPress software’s MySQL database to run on the A1 situations in a number of straightforward steps. As a normal finest apply, it’s really useful to check the method in a non-production surroundings.
Step 1: Add an Ampere A1 node pool to your OKE cluster
Utilizing the OCI console, replace your OKE cluster and add a brand new node pool. Use the identical placement configuration as your x86 nodes.
Choose the VM.Customary.A1.Flex form. Select 2x the variety of OCPUs as your x86 nodes, for instance 2 OCPUs on VM.Customary.3.Flex occasion is equal to 4 OCPUs on VM.Customary.A1.Flex occasion. The Oracle CPU (OCPU) unit of measurement for x86 OCPUs is value two vCPUs however an Ampere OCPU is a single vCPU.
A brand new node-pool and new situations with Ampere A1 shapes shall be added to your cluster. We are going to migrate the MySQL pods to the newly added Arm64 nodes.
$ kubectl get nodes -o vast -l kubernetes.io/arch=amd64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.214 Prepared 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 Prepared 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 Prepared 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 vast -l kubernetes.io/arch=arm64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.122 Prepared 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 Prepared 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
Step 2: Lengthen the MySQL secondary pod to an Ampere A1 node
As a way to migrate the MySQL secondary pod, begin by including a reproduction of the secondary pod on the Arm64 node. This step is non-compulsory. We are going to deploy a number of replicas of the MySQL secondary pod to make sure knowledge consistency and availability on the brand new Arm64 occasion. If you don’t want to create a number of replicas, you possibly can skip to the subsequent step and migrate the MySQL secondary pod to Arm64 with out the extra validation.
You’ll be able to lengthen the MySQL secondary pods to the Ampere A1 nodes with none interruptions to the online software.
Change the variety of replicas for the secondary pods in charts/bitnami-mysql/values.yaml. Additionally replace the nodeAffinityPreset values to permit the pods to be deployed on Arm64 nodes:
secondary:
identify: secondary
replicaCount: 2
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- amd64
- arm64
Use the helm improve command to put in the updates to your manifest file:
helm improve wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
Examine the pod standing utilizing Kubectl. You’ll discover a brand new reproduction of the MySQL secondary pod “wordpress-mysql-secondary-1” working on one of many Ampere A1 nodes:
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Operating 0 24m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Operating 0 27m 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 0 36s 10.244.4.133 10.0.10.214 <none> <none>
wordpress-mysql-secondary-1 1/1 Operating 0 2m13s 10.244.5.130 10.0.10.82 <none> <none>
The MySQL BinLog (Binary Logs) is chargeable for dealing with the replication. Confirm the replication standing by connecting to the MySQL database:
mysql> present processlist;
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| Id | Consumer | Host | db | Command | Time | State | Data |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 1638 | Ready on empty queue | NULL |
| 617 | replicator | 10.244.5.130:46208 | NULL | Binlog Dump | 98 | Supply has despatched all binlog to reproduction; ready for extra updates | NULL |
| 630 | replicator | 10.244.4.133:45986 | NULL | Binlog Dump | 68 | Supply has despatched all binlog to reproduction; ready for extra updates | NULL |
| 653 | root | localhost | NULL | Question | 0 | init | present processlist |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
Step 3: Migrate the MySQL secondary pod to an Ampere A1 node
As talked about earlier, you possibly can straight migrate the MySQL secondary pod to the Arm64 node. The MySQL pod makes use of OCI block volumes that may be indifferent from an occasion and moved to a special occasion with out the lack of knowledge. This knowledge persistence lets you migrate knowledge between situations and ensures that your knowledge is safely saved, even when it isn’t linked to an occasion. Any knowledge stays intact till you reformat or delete the quantity.
As a way to migrate the MySQL secondary pod to Ampere A1 node, replace the helm chart and set the nodeAffinityPreset to arm64 and take away amd64. On the identical time, you can too reset the replicaCount again to 1:
secondary:
identify: secondary
replicaCount: 1
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- arm64
Use the helm improve command to put in the updates to your MySQL manifest file:
helm improve wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Operating 0 28m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Operating 0 31m 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 0 77s 10.244.5.131 10.0.10.82 <none> <none>
You’ll discover the MySQL reproduction on the x86 node is deleted and a brand new reproduction created on the Arm64 node. Confirm the replication standing once more at this stage:
mysql> present processlist;
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| Id | Consumer | Host | db | Command | Time | State | Data |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 1854 | Ready on empty queue | NULL |
| 617 | replicator | 10.244.5.130:46208 | NULL | Binlog Dump | 314 | Supply has despatched all binlog to reproduction; ready for extra updates | NULL |
| 727 | replicator | 10.244.5.131:45904 | NULL | Binlog Dump | 68 | Supply has despatched all binlog to reproduction; ready for extra updates | NULL |
| 752 | root | localhost | NULL | Question | 0 | init | present processlist |
+-----+-----------------+--------------------+------+-------------+------+-----------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
Now you can delete the x86 node that was working the outdated reproduction for MySQL secondary, on this instance the node with ip tackle “10.0.10.214″. This step doesn’t require any service downtime and you’ve got now efficiently migrated your MySQL secondary pod to the Ampere A1 occasion.
Migrate MySQL Major Database to Ampere A1 Occasion
Within the earlier step, we migrated the MySQL secondary pod of the WordPress deployment to Ampere A1 node. The following step is emigrate the MySQL main pod to the second Ampere A1 node in the identical OKE cluster.
Observe: it’s endorsed to check the method in a non-production surroundings utilizing a snapshot of your manufacturing database. When performing a failover of the MySQL main database in a manufacturing surroundings, please ensure you have a full backup of the database and comply with all of the steps which might be really useful for database failover.
As a way to failover the MySQL main pod, reset the nodeAffinityPreset in charts/bitnami-mysql/values.yaml to make use of node with labels kubernetes.io/arch=arm64:
main:
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- arm64
Use the helm improve command to put in the updates to your manifest file.
Observe: this step will disrupt your software’s connectivity to the database for jiffy, please plan for service downtime.
helm improve wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Operating 1 (3m19s in the past) 37m 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Operating 0 4m2s 10.244.5.2 10.0.10.122 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 0 10m 10.244.5.131 10.0.10.82 <none> <none>
$ kubectl get nodes -o vast -l kubernetes.io/arch=arm64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.122 Prepared 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 Prepared 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 vast -l kubernetes.io/arch=amd64
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.217 Prepared 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
You’ll discover the MySQL main pod on the x86 node is now deleted and a brand new pod is deployed on the Arm64 node. This pod will robotically mount the first pod’s block quantity storage, making certain knowledge availability after the failover.
Now we have now efficiently migrated the WordPress deployment to a heterogenous Arm64 and x86 cluster. The frontend and software pods of WordPress proceed to run on the x86 situations, whereas the MySQL database main and secondary pods are actually migrated to the Arm64 situations in a single OKE cluster.
When you validate the performance and efficiency of your software in a heterogenous cluster, you possibly can then migrate the remainder of your software elements to Arm64 situations utilizing the same course of and take full benefit of the value efficiency advantages of an Ampere A1 cluster on OKE.
Appendix
Detailed directions to deploy the WordPress software on an OKE cluster.
Step 1: Create a 3-node cluster
Create a OKE cluster utilizing VM.Standard3.Flex form. Utilizing the Cloud Shell, setup the Kubernetes configuration file (kubeconfig) for the cluster (Cloud Shell Entry). As soon as this step is full, confirm the cluster particulars utilizing kubectl instructions:
$ kubectl get nodes -o vast
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.214 Prepared 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 Prepared 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 Prepared 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
Step2: Deploy the WordPress software
Obtain the values.yaml for bitnami/wordpress and bitnami/mysql and modify it to your deployment wants:
mkdir -p oci_a1_demo/charts/bitnami-mysql
cd oci_a1_demo/charts/bitnami-mysql
wget https://uncooked.githubusercontent.com/bitnami/charts/principal/bitnami/mysql/values.yaml
cd ../../..
mkdir -p oci_a1_demo/charts/bitnami-wordpress
cd oci_a1_demo/charts/bitnami-wordpress
wget https://uncooked.githubusercontent.com/bitnami/charts/principal/bitnami/wordpress/values.yaml
Modify oci_a1_demo/charts/bitnami-mysql/values.yaml as proven beneath. The parameters not proven right here might be left at their default values. The nodeAffinity worth is used to pick nodes to schedule the MySQL pods, we use the Kubernetes.io/arch label to distinguish the x86 and Arm64 nodes. This subject shall be up to date when migrating the MySQL deployment to Arm64 nodes:
structure: replication
auth:
rootPassword: "your_db_password"
database: "bitnami_wordpress"
username: "bn_username"
password: ""
main:
persistence:
enabled: true
storageClass: "oci-bv"
accessModes:
- ReadWriteOnce
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- amd64
secondary:
replicaCount: 1
persistence:
enabled: true
storageClass: "oci-bv"
accessModes:
- ReadWriteOnce
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- amd64
volumePermissions:
enabled: true
Modify charts/bitnami-wordpress/values.yaml as proven beneath. The parameters not proven right here might be left at their default values. Use the affinity.podAntiAffinity fields to make sure that WordPress pods aren’t deployed on the nodes which have MySQL pods working:
wordpressUsername: person
wordpressPassword: "wordpress_user_password"
replicaCount: 1
service:
kind: LoadBalancer
persistence:
enabled: true
storageClass: "fss-wp-storage"
accessModes:
- ReadWriteMany
accessMode: ReadWriteMany
nodeAffinityPreset:
kind: "laborious"
key: "kubernetes.io/arch"
values:
- amd64
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app.kubernetes.io/identify
operator: In
values:
- mysql
topologyKey: kubernetes.io/hostname
volumePermissions:
enabled: true
mariadb:
enabled: false
externalDatabase:
host: wordpress-mysql-primary
port: 3306
person: "root"
password: " your_db_password"
database: bitnami_wordpress
existingSecret: ""
memcached:
enabled: false
Step 3: Configure persistent volumes for MySQL containers
MySQL container makes use of persistent quantity claims to provision storage for the database. The Oracle Cloud Infrastructure Block Quantity service gives persistent, sturdy, and high-performance block storage utilizing the CSI quantity plugin. Set the “storageClass” parameter within the values.yaml file to “oci-bv” as proven above.
Volumes are solely accessible to situations in the identical availability area. We are going to use the identical availability area when including new Ampere A1 nodes emigrate the MySQL database:
Provisioning_PVCs_on_BlockVolume
Step 4: Configure filesystem storage for WordPress containers
The WordPress container is configured to make use of OCI’s filesystem dynamic storage to permit entry to a number of replicas throughout completely different nodes. The Oracle Cloud Infrastructure File Storage service gives a sturdy, scalable, distributed, enterprise-grade community file system. Detailed steps to make use of the CSI quantity plugin to attach clusters to file methods within the File Storage service is documented right here:
PVCs_on_FSS-Utilizing-CSI-Quantity-Plugin
As described, create a mount goal utilizing the OCI console.
Outline a brand new storage class that makes use of the fss.csi.oracleclould.com provisioner utilizing the OCID of the mount goal you simply created:
$ cat oci_a1_demo/oci-fs-storage-class.yaml
---
variety: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
identify: fss-wp-storage
provisioner: fss.csi.oraclecloud.com
parameters:
availabilityDomain: MBWR:PHX-AD-1
mountTargetOcid: <OCID of mount goal>
compartmentOcid: <OCID of compartment>
Observe: add IAM insurance policies to allow the CSI quantity plugin.
ALLOW any-user to handle file-family in tenancy
ALLOW any-user to make use of virtual-network-family in tenancy
Create the storage class from the manifest file utilizing:
kubectl create -f oci-fs-storage-class.yaml
Step 5: Deploy the MySQL main and secondary pods utilizing the helm chart
cd oci_a1_demo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm set up wordpress-mysql -f ./charts/bitnami-mysql/values.yaml bitnami/mysql
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-mysql-primary-0 1/1 Operating 0 2m5s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 0 2m5s 10.244.4.131 10.0.10.214 <none> <none>
Step 6: Deploy the WordPress software pods
As soon as the MySQL pods are working, use helm to deploy the WordPress frontend and software pods:
helm set up wordpress-demo -f ./charts/bitnami-wordpress/values.yaml bitnami/wordpress
Step 7: Confirm deployment standing
Confirm that every one pods are deployed and in “working” state. This can take a couple of minutes.
$ kubectl get pods -o vast
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
wordpress-demo-5d8d554d8d-gg2wd 1/1 Operating 0 119s 10.244.3.134 10.0.10.217 <none> <none>
wordpress-mysql-primary-0 1/1 Operating 0 5m23s 10.244.4.2 10.0.10.78 <none> <none>
wordpress-mysql-secondary-0 1/1 Operating 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 tackle” 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 Sure csi-d6d15401-9732-4060-9391-fe07993f5f11 50Gi RWO oci-bv 5m31s
data-wordpress-mysql-secondary-0 Sure csi-0cfcbf9f-9af9-4060-9063-f8d0ccb8f4f0 50Gi RWO oci-bv 5m48s
wordpress-demo Sure csi-fss-44851833-384a-4e3e-bad6-6253d37185a1 10Gi RWX fss-wp-storage 2m38s
WordPress deployment is now full. You’ll be able to login to the exterior IP of WordPress service and consider the weblog web site. Login to the http://<external-ip>/wp-admin web page utilizing the credentials username:person and password:root, modify the WordPress configuration, add new posts, pages, customers and so on.
Constructed for sustainable cloud computing, Ampere’s first Cloud Native Processors ship predictable excessive efficiency, platform scalability, and energy effectivity unprecedented within the trade.
Discuss to our skilled gross sales crew about partnerships or to get extra info, or get trial entry to Ampere Methods via our Developer Entry Applications.
