Originally published by Ampere Computing.
This post demonstrates an incremental migration strategy for cloud-native applications running on Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) x86 instances, allowing you to harness the cost and performance advantages of OCI Ampere A1-based instances without a complete application rewrite. We'll use a WordPress LAMP stack application as a practical example. Its modular design simplifies component-by-component migration.
This tutorial focuses on migrating the MySQL database from VM.Standard3.Flex (Intel) nodes to VM.Standard.A1.Flex (Ampere) nodes with minimal downtime. We start with a standard WordPress deployment (using Bitnami Helm charts) on three x86 nodes, incorporating a primary MySQL pod, a secondary replica, and an Apache/PHP WordPress pod. Data persistence is handled by OCI block volume and file storage. Asynchronous replication ensures data consistency.
The migration process involves these key steps:
Adding an Ampere A1 Node Pool: A new node pool is created within the existing OKE cluster, utilizing VM.Standard.A1.Flex instances. Remember to adjust OCPU counts appropriately (an Ampere A1 OCPU is equivalent to two x86 vCPUs).
Migrating MySQL Replicas: Additional MySQL replica pods are deployed onto the new Ampere A1 nodes. This ensures data redundancy and availability on the Arm64 architecture. Replication status is verified to confirm seamless data synchronization. This step is optional but highly recommended for data safety.
Primary Database Failover: The primary MySQL pod is then migrated to an Ampere A1 node. Important Note: This step will cause temporary service interruption. Thorough testing in a non-production environment is crucial before attempting this in production. Always back up your database before proceeding.
x86 Node Decommissioning: After successful validation, the x86 nodes hosting the original MySQL pods can be safely decommissioned.
The final result is a hybrid x86/Arm64 cluster: WordPress containers remain on x86, while the MySQL database runs entirely on Arm64 nodes. This phased approach allows for gradual migration, minimizing risk and maximizing the benefits of Ampere A1's performance and cost-effectiveness. Once this is validated, you can migrate other application components to Arm64.
Architectural diagram illustrating the WordPress deployment.
Detailed Steps (Appendix):
The following provides a more detailed breakdown of the deployment and migration process:
1. Deploying the WordPress Application:
kubeconfig
.values.yaml
files for both bitnami/wordpress
and bitnami/mysql
Helm charts. Adjust settings like passwords, persistence (using OCI block volumes for MySQL and OCI File Storage for WordPress), and node affinity (initially targeting x86). The nodeAffinityPreset
within the values.yaml
file is key for controlling which nodes the pods are deployed to.helm install
.helm install
, ensuring pod anti-affinity to prevent co-location with MySQL pods.kubectl get pods
and kubectl get service
.2. Migrating to Ampere A1:
values.yaml
for bitnami/mysql
to include arm64
in nodeAffinityPreset
for secondary replicas (and optionally create multiple secondary replicas for added redundancy). Update using helm upgrade
.mysql> show processlist;
nodeAffinityPreset
in values.yaml
to exclusively target arm64
. This step requires a brief service outage. Use helm upgrade
.Important Considerations:
This incremental approach allows for a smoother, safer transition to the performance and cost benefits of Ampere A1 instances on OKE. Contact Ampere’s sales team or explore their developer programs for further assistance.
The above is the detailed content of Migrate to Ampere on OCI with Heterogeneous Kubernetes Clusters. For more information, please follow other related articles on the PHP Chinese website!