AL2에서 AL2023으로 업그레이드 가속 Arm Docker에서 containerd로 마이그레이션 테스트 추가 정보

Amazon EKS 최적화 Amazon Linux AMI

Amazon EKS 최적화 Amazon Linux AMI는 Amazon Linux 2(AL2) 및 Amazon Linux 2023(AL2023) 기반으로 빌드됩니다. Amazon EKS 노드의 기본 이미지 역할을 하도록 구성되었습니다. AMI는 Amazon EKS와 연동하도록 구성되며 다음과 같은 구성 요소가 포함됩니다.

kubelet
AWS IAM 인증자
Docker(Amazon EKS 버전 1.23 이하)
containerd

참고

Amazon Linux 보안 센터에서 AL2의 보안 또는 프라이버시 이벤트를 추적하거나 관련 RSS 피드를 구독할 수 있습니다. 보안 및 프라이버시 이벤트에는 문제의 개요, 영향을 받는 패키지 및 인스턴스를 업데이트하여 문제를 해결하는 방법이 포함됩니다.
가속 또는 Arm AMI를 배포하기 전에 Amazon EKS 최적화 가속 Amazon Linux AMI 및 Amazon EKS 최적화 Arm Amazon Linux AMI의 정보를 검토하세요.
Kubernetes 버전 1.23의 경우 선택적 부트스트랩 플래그를 사용하여 Docker에서 containerd로의 마이그레이션을 테스트할 수 있습니다. 자세한 내용은 Docker에서 containerd로 마이그레이션 테스트 단원을 참조하십시오.
Kubernetes 버전 1.25부터 Amazon EKS 최적화 가속 Amazon Linux AMI와 함께 즉시 사용 가능한 Amazon EC2 P2 인스턴스를 더 이상 사용할 수 없습니다. Kubernetes 버전 1.25 이상의 이러한 AMI는 P2 인스턴스와 호환되지 않는 NVIDIA 525 이후 시리즈의 드라이버를 지원합니다. 하지만 NVIDIA 525 이후 시리즈의 드라이버는 P3, P4, 및 P5 인스턴스와 호환되므로 이러한 인스턴스를 Kubernetes 버전 1.25 이상의 AMI와 함께 사용할 수 있습니다. Amazon EKS 클러스터를 버전 1.25로 업그레이드하기 전에 P2 인스턴스를 P3, P4 및 P5 인스턴스로 마이그레이션하세요. 또한, NVIDIA 525 이후 시리즈에서 작동하려면 애플리케이션을 사전에 업그레이드해야 합니다. 2024년 1월 말에 최신 NVIDIA 525 시리즈 이상의 드라이버를 Kubernetes 버전 1.23 및 1.24로 백포팅할 계획입니다.
Amazon EKS 버전 1.30 이상부터 새로 생성되는 모든 관리형 노드 그룹은 자동으로 AL2023을 기본 노드 운영 체제로 사용합니다. 이전에는 새 노드 그룹이 AL2를 기본 노드 운영 체제로 사용했습니다. 새 노드 그룹을 생성할 때 AL2를 AMI 유형으로 선택하여 계속 사용할 수 있습니다.
AL2 지원은 2025년 6월 30일에 종료됩니다. 자세한 내용은 Amazon Linux 2 FAQs를 참조하십시오.

AL2에서 AL2023으로 업그레이드

Amazon EKS 최적화 AMI는 AL2와 AL2023 기반으로 제공됩니다. AL2023은 클라우드 애플리케이션에 안전하고 안정적이면서 고성능의 환경을 제공하도록 설계된 새로운 Linux 기반 운영 체제입니다. Amazon Web Services의 차세대 Amazon Linux로, 확장 지원 버전 1.23 및 1.24를 포함하여 지원되는 모든 Amazon EKS 버전에서 사용할 수 있습니다. AL2023 기반의 Amazon EKS 가속 AMI는 향후에 제공될 예정입니다. 워크로드를 가속화하면 AL2 가속 AMI 또는 Bottlerocket을 계속 사용해야 합니다.

