Running Applications on Arm-based Nodes

To run an application on an Arm-based worker node in a cluster, the application has to run on a node in a node pool for which you've specified an Arm-based shape. The shape determines the number of CPUs and the amount of memory allocated to each node in the node pool. You can select Arm-based bare metal shapes and flexible VM shapes. These Ampere A1 Compute instances are based on the Ampere Altra processor (see Arm-Based Compute). For information about the OCPU count, memory, storage, and networking details of these shapes, see Compute Shapes.

You can specify an Arm-based shape for a node pool using the Console, the API, and the CLI when you create a new cluster. You can also specify an Arm-based shape when you create a new node pool. See the node pool configuration steps in Creating a Kubernetes Cluster and Updating Worker Nodes by Creating a New Node Pool respectively.

To view the number of reservable Arm-based cores available to you, use the Console. Open the navigation menu and click Governance & Administration. Under Governance, click Limits, Quotas and Usage.

Compared to other shapes, Arm-based shapes provide better price-performance, greater security isolation (because each core is single-threaded), and more consistent performance. Typically, developers use Arm-based worker nodes in Kubernetes clusters to develop and test applications.

When you deploy an application on a cluster you've created with Container Engine for Kubernetes, you have to specify in the pod spec the compute resources that are required. To deploy the application, the kube-scheduler determines which node has the necessary resources. If a cluster has node pools with Arm-based shapes and also node pools with other shapes (for example, AMD64 shapes), you can use a nodeSelector in the pod spec to specify that an application is to run on Arm-based worker nodes. See Defining a pod to run only on Arm-based nodes.

If you want to deploy an application on both Arm-based and non-Arm-based worker nodes in the same cluster, use multi-architecture images (sometimes known as manifest lists) stored in an Open Container Initiative-compliant registry like Oracle Cloud Infrastructure Registry (see Overview of Container Registry). You build multi-architecture images from a single source tree, with one image tag that includes images for both x86 and Arm architectures. You can build multi-architecture images using Docker Buildx, Podman, and Buildah.

Note the following:

  • You can specify Arm-based shapes for node pools in clusters that have Kubernetes API endpoints hosted in a subnet of your VCN (known as native VCN clusters). Do not specify an Arm-based shape for node pools in a cluster if the cluster's Kubernetes API endpoint is not integrated into your VCN.
  • You can specify Arm-based shapes for node pools in clusters running Kubernetes version 1.19.7 or later. Do not specify an Arm-based shape for node pools running earlier versions of Kubernetes.
  • Having created a node pool with an Arm-based shape, you cannot change the node pool to have a non-Arm-based shape. Likewise, you cannot change a node pool with a non-Arm-based shape to have an Arm-based shape.
  • When you specify an Arm-based shape for a node pool, you also specify an image that is compatible with the shape. See Compute Shapes.

Defining a pod to run only on Arm-based nodes

If a cluster has node pools with Arm-based shapes and also node pools with other shapes (for example, AMD64 shapes), you can use a nodeSelector in the pod spec to specify that an application is to run only on Arm-based worker nodes. For example, the following configuration file defines a pod to run on any Arm-based node in the cluster:


apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    kubernetes.io/arch: arm64