이 페이지에서는 Arm 아키텍처에서 지원하는 노드를 요청하도록 Google Kubernetes Engine(GKE) Autopilot 배포를 구성하는 방법을 보여줍니다.
Autopilot의 ARM 아키텍처 정보
Autopilot 클러스터는 특정 하드웨어 요구사항이 있는 워크로드에 대해 컴퓨팅 클래스를 제공합니다. 이러한 컴퓨팅 클래스 중 일부는 amd64 및 arm64와 같은 여러 CPU 아키텍처를 지원합니다.
ARM 노드 사용 사례
Arm 아키텍처를 사용하는 노드는 비슷한 x86 노드보다 더 비용 효율적인 성능을 제공합니다. 다음과 같은 상황에서 Autopilot 워크로드에 Arm을 선택해야 합니다.
개발자 환경은 빌드 및 테스트에 ARM 아키텍처를 사용합니다.
Arm CPU에서 실행되는 Android 기기용 애플리케이션을 개발합니다.
멀티 아키텍처 이미지를 사용하고 워크로드를 실행하면서 비용을 최적화하길 원합니다.
Autopilot에서 ARM 노드를 요청하는 방법
포드에 대해 Arm 노드를 요청하려면 Arm 아키텍처를 사용하여 노드를 요청하고 Arm 노드를 지원하는 컴퓨팅 클래스를 요청해야 합니다. 다음 섹션에서는 포드 사양에서 노드 선택기 또는 노드 어피니티 규칙을 사용하여 컴퓨팅 클래스와 ARM 아키텍처를 요청하는 방법을 설명합니다.
노드 어피니티를 사용하여 Arm 노드를 요청할 수 있습니다. 사용할 노드 어피니티 유형을 지정할 수도 있습니다.
requiredDuringSchedulingIgnoredDuringExecution: 지정된 컴퓨팅 클래스 및 아키텍처를 사용해야 합니다.
preferredDuringSchedulingIgnoredDuringExecution: 가능한 한 지정된 컴퓨팅 클래스 및 아키텍처를 사용합니다. 예를 들어 기존 x86 노드를 할당할 수 있으면 GKE가 새 Arm 노드를 프로비저닝하는 대신 x86 노드에 포드를 배치합니다. 멀티 아키텍처 이미지 매니페스트를 사용하지 않는 한 포드가 다운됩니다. 원하는 특정 아키텍처를 명시적으로 요청하는 것이 좋습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-11-21(UTC)"],[],[],null,["# Deploy Autopilot workloads on Arm architecture\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview)\n\n*** ** * ** ***\n\nThis page shows you how to configure your Google Kubernetes Engine (GKE)\nAutopilot deployments to request nodes that are backed by Arm\narchitecture.\n\nAbout Arm architecture in Autopilot\n-----------------------------------\n\nAutopilot clusters offer\n[*compute classes*](/kubernetes-engine/docs/concepts/autopilot-compute-classes)\nfor workloads that have specific hardware requirements. Some of these compute\nclasses support multiple CPU architectures, such as `amd64` and `arm64`.\n\nUse cases for Arm nodes\n-----------------------\n\nNodes with Arm architecture offer more cost-efficient performance than similar\nx86 nodes. You should select Arm for your Autopilot workloads in\nsituations such as the following:\n\n- Your environment relies on Arm architecture for building and testing.\n- You're developing applications for Android devices that run on Arm CPUs.\n- You use multi-arch images and want to optimize costs while running your workloads.\n\nBefore you begin\n----------------\n\nBefore you start, make sure that you have performed the following tasks:\n\n- Enable the Google Kubernetes Engine API.\n[Enable Google Kubernetes Engine API](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com)\n- If you want to use the Google Cloud CLI for this task, [install](/sdk/docs/install) and then [initialize](/sdk/docs/initializing) the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running `gcloud components update`. **Note:** For existing gcloud CLI installations, make sure to set the `compute/region` [property](/sdk/docs/properties#setting_properties). If you use primarily zonal clusters, set the `compute/zone` instead. By setting a default location, you can avoid errors in the gcloud CLI like the following: `One of [--zone, --region] must be supplied: Please specify location`. You might need to specify the location in certain commands if the location of your cluster differs from the default that you set.\n\n\u003c!-- --\u003e\n\n- Review the [requirements and limitations for Arm\n nodes](/kubernetes-engine/docs/concepts/arm-on-gke#arm-requirements-limitations).\n- Ensure that you have quota for the [C4A](/compute/docs/general-purpose-machines#c4a_series) or [Tau T2A](/compute/docs/general-purpose-machines#t2a_machines) Compute Engine machine types.\n- Ensure that you have a Pod with a container image that's built for Arm architecture.\n\nHow to request Arm nodes in Autopilot\n-------------------------------------\n\nTo tell Autopilot to run your Pods on Arm nodes, specify one of the\nfollowing labels in a\n[nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)\nor [node\naffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)\nrule:\n\n- `kubernetes.io/arch: arm64`. GKE places Pods on `C4A` machine types by default for clusters running version 1.31.3-gke.1056000 and later. If the cluster is running an earlier version, GKE places Pods on `T2A` machine types.\n- `cloud.google.com/machine-family: `\u003cvar translate=\"no\"\u003eARM_MACHINE_SERIES\u003c/var\u003e. Replace \u003cvar translate=\"no\"\u003eARM_MACHINE_SERIES\u003c/var\u003e with an Arm machine series like `C4A` or `T2A`. GKE places Pods on the specified series.\n\nBy default, using either of the labels lets GKE place other Pods\non the same node if there's availability capacity on that node. To request a\ndedicated node for each Pod, add the `cloud.google.com/compute-class:\nPerformance` label to your manifest. For details, see [Optimize\nAutopilot Pod performance by choosing a machine\nseries](/kubernetes-engine/docs/how-to/performance-pods).\n\nOr, you can use the `Scale-Out` label with the `arm64` label to request `T2A`.\nYou can also request Arm architecture for [Spot Pods](/kubernetes-engine/docs/how-to/autopilot-spot-pods).\n\nWhen you deploy your workload, Autopilot does the following:\n\n1. Automatically provisions Arm nodes to run your Pods.\n2. Automatically taints the new nodes to prevent non-Arm Pods from being scheduled on those nodes.\n3. Automatically adds a toleration to your Arm Pods to allow scheduling on the new nodes.\n\nExample request for Arm architecture\n------------------------------------\n\nThe following example specifications show you how to use a node selector or a\nnode affinity rule to request Arm architecture in Autopilot. \n\n### nodeSelector\n\nThe following example manifest shows you how to request Arm nodes in a\nnodeSelector: \n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: nginx-arm\n spec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx-arm\n template:\n metadata:\n labels:\n app: nginx-arm\n spec:\n nodeSelector:\n cloud.google.com/compute-class: Performance\n kubernetes.io/arch: arm64\n containers:\n - name: nginx-arm\n image: nginx\n resources:\n requests:\n cpu: 2000m\n memory: 2Gi\n\n### nodeAffinity\n\nYou can use\n[node affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)\nto request Arm nodes. You can also specify the type of node affinity to use:\n\n- `requiredDuringSchedulingIgnoredDuringExecution`: Must use the specified compute class and architecture.\n- `preferredDuringSchedulingIgnoredDuringExecution`: Use the specified compute class and architecture on a best-effort basis. For example, if an existing x86 node is allocatable, GKE places your Pod on the x86 node instead of provisioning a new Arm node. Unless you're using a multi-arch image manifest, your Pod will crash. We strongly recommend that you explicitly request the specific architecture that you want.\n\nThe following example manifest *requires* the `Performance` class and Arm\nnodes: \n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: nginx-arm\n spec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx-arm\n template:\n metadata:\n labels:\n app: nginx-arm\n spec:\n terminationGracePeriodSeconds: 25\n containers:\n - name: nginx-arm\n image: nginx\n resources:\n requests:\n cpu: 2000m\n memory: 2Gi\n ephemeral-storage: 1Gi\n affinity:\n nodeAffinity:\n requiredDuringSchedulingIgnoredDuringExecution:\n nodeSelectorTerms:\n - matchExpressions:\n - key: cloud.google.com/compute-class\n operator: In\n values:\n - Performance\n - key: kubernetes.io/arch\n operator: In\n values:\n - arm64\n\nRecommendations\n---------------\n\n- [Build and use multi-arch images](/kubernetes-engine/docs/how-to/build-multi-arch-for-arm) as part of your pipeline. Multi-arch images ensure that your Pods run even if they're placed on x86 nodes.\n- Explicitly request architecture and compute classes in your workload manifests. If you don't, Autopilot uses the default architecture of the selected compute class, which might not be Arm.\n\nAvailability\n------------\n\nYou can deploy Autopilot workloads on Arm architecture in\nGoogle Cloud locations that support Arm architecture. For details, see\n[Available regions and zones](/compute/docs/regions-zones#available).\n\nTroubleshooting\n---------------\n\nFor common errors and troubleshooting information, refer to\n[Troubleshooting Arm workloads](/kubernetes-engine/docs/troubleshooting/troubleshooting-arm-workloads).\n\nWhat's next\n-----------\n\n- [Learn more about Autopilot cluster architecture](/kubernetes-engine/docs/concepts/autopilot-architecture).\n- [Learn about the lifecycle of Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/).\n- [Learn about the available Autopilot compute classes](/kubernetes-engine/docs/concepts/autopilot-compute-classes).\n- [Read about the default, minimum, and maximum resource requests for each\n platform](/kubernetes-engine/docs/concepts/autopilot-resource-requests)."]]