AL2023은 AL2에 비해 몇 가지 향상된 기능을 제공합니다. 전체 비교는 Amazon Linux 2023 사용 설명서의 AL2와 Amazon Linux 2023 비교를 참조하세요. AL2에서 여러 패키지가 추가, 업그레이드 및 제거되었습니다. 업그레이드하기 전에 AL2023 버전으로 애플리케이션을 테스트하는 것이 좋습니다. AL2023 패키지의 모든 변경 사항 목록은 Amazon Linux 2023 릴리스 정보의 Amazon Linux 2023의 패키지 변경 사항을 참조하세요.

이러한 변경 사항 외에도 다음 사항을 숙지해야 합니다.

AL2023에 YAML 구성 스키마를 사용하는 새로운 노드 초기화 프로세스 nodeadm이 도입됩니다. 자체 관리형 노드 그룹 또는 시작 템플릿이 있는 AMI를 사용하는 경우 이제 새 노드 그룹을 생성할 때 추가 클러스터 메타데이터를 명시적으로 제공해야 합니다. 최소 필수 파라미터의 예시는 다음과 같으며, 여기에서 apiServerEndpoint, certificateAuthority 및 서비스 cidr가 필수입니다.
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
```
AL2에서 이러한 파라미터의 메타데이터는 Amazon EKS DescribeCluster API 직접 호출에서 확인되었습니다. AL2023 버전에서는 대형 노드 스케일 업 도중 추가 API 직접 호출로 인해 제한이 발생할 위험이 있기 때문에 이러한 동작이 변경되었습니다. 시작 템플릿이 없는 관리형 노드 그룹을 사용하거나 Karpenter를 사용하는 경우 이 변경 사항이 영향을 미치지 않습니다. certificateAuthority 및 서비스 cidr에 대한 자세한 내용은 Amazon EKS API 참조의 DescribeCluster를 참조하세요.
Docker는 지원되는 모든 Amazon EKS 버전에 대해 AL2023 버전에서 지원되지 않습니다. AL2의 Amazon EKS 버전 1.24 이상에서 Docker 지원이 종료 및 제거되었습니다. 지원 중단에 대한 자세한 내용은 Dockershim에 대한 Amazon EKS 지원 종료를 참조하세요.
AL2023의 경우 Amazon VPC CNI 버전 1.16.2 이상이 필요합니다.
AL2023의 필수 기본값은 IMDSv2입니다. IMDSv2에는 보안 태세 개선에 도움이 되는 몇 가지 이점이 있습니다. 세션을 시작하려면 간단한 HTTP PUT 요청으로 비밀 토큰을 생성해야 하는 세션 지향 인증 방법을 사용합니다. 세션의 토큰은 1초에서 6시간 사이로 유효할 수 있습니다. IMDSv1에서 IMDSv2로 전환하는 방법에 대한 자세한 내용은 인스턴스 메타데이터 서비스 버전 2 사용으로 전환 및 Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure를 참조하세요. IMDSv1을 사용하려는 경우 인스턴스 메타데이터 옵션 시작 속성을 사용하여 설정을 수동으로 재정의하면 계속 사용할 수 있습니다.

참고
IMDSv2의 경우 관리형 노드 그룹의 기본 홉 수는 1로 설정되어 있습니다. 따라서 컨테이너는 IMDS를 사용하여 노드의 자격 증명에 액세스할 수 없습니다. 노드의 자격 증명에 대한 컨테이너 액세스가 필요한 경우에도 사용자 지정 Amazon EC2 시작 템플릿에서 HttpPutResponseHopLimit를 수동으로 재정의하여 2로 늘리면 됩니다. 아니면 Amazon EKS Pod Identity를 사용하여 IMDSv2 대신 자격 증명을 제공할 수도 있습니다.
AL2023에는 차세대 통합 제어 그룹 계층 구조(cgroupv2)가 있습니다. cgroupv2는 컨테이너 런타임을 구현하는 데 사용되며, systemd에 따라 사용됩니다. AL2023에 시스템이 cgroupv1을 사용하여 실행하도록 할 수 있는 코드가 포함되어 있지만 이 구성은 권장되거나 지원되지 않습니다. 이 구성은 Amazon Linux의 향후 메이저 릴리스에서 완전히 제거될 예정입니다.

기존 관리형 노드 그룹의 경우 시작 템플릿을 사용하는 방식에 따라 인플레이스 업그레이드 또는 블루/그린 업그레이드를 수행할 수 있습니다.

관리형 노드 그룹에서 사용자 지정 AMI를 사용하는 경우 시작 템플릿에서 AMI ID를 교체하여 인플레이스 업그레이드를 수행할 수 있습니다. 이 업그레이드 전략을 수행하기 전에 먼저 애플리케이션과 사용자 데이터가 AL2023으로 전송되는지 확인해야 합니다.
표준 시작 템플릿 또는 AMI ID를 지정하지 않은 사용자 지정 시작 템플릿에서 관리형 노드 그룹을 사용하는 경우 블루/그린 전략을 사용하여 업그레이드해야 합니다. 블루/그린 업그레이드는 대체로 더 복잡하고 AMI 유형으로 AL2023을 지정하는 완전히 새로운 노드 그룹을 생성해야 합니다. 이후 AL2 노드 그룹의 모든 사용자 지정 데이터가 새 OS와 호환되도록 새 노드 그룹을 신중하게 구성해야 합니다. 애플리케이션에서 새 노드 그룹을 테스트하고 검증한 후에는 이전 노드 그룹에서 새 노드 그룹으로 Pods를 마이그레이션할 수 있습니다. 마이그레이션이 완료되면 이전 노드 그룹을 삭제할 수 있습니다.

Karpenter를 사용 중이고 AL2023을 사용하려는 경우 EC2NodeClass amiFamily 필드를 AL2023으로 수정해야 합니다. 기본적으로 드리프트는 Karpenter에서 활성화됩니다. 따라서 amiFamily 필드가 변경되면 Karpenter에서 사용 가능할 때 워커 노드를 최신 AMI로 자동으로 업데이트합니다.

Amazon EKS 최적화 가속 Amazon Linux AMI

참고

AL2023 기반의 Amazon EKS 가속 AMI는 향후에 제공될 예정입니다. 워크로드를 가속화하면 AL2 가속 AMI 또는 Bottlerocket을 계속 사용해야 합니다.

Amazon EKS 최적화 가속 Amazon Linux AMI는 표준 Amazon EKS 최적화 Amazon Linux AMI를 기반으로 구축되었습니다. 이는 GPU, Inferentia 및 Trainium 기반 워크로드를 지원하기 위해 Amazon EKS 노드에 대한 선택적 이미지 역할을 하도록 구성되었습니다.

표준 Amazon EKS 최적화 AMI 구성 외에도 가속 AMI에는 다음이 포함됩니다.

NVIDIA 드라이버
nvidia-container-runtime(기본 실행 시간으로)
AWS Neuron 컨테이너 런타임

가속 AMI에 포함된 최신 구성 요소 목록은 GitHub의 amazon-eks-ami 릴리스를 참조하세요.

참고

Amazon EKS 최적화 가속 AMI는 GPU 및 Inferentia 기반 인스턴스 유형만 지원합니다. 노드 AWS CloudFormation 템플릿에서 이러한 인스턴스 유형을 지정해야 합니다. Amazon EKS 최적화 가속 AMI를 사용하게 되면 NVIDIA의 EULA(사용자 라이선스 계약)에 동의하게 됩니다.
이전에는 Amazon EKS 최적화 가속 AMI를 GPU를 지원하는 Amazon EKS 최적화된 AMI라고 불렀습니다.
Amazon EKS 최적화 가속 AMI의 이전 버전에서는 nvidia-docker 리포지토리를 설치했습니다. Amazon EKS AMI 버전 v20200529 이상에는 더 이상 이 리포지토리가 포함되지 않습니다.

GPU 기반 워크로드를 활성화하려면

다음 절차에서는 Amazon EKS 최적화 가속 AMI를 사용하여 GPU 기반 인스턴스에서 워크로드를 실행하는 방법에 대해 설명합니다. 다른 옵션은 다음을 참조하세요.

Inferentia 기반 워크로드 사용에 대한 자세한 내용을 알아보려면 AWS Inferentia를 사용한 기계 학습 추론 부분을 참조하세요.
Neuron 사용에 관한 추가 정보는 AWS Neuron 설명서의 Containers - Kubernetes - Getting Started를 참조하세요.

GPU 노드가 클러스터에 조인하면 클러스터에서 Kubernetes용 NVIDIA 디바이스 플러그 인을 DaemonSet(으)로 적용해야 합니다. 다음 명령을 실행하기 전에 vX.X.X을(를) 원하는 NVIDIA/k8s-device-plugin 버전으로 교체합니다.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml
```

