Configure the target architecture for an image

Limits

• Only Kubernetes ACK clusters are supported.

• This feature is only available when you deploy applications from WAR or JAR packages.

• The Java environment must be OpenJDK 8 or later, or Dragonwell JDK.

• If you set Build Repository Type to ACR Repository, you must use your own image build machine that runs an operating system with a Linux kernel version later than 4.8, such as:

  • All versions of Alibaba Cloud Linux

  • All versions of Anolis OS

  • Ubuntu 18.04.0 LTS or later

  • CentOS 8 or later

Prerequisites

Upgrade arms-pilot to ack-onepilot version 3.0.13 or later. You can manually check and upgrade the arms-pilot version by performing the following steps:

1. Log on to the Container Service for Kubernetes console. In the navigation pane on the left, choose Cluster List.

2. On the Cluster List page, click the name of the target cluster. In the navigation pane on the left, choose Applications > Helm.

3. On the Helm page, check that ack-onepilot is installed and its Chart Version is 3.0.13 or later. If not, go to the Operations Management > Components page to install or upgrade ack-onepilot.

4. After ack-onepilot is installed, go to the Applications > Helm page and uninstall ack-arms-pilot or arms-pilot.

Procedure

You can configure the target architecture for an image when you create or deploy an application.

1. EDAS console Log on to the . In the left-side navigation pane, choose Application Management > Applications. In the top navigation bar, select a region. In the upper part of the page, select a microservice namespace. In the upper-left corner of the Applications page, click Create Application.

2. On the Basic Information tab, set Cluster Type to Kubernetes Cluster and click Next.

3. On the Application Configuration tab, for Target Image Architecture, select the required architecture, and then click Next.

   • linux/amd64: The built image can run on the Linux x86_64 platform.

   • linux/arm64: The built image can run on the Linux ARM64 platform.

   If you want to run both linux/amd64 and linux/arm64 worker nodes in the same cluster, consider the following two scenarios:

   Scenario	Recommendation	Pros and cons
   Different applications run on different architectures.	Recommended.	Pros: This method provides high controllability and helps avoid performance issues caused by performance inconsistencies between nodes of different architectures. Cons: You must add taints to ARM-based worker nodes. You must also configure scheduling policies for applications that are scheduled to ARM-based nodes. For more information, see How do I add a worker node of a different architecture to a running cluster and schedule applications to it?.
   Pods of the same application are randomly scheduled to machines of different architectures.	Not recommended.	Pros: You do not need to configure scheduling policies. Cons: The performance of machines with different architectures is usually inconsistent. Under heavy loads, if the consumer of a microservice application uses a round-robin policy, the work queues of lower-performance machines may become stacked. This increases the response time (RT) of the slower machines, while higher-performance machines remain idle.

   If you select multiple architectures, the image is built using multi-architecture image technology and supports all selected platform architectures. For more information about the technology used, see Build and push multi-architecture images to Container Registry from your computer.

   Note

   When you select multiple architectures for Target Image Architecture, the build time increases. The build time varies based on the following factors:

   • If you set Build Repository Type to EDAS Image Repository, high-performance EDAS build machines are used. Each additional architecture increases the build time by 10 to 60 seconds.

   • If you set Build Repository Type to ACR Repository, the build runs on your own machines, which have limited CPU performance by default. Each additional architecture increases the build time by 2 to 6 minutes.

     Use an amd64 machine for the build. Add the label edas.image.build: enable to the machine to schedule build tasks to it. To accelerate image builds by adjusting resource limits, see How do I adjust the resource limits for image builds?.

4. On the Advanced Settings tab, configure the parameters as needed.

5. After you configure the advanced settings, click Create Application. In the Creation Completed step, click Create Application.

6. In the Application Change Precheck Confirmation dialog box, click Start Precheck.

   1. In the Application Change Precheck Confirmation dialog box, confirm the precheck items and results, and then click Continue.

   2. Optional: If you change any of the precheck items, click Re-run Precheck.

   The application may take a few minutes to create. During the creation process, you can track the progress on the Change History page. After the application is created, return to the Overview page to view the status of the instance pod. If the Status is Running, the application is successfully deployed. Click the pod status to view the workload (deployment), pod (container group), and advanced configuration information of the application instance.

   Note

   The precheck task checks for the following issues in multi-architecture deployments.

   • There are no worker nodes that match the selected architecture. For example, you select linux/arm64 in EDAS, but the cluster contains only linux/amd64 worker nodes.

   • Build Repository Type is set to ACR Repository for one or more selected architectures, but the cluster has no worker nodes with a kernel version of 4.8 or later.

   • Some legacy applications in EDAS are still using a Java environment other than OpenJDK or Dragonwell JDK.

FAQ

How do I add a worker node of a different architecture to a running cluster and schedule applications to it?

For example, to add linux/arm64 machines to a cluster that already contains linux/amd64 nodes, perform the following steps:

1. On the ACK cluster management page, add an arm64 node pool. In the node pool configuration, add the taint kubernetes.io/arch=arm64 and set Effect to NoSchedule. This ensures that only applications and components designed for ARM nodes are scheduled to these nodes. For more information, see Create and manage a node pool.

2. On the Advanced Settings tab of the EDAS console, configure Node Affinity and Toleration to schedule the application to arm64 nodes.

   

   

What do I do if an image build task is always running or fails?

If Build Repository Type is set to ACR Repository and an image build task hangs or fails, you can run the following commands to check its status.

What do I do if the application pod status is Error or CrashLoopBackOff?

1. Run the following command to query the pod logs:

   kubectl logs <pod_name>

   The log shows:

   exec /bin/sh: exec format error

   Check whether the selected image architecture includes the node architecture. If not, see How do I add a worker node of a different architecture to a running cluster and schedule applications to it? to complete the configuration.

What do I do if the application starts or runs slowly?

1. Run the following command in the pod container:

   ps -ef | grep java

   If the java command is preceded by qemu, it indicates that the current node is running the image in qemu mode. See How do I add a worker node of a different architecture to a running cluster and schedule applications to it? to complete the configuration.

References

For scenarios where you create and deploy applications from sources other than WAR or JAR packages, see the following topics for information about multi-architecture image support:

• Build multi-architecture container images:

  • Build multi-architecture container images

  • Build and push multi-architecture images to Container Registry from your computer

• Schedule workloads: Schedule workloads to ARM nodes