**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# EKS 자율 모드 클러스터에서 샘플 워크로드 실행
이 장에서는 Auto Mode에서 실행되는 Amazon EKS 클러스터에 다양한 유형의 워크로드를 배포하는 방법의 예를 제공합니다. 이 예제에서는 샘플 애플리케이션, 로드 밸런싱된 웹 애플리케이션, 영구 스토리지를 사용하는 상태 저장 워크로드, 특정 노드 배치 요구 사항이 있는 워크로드를 포함한 주요 워크로드 패턴을 보여줍니다. 각 예제에는 자체 애플리케이션의 템플릿으로 사용할 수 있는 전체 매니페스트와 단계별 배포 지침이 포함되어 있습니다.
예제를 진행하기 전에 Auto Mode에서 실행 중인 EKS 클러스터가 있고 AWS CLI 및 kubectl을 설치했는지 확인합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요. 이 예제에서는 Kubernetes 개념 및 kubectl 명령을 기본적으로 잘 알고 있다고 가정합니다.
이러한 사용 사례 기반 샘플을 사용하여 EKS Auto Mode 클러스터에서 워크로드를 실행할 수 있습니다.
[Amazon EKS Auto Mode 클러스터에 샘플 팽창 워크로드 배포](automode-workload.md)
`kubectl` 명령을 사용하여 EKS Auto Mode 클러스터에 샘플 워크로드를 배포하는 방법을 보여줍니다.
[EKS 자율 모드에 샘플 로드 밸런서 워크로드 배포](auto-elb-example.md)
Amazon EKS에서 2048 게임의 컨테이너화된 버전을 배포하는 방법을 보여줍니다.
[EKS Auto Mode에 샘플 상태 저장 워크로드 배포](sample-storage-workload.md)
EKS Auto Mode 클러스터에 샘플 상태 저장 애플리케이션을 배포하는 방법을 보여줍니다.
[가속화된 워크로드 배포](auto-accelerated.md)
EKS Auto Mode에서 관리하는 노드에 하드웨어 가속 워크로드를 배포하는 방법을 보여줍니다.
[EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md)
주석을 사용하여 EKS Auto Mode에서 관리하는 노드에 워크로드가 배포되는지 여부를 제어하는 방법을 보여줍니다.
# Amazon EKS Auto Mode 클러스터에 샘플 팽창 워크로드 배포
이 자습서에서는 EKS Auto Mode 클러스터에 샘플 워크로드를 배포하고 필요한 컴퓨팅 리소스를 자동으로 프로비저닝하는 방법을 알아봅니다. `kubectl` 명령을 사용하여 클러스터의 동작을 관찰하고 Auto Mode가 AWS에서 Kubernetes 작업을 간소화하는 방법을 직접 확인할 수 있습니다. 이 자습서를 마치면 수동 노드 그룹 구성 없이 기본 컴퓨팅 리소스를 자동으로 관리하여 EKS Auto Mode가 워크로드 배포에 대응하는 방식을 이해할 수 있습니다.
## 사전 조건
+ Amazon EKS 자동 모드 클러스터. 클러스터의 이름과 AWS 리전을 기록해 둡니다.
+ IAM 보안 주체가 네트워킹, 컴퓨팅, EKS 리소스를 관리할 수 있는 충분한 권한이 있는 사용자 또는 역할입니다.
+ 자세한 내용은 IAM 사용 설명서의 [Creating roles and attaching policies in the IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)을 참조하세요.
+ `aws` CLI가 IAM 자격 증명으로 설치 및 구성되었습니다.
+ `kubectl` CLI가 설치되고 클러스터에 연결되었습니다.
+ 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
## 1단계: 기존 컴퓨팅 리소스 검토(선택 사항)
먼저 `kubectl`을 사용하여 클러스터의 노드 풀을 나열합니다.
```
kubectl get nodepools
```
샘플 출력:
```
general-purpose
```
이 자습서에서는 `general-purpose` 노드 풀을 사용하도록 구성된 워크로드를 배포합니다. 이 노드 풀은 EKS Auto Mode에 내장되어 있으며 마이크로서비스 및 웹 앱과 같은 일반 워크로드에 대한 합리적인 기본값을 포함합니다. 자체 노드 풀을 생성할 수 있습니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
둘째, `kubectl`을 사용하여 클러스터에 연결된 노드를 나열합니다.
```
kubectl get nodes
```
방금 EKS Auto Mode 클러스터를 생성한 경우 노드가 없습니다.
이 자습서에서는 샘플 워크로드를 배포합니다. 노드가 없거나 워크로드가 기존 노드에 맞지 않는 경우 EKS Auto Mode가 새 노드를 프로비저닝합니다.
## 2단계: 클러스터에 샘플 애플리케이션 배포
다음 Kubernetes 배포를 검토하고 `inflate.yaml`로 저장합니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
`eks.amazonaws.com/compute-type: auto` 선택기를 사용하려면 Amazon EKS Auto Mode 노드에 워크로드를 배포해야 합니다.
배포를 클러스터에 적용합니다.
```
kubectl apply -f inflate.yaml
```
## 3단계: Kubernetes 이벤트 보기
다음 명령을 사용하여 새 노드 생성을 포함한 Kubernetes 이벤트를 관찰합니다. `ctrl+c`를 사용하여 이벤트 시청을 중지합니다.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
`kubectl`을 사용하여 클러스터에 연결된 노드를 다시 나열합니다. 새로 생성된 노드를 기록해 둡니다.
```
kubectl get nodes
```
## 4단계: AWS 콘솔에서 노드 및 인스턴스 보기
EKS 콘솔에서 EKS Auto Mode 노드를 보고 EC2 콘솔에서 연결된 EC2 인스턴스를 볼 수 있습니다.
EKS Auto Mode에서 배포한 EC2 인스턴스는 제한됩니다. EKS Auto Mode 노드에서는 임의의 명령을 실행할 수 없습니다.
## 5단계: 배포 삭제
`kubectl`을 사용하여 샘플 배포를 삭제합니다.
```
kubectl delete -f inflate.yaml
```
클러스터에 배포된 다른 워크로드가 없는 경우 EKS Auto Mode에서 생성한 노드는 비어 있습니다.
기본 구성에서 EKS Auto Mode는 30초 동안 비어 있는 노드를 감지하고 종료합니다.
`kubectl` 또는 EC2 콘솔을 사용하여 연결된 인스턴스가 삭제되었는지 확인합니다.
# EKS 자율 모드에 샘플 로드 밸런서 워크로드 배포
이 가이드에서는 로드 밸런싱 및 인터넷 접근성이 포함된 Amazon EKS에 2048 게임의 컨테이너화된 버전을 배포하는 방법을 안내합니다.
## 사전 조건
+ EKS Auto Mode 클러스터
+ `kubectl`이 클러스터와 상호 작용하도록 구성됨
+ ALB 리소스 생성을 위한 적절한 IAM 권한
## 1단계: 네임스페이스 생성
먼저 2048 게임 애플리케이션을 위한 전용 네임스페이스를 생성합니다.
`01-namespace.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
네임스페이스 구성을 적용합니다.
```
kubectl apply -f 01-namespace.yaml
```
## 2단계: 애플리케이션 배포
애플리케이션은 2048 게임 컨테이너의 여러 복제본을 실행합니다.
`02-deployment.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**참고**
이미지 `public.ecr.aws/l6m2t8p7/docker-2048:latest`를 로드하는 동안 오류가 발생하면 노드 IAM 역할에 ECR에서 이미지를 가져올 수 있는 충분한 권한이 있는지 확인합니다. 자세한 내용은 [노드 IAM 역할](auto-learn-iam.md#auto-learn-node-iam-role) 섹션을 참조하세요. 또한 예제의 `docker-2048` 이미지는 `x86_64` 이미지이며 다른 아키텍처에서는 실행되지 않습니다.
**핵심 구성 요소:**
+ 애플리케이션의 복제본 5개 배포
+ 퍼블릭 ECR 이미지 사용
+ 포드당 0.5 CPU 코어 요청
+ HTTP 트래픽에 포트 80 노출
배포를 적용합니다.
```
kubectl apply -f 02-deployment.yaml
```
## 3단계: 서비스 생성
서비스는 배포를 클러스터 네트워크에 노출합니다.
`03-service.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**핵심 구성 요소:**
+ NodePort 서비스 생성
+ 포트 80을 컨테이너의 포트 80에 매핑
+ 레이블 선택기를 사용하여 포드 찾기
서비스를 적용합니다.
```
kubectl apply -f 03-service.yaml
```
## 4단계: 로드 밸런싱 구성
애플리케이션을 인터넷에 노출하도록 수신을 설정합니다.
먼저 `IngressClass`를 생성합니다. `04-ingressclass.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**참고**
EKS 자동 모드에서는 퍼블릭 및 프라이빗 서브넷을 식별하기 위해 서브넷 태그가 필요합니다.
`eksctl`로 클러스터를 생성한 경우 이미 이러한 태그가 있는 것입니다.
[EKS 자동 모드의 태그 서브넷](tag-subnets-auto.md) 방법에 대해 알아봅니다.
그런 다음 수신 리소스를 생성합니다. `05-ingress.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**핵심 구성 요소:**
+ 인터넷 연결 ALB 생성
+ 직접 포드 라우팅에 IP 대상 유형 사용
+ 모든 트래픽(/)을 게임 서비스로 라우팅
수신 구성을 적용합니다.
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## 5단계: 배포 확인
1. 모든 포드가 실행 중인지 확인합니다.
```
kubectl get pods -n game-2048
```
1. 서비스가 생성되었는지 확인합니다.
```
kubectl get svc -n game-2048
```
1. ALB 엔드포인트를 가져옵니다.
```
kubectl get ingress -n game-2048
```
수신 출력의 ADDRESS 필드에 ALB 엔드포인트가 표시됩니다. ALB가 모든 대상을 프로비저닝하고 등록할 때까지 2\$13분 기다립니다.
## 6단계: 게임에 액세스
웹 브라우저를 열고 이전 단계에서 ALB 엔드포인트 URL로 이동합니다. 2048 게임 인터페이스가 표시됩니다.
## 7단계: 정리
이 자습서에서 만든 리소스를 모두 제거합니다.
```
kubectl delete namespace game-2048
```
그러면 배포, 서비스 및 수신 리소스를 포함하여 네임스페이스의 모든 리소스가 삭제됩니다.
## 비하인드 스토리
1. 배포를 통해 2048 게임을 실행하는 포드 5개 생성
1. 해당 서비스는 이러한 포드에 대한 안정적인 네트워크 액세스 제공
1. EKS Auto Mode:
+ AWS에서 Application Load Balancer 생성
+ 포드의 대상 그룹 구성
+ 트래픽이 서비스로 전달되도록 라우팅 규칙 설정
## 문제 해결
게임이 로드되지 않는 경우 다음을 수행합니다.
+ 모든 포드가 실행 중인지 확인: `kubectl get pods -n game-2048`
+ 수신 상태 확인: `kubectl describe ingress -n game-2048`
+ ALB 상태 확인: AWS 콘솔에서 대상 그룹 상태 확인
# EKS Auto Mode에 샘플 상태 저장 워크로드 배포
이 자습서에서는 EKS Auto Mode 클러스터에 샘플 상태 저장 애플리케이션을 배포하는 방법을 안내합니다. 애플리케이션은 영구 볼륨에 타임스탬프를 기록하여 EKS Auto Mode의 자동 EBS 볼륨 프로비저닝 및 지속성 기능을 보여줍니다.
## 사전 조건
+ EKS Auto Mode 클러스터
+ 적절한 권한으로 구성된 AWS CLI
+ `kubectl` 설치 및 구성
+ 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
## 1단계: 환경 구성
1. 환경 변수를 설정합니다.
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. kubeconfig를 업데이트합니다.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## 2단계: 스토리지 클래스 생성
`StorageClass`는 EKS 자동 모드가 EBS 볼륨을 프로비저닝하는 방법을 정의합니다.
EKS 자동 모드는 `StorageClass`를 생성하지 않습니다. EKS 자동 모드의 스토리지 기능을 사용하려면 `ebs.csi.eks.amazonaws.com`을 참조하는 `StorageClass`를 생성해야 합니다.
1. `storage-class.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. `StorageClass`를 적용합니다.
```
kubectl apply -f storage-class.yaml
```
**핵심 구성 요소:**
+ `provisioner: ebs.csi.eks.amazonaws.com`-EKS Auto Mode를 사용합니다.
+ `volumeBindingMode: WaitForFirstConsumer`-포드에 필요할 때까지 볼륨 생성을 지연합니다.
+ `type: gp3`-EBS 볼륨 유형을 지정합니다.
+ `encrypted: "true"`-EBS는 기본 `aws/ebs` 키를 사용하여 이 클래스로 생성된 볼륨을 암호화합니다. 이는 선택 사항이며, 권장 사항은 아닙니다.
+ `storageclass.kubernetes.io/is-default-class: "true"`-영구 볼륨 클레임에서 다른 볼륨 클래스를 지정하지 않는 한 Kubernetes는 기본적으로 이 스토리지 클래스를 사용합니다. 다른 스토리지 컨트롤러에서 마이그레이션하는 경우 이 값을 설정할 때 주의하세요. (선택 사항)
## 3단계: 영구 볼륨 클레임 생성
PVC는 `StorageClass`에서 스토리지를 요청합니다.
1. `pvc.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. PVC를 적용합니다.
```
kubectl apply -f pvc.yaml
```
**핵심 구성 요소:**
+ `accessModes: ReadWriteOnce`-한 번에 한 노드씩 볼륨 탑재 가능
+ `storage: 8Gi`-8GiB 볼륨 요청
+ `storageClassName: auto-ebs-sc` - 생성한 `StorageClass`를 참조합니다.
## 4단계: 애플리케이션 배포
배포는 영구 볼륨에 타임스탬프를 기록하는 컨테이너를 실행합니다.
1. `deployment.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. 배포를 적용합니다.
```
kubectl apply -f deployment.yaml
```
**핵심 구성 요소:**
+ 파일에 타임스탬프를 기록하는 단순 Bash 컨테이너
+ `/data`에 PVC 탑재
+ CPU 코어 1개 요청
+ EKS 관리형 노드에 노드 선택기 사용
## 5단계: 설정 확인
1. 포드가 실행 중인지 확인합니다.
```
kubectl get pods -l app=inflate-stateful
```
1. PVC가 바인딩되었는지 확인합니다.
```
kubectl get pvc auto-ebs-claim
```
1. EBS 볼륨을 확인합니다.
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. 데이터가 작성되고 있는지 확인합니다.
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## 6단계: 정리
다음 명령을 실행하여 이 자습서에서 만든 리소스를 모두 제거합니다.
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## 비하인드 스토리
1. PVC는 `StorageClass`에서 스토리지를 요청합니다.
1. 포드가 예약된 경우:
1. EKS Auto Mode는 EBS 볼륨을 프로비저닝합니다.
1. PersistentVolume을 생성합니다.
1. 노드에 볼륨을 연결합니다.
1. 포드가 볼륨을 탑재하고 타임스탬프 작성을 시작합니다.
## 스냅샷 컨트롤러
EKS Auto Mode는 스냅샷 컨트롤러라고도 하는 Kubernetes CSI Snapshotter와 호환됩니다. 그러나 EKS Auto Mode에는 스냅샷 컨트롤러가 포함되지 않습니다. 스냅샷 컨트롤러의 설치와 구성은 사용자의 책임입니다. 자세한 내용은 [CSI 볼륨의 스냅샷 기능 활성화](csi-snapshot-controller.md) 단원을 참조하십시오.
EKS Auto Mode의 스토리지 기능을 참조하는 다음 `VolumeSnapshotClass`를 검토합니다.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Kubernetes CSI Snapshotter에 대해 자세히 알아보세요.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 가속화된 워크로드 배포
이 자습서에서는 Amazon EKS Auto Mode가 하드웨어 가속 워크로드 시작을 단순화하는 방법을 보여줍니다. Amazon EKS Auto Mode는 컴퓨팅, 네트워킹, 로드 밸런싱, 스토리지, Identity Access and Management 기능을 즉시 제공하는 주요 인프라 구성 요소를 자동화하여 클러스터 자체를 넘어 운영을 간소화합니다.
Amazon EKS Auto Mode에는 NVIDIA 및 AWS Neuron 드라이버와 같은 특정 인스턴스 유형에 필요한 드라이버와 디바이스 플러그인이 포함되어 있습니다. 이러한 구성 요소를 설치 또는 업데이트할 필요가 없습니다.
EKS Auto Mode는 이러한 액셀러레이터의 드라이버를 자동으로 관리합니다.
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Amazon EC2 가속 인스턴스의 NVIDIA GPU](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**참고**
EKS Auto Mode에는 Kubernetes용 NVIDIA 디바이스 플러그인이 포함되어 있습니다. 이 플러그인은 자동으로 실행되고 클러스터에서 대몬 세트로 표시되지 않습니다.
추가 네트워킹 지원:
+ [Elastic Fabric Adapter(EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS Auto Mode를 사용하면 액셀러레이터 드라이버 및 디바이스 플러그인 관리할 필요가 없습니다.
클러스터를 0으로 조정하면 비용을 절감할 수도 있습니다. 실행 중인 워크로드가 없을 때 인스턴스를 종료하도록 EKS Auto Mode를 구성할 수 있습니다. 이는 배치 기반 추론 워크로드에 유용합니다.
다음은 Amazon EKS Auto Mode를 사용하여 가속화된 워크로드를 시작하는 방법의 예제입니다.
## 사전 조건
+ Amazon EKS Auto Mode가 구성된 Kubernetes 클러스터.
+ `general-purpose` 또는 `system` 관리형 노드 풀이 활성화될 때 생성된 `default` EKS 노드 클래스.
## 1단계: GPU 워크로드 배포
이 예제에서는 45GB GPU 메모리가 필요한 NVIDIA 기반 워크로드용 NodePool을 생성합니다. EKS Auto Mode에서는 Kubernetes 예약 제약 조건을 사용하여 인스턴스 요구 사항을 정의합니다.
Amazon EKS Auto Mode `NodePool` 및 샘플 `workload`를 배포하려면 다음 NodePool 및 포드 정의를 검토하고 `nodepool-gpu.yaml` 및 `pod.yaml`로 저장합니다.
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
`eks.amazonaws.com/compute-type: auto` 선택기를 사용하려면 Amazon EKS Auto Mode 노드에 워크로드를 배포해야 합니다. 또한 NodePool은 Nvidia GPU가 예약되도록 허용 오차가 있는 포드만 허용하는 테인트를 설정합니다.
클러스터에 NodePool과 워크로드를 적용합니다.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
다음 결과가 표시됩니다.
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
몇 초 정도 기다리고, 클러스터의 노드를 확인합니다. 이제 Amazon EKS Auto Mode 클러스터에 프로비저닝된 새 노드가 표시됩니다.
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## 2단계: 검증
다음 Kubernetes 예약 제약 조건에 따라 워크로드에 l40s `GPU`가 있는 인스턴스가 필요하므로 Amazon EKS Auto Mode가 `g6.2xlarge` 대신 `g6e.2xlarge`를 시작한 것을 확인할 수 있습니다.
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
이제 다음 명령을 실행하여 컨테이너 로그를 살펴봅니다.
```
kubectl logs nvidia-smi
```
샘플 출력은 다음과 같습니다.
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
컨테이너가 `NVIDIA` GPU가 있는 인스턴스에서 실행 중임을 감지했으며 Amazon EKS Auto Mode에서 관리하므로 디바이스 드라이버를 설치할 필요가 없음을 알 수 있습니다.
## 3단계: 정리
생성된 모든 객체를 제거하려면 `kubectl`을 사용하여 노드가 종료되도록 샘플 배포와 NodePool을 삭제합니다.
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePools 참조 예제
### NVIDIA NodePool 생성
다음 NodePool에서 정의하는 사항:
+ `g6e` 및 `g6` 패밀리의 인스턴스만 시작
+ 1시간 동안 비어 있는 경우 노드 통합
+ `consolodateAfter`의 1시간 값은 급증하는 워크로드를 지원하고 노드 이탈을 줄입니다. 워크로드 요구 사항에 따라 `consolidateAfter`를 조정할 수 있습니다.
**GPU 인스턴스 패밀리 및 통합이 포함된 NodePool 예제**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
`eks.amazonaws.com/instance-gpu-name`을 설정하는 대신 `eks.amazonaws.com/instance-family`를 사용하여 인스턴스 패밀리를 지정할 수 있습니다. 예약 검토에 영향을 미치는 다른 잘 알려진 레이블은 [EKS 자동 모드 지원 레이블](create-node-pool.md#auto-supported-labels) 섹션을 참조하세요.
특정 스토리지 요구 사항이 있는 경우 NodePool의 참조에 대해 [NodeClass](create-node-class.md)를 생성하여 노드 임시 스토리지 `iops`, `size` 및 `throughput`를 조정할 수 있습니다. [구성 가능한 NodeClass 옵션](create-node-class.md)에 대해 자세히 알아봅니다.
**NodeClass의 스토리지 구성 예제**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### AWS Trainium 및 AWS Inferentia NodePool 정의
다음 NodePool에는 Inferentia 및 Trainium 패밀리의 인스턴스만 시작하도록 하는 `eks.amazonaws.com/instance-category` 세트가 있습니다.
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```