다음 명령으로 노드에 할당 가능한 GPU가 있는지 확인할 수 있습니다.


kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

GPU 노드의 구성이 올바른지 테스트하기 위한 Pod 배포하기

다음 콘텐츠를 가진 nvidia-smi.yaml이라는 파일을 생성합니다: tag을(를) 원하는 nvidia/cuda용 태그와 바꿉니다. 이 매니페스트는 노드에서 nvidia-smi을(를) 실행하는 NVIDIA CUDA 컨테이너를 시작합니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: nvidia/cuda:tag
    args:
    - "nvidia-smi"
    resources:
      limits:
        nvidia.com/gpu: 1
```
다음 명령으로 매니페스트를 적용합니다.
```
kubectl apply -f nvidia-smi.yaml
```

Pod 실행이 끝난 후, 다음 명령을 사용하여 로그를 확인합니다.


kubectl logs nvidia-smi

예제 출력은 다음과 같습니다.

Mon Aug  6 20:23:31 20XX
+-----------------------------------------------------------------------------+
| NVIDIA-SMI XXX.XX                 Driver Version: XXX.XX                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1C.0 Off |                    0 |
| N/A   46C    P0    47W / 300W |      0MiB / 16160MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Amazon EKS 최적화 Arm Amazon Linux AMI

Arm 인스턴스는 웹 서버, 컨테이너식 마이크로서비스, 캐싱 플릿 및 분산 데이터 스토어와 같은 스케일 아웃 및 Arm 기반 애플리케이션에 상당한 비용 절감 효과를 제공합니다. 클러스터에 Arm 노드를 추가하는 경우 다음 고려 사항을 검토하세요.

고려 사항

클러스터가 2020년 8월 17일 이전에 배포된 경우 중요한 클러스터 추가 기능 매니페스트의 일회성 업그레이드를 수행해야 합니다. 이는 Kubernetes가 클러스터에서 사용 중인 각 하드웨어 아키텍처에 대해 올바른 이미지를 가져올 수 있도록 하기 위함입니다. 클러스터 추가 기능을 업데이트하는 방법에 대한 자세한 내용은 Amazon EKS 클러스터의 Kubernetes 버전 업데이트 부분을 참조하세요. 2020년 8월 17일 또는 이후에 클러스터를 배포한 경우는 이미 CoreDNS, kube-proxy 및 Amazon VPC CNI plugin for Kubernetes가 다중 아키텍처를 지원합니다.
Arm 노드에 배포된 애플리케이션은 Arm용으로 컴파일되어야 합니다.
기존 클러스터에 배포된 DaemonSets이 있거나, Arm 노드도 배포할 새 클러스터에 DaemonSet를 배포하려는 경우 DaemonSet가 클러스터의 모든 하드웨어 아키텍처에서 실행될 수 있는지 확인합니다.
동일한 클러스터에서 Arm 노드 그룹과 x86 노드 그룹을 실행할 수 있습니다. 이 경우에 다중 아키텍처 컨테이너 이미지를 Amazon Elastic Container Registry와 같은 컨테이너 리포지토리에 배포한 다음, 매니페스트에 노드 선택기를 추가하여 어떤 하드웨어에 Pod를 배포할 수 있는지 Kubernetes가 알 수 있도록 해야 합니다. 자세한 내용은 Amazon ECR 사용 설명서의 다중 아키텍처 이미지 푸시 및 Amazon ECR용 다중 아키텍처 컨테이너 이미지 소개 블로그 게시물을 참조하세요.

Docker에서 `containerd`로 마이그레이션 테스트

Amazon EKS에서는 Kubernetes 버전 1.24 출시부터 Docker에 대한 지원이 종료되었습니다. 자세한 내용은 Amazon EKS에서는 Dockershim에 대한 지원을 종료했습니다. 단원을 참조하십시오.

Kubernetes 버전 1.23의 경우 선택적 부트스트랩 플래그를 사용하여 Amazon EKS 최적화 AL2 AMI에 대해 containerd 런타임을 활성화할 수 있습니다. 이 기능에서는 버전 1.24 또는 이후 버전으로 업데이트할 때 containerd로 마이그레이션하는 명확한 경로를 제공합니다. Amazon EKS에서는 Kubernetes 버전 1.24 출시부터 Docker에 대한 지원이 종료되었습니다. containerd 런타임은 Kubernetes 커뮤니티에서 널리 채택되었으며 CNCF의 마무리 단계를 통과한 프로젝트입니다. 노드 그룹을 새 클러스터나 기존 클러스터에 추가하여 테스트할 수 있습니다.

다음 노드 그룹 유형 중 하나를 생성하여 부트스트랩 플래그를 사용할 수 있습니다.

자체 관리형

자체 관리형 Amazon Linux 노드 시작하기의 지침에 따라 노드 그룹을 생성합니다. Amazon EKS 최적화 AMI를 지정하고 BootstrapArguments 파라미터에 다음 텍스트를 지정합니다.


--container-runtime containerd

관리형

eksctl을 사용하는 경우 다음 내용이 포함된 my-nodegroup.yaml이라는 파일을 생성합니다. 모든 example value를 고유한 값으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. ami-1234567890abcdef0에 대해 최적화된 AMI ID를 검색하려면 Amazon EKS 최적화 Amazon Linux AMI ID 검색 섹션을 참조하세요.


apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd

참고

많은 노드를 동시에 시작하는 경우 --apiserver-endpoint, --b64-cluster-ca 및 --dns-cluster-ip 부트스트랩 인수에 대한 값을 지정하여 오류를 방지하려 할 수도 있습니다. 자세한 내용은 AMI 지정 단원을 참조하십시오.

다음 명령을 실행하여 노드 그룹을 생성합니다.


eksctl create nodegroup -f my-nodegroup.yaml

다른 도구를 사용하여 관리형 노드 그룹을 생성하려면 시작 템플릿을 사용하여 노드 그룹을 배포해야 합니다. 시작 템플릿에서 Amazon EKS 최적화 AMI ID를 지정한 다음 시작 템플릿을 사용하여 노드 그룹 배포하고 다음 사용자 데이터를 제공합니다. 이 사용자 데이터는 인수를 bootstrap.sh 파일에 전달합니다. 부트스트랩 파일에 대한 자세한 내용은 GitHub에서 bootstrap.sh 부분을 참조하세요.


/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

추가 정보

Amazon EKS 최적화 Amazon Linux AMI 사용에 대한 자세한 내용은 다음 섹션을 참조하세요.

관리형 노드 그룹과 함께 Amazon Linux를 사용하려면 관리형 노드 그룹 섹션을 참조하세요.
자체 관리형 Amazon Linux 노드를 시작하려면 Amazon EKS 최적화 Amazon Linux AMI ID 검색 섹션을 참조하세요.
버전 정보는 Amazon EKS 최적화 Amazon Linux AMI 버전를 참조하십시오.
Amazon EKS 최적화 Amazon Linux AMI의 최신 ID를 검색하려면 Amazon EKS 최적화 Amazon Linux AMI ID 검색 섹션을 참조하세요.
Amazon EKS 최적화 AMI를 빌드하는 데 사용되는 오픈 소스 스크립트는 Amazon EKS 최적화 Amazon Linux AMI 빌드 스크립트 섹션을 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Dockershim 사용 중단

버전 보기