**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# EKS Auto Mode를 사용하여 클러스터 인프라 자동화
**작은 정보**
향후 예정된 Amazon EKS Auto Mode 워크숍에 [등록](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)합니다.
EKS Auto Mode는 Kubernetes 클러스터의 AWS 관리를 클러스터 자체 이상으로 확장하여 AWS가 워크로드를 원활하게 운영할 수 있는 인프라를 설정하고 관리할 수 있게 합니다. 주요 인프라 결정을 위임하고 일상적인 작업에 AWS의 전문 지식을 활용할 수 있습니다. AWS에서 관리하는 클러스터 인프라에는 컴퓨팅 오토 스케일링, 포드 및 서비스 네트워킹, 애플리케이션 로드 밸런싱, 클러스터 DNS, 블록 스토리지, GPU 지원과 같은 추가 기능과 달리 많은 Kubernetes 기능이 핵심 구성 요소로 포함되어 있습니다.
시작하려면 새 EKS Auto Mode 클러스터를 배포하거나 기존 클러스터에서 EKS Auto Mode를 활성화할 수 있습니다. eksctl, AWS CLI, AWS Management Console, EKS API 또는 선호하는 코드형 인프라 도구를 사용하여 EKS 자동 모드 클러스터를 배포, 업그레이드 또는 수정할 수 있습니다.
EKS Auto Mode를 사용하면 원하는 Kubernetes 호환 도구를 계속 사용할 수 있습니다. EKS Auto Mode는 모범 사례를 따르는 AWS 클라우드 리소스를 활용하여 Amazon EC2, Amazon EBS 및 ELB와 같은 AWS 서비스와 통합됩니다. 이러한 리소스는 자동으로 조정되고, 비용이 최적화되고, 정기적으로 업데이트되어 운영 비용 및 오버헤드를 최소화하는 데 도움이 됩니다.
## 특성
EKS Auto Mode은 다음의 대략적인 기능을 제공합니다.
**Kubernetes 클러스터 관리 간소화**: EKS Auto Mode는 운영 오버헤드를 최소화하면서 프로덕션 지원 클러스터를 제공하여 EKS 관리를 간소화합니다. EKS Auto Mode를 사용하면 심층적인 EKS 전문 지식 없이도 까다롭고 동적인 워크로드를 자신 있게 실행할 수 있습니다.
**애플리케이션 가용성**: EKS Auto Mode는 Kubernetes 애플리케이션의 요구 사항에 따라 EKS 클러스터의 노드를 동적으로 추가하거나 제거합니다. 이렇게 하면 수동 용량 계획의 필요성을 최소화하고 애플리케이션 가용성을 보장할 수 있습니다.
**효율성**: EKS 자동 모드는 NodePool 및 워크로드 요구 사항에 정의된 유연성을 준수하면서 비용을 최적화하도록 설계되었습니다. 또한 미사용 인스턴스를 종료하고 워크로드를 다른 노드로 통합하여 비용 효율성을 개선합니다.
**보안**: EKS Auto Mode는 노드에 대해 변경할 수 없는 것으로 취급되는 AMI를 사용합니다. 이러한 AMI는 잠긴 소프트웨어를 적용하고 SELinux 필수 액세스 제어를 활성화하며 읽기 전용 루트 파일 시스템을 제공합니다. 또한 EKS Auto Mode에서 시작된 노드의 최대 수명은 21일(단축할 수 있음)이며, 그 후에는 새 노드로 자동 대체됩니다. 이 접근 방식은 많은 고객이 이미 채택한 모범 사례에 따라 노드를 정기적으로 사이클링하여 보안 태세를 강화합니다.
**자동 업그레이드**: EKS Auto Mode는 구성된 포드 중단 예산(PDB) 및 NodePool 중단 예산(NDB)을 준수하면서 최신 패치를 사용하여 Kubernetes 클러스터, 노드, 관련 구성 요소를 최신 상태로 유지합니다. 최대 수명 21일까지 PDB 또는 기타 구성을 차단하여 업데이트가 불가능한 경우 중재가 필요할 수 있습니다.
**관리형 구성 요소**: EKS Auto Mode에는 Kubernetes 및 AWS 클라우드 기능이 추가 기능으로 관리해야 하는 핵심 구성 요소로 포함되어 있습니다. 여기에는 포드 IP 주소 할당, 포드 네트워크 정책, 로컬 DNS 서비스, GPU 플러그인, 상태 확인기, EBS CSI 스토리지에 대한 기본 지원이 포함됩니다.
**사용자 지정 가능한 NodePool 및 NodeClasse**: 워크로드에서 스토리지, 컴퓨팅 또는 네트워킹 구성을 변경해야 하는 경우 EKS Auto Mode를 사용하여 사용자 지정 NodePool 및 NodeClasse를 생성할 수 있습니다. 기본 NodePool 및 NodeClass는 편집하면 안 되지만 특정 요구 사항을 충족하기 위해 기본 구성과 함께 새 사용자 지정 NodePool 또는 NodeClass를 추가할 수 있습니다.
## 자동 구성 요소
EKS Auto Mode는 주요 인프라 구성 요소를 자동화하여 Amazon EKS 클러스터의 작업을 간소화합니다. EKS Auto Mode를 활성화하면 EKS 클러스터를 관리하는 작업이 더욱 줄어듭니다.
다음은 자동화된 데이터 플레인 구성 요소의 목록입니다.
+ **컴퓨팅**: 많은 워크로드에서 EKS Auto Mode를 사용하면 EKS 클러스터에 대한 컴퓨팅의 여러 측면을 잊어버릴 수 있습니다. 다음이 포함됩니다.
+ **노드**: EKS Auto Mode 노드는 어플라이언스처럼 처리되도록 설계되었습니다. EKS Auto Mode는 다음을 수행합니다.
+ 개입 없이 워크로드를 실행하는 데 필요한 많은 서비스로 구성된 적절한 AMI를 선택합니다.
+ SELinux 적용 모드와 읽기 전용 루트 파일 시스템을 사용하여 AMI에서 파일 액세스를 잠급니다.
+ SSH 또는 SSM 액세스를 허용하지 않음으로써 노드에 대한 직접 액세스를 방지합니다.
+ NVIDIA 및 Neuron GPU에 대한 별도의 커널 드라이버와 플러그인을 통해 고성능 워크로드를 지원하는 GPU 지원이 포함되어 있습니다.
+ [EC2 스팟 인스턴스 중단 알림](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) 및 EC2 인스턴스 상태 이벤트 자동 처리
+ **오토 스케일링**: [Karpenter](https://karpenter.sh/docs/) 오토 스케일링을 사용하는 EKS Auto Mode는 예약 불가능한 포드를 모니터링하고 새 노드를 배포하여 해당 포드를 실행할 수 있습니다. 워크로드가 종료되면 EKS Auto Mode는 노드가 더 이상 필요하지 않을 때 노드를 동적으로 중단 및 종료하여 리소스 사용을 최적화합니다.
+ **업그레이드**: 노드를 제어하면 필요에 따라 보안 패치와 운영 체제 및 구성 요소 업그레이드를 제공하는 EKS Auto Mode의 기능이 간소화됩니다. 이러한 업그레이드는 워크로드 중단을 최소화하도록 설계되었습니다. EKS Auto Mode는 최신 소프트웨어 및 API를 보장하기 위해 최대 21일의 노드 수명을 적용합니다.
+ **로드 밸런싱**: EKS Auto Mode는 Amazon의 Elastic Load Balancing 서비스와 통합하여 Kubernetes 서비스 및 수신 리소스용 로드 밸런서의 프로비저닝 및 구성을 자동화함으로써 로드 밸런싱을 간소화합니다. 애플리케이션과 Network Load Balancer 모두에 고급 기능을 지원하고, 수명 주기를 관리하며, 클러스터 수요에 맞게 확장합니다. 이러한 통합은 AWS 모범 사례를 준수하는 프로덕션 지원 로드 밸런싱 솔루션을 제공하므로 인프라 관리가 아닌 애플리케이션에 집중할 수 있습니다.
+ **스토리지**: EKS Auto Mode는 노드 종료 시 볼륨 유형, 볼륨 크기, 암호화 정책, 삭제 정책을 설정하여 임시 스토리지를 구성합니다.
+ **네트워킹**: EKS Auto Mode는 포드 및 서비스 연결을 위한 중요한 네트워킹 작업을 자동화합니다. 여기에는 IPv4/IPv6 지원과 IP 주소 공간을 확장하기 위한 보조 CIDR 블록 사용이 포함됩니다.
+ **ID 및 액세스 관리**: EKS Auto Mode 클러스터에 EKS Pod Identity 에이전트를 설치할 필요가 없습니다.
이러한 구성 요소에 대한 자세한 내용은 [EKS Auto Mode 작동 방식 알아보기](auto-reference.md) 섹션을 참조하세요.
## 구성
EKS Auto Mode는 개입 없이 대부분의 데이터 플레인 서비스를 효과적으로 관리하지만 일부 서비스의 동작을 변경해야 하는 경우가 있을 수 있습니다. 다음과 같은 방법으로 EKS Auto Mode 클러스터의 구성을 수정할 수 있습니다.
+ **Kubernetes DaemonSets**: 노드에 설치된 서비스를 수정하는 대신 Kubernetes DaemonSets를 사용할 수 있습니다. DaemonSets는 Kubernetes에서 관리하도록 설계되었지만 클러스터의 모든 노드에서 실행됩니다. 이렇게 하면 노드를 모니터링하거나 다른 방식으로 감시하기 위한 특수 서비스를 추가할 수 있습니다.
+ **사용자 지정 NodePool 및 NodeClass**: 기본 NodePool 및 NodeClass는 EKS Auto Mode에 의해 구성되며 편집하면 안 됩니다. 노드 동작을 사용자 지정하려면 다음과 같은 사용 사례에 대해 추가 NodePool 또는 NodeClasse를 생성할 수 있습니다.
+ 특정 인스턴스 유형(예: 가속 프로세서 또는 EC2 스팟 인스턴스)을 선택합니다.
+ 보안 또는 비용 추적을 위해 워크로드를 격리합니다.
+ IOPS, 크기, 처리량과 같은 임시 스토리지 설정을 구성합니다.
+ **로드 밸런싱**: EKS Auto Mode가 Kubernetes 객체로 실행되는 로드 밸런싱과 같은 일부 서비스를 EKS Auto Mode 클러스터에서 직접 구성할 수 있습니다.
EKS Auto Mode 구성 옵션에 대한 자세한 내용은 [EKS 자율 모드 설정 구성](settings-auto.md) 섹션을 참조하세요.
## 공동 책임 모델
AWS 공동 책임 모델은 AWS와 고객 사이의 보안 및 규정 준수 책임을 정의합니다. 아래의 이미지와 텍스트는 EKS Auto Mode와 EKS 표준 모드 사이에서 고객과 AWS 책임의 차이를 비교 및 대조합니다.
![\[EKS Auto Mode 및 표준 모드를 사용하는 공동 책임 모델\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/eksautosrm.png)
EKS Auto Mode는 Kubernetes 인프라에 대한 공동 책임의 대부분을 고객에서 AWS로 전환합니다. EKS Auto Mode를 사용하면 한때 고객의 몫이었던 클라우드 보안 책임을 AWS에서 더 많이 지고, 이제는 책임이 공유됩니다. 이제 고객은 애플리케이션에 더 집중할 수 있으며 AWS는 기본 인프라를 관리합니다.
**고객의 책임**
EKS Auto Mode에서 고객은 가용성, 보안 및 모니터링을 포함한 애플리케이션 컨테이너에 대한 책임을 계속 유지합니다. 또한 VPC 인프라 및 EKS 클러스터 구성을 계속해서 제어합니다. 이 모델을 통해 고객은 AWS에 클러스터 인프라 관리를 위임하면서 애플리케이션 관련 문제에 집중할 수 있습니다. AWS 추가 기능을 통해 노드별 선택적 기능을 클러스터에 포함할 수 있습니다.
**AWS 책임**
EKS Auto Mode를 사용하면 Auto Mode를 사용하지 않는 EKS 클러스터에서 이미 관리 중인 구성 요소에 비해 여러 추가 중요 구성 요소의 관리를 포함하도록 AWS의 책임이 확장됩니다. 특히 EKS Auto Mode는 시작된 EC2 인스턴스의 구성, 관리, 보안 및 스케일링과 로드 밸런싱, IP 주소 관리, 네트워킹 정책 및 블록 스토리지에 대한 클러스터 기능을 맡습니다. 다음 구성 요소는 EKS Auto Mode에서 AWS가 관리합니다.
+ **Auto Mode 시작 EC2 인스턴스**: AWS는 Amazon EC2 관리형 인스턴스를 활용하여 노드의 전체 수명 주기를 처리합니다. EC2 관리형 인스턴스는 운영 체제 구성, 패치 적용, 모니터링 및 상태 유지 관리 책임을 집니다. 이 모델에서 인스턴스 자체와 인스턴스에서 실행되는 게스트 운영 체제는 모두 AWS의 책임입니다. 노드는 컨테이너 실행에 최적화된 [Bottlerocket](https://aws.amazon.com/bottlerocket) AMI의 버전을 사용합니다. Bottlerocket AMI에는 잠긴 소프트웨어, 변경 불가능한 루트 파일 시스템, 보안 네트워크 시스템(SSH 또는 SSM을 통한 직접 통신 방지)이 있습니다.
+ **클러스터 기능**: AWS는 컴퓨팅 오토 스케일링, 네트워크 정책 적용을 통한 포드 네트워킹, Elastic Load Balancing 통합 및 스토리지 드라이버 구성을 관리합니다.
+ **클러스터 컨트롤 플레인**: AWS는 표준 EKS에서와 마찬가지로 Kubernetes API 서버, 교차 계정 ENI, etcd 데이터베이스를 계속해서 관리합니다.
+ **기본 서비스 및 글로벌 인프라**: AWS는 기본 컴퓨팅, 스토리지, 네트워킹 및 모니터링 서비스와 리전, 로컬 영역 및 엣지 로케이션의 글로벌 인프라에 대한 책임을 유지합니다.
# Amazon EKS 자율 모드에서 클러스터 생성
이 장에서는 다양한 도구와 인터페이스를 사용하여 Auto Mode가 활성화된 Amazon EKS 클러스터를 생성하는 방법을 설명합니다. Auto Mode는 클러스터의 컴퓨팅, 네트워킹, 스토리지 인프라를 자동으로 구성하고 관리하여 클러스터 생성을 간소화합니다. AWS CLI, AWS Management Console 또는 eksctl 명령줄 도구를 사용하여 자동 모드 클러스터를 생성하는 방법을 알아봅니다.
**참고**
EKS Auto Mode에는 Kubernetes 버전 1.29 이상이 필요합니다.
필요에 따라 원하는 도구를 선택합니다. AWS Management Console은 EKS 자동 모드 기능을 알아보고 개별 클러스터를 생성하는 데 이상적인 시각적 인터페이스를 제공합니다. AWS CLI는 스크립팅 및 자동화 작업, 특히 클러스터 생성을 기존 워크플로 또는 CI/CD 파이프라인에 통합할 때 가장 적합합니다. eksctl CLI는 Kubernetes 네이티브 환경을 제공하며, 합리적인 기본값으로 간소화된 명령줄 작업을 원하는 Kubernetes 도구에 익숙한 사용자에게 권장됩니다.
시작하기 전에 EKS 클러스터를 생성하는 데 필요한 IAM 권한을 포함하여 필요한 사전 요구 사항을 설치하고 구성했는지 확인합니다. `kubectl`, `aws`, `eksctl`과 같은 CLI 도구를 설치하는 방법은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
AWS CLI, AWS Management Console 또는 eksctl CLI를 사용하여 Amazon EKS 자동 모드로 클러스터를 생성할 수 있습니다.
**Topics**
+ [eksctl CLI를 사용하여 EKS Auto Mode 클러스터 생성](automode-get-started-eksctl.md)
+ [AWS CLI를 사용하여 EKS Auto Mode 클러스터 생성](automode-get-started-cli.md)
+ [AWS Management Console을 사용하여 EKS 자동 모드 클러스터 생성](automode-get-started-console.md)
# eksctl CLI를 사용하여 EKS Auto Mode 클러스터 생성
이 주제에서는 eksctl 명령줄 인터페이스(CLI)를 사용하여 Amazon EKS Auto Mode 클러스터를 생성하는 방법을 보여줍니다. 단일 CLI 명령을 실행하거나 YAML 구성 파일을 적용하여 Auto Mode 클러스터를 생성할 수 있습니다. 두 방법 모두 동일한 기능을 제공하며, YAML 접근 방식은 클러스터 설정을 더 세밀하게 제어할 수 있습니다.
eksctl CLI는 기본 AWS 리소스 생성 및 구성을 처리하여 EKS Auto Mode 클러스터를 생성하고 관리하는 프로세스를 간소화합니다. 계속하기 전에 로컬 시스템에 필요한 AWS 자격 증명과 권한이 구성되어 있는지 확인합니다. 이 안내서에서는 사용자가 기본 Amazon EKS 개념을 잘 알고 필요한 CLI 도구를 이미 설치했다고 가정합니다.
**참고**
버전 `0.195.0` 이상의 eksctl을 설치해야 합니다. 자세한 내용은 GitHub의 [eksctl 릴리스](https://github.com/eksctl-io/eksctl/releases)를 참조하세요.
## CLI 명령을 사용하여 EKS Auto Mode 클러스터 생성
`aws` 및 `eksctl` 도구가 설치되어 있어야 합니다. EC2 인스턴스, EC2 네트워킹, EKS 클러스터, IAM 역할을 포함한 AWS 리소스를 관리하려면 충분한 권한을 가지고 AWS CLI에 로그인해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
다음 명령을 실행하여 새 EKS Auto Mode 클러스터를 생성합니다.
```
eksctl create cluster --name= --enable-auto-mode
```
## YAML 파일을 사용하여 EKS Auto Mode 클러스터 생성
`aws` 및 `eksctl` 도구가 설치되어 있어야 합니다. EC2 인스턴스, EC2 네트워킹, EKS 클러스터, IAM 역할을 포함한 AWS 리소스를 관리하려면 충분한 권한을 가지고 AWS CLI에 로그인해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
아래 샘플 ClusterConfig 리소스의 EKS Auto Mode 구성 옵션을 검토합니다. 전체 ClusterConfig 사양은 [eksctl documentation](https://eksctl.io/usage/creating-and-managing-clusters/)를 참조하세요.
AWS에서는 EKS Auto Mode를 활성화할 것을 제안합니다. EKS Auto Mode 클러스터를 처음 생성하는 경우 `nodeRoleARN`을 지정되지 않은 상태로 두고 EKS Auto Mode에 대한 노드 IAM 역할을 생성합니다. AWS 계정에 노드 IAM 역할이 이미 있는 경우 AWS는 이를 재사용할 것을 제안합니다.
AWS는 `nodePools`에 대한 값을 지정하지 않을 것을 제안합니다. EKS Auto Mode는 기본 노드 풀을 생성합니다. Kubernetes API를 사용하여 추가 노드 풀을 생성할 수 있습니다.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
`ClusterConfig` 파일을 `cluster.yaml`로 저장하고 다음 명령을 사용하여 클러스터를 생성합니다.
```
eksctl create cluster -f cluster.yaml
```
# AWS CLI를 사용하여 EKS Auto Mode 클러스터 생성
EKS Auto Mode 클러스터는 컴퓨팅, 스토리지, 네트워킹을 위한 일상적인 클러스터 관리 작업을 자동화합니다. 예를 들어 EKS Auto Mode 클러스터는 추가 노드가 필요한 시기를 자동으로 감지하고 워크로드 수요에 맞춰 새 EC2 인스턴스를 프로비저닝합니다.
이 주제에서는 AWS CLI를 사용하여 새 EKS Auto Mode 클러스터를 생성하고 선택적으로 샘플 워크로드를 배포하는 방법을 안내합니다.
## 사전 조건
+ 장치에 최신 버전의 AWS Command Line Interface(AWS CLI)가 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)을 참조하세요.
+ 충분한 IAM 권한을 사용하여 CLI에 로그인하고 IAM 정책, IAM 역할, EKS 클러스터를 포함한 AWS 리소스를 생성합니다.
+ 장치에 설치된 kubectl 명령줄 도구입니다. AWS에서는 EKS 클러스터의 Kubernetes 버전과 동일한 kubectl 버전을 사용할 것을 권장합니다. kubectl을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 섹션을 참조하세요.
## VPC 서브넷 지정
Amazon EKS Auto Mode는 노드를 VPC 서브넷에 배포합니다. EKS 클러스터를 생성할 때 노드가 배포될 VPC 서브넷을 지정해야 합니다. AWS 계정에서 기본 VPC 서브넷을 사용하거나 중요한 워크로드를 위한 전용 VPC를 생성할 수 있습니다.
+ AWS는 클러스터에 대한 전용 VPC를 생성할 것을 제안합니다. [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md) 방법에 대해 알아봅니다.
+ EKS 콘솔은 새 VPC 생성을 지원합니다. [AWS Management Console을 사용하여 EKS 자동 모드 클러스터 생성](automode-get-started-console.md) 방법에 대해 알아봅니다.
+ 또는 AWS 계정의 기본 VPC를 사용할 수 있습니다. 다음 지침에 따라 서브넷 ID를 찾습니다.
### 기본 VPC의 서브넷 ID를 찾으려면
**AWS CLI 사용:**
1. 다음 명령을 실행하여 기본 VPC와 해당 서브넷을 나열합니다.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. 출력을 저장하고 **서브넷 ID**를 기록합니다.
샘플 출력:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## EKS Auto Mode 클러스터에 대한 IAM 역할
### 클러스터 IAM 역할
EKS Auto Mode에서 새 EC2 인스턴스 프로비저닝과 같은 작업을 AWS 계정에서 수행하려면 클러스터 IAM 역할이 필요합니다. EKS에 필요한 권한을 부여하려면 이 역할을 생성해야 합니다. AWS는 클러스터 IAM 역할에 다음 AWS 관리형 정책을 연결할 것을 권장합니다.
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### 노드 IAM 역할
EKS Auto Mode 클러스터를 생성할 때 노드 IAM 역할을 지정합니다. EKS Auto Mode가 보류 중인 워크로드를 처리할 노드를 생성하면 각 새 EC2 인스턴스 노드에 노드 IAM 역할이 할당됩니다. 이 역할은 노드가 EKS와 통신하도록 허용하지만 일반적으로 노드에서 실행되는 워크로드에서는 액세스하지 않습니다.
노드에서 실행되는 워크로드에 권한을 부여하려면 EKS Pod Identity를 사용합니다. 자세한 내용은 [EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md) 섹션을 참조하세요.
이 역할을 생성하고 다음 AWS 관리형 정책을 연결해야 합니다.
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
또한 EKS Auto Mode에는 AWS에서 자동으로 생성 및 구성하는 서비스 연결 역할이 필요합니다. 자세한 내용은 [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md)를 참조하세요.
## EKS Auto Mode 클러스터 IAM 역할 생성
### 1단계: 신뢰 정책 생성
Amazon EKS 서비스가 이 역할을 수임하도록 허용하는 신뢰 정책을 생성합니다. 정책을 `trust-policy.json`으로 저장합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 2단계: IAM 역할 생성
신뢰 정책을 사용하여 클러스터 IAM 역할을 생성합니다.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### 3단계: 역할 ARN 기록
다음 단계에서 사용할 새 역할의 ARN을 검색하고 저장합니다.
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### 4단계: 필수 정책 연결
다음 AWS 관리형 정책을 클러스터 IAM 역할에 연결하여 필요한 권한을 부여합니다.
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
## EKS Auto Mode 노드 IAM 역할 생성
### 1단계: 신뢰 정책 생성
Amazon EKS 서비스가 이 역할을 수임하도록 허용하는 신뢰 정책을 생성합니다. 정책을 `node-trust-policy.json`으로 저장합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### 2단계: 노드 IAM 역할 생성
이전 단계의 **node-trust-policy.json** 파일을 사용하여 역할을 수임할 수 있는 엔터티를 정의합니다. 다음 명령을 실행하여 노드 IAM 역할을 만듭니다.
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### 3단계: 역할 ARN 기록
역할을 생성한 후 노드 IAM 역할의 ARN을 검색하고 저장합니다. 이후 단계에서 이 ARN이 필요합니다. 다음 명령을 사용하여 ARN을 가져옵니다.
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### 4단계: 필수 정책 연결
다음 AWS 관리형 정책을 노드 IAM 역할에 연결하여 필요한 권한을 제공합니다.
**AmazonEKSWorkerNodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## EKS Auto Mode 클러스터 생성
### 개요
AWS CLI를 사용하여 EKS Auto Mode 클러스터를 생성하려면 다음 파라미터가 필요합니다.
+ `cluster-name`: 클러스터의 이름입니다.
+ `k8s-version`: Kubernetes 버전(예: 1.31)입니다.
+ `subnet-ids`: 이전 단계에서 식별된 서브넷 ID입니다.
+ `cluster-role-arn`: 클러스터 IAM 역할의 ARN입니다.
+ `node-role-arn`: 노드 IAM 역할의 ARN입니다.
#### 기본 클러스터 구성
클러스터를 생성하기 전에 다음 기본값과 기능을 검토합니다.
+ `nodePools`: EKS Auto Mode에는 범용 및 시스템 기본 노드 풀이 포함됩니다. [노드 풀](create-node-pool.md)에 대해 자세히 알아봅니다.
**참고:** EKS Auto Mode의 노드 풀은 Amazon EKS 관리형 노드 그룹과 다르지만 동일한 클러스터에 공존할 수 있습니다.
+ `computeConfig.enabled`: EC2 인스턴스 생성 및 삭제와 같은 일상적인 컴퓨팅 작업을 자동화합니다.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: Elastic Load Balancer 생성 및 삭제와 같은 로드 밸런싱 작업을 자동화합니다.
+ `storageConfig.blockStorage.enabled`: Amazon EBS 볼륨 생성 및 삭제와 같은 스토리지 작업을 자동화합니다.
+ `accessConfig.authenticationMode`: EKS 액세스 항목이 필요합니다. [EKS 인증 모드](grant-k8s-access.md)에 대해 자세히 알아봅니다.
#### 명령 실행
다음 명령을 사용하여 클러스터를 생성합니다.
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### 클러스터 상태 확인
#### 1단계: 클러스터 생성 확인
다음 명령을 실행하여 클러스터의 상태를 확인합니다. 클러스터 생성에는 일반적으로 15분 정도 걸립니다.
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### 2단계: kubeconfig 업데이트
클러스터가 준비되면 `kubectl`이 클러스터와 통신할 수 있도록 로컬 kubeconfig 파일을 업데이트합니다. 이 구성은 인증에 AWS CLI를 사용합니다.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### 3단계: 노드 풀 확인
다음 명령을 사용하여 클러스터의 노드 풀을 나열합니다.
```
kubectl get nodepools
```
## 다음 단계
+ 새 EKS Auto Mode 클러스터에 [샘플 워크로드를 배포](automode-workload.md)하는 방법을 알아봅니다.
# AWS Management Console을 사용하여 EKS 자동 모드 클러스터 생성
AWS Management Console에서 EKS 자동 모드 클러스터를 생성하려면 다른 옵션보다 구성이 적게 필요합니다. EKS는 AWS IAM 및 VPC 네트워킹과 통합되어 EKS 클러스터와 연결된 리소스를 생성하는 데 도움이 됩니다.
콘솔에서 클러스터를 생성하는 두 가지 옵션이 있습니다.
+ 빠른 구성(EKS Auto Mode 사용)
+ 사용자 지정 구성
이 주제에서는 빠른 구성 옵션을 사용하여 EKS Auto Mode 클러스터를 생성하는 방법을 알아봅니다.
## 빠른 구성 옵션을 사용하여 EKS Auto Mode 생성
EC2 인스턴스, EC2 네트워킹, EKS 클러스터, IAM 역할을 포함한 AWS 리소스를 관리하려면 충분한 권한을 가지고 AWS Management Console에 로그인해야 합니다.
1. EKS 콘솔로 이동합니다.
1. **클러스터 생성**을 클릭합니다.
1. **빠른 구성** 옵션이 선택되었는지 확인합니다.
1. 다음 값을 결정하거나 테스트 클러스터의 기본값을 사용합니다.
+ 클러스터 **이름**
+ Kubernetes 버전
1. 클러스터 IAM 역할을 선택합니다. EKS Auto Mode 클러스터를 처음 생성하는 경우 **권장 역할 생성** 옵션을 사용합니다.
+ 선택적으로 모든 EKS Auto Mode 클러스터에 대해 AWS 계정의 단일 클러스터 IAM 역할을 재사용할 수 있습니다.
+ 클러스터 IAM 역할에는 EKS Auto Mode가 EC2 인스턴스, EBS 볼륨, EC2 로드 밸런서 등의 리소스를 관리하는 데 필요한 권한이 포함됩니다.
+ **권장 역할 생성** 옵션은 모든 필드를 권장 값으로 미리 채웁니다. **다음**을 선택하고 **생성**을 선택합니다. 역할은 제안된 `AmazonEKSAutoClusterRole` 이름을 사용합니다.
+ 최근에 새 역할을 생성한 경우 **새로 고침** 아이콘을 사용하여 역할 선택 드롭다운을 다시 로드합니다.
1. 노드 IAM 역할을 선택합니다. EKS Auto Mode 클러스터를 처음 생성하는 경우 **권장 역할 생성** 옵션을 사용합니다.
+ 선택적으로 모든 EKS Auto Mode 클러스터에 대해 AWS 계정의 단일 노드 IAM 역할을 재사용할 수 있습니다.
+ 노드 IAM 역할에는 Auto Mode 노드가 클러스터에 연결하는 데 필요한 권한이 포함되어 있습니다. 노드 IAM 역할에는 컨테이너의 ECR 이미지를 검색할 수 있는 권한이 포함되어야 합니다.
+ **권장 역할 생성** 옵션은 모든 필드를 권장 값으로 미리 채웁니다. **다음**을 선택하고 **생성**을 선택합니다. 역할은 제안된 `AmazonEKSAutoNodeRole` 이름을 사용합니다.
+ 최근에 새 역할을 생성한 경우 **새로 고침** 아이콘을 사용하여 역할 선택 드롭다운을 다시 로드합니다.
1. EKS Auto Mode 클러스터의 VPC를 선택합니다. **VPC 생성**을 선택하여 EKS용 새 VPC를 생성하거나 이전에 EKS용으로 생성한 VPC를 선택합니다.
+ VPC 콘솔을 사용하여 새 VPC를 생성하는 경우 AWS는 가용 영역당 하나 이상의 NAT 게이트웨이를 생성할 것을 제안합니다. 또는 다른 모든 기본값을 사용할 수 있습니다.
+ IPv6 클러스터 요구 사항에 대한 자세한 내용은 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md) 섹션을 참조하세요.
1. (선택 사항) EKS Auto Mode는 선택한 VPC의 프라이빗 서브넷을 자동으로 채웁니다. 원치 않는 서브넷을 제거할 수 있습니다.
+ EKS는 모범 사례에 따라 VPC에서 프라이빗 서브넷을 자동으로 선택합니다. 필요에 따라 VPC에서 퍼블릭 서브넷과 같은 추가 서브넷을 선택할 수 있습니다.
1. (선택 사항) **빠른 구성 기본값 보기**를 선택하고 새 클러스터의 모든 구성 값을 검토합니다. 테이블은 클러스터가 생성된 후 일부 값을 편집할 수 없음을 나타냅니다.
1. [**클러스터 생성(Create cluster)**]을 선택합니다. 클러스터 생성을 완료하는 데 15분이 걸릴 수 있습니다.
## 다음 단계
+ [EKS Auto Mode 클러스터에 샘플 워크로드를 배포](sample-storage-workload.md)하는 방법을 알아봅니다.
# 기존 EKS 클러스터에서 EKS Auto Mode 활성화
기존 EKS 클러스터에서 EKS Auto Mode를 활성화할 수 있습니다.
**AWS는 다음과 같은 마이그레이션을 지원합니다.**
+ Karpenter에서 EKS 자동 모드 노드로 마이그레이션. 자세한 내용은 [kubectl을 사용하여 Karpenter에서 EKS Auto Mode로 마이그레이션](auto-migrate-karpenter.md) 섹션을 참조하세요.
+ EKS 관리형 노드 그룹에서 EKS 자동 모드 노드로 마이그레이션. 자세한 내용은 [EKS 관리형 노드 그룹에서 EKS Auto Mode로 마이그레이션](auto-migrate-mng.md) 섹션을 참조하세요.
+ EKS Fargate에서 EKS 자동 모드로 마이그레이션. 자세한 내용은 [EKS Fargate에서 EKS 자동 모드로 마이그레이션](auto-migrate-fargate.md) 섹션을 참조하세요.
**AWS는 다음과 같은 마이그레이션을 지원하지 않습니다.**
+ EBS CSI 컨트롤러(Amazon EKS 추가 기능 사용)에서 EKS 자동 모드 EBS CSI 컨트롤러(EKS 자동 모드에서 관리)로 볼륨 마이그레이션. 둘 중 하나로 만든 PVC는 다른 하나로 마운트할 수 없습니다. 두 개의 서로 다른 Kubernetes 볼륨 프로비저너를 사용하기 때문입니다.
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)(AWS Labs 프로젝트)은 표준 EBS CSI StorageClass(`ebs.csi.aws.com`)와 EKS 자동 EBS CSI StorageClass(`ebs.csi.eks.amazonaws.com`) 간의 마이그레이션을 가능하게 합니다. 마이그레이션하려면 기존 PersistentVolumeClaim/PersistentVolume 리소스를 삭제했다가 다시 생성해야 하므로 구현하기 전에 비 프로덕션 환경에서 검증해야 합니다.
+ AWS 로드 밸런서 컨트롤러에서 EKS Auto Mode로 로드 밸런서 마이그레이션
Amazon EKS Auto Mode 클러스터에 AWS 로드 밸런서 컨트롤러를 설치할 수 있습니다. `IngressClass` 또는 `loadBalancerClass` 옵션을 사용하여 서비스 및 수신 리소스를 로드 밸런서 컨트롤러 또는 EKS Auto Mode와 연결합니다.
+ 대체 CNI 또는 기타 지원되지 않는 네트워킹 구성을 사용하여 EKS 클러스터 마이그레이션
## 마이그레이션 참조
다음 마이그레이션 참조를 사용하여 자체 관리형 컨트롤러 또는 EKS 자동 모드가 소유하도록 Kubernetes 리소스를 구성합니다.
| 기능 | 리소스 | 필드 | 자체 관리형 | EKS Auto Mode |
| --- | --- | --- | --- | --- |
| 블록 스토리지 | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| 로드 밸런싱 | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| 로드 밸런싱 | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| 로드 밸런싱 | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 로드 밸런싱 | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 컴퓨팅 | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## EBS 볼륨 마이그레이션
워크로드를 EKS 자동 모드로 마이그레이션할 때는 다음과 같이 다양한 CSI 드라이버 프로비저너로 인해 EBS 볼륨 마이그레이션을 처리해야 합니다.
+ EKS 자동 모드 프로비저너: `ebs.csi.eks.amazonaws.com`
+ 오픈 소스 EBS CSI 프로비저너: `ebs.csi.aws.com`
영구 볼륨을 마이그레이션하려면 다음 단계를 따르세요.
1. **볼륨 보존 정책 수정**: 기본 EBS 볼륨이 삭제되지 않도록 기존 플랫폼 버전(PV)의 `persistentVolumeReclaimPolicy`를 `Retain`으로 변경합니다.
1. **Kubernetes에서 PV 제거**: 실제 EBS 볼륨을 그대로 유지하면서 이전 PV 리소스를 삭제합니다.
1. **정적 프로비저닝을 사용하여 새 PV 생성**: 동일한 EBS 볼륨을 참조하지만 대상 CSI 드라이버에서 작동하는 새 PV를 생성합니다.
1. **새 PVC에 바인딩**: `volumeName` 필드를 사용하여 PV를 구체적으로 참조하는 새 PVC를 생성합니다.
### 고려 사항
+ 이 마이그레이션을 시작하기 전에 애플리케이션이 중지되었는지 확인합니다.
+ 마이그레이션 프로세스를 시작하기 전에 데이터를 백업합니다.
+ 각 영구 볼륨에 대해 이 프로세스를 수행해야 합니다.
+ 새 PVC를 사용하도록 워크로드를 업데이트해야 합니다.
## 로드 밸런서 마이그레이션
자체 관리형 AWS 로드 밸런서 컨트롤러에서 EKS Auto Mode로 기존 로드 밸런서를 직접 이전할 수 없습니다. 대신 블루/그린 배포 전략을 구현해야 합니다. 관리형 컨트롤러에서 새 로드 밸런서를 생성하는 동안 기존 로드 밸런서 구성을 유지하는 작업이 포함됩니다.
서비스 중단을 최소화하려면 DNS 기반 트래픽 이동 접근 방식을 사용하는 것이 좋습니다. 먼저 기존 구성의 작동을 유지하면서 EKS 자동 모드를 사용하여 새 로드 밸런서를 생성합니다. 그런 다음 DNS 라우팅(예: Route 53)을 사용하여 트래픽을 이전 로드 밸런서에서 새 로드 밸런서로 점진적으로 이동합니다. 트래픽이 성공적으로 마이그레이션되고 새 구성을 확인한 후에는 이전 로드 밸런서와 자체 관리형 컨트롤러를 폐기할 수 있습니다.
# 기존 클러스터에서 EKS Auto Mode 활성화
이 주제에서는 기존 Amazon EKS 클러스터에서 Amazon EKS Auto Mode를 활성화하는 방법을 설명합니다. 기존 클러스터에서 Auto Mode를 활성화하려면 IAM 권한을 업데이트하고 코어 EKS Auto Mode 설정을 구성해야 합니다. 활성화되면 기존 컴퓨팅 워크로드의 마이그레이션을 시작하여 Auto Mode의 간소화된 운영과 자동화된 인프라 관리를 활용할 수 있습니다.
**중요**
EKS Auto Mode를 활성화하기 전에 특정 Amazon EKS 추가 기능의 최소 필수 버전이 설치되어 있는지 확인합니다. 자세한 내용은 [필요한 추가 기능 버전](#auto-addons-required) 섹션을 참조하세요.
시작하기 전에 Amazon EKS 클러스터에 대한 관리자 액세스 권한과 IAM 역할을 수정할 권한이 있는지 확인합니다. 이 주제의 단계는 AWS Management Console 또는 AWS CLI를 사용하여 자동 모드를 활성화하는 방법을 안내합니다.
## AWS Management Console
IAM, EKS, EC2 리소스를 관리할 수 있는 권한을 가지고 AWS 콘솔에 로그인해야 합니다.
**참고**
클러스터가 생성된 후에는 EKS 클러스터의 클러스터 IAM 역할을 변경할 수 없습니다. EKS Auto Mode에는 이 역할에 대한 추가 권한이 필요합니다. 현재 역할에 추가 정책을 연결해야 합니다.
### 클러스터 IAM 역할 업데이트
1. AWS Management Console에서 클러스터 개요 페이지를 엽니다.
1. **클러스터 IAM 역할 ARN**에서 **IAM에서 보기**를 선택합니다.
1. **권한 추가** 드롭다운에서 **정책 연결**을 선택합니다.
1. **검색** 상자를 사용하여 다음 정책을 찾아 선택합니다.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. **권한 추가**를 선택합니다.
1. **신뢰 관계** 탭에서 **신뢰 정책 편집**을 선택합니다.
1. 다음 클러스터 IAM 역할 신뢰 정책을 삽입하고 **정책 업데이트**를 선택합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### EKS Auto Mode 활성화
1. AWS Management Console에서 클러스터 개요 페이지를 엽니다.
1. **EKS Auto Mode**에서 **관리**를 선택합니다.
1. **EKS Auto Mode**를 켜기로 전환합니다.
1. **EKS 노드 풀** 드롭다운에서 생성할 기본 노드 풀을 선택합니다.
+ EKS Auto Mode의 노드 풀에 대해 자세히 알아봅니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
1. 이전에 이 AWS 계정의 EKS Auto Mode 노드 IAM 역할을 생성한 경우 **노드 IAM 역할** 드롭다운에서 해당 역할을 선택합니다. 이전에 이 역할을 생성하지 않은 경우 **권장 역할 생성**을 선택하고 단계를 따릅니다.
## AWS CLI
### 사전 조건
+ 기존 EKS 클러스터의 클러스터 IAM 역할에는 다음 정책과 같은 EKS Auto Mode에 대한 충분한 권한이 포함되어야 합니다.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ 클러스터 IAM 역할에는 `sts:TagSession` 작업을 포함하여 업데이트된 신뢰 정책이 있어야 합니다. 클러스터 IAM 역할 생성에 대한 자세한 내용은 [AWS CLI를 사용하여 EKS Auto Mode 클러스터 생성](automode-get-started-cli.md) 섹션을 참조하세요.
+ `aws` CLI가 설치되고, 로그인되고, 충분한 버전이 있습니다. IAM, EKS 및 EC2 리소스를 관리할 권한이 있어야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
### 절차
다음 명령을 사용하여 기존 클러스터에서 EKS Auto Mode를 활성화합니다.
**참고**
동일한 요청에서 컴퓨팅, 블록 스토리지, 로드 밸런싱 기능을 모두 활성화 또는 비활성화해야 합니다.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## 필요한 추가 기능 버전
기존 클러스터에서 EKS Auto Mode를 활성화하려는 경우 특정 추가 기능을 업데이트해야 할 수 있습니다. 다음을 참고하세요.
+ 이는 EKS Auto Mode로 전환하는 기존 클러스터에만 적용됩니다.
+ EKS Auto Mode가 활성화된 상태로 생성된 새 클러스터에는 이러한 업데이트가 필요하지 않습니다.
다음 추가 기능 중 하나라도 설치되어 있는 경우 지정된 최소 버전 이상이어야 합니다.
| 추가 기능 이름 | 필요한 최소 버전 |
| --- | --- |
| Kubernetes용 Amazon VPC CNI 플러그 인 | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/auto-enable-existing.html) |
| Amazon EBS CSI 드라이버 | v1.37.0-eksbuild.1 |
| CSI 스냅샷 컨트롤러 | v8.1.0-eksbuild.2 |
| EKS Pod Identity 에이전트 | v1.3.4-eksbuild.1 |
자세한 내용은 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 섹션을 참조하세요.
## 다음 단계
+ 노드 그룹 워크로드 관리를 마이그레이션하려면 [EKS 관리형 노드 그룹에서 EKS Auto Mode로 마이그레이션](auto-migrate-mng.md) 섹션을 참조하세요.
+ 자체 관리형 Karpenter에서 마이그레이션하려면 [kubectl을 사용하여 Karpenter에서 EKS Auto Mode로 마이그레이션](auto-migrate-karpenter.md) 섹션을 참조하세요.
# kubectl을 사용하여 Karpenter에서 EKS Auto Mode로 마이그레이션
이 주제에서는 kubectl을 사용하여 Karpenter에서 Amazon EKS Auto Mode로 워크로드를 마이그레이션하는 프로세스를 안내합니다. 마이그레이션을 점진적으로 수행할 수 있으므로 전환 기간 동안 클러스터 안정성과 애플리케이션 가용성을 유지하면서 원하는 속도로 워크로드를 이동할 수 있습니다.
아래에 설명된 단계별 접근 방식을 사용하면 마이그레이션 기간에 Karpenter와 EKS Auto Mode를 나란히 실행할 수 있습니다. 이러한 이중 작업 전략은 Karpenter를 완전히 폐기하기 전에 EKS Auto Mode에서 워크로드 동작을 검증할 수 있게 하여 원활한 전환을 보장하는 데 도움이 됩니다. 애플리케이션을 개별적으로 또는 그룹으로 마이그레이션하여 특정 운영 요구 사항과 위험 허용 범위를 유연하게 수용할 수 있습니다.
## 사전 조건
마이그레이션을 시작하기 전에 다음이 있는지 확인합니다.
+ 클러스터에 Karpenter v1.1 이상이 설치되어 있습니다. 자세한 내용은 Karpenter 설명서의 [Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110)를 참조하세요.
+ `kubectl`이 설치되고 클러스터에 연결되었습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
이 주제에서는 사용자가 Karpenter 및 NodePools를 잘 알고 있다고 가정합니다. 자세한 내용은 [Karpenter Documentation](https://karpenter.sh/)를 참조하세요.
## 1단계: 클러스터에서 EKS Auto Mode 활성화
AWS CLI 또는 관리 콘솔을 사용하여 기존 클러스터에서 EKS Auto Mode를 활성화합니다. 자세한 내용은 [기존 클러스터에서 EKS Auto Mode 활성화](auto-enable-existing.md) 섹션을 참조하세요.
**참고**
EKS Auto Mode를 활성화하는 동안 전환 중에 이 단계에서 `general purpose` 노드 풀을 활성화하지 마세요. 이 노드 풀은 선택 사항이 아닙니다.
자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
## 2단계: 테인트된 EKS Auto Mode NodePool 생성
테인트가 있는 EKS Auto Mode용 새 NodePool을 생성합니다. 이렇게 하면 기존 포드가 새 EKS Auto Mode 노드에서 자동으로 예약되지 않습니다. 이 노드 풀은 EKS Auto Mode에 내장된 `default` `NodeClass`를 사용합니다. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
테인트가 있는 노드 풀 예제:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
마이그레이션의 소스에 해당하는 Karpenter 구성과 일치하도록 노드 풀의 요구 사항을 업데이트합니다. 하나 이상의 요구 사항이 필요합니다.
## 3단계: 마이그레이션할 워크로드 업데이트
EKS Auto Mode로 마이그레이션하려는 워크로드를 식별하고 업데이트합니다. 이러한 워크로드에 허용 값과 노드 선택기를 모두 추가합니다.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
이 변경 사항을 통해 새 EKS Auto Mode 노드에서 워크로드를 예약할 수 있습니다.
EKS Auto Mode는 Karpenter와 다른 레이블을 사용합니다. EC2 관리형 인스턴스와 관련된 레이블은 `eks.amazonaws.com`으로 시작합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 4단계: 점진적으로 워크로드 마이그레이션
마이그레이션하려는 각 워크로드에 대해 3단계를 반복합니다. 이를 통해 요구 사항 및 위험 허용 범위에 따라 워크로드를 개별적으로 또는 그룹으로 이동할 수 있습니다.
## 5단계: 원래 Karpenter NodePool 제거
모든 워크로드가 마이그레이션되면 원래 Karpenter NodePool을 제거할 수 있습니다.
```
kubectl delete nodepool
```
## 6단계: EKS Auto Mode NodePool에서 테인트 제거(선택 사항)
EKS Auto Mode가 새 워크로드의 기본값이 되게 하려면 EKS Auto Mode NodePool에서 테인트를 제거할 수 있습니다.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## 7단계: 워크로드에서 노드 선택기 제거(선택 사항)
EKS Auto Mode NodePool에서 테인트를 제거한 경우 이제 EKS Auto Mode가 기본값이므로 선택적으로 워크로드에서 노드 선택기를 제거할 수 있습니다.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## 8단계: 클러스터에서 Karpenter 제거
Karpenter를 제거하는 단계는 설치 방법에 따라 다릅니다. 자세한 내용은 [Karpenter 설치 지침](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter)을 참조하세요.
# EKS 관리형 노드 그룹에서 EKS Auto Mode로 마이그레이션
Amazon EKS 클러스터를 EKS 자동 모드를 사용하도록 전환하면 eksctl CLI 도구를 사용하여 관리형 노드 그룹(MNG)에서 기존 워크로드를 원활하게 마이그레이션할 수 있습니다. 이 프로세스는 EKS Auto Mode가 컴퓨팅 리소스를 최적화하는 동안 지속적인 애플리케이션 가용성을 보장합니다. 실행 중인 애플리케이션의 중단을 최소화하면서 마이그레이션을 수행할 수 있습니다.
이 주제에서는 기존 관리형 노드 그룹에서 포드를 안전하게 드레이닝하고 EKS Auto Mode가 새로 프로비저닝된 인스턴스에서 포드를 다시 예약하도록 허용하는 단계를 안내합니다. 이 절차에 따라 마이그레이션 전반에 걸쳐 애플리케이션의 가용성을 유지하면서 EKS Auto Mode의 지능형 워크로드 통합을 활용할 수 있습니다.
## 사전 조건
+ EKS Auto Mode가 활성화된 클러스터
+ `eksctl` CLI가 설치되고 클러스터에 연결되었습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
+ Karpenter가 클러스터에 설치되지 않았습니다.
## 절차
다음 `eksctl` CLI 명령을 사용하여 기존 관리형 노드 그룹 인스턴스에서 포드 드레이닝을 시작합니다. EKS Auto Mode는 대체된 포드를 지원하는 새 노드를 생성합니다.
```
eksctl delete nodegroup --cluster= --name=
```
클러스터의 각 관리형 노드 그룹에 이 명령을 실행해야 합니다.
이 명령에 대한 자세한 내용은 eksctl 문서의 [노드 그룹 삭제 및 드레이닝](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)을 참조하세요.
# EKS Fargate에서 EKS 자동 모드로 마이그레이션
이 주제에서는 `kubectl`을 사용하여 EKS Fargate에서 Amazon EKS 자동 모드로 워크로드를 마이그레이션하는 프로세스를 안내합니다. 마이그레이션을 점진적으로 수행할 수 있으므로 전환 기간 동안 클러스터 안정성과 애플리케이션 가용성을 유지하면서 원하는 속도로 워크로드를 이동할 수 있습니다.
아래에 설명된 단계별 접근 방식을 사용하면 마이그레이션 기간에 EKS Fargate와 EKS 자동 모드를 나란히 실행할 수 있습니다. 이러한 이중 작업 전략은 EKS Fargate를 완전히 폐기하기 전에 EKS 자동 모드에서 워크로드 동작을 검증할 수 있게 하여 원활한 전환을 보장하는 데 도움이 됩니다. 애플리케이션을 개별적으로 또는 그룹으로 마이그레이션하여 특정 운영 요구 사항과 위험 허용 범위를 유연하게 수용할 수 있습니다.
## Amazon EKS 자동 모드와 AWS Fargate가 포함된 EKS 비교
EKS를 실행하려는 고객에게는 AWS Fargate가 포함된 Amazon EKS가 여전히 옵션으로 제공되지만, 앞으로는 Amazon EKS 자동 모드를 사용하는 것이 권장됩니다. EKS 자동 모드는 Kubernetes를 완벽하게 준수하며 Fargate가 지원할 수 없는 Istio와 같은 모든 업스트림 Kubernetes 기본 요소와 플랫폼 도구를 지원합니다. 또한 EKS 자동 모드는 GPU 및 스팟 인스턴스를 포함한 모든 EC2 런타임 구매 옵션을 완벽하게 지원하므로 고객은 협상된 EC2 할인 및 기타 절감 메커니즘을 활용할 수 있습니다. Fargate가 포함된 EKS를 사용할 때는 이러한 기능을 이용할 수 없습니다.
또한 EKS 자동 모드를 통해 고객은 각 EC2 인스턴스가 단일 애플리케이션 컨테이너를 실행하도록 표준 Kubernetes 예약 기능을 사용하여 Fargate와 동일한 격리 모델을 구현할 수 있습니다. Amazon EKS 자동 모드를 채택함으로써 고객은 Fargate가 제공하는 인프라 관리의 사용 편의성과 추상화를 유지하면서 모든 범위의 EC2 및 구매 옵션을 활용할 수 있는 유연성을 제공하는 완전한 Kubernetes 호환 플랫폼인 AWS에서 Kubernetes를 실행하는 모든 이점을 누릴 수 있습니다.
### EKS Auto Mode에서 Fargate와 유사한 격리 달성
각 포드가 자체 전용 인스턴스에서 실행되는 Fargate의 포드 격리 모델을 복제하기 위해 Kubernetes 토폴로지 분산 제약 조건을 사용할 수 있습니다. 이 방법은 노드 간 포드 분산을 제어하는 데 권장되는 접근 방식입니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
이 구성의 경우:
+ `maxSkew: 1`은 노드당 1개 포드를 효과적으로 분산하도록 두 노드 간 포드 수 차이가 최대 1개가 되도록 보장함
+ `topologyKey: kubernetes.io/hostname`은 노드를 토폴로지 도메인으로 정의함
+ `whenUnsatisfiable: DoNotSchedule`은 제약 조건을 충족할 수 없는 경우 예약을 방지함
+ `minDomains: 1`은 예약하기 전에 하나 이상의 도메인(노드)이 존재하는지 확인
EKS Auto Mode는 이 제약 조건을 충족하기 위해 필요한 경우 새 EC2 인스턴스를 자동으로 프로비저닝하여 Fargate와 동일한 격리 모델을 제공하는 동시에 EC2 인스턴스 유형 및 구매 옵션의 전체 범위에 액세스할 수 있습니다.
또는 보다 엄격한 격리를 위해 포드 비선호도 규칙을 사용할 수 있습니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
`requiredDuringSchedulingIgnoredDuringExecution`을 사용하는 `podAntiAffinity` 규칙은 레이블이 `app: isolated-app`인 두 포드를 동일한 노드에서 예약할 수 없도록 보장합니다. 이 접근 방식에서는 Fargate와 유사한 하드 격리 보장을 제공합니다.
## 사전 조건
마이그레이션을 시작하기 전에 다음을 수행했는지 확인합니다.
+ Fargate가 포함된 클러스터를 설정합니다. 자세한 내용은 [클러스터를 위한 AWS Fargate 시작하기](fargate-getting-started.md) 섹션을 참조하세요.
+ `kubectl`을 설치하고 클러스터에 연결합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
## 1단계: Fargate 클러스터 확인
1. Fargate가 포함된 EKS 클러스터가 실행 중인지 확인합니다.
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 실행 중인 포드를 확인합니다.
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. `deployment_fargate.yaml`이라는 파일에 배포를 생성합니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 배포를 적용합니다.
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. 포드와 배포를 확인합니다.
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. 노드를 확인합니다.
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## 2단계: 클러스터에서 EKS 자동 모드 활성화
1. AWS CLI 또는 관리 콘솔을 사용하여 기존 클러스터에서 EKS Auto Mode를 활성화합니다. 자세한 내용은 [기존 클러스터에서 EKS Auto Mode 활성화](auto-enable-existing.md) 섹션을 참조하세요.
1. NodePool을 확인합니다.
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## 3단계: 마이그레이션할 워크로드 업데이트
EKS Auto Mode로 마이그레이션하려는 워크로드를 식별하고 업데이트합니다.
Fargate에서 EKS 자동 모드로 워크로드를 마이그레이션하려면 주석 `eks.amazonaws.com/compute-type: ec2`를 적용합니다. 이렇게 하면 Fargate 프로파일에도 불구하고 Fargate에서 워크로드를 예약하지 않고 EKS 자동 모드 NodePool에서 워크로드를 포착할 수 있습니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
1. 배포(예: `deployment_fargate.yaml` 파일)를 수정하여 컴퓨팅 유형을 `ec2`로 변경합니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 배포를 적용합니다. 이 변경 사항을 통해 새 EKS 자동 모드 노드에서 워크로드를 예약할 수 있습니다.
```
kubectl apply -f deployment_fargate.yaml
```
1. 배포가 EKS 자동 모드 클러스터에서 실행 중인지 확인합니다.
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. EKS 자동 모드 관리형 노드에서 실행 중인 Fargate 노드와 배포가 없는지 확인합니다.
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## 4단계: 점진적으로 워크로드 마이그레이션
마이그레이션하려는 각 워크로드에 대해 3단계를 반복합니다. 이를 통해 요구 사항 및 위험 허용 범위에 따라 워크로드를 개별적으로 또는 그룹으로 이동할 수 있습니다.
## 5단계: 원래 fargate 프로파일 제거
모든 워크로드가 마이그레이션되면 원래 `fargate` 프로파일을 제거할 수 있습니다. **을 Fargate 프로파일의 이름으로 바꿉니다.
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## 6단계: CoreDNS 스케일 다운
EKS 자동 모드는 CoreDNS를 처리하기 때문에 `coredns` 배포를 0으로 스케일 다운합니다.
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# 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
```
# EKS 자율 모드 설정 구성
이 장에서는 Amazon Elastic Kubernetes Service(EKS) Auto Mode 클러스터의 특정 측면을 구성하는 방법을 설명합니다. EKS Auto Mode는 대부분의 인프라 구성 요소를 자동으로 관리하지만 워크로드 요구 사항에 맞게 특정 기능을 사용자 지정할 수 있습니다.
이 주제에 설명된 구성 옵션을 사용하여 자동화된 인프라 관리의 이점을 유지하면서 네트워킹 설정, 컴퓨팅 리소스, 로드 밸런싱 동작을 수정할 수 있습니다. 구성을 변경하기 전에 다음 섹션에서 사용 가능한 옵션을 검토하여 필요에 가장 적합한 접근 방식을 결정합니다.
| 구성하려는 기능 | 구성 옵션 |
| --- | --- |
| **노드 네트워킹 및 스토리지** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [Amazon EKS용 노드 클래스 생성](create-node-class.md) |
| **노드 컴퓨팅 리소스** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) |
| **정적 용량 노드 풀** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode에서 정적 용량 노드 풀](auto-static-capacity.md) |
| **Application Load Balancer 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [IngressClass를 생성하여 Application Load Balancer 구성](auto-configure-alb.md) |
| **Network Load Balancer 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [서비스 주석을 사용하여 Network Load Balancer 구성](auto-configure-nlb.md) |
| **스토리지 클래스 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [스토리지 클래스 생성](create-storage-class.md) |
| **ODCR 사용량 제어** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어](auto-odcr.md) |
| **노드 고급 보안** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [노드에 대한 고급 보안 설정 구성](auto-advanced-security.md) |
# Amazon EKS용 노드 클래스 생성
Amazon EKS 노드 클래스는 EKS 자동 모드 관리형 노드의 구성을 세부적으로 제어할 수 있는 템플릿입니다. 노드 클래스는 네트워크 구성, 스토리지 설정, 리소스 태그 지정을 포함하여 EKS 클러스터의 노드 그룹에 적용되는 인프라 수준 설정을 정의합니다. 이 주제에서는 특정 운영 요구 사항에 맞게 노드 클래스를 생성하고 구성하는 방법을 설명합니다.
EKS Auto Mode가 기본 설정 이상으로 EC2 인스턴스를 프로비저닝하고 구성하는 방법을 사용자 지정해야 하는 경우, 노드 클래스를 생성하면 중요한 인프라 파라미터를 정확하게 제어할 수 있습니다. 예를 들어 보안 강화를 위해 프라이빗 서브넷 배치를 지정하거나, 성능에 민감한 워크로드에 대해 인스턴스 임시 스토리지를 구성하거나, 비용 할당을 위해 사용자 지정 태그 지정을 적용할 수 있습니다.
## 노드 클래스 생성
`NodeClass`를 생성하려면 다음 단계를 따르세요.
1. 노드 클래스 구성으로 YAML 파일(예: `nodeclass.yaml`) 생성
1. `kubectl`을 사용하여 클러스터에 해당 구성 적용
1. 노드 풀 구성에서 노드 클래스를 참조하세요. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
`kubectl`을 설치하고 구성해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
### 기본 노드 클래스 예제
다음은 노드 클래스 예제입니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
이 NodeClass는 노드의 임시 스토리지 양을 늘립니다.
다음을 사용하여 이 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
그런 다음 노드 풀 구성에서 노드 클래스를 참조합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 노드 클래스 액세스 항목 생성
사용자 지정 노드 클래스를 생성하는 경우 노드가 클러스터에 조인할 수 있도록 EKS 액세스 항목을 생성해야 합니다. EKS는 내장 노드 클래스와 노드 풀을 사용할 때 액세스 항목을 자동으로 생성합니다.
Access Entries 작동 방법에 대한 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
EKS 자동 모드 노드 클래스에 대한 액세스 항목을 생성할 때 `EC2` 액세스 항목 유형을 사용해야 합니다.
### CLI를 사용하여 액세스 항목 생성
**EC2 노드에 대한 액세스 항목 생성 및 EKS 자동 모드 정책 연결**
클러스터 이름과 노드 역할 ARN으로 다음 CLI 명령을 업데이트합니다. 노드 역할 ARN은 노드 클래스 YAML에 지정됩니다.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### CloudFormation을 사용하여 액세스 항목 생성
**EC2 노드에 대한 액세스 항목 생성 및 EKS 자동 모드 정책 연결**
클러스터 이름과 노드 역할 ARN으로 다음 CLI 명령을 업데이트합니다. 노드 역할 ARN은 노드 클래스 YAML에 지정됩니다.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
CloudFormation 스택 배포에 대한 자세한 내용은 [CloudFormation 시작하기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)를 참조하세요.
## 노드 클래스 사양
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 고려 사항
+ 인스턴스에 있는 로컬 스토리지의 양을 확인하려면 노드를 설명하여 임시 스토리지 리소스를 확인할 수 있습니다.
+ **볼륨 암호화** - EKS는 구성된 사용자 지정 KMS 키를 사용하여 인스턴스의 읽기 전용 루트 볼륨과 읽기/쓰기 데이터 볼륨을 암호화합니다.
+ **노드 IAM 역할 바꾸기** - `NodeClass`와 연결된 노드 IAM 역할을 변경하는 경우 새 액세스 항목을 생성해야 합니다. EKS는 클러스터 생성 중 노드 IAM 역할에 대한 액세스 항목을 자동으로 생성합니다. 노드 IAM 역할에는 `AmazonEKSAutoNodePolicy` EKS 액세스 정책이 필요합니다. 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
+ **최대 포드 밀도** - EKS는 노드의 최대 포드 수를 110개로 제한합니다. 이 제한은 기존의 최대 포드 계산 후에 적용됩니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요.
+ **태그** - Kubernetes에서 EC2로 태그를 전파하려면 추가 IAM 권한을 구성해야 합니다. 자세한 내용은 [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md) 섹션을 참조하세요.
+ **기본 노드 클래스** - 사용자 지정 노드 클래스의 이름을 `default`로 지정하지 마세요. 이는 EKS 자동 모드에 내장 `NodePool`을 하나 이상 활성화하면 자동으로 프로비저닝되는 `default`라는 `NodeClass`가 포함되어 있기 때문입니다. 내장 `NodePools` 활성화에 대한 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
+ **여러 서브넷이 있는 `subnetSelectorTerms` 동작** - `subnetSelectorTerms` 조건과 일치하거나 ID로 제공하는 서브넷이 여러 개 있는 경우 EKS 자동 모드는 서브넷 전체에 분산된 노드를 생성합니다.
+ 서브넷이 서로 다른 가용 영역(AZ)에 있는 경우 [포드 토폴로지 확산 제약 조건](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) 및 [토폴로지 인식 라우팅](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)과 같은 Kubernetes 기능을 사용하여 각각 영역에 걸쳐 포드와 트래픽을 확산할 수 있습니다.
+ *동일한 AZ*에 `subnetSelectorTerms`와 일치하는 서브넷이 여러 개 있는 경우 EKS 자동 모드는 해당 AZ의 서브넷에 분산된 각 노드에 포드를 생성합니다. EKS 자동 모드는 동일한 AZ의 다른 서브넷에 있는 각 노드에 보조 네트워크 인터페이스를 생성합니다. 각 서브넷에서 사용 가능한 IP 주소 수를 기준으로 선택하여 서브넷을 보다 효율적으로 사용합니다. 하지만 EKS 자동 모드가 각 포드에 대해 어떤 서브넷을 사용할지는 지정할 수 없습니다. 포드가 특정 서브넷에서 실행되도록 하려면 대신 [포드에 대한 별도의 서브넷 및 보안 그룹](#pod-subnet-selector)를 사용합니다.
## 포드에 대한 별도의 서브넷 및 보안 그룹
`podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms` 필드는 포드가 노드와 다른 서브넷을 사용하도록 허용함으로써 고급 네트워킹 구성을 지원합니다. 두 필드를 함께 지정해야 합니다. 이 분리는 네트워크 트래픽 라우팅 및 보안 정책에 대한 향상된 제어를 제공합니다.
**참고**
이 기능은 EKS Auto Mode 이외 컴퓨팅을 위해 AWS VPC CNI와 함께 사용되는 [포드 보안 그룹](security-groups-for-pods.md)(SGPP) 기능과 다릅니다. SGPP는 EKS Auto Mode에서 지원되지 않습니다. 대신 `NodeClass`에서 `podSecurityGroupSelectorTerms`를 사용하여 포드 트래픽에 별도의 보안 그룹을 적용합니다. 보안 그룹은 `NodeClass` 수준에서 적용됩니다. 즉, 해당 `NodeClass`를 사용하는 노드의 모든 포드가 동일한 포드 보안 그룹을 공유합니다.
### 작동 방식
`podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms`를 구성하는 경우:
1. 노드의 기본 ENI는 `subnetSelectorTerms` 및 `securityGroupSelectorTerms`의 서브넷 및 보안 그룹을 사용합니다. 노드의 고유 IP 주소만 이 인터페이스에 할당됩니다.
1. EKS Auto Mode는 `podSecurityGroupSelectorTerms`의 보안 그룹이 연결된 `podSubnetSelectorTerms`와 일치하는 서브넷에서 보조 ENI를 생성합니다. 포드 IP 주소는 기본적으로 /28 접두사를 사용하여 이러한 보조 ENI에서 할당되며, 연속 접두사 블록을 사용할 수 없는 경우 보조 IP(/32)로 자동 폴백됩니다. `ipv4PrefixSize`가 `advancedNetworking`에서 `"32"`로 설정된 경우 보조 IP만 사용됩니다.
1. `podSecurityGroupSelectorTerms`에 지정된 보안 그룹은 VPC 내 포드 트래픽에 적용됩니다. VPC 외부로 향하는 트래픽의 경우 소스 네트워크 주소 변환(SNAT)이 포드 IP를 노드 IP로 변환하기 때문에 포드는 노드의 기본 ENI 및 해당 보안 그룹을 사용합니다. `NodeClass`에서 `snatPolicy` 필드를 사용하여 이 동작을 수정할 수 있습니다.
### 사용 사례
다음 수행해야 하는 경우 `podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms`를 사용합니다.
+ 서로 다른 보안 그룹을 적용하여 노드와 포드의 트래픽을 개별적으로 제어합니다.
+ 애플리케이션 트래픽(포드 간 통신)에서 인프라 트래픽(노드 간 통신)을 분리합니다.
+ 포드 서브넷과 다른 네트워크 구성을 노드 서브넷에 적용합니다.
+ 포드 트래픽에 영향을 주지 않고 노드 트래픽에 대해 특히 역방향 프록시 또는 네트워크 필터링을 구성합니다. `advancedNetworking` 및 `certificateBundles`를 사용하여 역방향 프록시와 프록시에 대한 자체 서명 또는 프라이빗 인증서를 정의합니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 별도의 포드 서브넷 및 보안 그룹에 대한 고려 사항
+ **보안 그룹 범위**: `podSecurityGroupSelectorTerms`의 보안 그룹은 보조 ENI에 연결되며 VPC 내의 포드 트래픽에 적용됩니다. SNAT가 활성화되면(기본값 `snatPolicy: Random`) VPC에서 나가는 트래픽이 노드의 기본 ENI IP 주소로 변환되므로 대신 `securityGroupSelectorTerms`의 노드 보안 그룹이 대신 해당 트래픽에 적용됩니다. `snatPolicy: Disabled`를 설정하면 포드가 모든 트래픽에 대해 자체 IP 주소를 사용하므로 라우팅 및 보안 그룹이 적절히 구성되어야 합니다.
+ **NodeClass 수준 세부 수준**: 포드 보안 그룹은 `NodeClass`를 사용하여 노드에 예약된 모든 포드에 적용됩니다. 서로 다른 보안 그룹을 서로 다른 워크로드에 적용하려면 별도의 `NodeClass` 및 `NodePool` 리소스를 생성하고 테인트, 허용 오차 또는 노드 선택기를 사용하여 워크로드를 적절한 노드로 예약합니다.
+ **포드 밀도 감소**: 노드의 기본 네트워크 인터페이스가 노드 IP에 대해 예약되었고 포드에 대해 사용할 수 없으므로 각 노드에서 더 적은 포드를 실행할 수 있습니다.
+ **서브넷 선택기 제한 사항**: 포드 서브넷 또는 보안 그룹 선택에는 표준 `subnetSelectorTerms` 및 `securityGroupSelectorTerms` 구성이 적용되지 않습니다.
+ **네트워크 계획**: 워크로드 요구 사항을 지원하기 위해 노드와 포드 서브넷 모두에서 적절한 IP 주소 공간을 확보합니다.
+ **라우팅 구성**: 포드 서브넷의 라우팅 테이블과 네트워크 액세스 제어 목록(ACL)이 노드와 포드 서브넷 간의 통신을 위해 올바르게 구성되어 있는지 확인합니다.
+ **가용 영역**: 여러 AZ에 걸쳐 포드 서브넷을 생성했는지 확인합니다. 특정 포드 서브넷을 사용하는 경우 노드 서브넷 AZ와 동일한 AZ에 있어야 합니다.
## 포드에 대한 보조 IP 모드
`ipv4PrefixSize` 필드는 노드에 보조 IP 주소만 할당하여 고급 네트워킹 구성을 지원합니다. 이 기능은 노드에 접두사(/28)를 할당하지 않으며 하나의 보조 IP만 MinimalIPTarget으로 유지 관리합니다.
### 사용 사례
다음 작업 시 `ipv4PrefixSize`를 사용합니다.
+ **IP 사용률 감소**: 모든 노드에서 하나의 IP 주소만 워밍업됩니다.
+ **낮은 포드 이탈 속도**: 포드 생성 속도는 주요 사안이 아닙니다.
+ **접두사 조각화 없음**: 접두사로 인한 조각화는 Auto Mode를 사용하는 데 주요 사안 또는 차단 요인입니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### 보조 IP 모드에 대한 고려 사항
+ **포드 생성 속도 감소**: 하나의 보조 IP만 워밍업되므로 IPAM 서비스에는 더 많은 포드 생성 시 IP를 프로비저닝하는 데 더 많은 시간이 필요합니다.
## IPv6 클러스터의 IPv6 포드에서 IPv4 송신 비활성화.
`enableV4Egress` 필드는 기본적으로 `true`입니다. Auto Mode IPv6 클러스터의 경우 기능을 비활성화할 수 있으므로 Auto Mode에서는 IPv6 포드에 대한 송신 전용 IPv4 인터페이스를 생성하지 않습니다. 이는 IPv4 송신 인터페이스에 네트워크 정책이 적용되지 않기 때문에 중요합니다. 네트워크 정책은 포드의 기본 인터페이스(eth0)에만 적용됩니다.
### 사용 사례
다음 작업 시 `enableV4Egress`를 사용합니다.
+ **IPv6 클러스터 사용**: IPv4 송신 트래픽이 기본적으로 허용됩니다.
+ **네트워크 정책 사용**: 현재 EKS 네트워크 정책은 듀얼 스택을 지원하지 않습니다. `enableV4Egress`를 비활성화하면 포드 트래픽이 예기치 않게 IPv4를 통해 나가는 것을 방지할 수 있습니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### enableV4Egress 비활성화 시 고려 사항
+ **IPv6 클러스터의 네트워크 정책**: IPv6 클러스터는 기본적으로 IPv4 트래픽을 허용합니다. `enableV4Egress: false`를 설정하면 IPv4 송신 트래픽이 차단되어 특히 네트워크 정책과 함께 사용할 때 향상된 보안을 제공합니다.
# EKS Auto Mode용 노드 풀 생성
Amazon EKS 노드 풀은 Kubernetes 클러스터에서 컴퓨팅 리소스를 관리하는 유연한 방법을 제공합니다. 이 주제에서는 클러스터 조정 및 리소스 사용률을 최적화하는 데 도움이 되는 노드 프로비저닝 도구인 Karpenter를 사용하여 노드 풀을 생성하고 구성하는 방법을 보여줍니다. Karpenter의 NodePool 리소스를 사용하면 인스턴스 유형, 가용 영역, 아키텍처, 용량 유형을 포함한 컴퓨팅 리소스에 대한 특정 요구 사항을 정의할 수 있습니다.
내장 `system` 및 `general-purpose` 노드 풀은 수정할 수 없습니다. 활성화 또는 비활성화만 가능합니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
NodePool 사양을 사용하면 지원되는 다양한 레이블 및 요구 사항을 통해 EKS 클러스터의 컴퓨팅 리소스를 세밀하게 제어할 수 있습니다. 여기에는 EC2 인스턴스 범주, CPU 구성, 가용 영역, 아키텍처(ARM64/AMD64), 용량 유형(스팟 또는 온디맨드)을 지정하는 옵션이 포함됩니다. 또한 CPU 및 메모리 사용량에 대한 리소스 제한을 설정하여 클러스터가 필요한 운영 경계 내에 있게 할 수 있습니다.
EKS Auto Mode는 잘 알려진 Kubernetes 레이블을 활용하여 일관되고 표준화된 노드 특성 식별 방법을 제공합니다. 가용 영역의 `topology.kubernetes.io/zone` 및 CPU 아키텍처의 `kubernetes.io/arch`와 같은 이러한 레이블은 설정된 Kubernetes 규칙을 따릅니다. 또한 EKS별 레이블(접두사 `eks.amazonaws.com/`)은 인스턴스 유형, CPU 제조업체, GPU 기능, 네트워킹 사양 등의 AWS 특정 속성으로 이 기능을 확장합니다. 이 표준화된 레이블 지정 시스템을 사용하면 기존 Kubernetes 도구와 원활하게 통합하는 동시에 심층적인 AWS 인프라 통합을 제공할 수 있습니다.
## NodePool 생성
다음 단계에 따라 Amazon EKS 클러스터용 NodePool을 생성합니다.
1. 필요한 NodePool 구성으로 `nodepool.yaml`이라는 YAML 파일을 생성합니다. 아래 샘플 구성을 사용할 수 있습니다.
1. 클러스터에 NodePool을 적용합니다.
```
kubectl apply -f nodepool.yaml
```
1. NodePool이 성공적으로 생성되었는지 확인합니다.
```
kubectl get nodepools
```
1. (선택 사항) NodePool 상태를 모니터링합니다.
```
kubectl describe nodepool default
```
NodePool이 클러스터에 있는 유효한 NodeClass를 참조하는지 확인합니다. NodeClass는 컴퓨팅 리소스에 대한 AWS 특정 구성을 정의합니다. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 샘플 NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## EKS 자동 모드 지원 레이블
EKS Auto Mode는 다음과 같이 잘 알려진 레이블을 지원합니다.
**참고**
EKS Auto Mode는 Karpenter와 다른 레이블을 사용합니다. EC2 관리형 인스턴스와 관련된 레이블은 `eks.amazonaws.com`으로 시작합니다.
| 레이블 | 예제 | 설명 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS 리전 |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS 인스턴스 유형 |
| kubernetes.io/arch | amd64 | 아키텍처는 인스턴스의 [GOARCH 값](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)으로 정의됨 |
| karpenter.sh/capacity-type | spot | 용량 유형에 `spot`, `on-demand` 포함 |
| eks.amazonaws.com/instance-hypervisor | nitro | 특정 하이퍼바이저를 사용하는 인스턴스 유형 |
| eks.amazonaws.com/compute-type | auto | EKS Auto Mode 관리형 노드 식별 |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | 전송 중 암호화를 지원하는(또는 지원하지 않는) 인스턴스 유형 |
| eks.amazonaws.com/instance-category | g | 동일한 범주의 인스턴스 유형, 일반적으로 생성 번호 앞의 문자열 |
| eks.amazonaws.com/instance-generation | 4 | 인스턴스 범주 내의 인스턴스 유형 생성 번호 |
| eks.amazonaws.com/instance-family | g4dn | 속성이 유사하지만 리소스 수량이 다른 인스턴스 유형 |
| eks.amazonaws.com/instance-size | 8xlarge | 리소스 수량은 비슷하지만 속성이 다른 인스턴스 유형 |
| eks.amazonaws.com/instance-cpu | 32 | 인스턴스의 CPU 수 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU 제조업체 이름 |
| eks.amazonaws.com/instance-memory | 131072 | 인스턴스의 메모리 메비바이트 수 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 인스턴스에서 사용 가능한 EBS의 [최대 메가비트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) 수 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | 인스턴스에서 사용 가능한 [기준 메가비트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) 수 |
| eks.amazonaws.com/instance-gpu-name | t4 | 사용 가능한 경우 인스턴스의 GPU 이름 |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU 제조업체 이름 |
| eks.amazonaws.com/instance-gpu-count | 1 | 인스턴스의 GPU 수 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU의 메모리 메비바이트 수 |
| eks.amazonaws.com/instance-local-nvme | 900 | 인스턴스의 로컬 nvme 스토리지 기비바이트 수 |
**참고**
EKS 자동 모드는 특정 인스턴스만 지원하며 최소 크기 요구 사항이 있습니다. 자세한 내용은 [EKS 자동 모드 지원 인스턴스 참조](automode-learn-instances.md#auto-supported-instances) 섹션을 참조하세요.
## EKS 자동 모드 미지원 레이블
EKS Auto Mode는 다음 레이블을 지원하지 않습니다.
+ EKS Auto Mode는 Linux만 지원
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 내장 노드 풀 비활성화
사용자 지정 노드 풀을 생성하는 경우 내장 노드 풀을 비활성화할 수 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
## 내장 노드 풀이 없는 클러스터
내장 노드 풀 없이 클러스터를 생성할 수 있습니다. 이는 조직에서 사용자 지정 노드 풀을 생성한 경우에 유용합니다.
**참고**
내장 노드 풀 없이 클러스터를 생성하면 `default` NodeClass가 자동으로 프로비저닝되지 않습니다. 사용자 지정 NodeClass를 생성해야 합니다. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
**개요:**
1. `nodePools` 및 `nodeRoleArn` 값을 모두 비워두고 EKS 클러스터를 생성합니다.
+ 샘플 eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
자세한 내용은 [eksctl CLI를 사용하여 EKS Auto Mode 클러스터 생성](automode-get-started-eksctl.md) 섹션을 참조하세요.
1. 노드 역할 ARN을 사용하여 사용자 지정 노드 클래스 생성
+ 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
1. 사용자 지정 노드 클래스에 대한 액세스 항목 생성
+ 자세한 내용은 [노드 클래스 액세스 항목 생성](create-node-class.md#auto-node-access-entry) 섹션을 참조하세요.
1. 위에서 설명한 대로 사용자 지정 노드 풀을 생성합니다.
## 중단
여러 가지 방법으로 NodePool을 통해 노드를 중단하도록 EKS 자동 모드를 구성할 수 있습니다. `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` 또는 `spec.template.spec.expireAfter`를 사용할 수 있습니다. 또한 NodePool의 `spec.disruption.budgets`를 통해 EKS 자동 모드의 중단 비율을 제한할 수 있습니다. 시간 범위와 중단된 동시 노드 수를 제어할 수도 있습니다. 이 동작을 구성하는 방법은 Karpenter 설명서의 [Disruption](https://karpenter.sh/docs/concepts/disruption/)을 참조하세요.
노드 풀에 대한 중단을 구성하여 다음을 수행할 수 있습니다.
+ 인스턴스 활용도가 낮은 시기를 식별하고 워크로드를 통합합니다.
+ 노드 풀 중단 예산을 생성하여 드리프트, 비우기 및 통합으로 인한 노드 종료 비율을 제한합니다.
기본적으로 EKS 자동 모드는 다음을 수행합니다.
+ 활용도가 낮은 인스턴스를 통합합니다.
+ 336시간 후에 인스턴스를 종료합니다.
+ 단일 중단 예산을 노드의 10%로 설정합니다.
+ 약 일주일에 한 번씩 발생하는 새로운 자동 모드 AMI가 릴리스될 때 드리프트로 인한 노드 교체가 가능합니다.
## 종료 유예 기간
`terminationGracePeriod`가 EKS Auto NodePool에 명시적으로 정의되지 않은 경우 시스템은 연결된 NodeClaim에 기본 24시간 종료 유예 기간을 자동으로 적용합니다. EKS 자동 고객은 사용자 지정 NodePool 구성에서 `terminationGracePeriod`가 기본값으로 설정되어 있는 것을 볼 수 없지만 NodeClaim에서는 이 기본값이 표시됩니다. 이 기능은 유예 기간이 NodePool에 명시적으로 설정되어 있든, NodeClaim에 기본값으로 설정되어 있든 일관되게 유지되므로 클러스터 전체에서 예측 가능한 노드 종료 동작을 보장합니다.
# EKS Auto Mode에서 정적 용량 노드 풀
Amazon EKS Auto Mode는 포드 수요에 관계없이 고정된 수의 노드를 유지 관리하는 정적 용량 노드 풀을 지원합니다. 정적 용량 노드 풀은 일관된 인프라 공간을 유지 관리해야 하는 예측 가능한 용량, 예약 인스턴스 또는 특정 규정 준수 요구 사항이 필요한 워크로드에 유용합니다.
포드 예약 수요에 따라 조정되는 동적 노드 풀과 달리 정적 용량 노드 풀은 사용자가 구성한 노드 수를 유지 관리합니다.
## 정적 용량 노드 풀 구성
정적 용량 노드 풀을 생성하려면 NodePool 사양에서 `replicas` 필드를 설정합니다. `replicas` 필드에서는 노드 풀에서 유지 관리할 정확한 노드 수를 정의합니다. `replicas` 구성 방법은 [예제](#static-capacity-examples) 섹션을 참조하세요.
## 정적 용량 노드 풀 고려 사항
정적 용량 노드 풀에는 다음과 같이 여러 중요한 제약 조건과 동작이 있습니다.
**구성 제약 조건:**
+ **모드 전환 불가**: 노드 풀에 `replicas`를 설정한 후에는 노드 풀을 제거할 수 없습니다. 노드 풀에서는 정적 모드와 동적 모드 사이를 전환할 수 없습니다.
+ **제한된 리소스 제한**: 제한 섹션에서 `limits.nodes` 필드만 지원됩니다. CPU 및 메모리 제한은 적용되지 않습니다.
+ **가중치 필드 없음**: 노드 선택이 우선순위를 기반으로 하지 않으므로 정적 용량 노드 풀에서 `weight` 필드를 설정할 수 없습니다.
**운영 동작:**
+ **통합 없음**: 정적 용량 풀의 노드는 통합 시 고려되지 않습니다.
+ **조정 작업**: 조정 작업은 노드 중단 예산을 우회하지만 여전히 PodDisruptionBudgets를 고려합니다.
+ **노드 교체**: 구성에 따라 드리프트(예: AMI 업데이트) 및 만료에 대해 여전히 노드가 교체됩니다.
## 모범 사례
**용량 계획:**
+ 노드 교체 작업 중에 임시 조정을 허용하려면 `limits.nodes`를 `replicas`보다 높게 설정합니다.
+ 제한을 설정할 때 노드 드리프트 또는 AMI 업데이트 중에 필요한 최대 용량을 고려합니다.
**인스턴스 선택:**
+ 예약 인스턴스 또는 특정 하드웨어 요구 사항이 있는 경우 특정 인스턴스 유형을 사용합니다.
+ 조정 중에 인스턴스 가용성을 제한할 수 있는 지나치게 제한적인 요구 사항을 피합니다.
**중단 관리:**
+ 가용성과 유지 관리 작업의 균형을 맞추도록 적절한 중단 예산을 구성합니다.
+ 예산 백분율을 설정할 때 노드 교체에 대한 애플리케이션의 허용 오차를 고려합니다.
**모니터링:**
+ `status.nodes` 필드를 정기적으로 모니터링하여 원하는 용량이 유지되는지 확인합니다.
+ 실제 노드 수가 원하는 복제본에서 벗어나는 경우에 대한 알림을 설정합니다.
**영역 분산:**
+ 고가용성을 위해 여러 가용 영역으로 정적 용량을 분산합니다.
+ 여러 가용 영역에 걸쳐 분산된 정적 용량 노드 풀을 생성하면 EKS Auto Mode는 지정된 영역에 노드를 분산하지만 균등한 분산을 보장하지는 않습니다.
+ 여러 가용 영역에서 예측 가능하고 균등하게 배포하려면 `topology.kubernetes.io/zone` 요구 사항을 사용하여 각 특정 가용 영역에 고정되는 별도의 정적 용량 노드 풀을 생성합니다.
+ 3개 영역에 균등하게 분산된 노드 12개가 필요한 경우 3개 영역에 복제본 12개가 있는 노드 풀 1개가 아니라 각각 복제본 4개가 있는 노드 풀 3개를 생성합니다.
## 정적 용량 노드 풀 규모 조정
`kubectl scale` 명령을 사용하여 정적 용량 노드 풀의 복제본 수를 변경할 수 있습니다.
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
스케일 다운 시 EKS Auto Mode는 PodDisruptionBudgets를 고려하고 실행 중인 포드를 나머지 노드로 다시 예약할 수 있도록 노드를 정상적으로 종료합니다.
## 정적 용량 노드 풀 모니터링
다음 명령을 사용하여 정적 용량 노드 풀을 모니터링합니다.
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` 필드에는 노드 풀에서 관리하는 현재 노드 수가 표시되며, 이는 정상 조건에서 원하는 `replicas` 수와 일치해야 합니다.
## 문제 해결
**노드가 원하는 복제본에 도달하지 않음:**
+ `limits.nodes` 값이 충분한지 확인
+ 요구 사항이 인스턴스 선택을 지나치게 제한하지 않는지 확인
+ 사용하는 인스턴스 유형 및 리전에 대한 AWS 서비스 할당량 검토
**노드 교체 시간이 너무 오래 걸림:**
+ 더 많은 동시 교체를 허용하도록 중단 예산 조정
+ PodDisruptionBudgets가 노드 종료를 방지하는지 확인
**예기치 않은 노드 종료:**
+ `expireAfter` 및 `terminationGracePeriod` 설정 검토
+ 수동 노드 종료 또는 AWS 유지 관리 이벤트 확인
## 예제
### 기본 정적 용량 노드 풀
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 특정 인스턴스 유형을 사용하는 정적 용량
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### 다중 영역 정적 용량 노드 풀
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### 용량 예약을 사용하는 정적 용량
다음 예제에서는 EC2 용량 예약과 함께 정적 용량 노드 풀을 사용하는 방법을 보여줍니다. EKS Auto Mode에서 EC2 용량 예약을 사용하는 방법에 대한 자세한 내용은 [EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어](auto-odcr.md) 섹션을 참조하세요.
`capacityReservationSelectorTerms`를 정의하는 `NodeClass`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
위의 `NodeClass`를 참조하고 `karpenter.sh/capacity-type: reserved`를 사용하는 `NodePool`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# IngressClass를 생성하여 Application Load Balancer 구성
EKS Auto Mode는 클러스터 앱을 인터넷에 노출하는 등 로드 밸런싱을 위한 일상적인 작업을 자동화합니다.
AWS에서는 Application Load Balancer(ALB)를 사용하여 HTTP 및 HTTPS 트래픽을 제공할 것을 제안합니다. Application Load Balancer는 요청의 내용을 기반으로 요청을 라우팅할 수 있습니다. Application Load Balancer에 대한 자세한 내용은 [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)을 참조하세요.
EKS Auto Mode는 Application Load Balancer(ALB)를 생성하고 구성합니다. 예를 들어 EKS Auto Mode는 `Ingress` Kubernetes 객체를 생성할 때 로드 밸런서를 생성하고 클러스터 워크로드로 트래픽을 라우팅하도록 구성합니다.
**개요**
1. 인터넷에 노출하려는 워크로드를 생성합니다.
1. SSL/TLS 및 VPC 서브넷에 사용할 인증서와 같은 AWS 특정 구성 값을 지정하여 `IngressClassParams` 리소스를 생성합니다.
1. EKS Auto Mode가 `IngressClass` 리소스의 컨트롤러가 되도록 지정하는 리소스를 생성합니다.
1. HTTP 경로 및 포트를 클러스터 워크로드와 연결하는 `Ingress` 리소스를 생성합니다.
EKS Auto Mode는 `Ingress` 리소스에 지정된 로드 밸런서 구성을 사용하여 `IngressClassParams` 리소스에 지정된 워크로드를 가리키는 Application Load Balancer를 생성합니다.
## 사전 조건
+ Amazon EKS 클러스터에서 활성화된 EKS Auto Mode
+ 클러스터에 연결하도록 구성된 Kubectl
+ `kubectl apply -f `를 사용하여 아래의 샘플 구성 YAML 파일을 클러스터에 적용할 수 있습니다.
**참고**
EKS 자동 모드에서는 퍼블릭 및 프라이빗 서브넷을 식별하기 위해 서브넷 태그가 필요합니다.
`eksctl`로 클러스터를 생성한 경우 이미 이러한 태그가 있는 것입니다.
[EKS 자동 모드의 태그 서브넷](tag-subnets-auto.md) 방법에 대해 알아봅니다.
## 1단계: 워크로드 생성
먼저 인터넷에 공개하려는 워크로드를 생성합니다. 배포 또는 서비스와 같이 HTTP 트래픽을 제공하는 모든 Kubernetes 리소스일 수 있습니다.
이 예제에서는 포트 `80`에서 수신 대기하는 `service-2048`이라는 간단한 HTTP 서비스를 사용합니다. `2048-deployment-service.yaml` 매니페스트를 적용하여 이 서비스와 해당 배포를 생성합니다.
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
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
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f 2048-deployment-service.yaml
```
위에 나열된 리소스는 기본 네임스페이스에서 생성됩니다. 다음 명령을 실행하여 확인할 수 있습니다.
```
kubectl get all -n default
```
## 2단계: IngressClassParams 생성
`IngressClassParams` 객체를 생성하여 Application Load Balancer에 대한 AWS 특정 구성 옵션을 지정합니다. 이 예제에서는 다음 단계에서 사용할 `alb`라는 `IngressClassParams` 리소스를 생성합니다. 이 리소스는 `alb-ingressclassparams.yaml`이라는 파일에서 로드 밸런서 체계를 `internet-facing`으로 지정합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingressclassparams.yaml
```
## 3단계: IngressClass 생성
`alb-ingressclass.yaml`이라는 파일에 `IngressClassParams` 리소스에 설정된 AWS 특정 구성 값을 참조하는 `IngressClass`를 생성합니다. `IngressClass`의 이름을 기록해 둡니다. 이 예제에서는 `IngressClass` 및 `IngressClassParams`의 이름이 모두 `alb`입니다.
`is-default-class` 주석을 사용하여 `Ingress` 리소스가 기본적으로 이 클래스를 사용해야 하는지 여부를 제어합니다.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
구성 옵션에 대한 자세한 내용은 [IngressClassParams 참조](#ingress-reference) 섹션을 참조하세요.
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingressclass.yaml
```
## 4단계: 수신 생성
`alb-ingress.yaml`이라는 파일에 `Ingress` 리소스를 생성합니다. 이 리소스의 목적은 Application Load Balancer의 경로 및 포트를 클러스터의 워크로드와 연결하는 것입니다. 이 예제에서는 포트 80에서 `service-2048`이라는 서비스로 트래픽을 라우팅하는 `2048-ingress`라는 `Ingress` 리소스를 생성합니다.
이 리소스 구성에 대한 자세한 내용은 Kubernetes 설명서의 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) 섹션을 참조하세요.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingress.yaml
```
## 5단계: 상태 확인
`kubectl`을 사용하여 `Ingress`의 상태를 찾습니다. 로드 밸런서를 사용할 수 있기까지 몇 분 정도 걸릴 수 있습니다.
이전 단계에서 설정한 `Ingress` 리소스의 이름을 사용합니다. 예제:
```
kubectl get ingress 2048-ingress
```
리소스가 준비되면 로드 밸런서의 도메인 이름을 검색합니다.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
웹 브라우저에서 서비스를 보려면 `Ingress` 복구에 지정된 포트와 경로를 검토합니다.
## 6단계: 정리
로드 밸런서를 정리하려면 다음 명령을 사용합니다.
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode는 AWS 계정에서 연결된 로드 밸런서를 자동으로 삭제합니다.
## IngressClassParams 참조
아래 표는 일반적으로 사용되는 구성 옵션에 대한 빠른 참조입니다.
| 필드 | 설명 | 예시 값 |
| --- | --- | --- |
| `scheme` | ALB가 내부인지 인터넷 연결인지를 정의 | `internet-facing` |
| `namespaceSelector` | 이 IngressClass를 사용할 수 있는 네임스페이스 제한 | `environment: prod` |
| `group.name` | 여러 수신을 그룹화하여 단일 ALB 공유 | `retail-apps` |
| `ipAddressType` | ALB의 IP 주소 유형 설정 | `dualstack` |
| `subnets.ids` | ALB 배포를 위한 서브넷 ID 목록 | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | 필터에 태그를 지정하여 ALB의 서브넷 선택 | `Environment: prod` |
| `certificateARNs` | 사용할 SSL 인증서의 ARN | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | AWS 리소스에 대한 사용자 지정 태그 | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | 로드 밸런서별 속성 | `idle_timeout.timeout_seconds: 60` |
## 고려 사항
+ IngressClass에서 주석을 사용하여 EKS Auto Mode로 로드 밸런서를 구성할 수 없습니다. IngressClass 구성은 IngressClassParams를 통해 완료되어야 합니다. 그러나 개별 수신 리소스에 주석을 사용하여 로드 밸런서 동작(예: `alb.ingress.kubernetes.io/security-group-prefix-lists` 또는 `alb.ingress.kubernetes.io/conditions.*`)을 구성할 수 있습니다.
+ EKS 자동 모드에서 [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)를 설정할 수 없습니다.
+ Kubernetes에서 AWS 로드 밸런서 리소스로 태그 전파를 활성화하려면 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EKS Auto Mode 또는 자체 관리형 AWS 로드 밸런서 컨트롤러와 리소스를 연결하는 방법에 대한 자세한 내용은 [마이그레이션 참조](migrate-auto.md#migration-reference) 섹션을 참조하세요.
+ 로드 밸런서 관련 문제 해결에 대한 자세한 내용은 [EKS Auto Mode 문제 해결](auto-troubleshoot.md) 섹션을 참조하세요.
+ EKS Auto Mode의 로드 밸런싱 기능 사용에 대한 자세한 고려 사항은 [로드 밸런싱](auto-networking.md#auto-lb-consider) 섹션을 참조하세요.
다음 표에서는 EKS Auto Mode에 대한 IngressClassParams, Ingress 주석, TargetGroupBinding 구성의 변경 사항을 자세히 비교합니다. 이 표에서는 API 버전 변경, 사용 중단된 기능, 업데이트된 파라미터 이름을 포함하여 EKS Auto Mode의 로드 밸런싱 기능과 오픈 소스 로드 밸런서 컨트롤러 간의 주요 차이점을 강조합니다.
### IngressClassParams
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.certificateArn` | `spec.certificateARNs` | 여러 인증서 ARN 지원 |
| `spec.subnets.tags` | `spec.subnets.matchTags` | 서브넷 일치 스키마가 변경됨 |
| `spec.listeners.listenerAttributes` | 지원되지 않음 | 아직 EKS 자동 모드에서 지원하지 않음 |
### 수신 주석
| 이전 | New | 설명 |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | 지원되지 않음 | 수신 객체에서 `spec.ingressClassName` 사용 |
| `alb.ingress.kubernetes.io/group.name` | 지원되지 않음 | IngressClass에서만 그룹 지정 |
| `alb.ingress.kubernetes.io/waf-acl-id` | 지원되지 않음 | 대신 WAF v2 사용 |
| `alb.ingress.kubernetes.io/web-acl-id` | 지원되지 않음 | 대신 WAF v2 사용 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | 지원되지 않음 | Shield 통합 비활성화됨 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | 지원되지 않음 | OIDC 인증 유형은 현재 지원되지 않습니다. |
### TargetGroupBinding
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.targetType` 선택 사항 | `spec.targetType` 필수 | 명시적 대상 유형 사양 |
| `spec.networking.ingress.from` | 지원되지 않음 | 보안 그룹 없이 더 이상 NLB를 지원하지 않음 |
사용자 지정 TargetGroupBinding 기능을 사용하려면 대상 그룹에 클러스터 이름을 포함하는 eks:eks-cluster-name 태그를 지정하여 컨트롤러에 필요한 IAM 권한을 부여해야 합니다. TargetGroupBinding 리소스 또는 클러스터가 삭제되면 컨트롤러가 대상 그룹을 삭제합니다.
# 서비스 주석을 사용하여 Network Load Balancer 구성
Kubernetes 서비스 주석을 사용하여 Amazon EKS에서 Network Load Balancer(NLB)를 구성하는 방법을 알아봅니다. 이 주제에서는 인터넷 접근성, 상태 확인, SSL/TLS 종료, IP 대상 지정 모드를 포함하여 NLB 동작을 사용자 지정하기 위해 EKS Auto Mode에서 지원하는 주석에 대해 설명합니다.
EKS Auto Mode에서 `LoadBalancer` 유형의 Kubernetes 서비스를 생성하면 EKS는 사용자가 지정한 주석을 기반으로 AWS Network Load Balancer를 자동으로 프로비저닝하고 구성합니다. 이 선언적 접근 방식을 사용하면 Kubernetes 매니페스트를 통해 직접 로드 밸런서 구성을 관리하여 코드형 인프라 관행을 유지할 수 있습니다.
EKS Auto Mode는 기본적으로 LoadBalancer 유형의 모든 서비스에 대해 Network Load Balancer 프로비저닝을 처리합니다. 추가 컨트롤러 설치 또는 구성은 필요하지 않습니다. `loadBalancerClass: eks.amazonaws.com/nlb` 사양은 클러스터 기본값으로 자동 설정되므로 기존 Kubernetes 워크로드와의 호환성을 유지하면서 배포 프로세스를 간소화합니다.
**참고**
EKS 자동 모드에서는 퍼블릭 및 프라이빗 서브넷을 식별하기 위해 서브넷 태그가 필요합니다.
`eksctl`로 클러스터를 생성한 경우 이미 이러한 태그가 있는 것입니다.
[EKS 자동 모드의 태그 서브넷](tag-subnets-auto.md) 방법에 대해 알아봅니다.
## 샘플 서비스
Kubernetes `Service` 리소스에 대한 자세한 내용은 [the Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/service/)를 참조하세요.
아래의 샘플 `Service` 리소스를 검토합니다.
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 일반적으로 사용되는 주석
다음 표에는 EKS Auto Mode에서 지원하는 일반적으로 사용되는 주석이 나열되어 있습니다. EKS Auto Mode가 일부 주석을 지원하지 않을 수 있습니다.
**작은 정보**
다음 주석은 모두 `service.beta.kubernetes.io/` 접두사로 지정해야 합니다.
| 필드 | 설명 | 예제 |
| --- | --- | --- |
| `aws-load-balancer-type` | 로드 밸런서 유형을 지정합니다. 새 배포에 `external`을 사용합니다. | `external` |
| `aws-load-balancer-nlb-target-type` | 트래픽을 노드 인스턴스로 라우팅할지 아니면 포드 IP로 직접 라우팅할지 지정합니다. 표준 배포에 `instance` 또는 직접 포드 라우팅에 `ip`를 사용합니다. | `instance` |
| `aws-load-balancer-scheme` | 로드 밸런서가 내부인지 인터넷 연결인지를 제어합니다. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | 대상 그룹에 대한 상태 확인 프로토콜입니다. 일반적인 옵션은 `TCP`(기본값) 또는 `HTTP`입니다. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | HTTP/HTTPS 프로토콜을 사용할 때 상태 확인을 위한 HTTP 경로입니다. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | 상태 확인에 사용되는 포트입니다. 특정 포트 번호 또는 `traffic-port`일 수 있습니다. | `traffic-port` |
| `aws-load-balancer-subnets` | 로드 밸런서를 생성할 서브넷을 지정합니다. 서브넷 ID 또는 이름일 수 있습니다. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | HTTPS/TLS용 AWS Certificate Manager의 SSL 인증서 ARN입니다. | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | SSL/TLS를 사용해야 하는 포트를 지정합니다. | `443, 8443` |
| `load-balancer-source-ranges` | 로드 밸런서에 액세스할 수 있는 CIDR 범위입니다. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | 로드 밸런서 및 관련 리소스에 적용할 추가 AWS 태그입니다. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | 로드 밸런서가 IPv4 또는 듀얼 스택(IPv4 \$1 IPv6)을 사용할지 여부를 지정합니다. | `ipv4` 또는 `dualstack` |
## 고려 사항
+ Kubernetes에서 AWS 로드 밸런서 리소스로 태그 전파를 활성화하려면 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EKS Auto Mode 또는 자체 관리형 AWS 로드 밸런서 컨트롤러와 리소스를 연결하는 방법에 대한 자세한 내용은 [마이그레이션 참조](migrate-auto.md#migration-reference) 섹션을 참조하세요.
+ 로드 밸런서 관련 문제 해결에 대한 자세한 내용은 [EKS Auto Mode 문제 해결](auto-troubleshoot.md) 섹션을 참조하세요.
+ EKS Auto Mode의 로드 밸런싱 기능 사용에 대한 자세한 고려 사항은 [로드 밸런싱](auto-networking.md#auto-lb-consider) 섹션을 참조하세요.
로드 밸런싱을 위해 EKS Auto Mode로 마이그레이션할 때 서비스 주석 및 리소스 구성을 여러 번 변경해야 합니다. 다음 표에는 지원되지 않는 옵션과 권장 대안을 포함하여 이전 구현과 새 구현 간의 주요 차이점이 요약되어 있습니다.
### 서비스 주석
| 이전 | New | 설명 |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | 지원되지 않음 | 서비스에서 `spec.loadBalancerSourceRanges` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-type` | 지원되지 않음 | 서비스에서 `spec.loadBalancerClass` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | 지원되지 않음 | `service.beta.kubernetes.io/aws-load-balancer-scheme` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` 사용 |
| 다양한 로드 밸런서 속성 | 지원되지 않음 | `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
더 이상 사용되지 않는 로드 밸런서 속성 주석에서 마이그레이션하려면 이러한 설정을 `service.beta.kubernetes.io/aws-load-balancer-attributes` 주석으로 통합합니다. 이 주석은 다양한 로드 밸런서 속성에 대해 쉼표로 구분된 키-값 페어 목록을 허용합니다. 예를 들어 액세스 로깅, 교차 영역 로드 밸런싱을 지정하려면 다음 형식을 사용합니다.
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
이 통합 형식은 필요한 개별 주석 수를 줄이면서 로드 밸런서 속성을 구성하는 더욱 일관되고 유연한 방법을 제공합니다. 기존 서비스 구성을 검토하고 이 통합 형식을 사용하도록 업데이트합니다.
### TargetGroupBinding
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.targetType` 선택 사항 | `spec.targetType` 필수 | 명시적 대상 유형 사양 |
| `spec.networking.ingress.from` | 지원되지 않음 | 보안 그룹 없이 더 이상 NLB를 지원하지 않음 |
참고: 사용자 지정 TargetGroupBinding 기능을 사용하려면 대상 그룹에 클러스터 이름을 포함하는 `eks:eks-cluster-name` 태그를 지정하여 컨트롤러에 필요한 IAM 권한을 부여해야 합니다. TargetGroupBinding 리소스 또는 클러스터가 삭제되면 컨트롤러가 대상 그룹을 삭제합니다.
# 스토리지 클래스 생성
Amazon EKS 자동 모드의 `StorageClass`는 애플리케이션이 영구 스토리지를 요청할 때 Amazon EBS 볼륨이 자동으로 프로비저닝되는 방식을 정의합니다. 이 페이지에서는 Amazon EKS 자동 모드와 함께 작동하여 EBS 볼륨을 프로비저닝하는 `StorageClass`를 생성하고 구성하는 방법을 설명합니다.
`StorageClass`를 구성하여 볼륨 유형, 암호화, IOPS 및 기타 스토리지 파라미터를 포함하여 EBS 볼륨에 대한 기본 설정을 지정할 수 있습니다. 암호화 관리에 AWS KMS 키를 사용하도록 `StorageClass`를 구성할 수도 있습니다.
EKS 자동 모드는 `StorageClass`를 생성하지 않습니다. EKS 자동 모드의 스토리지 기능을 사용하려면 `ebs.csi.eks.amazonaws.com`을 참조하는 `StorageClass`를 생성해야 합니다.
첫째, `storage-class.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
둘째, 클러스터에 스토리지 클래스를 적용합니다.
```
kubectl apply -f storage-class.yaml
```
**핵심 구성 요소:**
+ `provisioner: ebs.csi.eks.amazonaws.com`-EKS Auto Mode를 사용합니다.
+ `allowedTopologies` - `eks.amazonaws.com/compute-type:auto`에서 일치하도록 `matchLabelExpressions`를 지정하면 포드가 자동 모드를 사용하여 볼륨을 자동으로 프로비저닝해야 하는 경우 포드가 자동 모드가 아닌 노드에서 예약되지 않습니다.
+ `volumeBindingMode: WaitForFirstConsumer`-포드에 필요할 때까지 볼륨 생성을 지연합니다.
+ `type: gp3`-EBS 볼륨 유형을 지정합니다.
+ `encrypted: "true"` - EBS는 `StorageClass`를 사용하여 생성된 모든 볼륨을 암호화합니다. EBS는 기본 `aws/ebs` 키 별칭을 사용합니다. 자세한 내용은 Amazon EBS 사용 설명서의 [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)을 참조하세요. 이 값은 선택 사항이지만 권장됩니다.
+ `storageclass.kubernetes.io/is-default-class: "true"`-영구 볼륨 클레임에서 다른 볼륨 클래스를 지정하지 않는 한 Kubernetes는 기본적으로 이 스토리지 클래스를 사용합니다. 이 값은 선택 사항입니다. 다른 스토리지 컨트롤러에서 마이그레이션하는 경우 이 값을 설정할 때 주의하세요.
## 자체 관리형 KMS 키를 사용하여 EBS 볼륨 암호화
자체 관리형 KMS 키를 사용하여 EKS Auto Mode로 자동화된 EBS 볼륨을 암호화하려면 다음을 수행해야 합니다.
1. 자체 관리형 KMS 키를 생성합니다.
+ 자세한 내용은 KMS 사용 설명서의 [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) 또는 [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)을 참조하세요.
1. KMS 키에 대한 액세스를 허용하는 새 정책을 생성합니다.
+ 아래의 샘플 IAM 정책을 사용하여 정책을 생성합니다. 새 자체 관리형 KMS 키의 ARN을 삽입합니다. 자세한 내용은 AWS IAM 사용 설명서의 [Creating roles and attaching policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)을 참조하세요.
1. 정책을 EKS 클러스터 역할에 연결합니다.
+ AWS 콘솔을 사용하여 EKS 클러스터 역할의 ARN을 찾습니다. 역할 정보는 **개요** 섹션에 표시됩니다. 자세한 내용은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) 섹션을 참조하세요.
1. `parameters.kmsKeyId` 필드에서 KMS 키 ID를 참조하도록 `StorageClass`를 업데이트합니다.
### 샘플 자체 관리형 KMS IAM 정책
아래 정책에서 다음 값을 업데이트합니다.
+ `` - AWS 계정 ID(예: `111122223333`)
+ `` - 클러스터의 AWS 리전(예: `us-west-2`)
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### 샘플 자체 관리형 KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` 파라미터 참조
Kubernetes `StorageClass` 리소스에 대한 일반적인 내용은 Kubernetes 설명서의 [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)를 참조하세요.
`StorageClass` 리소스의 `parameters` 섹션은 AWS와 관련이 있습니다. 다음 표를 이용하여 사용 가능한 옵션을 검토하세요.
| Parameters | 값 | 기본값 | 설명 |
| --- | --- | --- | --- |
| "csi.storage.k8s.io/fstype" | xfs, ext2, ext3, ext4 | ext4 | 볼륨 생성 중에 형식을 지정할 파일 시스템 유형입니다. 이 파라미터는 대소문자를 구분합니다. |
| "type" | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | EBS 볼륨 유형. |
| "iopsPerGB" | | | GiB당 초당 I/O 작업. IO1, IO2, GP3 볼륨에 대해 지정할 수 있습니다. |
| "allowAutoIOPSPerGBIncrease" | true, false | false | `"true"`인 경우, CSI 드라이버는 `iopsPerGB * `가 너무 낮아 AWS에서 지원하는 IOPS 범위에 맞지 않는 경우 볼륨에 대해 IOPS를 늘립니다. 이렇게 하면 사용자가 너무 작은 PVC 용량 또는 `iopsPerGB` 값을 지정하는 경우에도 동적 프로비저닝이 항상 성공할 수 있습니다. 반면, 이러한 볼륨은 `iopsPerGB`에서 요청된 것보다 IOPS가 높기 때문에 추가 비용이 발생할 수 있습니다. |
| "iops" | | | 초당 I/O 작업. IO1, IO2, GP3 볼륨에 대해 지정할 수 있습니다. |
| "throughput" | | 125 | 처리량 단위는 MiB/s입니다. gp3 볼륨 유형이 지정된 경우에만 유효합니다. |
| "encrypted" | true, false | false | 볼륨이 암호화되어야 하는지 여부입니다. 유효한 값은 "true" 또는 "false"입니다. |
| "blockExpress" | true, false | false | io2 Block Express 볼륨 생성을 활성화합니다. |
| "kmsKeyId" | | | 볼륨을 암호화할 때 사용할 키의 전체 ARN입니다. 지정하지 않으면 AWS는 볼륨이 있는 리전에 기본 KMS 키를 사용합니다. 변경하지 않으면 `/aws/ebs`라는 자동 생성된 키가 됩니다. |
| "blockSize" | | | 기본 파일 시스템을 포맷할 때 사용할 블록 크기입니다. Linux 노드와 fstype `ext2`, `ext3`, `ext4` 또는 `xfs`에서만 지원됩니다. |
| "inodeSize" | | | 기본 파일 시스템을 포맷할 때 사용할 inode 크기입니다. Linux 노드와 fstype `ext2`, `ext3`, `ext4` 또는 `xfs`에서만 지원됩니다. |
| "bytesPerInode" | | | 기본 파일 시스템을 포맷할 때 사용할 `bytes-per-inode`입니다. linux 노드와 fstype `ext2`, `ext3`, `ext4`에서만 지원됩니다. |
| "numberOfInodes" | | | 기본 파일 시스템을 포맷할 때 사용할 `number-of-inodes`입니다. linux 노드와 fstype `ext2`, `ext3`, `ext4`에서만 지원됩니다. |
| "ext4BigAlloc" | true, false | false | `bigalloc` 형식 지정 옵션을 활성화하여 클러스터링된 블록 할당을 사용하도록 `ext4` 파일 시스템을 변경합니다. 경고: `bigalloc`가 노드의 Linux 커널에서 완전히 지원되지 않을 수 있습니다. |
| "ext4ClusterSize" | | | `bigalloc` 기능이 활성화된 경우 `ext4` 파일 시스템을 포맷할 때 사용할 클러스터 크기입니다. 참고: `ext4BigAlloc` 파라미터를 true로 설정해야 합니다. |
자세한 내용은 GitHub의 [AWS EFS CSI 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)를 참조하세요.
## 고려 사항
**참고**
EKS Auto Mode 노드의 EKS Auto Mode StorageClasses에 따라 워크로드만 배포할 수 있습니다. 노드 유형이 혼합된 클러스터가 있는 경우 EKS Auto Mode 노드에서만 실행되도록 워크로드를 구성해야 합니다. 자세한 내용은 [EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md) 섹션을 참조하세요.
EKS Auto Mode의 블록 스토리지 기능은 EBS CSI 드라이버와 다릅니다.
+ 정적 프로비저닝
+ EKS Auto Mode에서 외부에서 생성된 EBS 볼륨을 사용하려면 키 `eks:eks-cluster-name`와 클러스터 이름의 값이 포함된 AWS 태그를 수동으로 추가해야 합니다.
+ 노드 시작 테인트
+ 노드 시작 테인트 기능을 사용하여 스토리지 기능 준비 전에 포드 예약을 방지할 수 없습니다.
+ 동적으로 프로비저닝된 볼륨의 사용자 지정 태그
+ 추가 태그 CLI 플래그를 사용하여 동적으로 프로비저닝된 EBS 볼륨에 사용자 지정 태그를 구성할 수 없습니다.
+ `StorageClass` 태깅을 사용하여 사용자 지정 태그를 추가할 수 있습니다. EKS Auto Mode는 연결된 AWS 리소스에 태그를 추가합니다. 사용자 지정 태그에 대한 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EBS 세부 성능 지표
+ EBS 세부 성능에 대한 Prometheus 지표에 액세스할 수 없습니다.
## CSI 스냅샷 컨트롤러 추가 기능 설치
EKS Auto Mode는 CSI 스냅샷 컨트롤러 Amazon EKS 추가 기능과 호환됩니다.
AWS에서는 이 추가 기능을 내장 `system` 노드 풀에서 실행하도록 구성할 것을 제안합니다.
자세한 내용은 다음을 참조하세요.
+ [전용 인스턴스에서 핵심 추가 기능 실행](critical-workload.md)
+ [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md)
+ [CSI 볼륨의 스냅샷 기능 활성화](csi-snapshot-controller.md)
### 시스템 노드 풀에 스냅샷 컨트롤러를 설치하려면
1. AWS 콘솔에서 EKS 클러스터 열기
1. **추가 기능** 탭에서 **추가 기능 더 가져오기**를 선택합니다.
1. **CSI 스냅샷 컨트롤러**와 **다음**을 차례로 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 **선택적 구성 설정**을 선택하여 **추가 기능 구성 스키마**를 확인합니다.
1. 스냅샷 컨트롤러를 `system` 노드 풀과 연결하려면 다음 yaml을 삽입합니다. 스냅샷 컨트롤러에는 `CriticalAddonsOnly` 테인트에 대한 허용치가 포함됩니다.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. **다음**을 선택합니다.
1. 추가 기능 구성을 검토한 다음 **생성**을 선택합니다.
# EKS Auto Mode 비활성화
기존 EKS 클러스터에서 EKS Auto Mode를 비활성화할 수 있습니다. 이는 파괴적인 작업입니다.
+ EKS는 EKS Auto Mode에서 운영하는 모든 EC2 인스턴스를 종료합니다.
+ EKS는 EKS Auto Mode에서 운영하는 모든 로드 밸런서를 삭제합니다.
+ EKS는 EKS Auto Mode에서 프로비저닝한 EBS 볼륨을 삭제하지 **않습니다**.
EKS 자율 모드는 생성한 리소스를 완전히 관리하도록 설계되었습니다. 수동 개입으로 인해 EKS 자율 모드가 비활성화되면 해당 리소스를 완전히 정리하지 못할 수 있습니다. 예를 들어 외부 보안 그룹 규칙에서 관리형 보안 그룹을 참조하고 클러스터에 대해 EKS 자율 모드를 비활성화하기 전에 해당 참조를 제거하는 것을 잊어버린 경우 관리형 보안 그룹이 유출됩니다(삭제되지 않음). 아래 단계에서는 누출된 보안 그룹을 제거하는 경우 해당 방법을 설명합니다.
## EKS Auto Mode 비활성화(AWS 콘솔)
1. AWS Management Console에서 클러스터 개요 페이지를 엽니다.
1. **EKS Auto Mode**에서 **관리**를 선택합니다.
1. **EKS Auto Mode**를 `off`로 전환합니다.
이 프로세스가 끝나는 시점에서 관리형 보안 그룹이 삭제되지 않은 경우 [보안 그룹 삭제](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)의 설명을 사용하여 수동으로 삭제할 수 있습니다.
## EKS Auto Mode 비활성화(AWS CLI)
다음 명령을 사용하여 기존 클러스터에서 EKS Auto Mode를 비활성화합니다.
`aws` CLI가 설치되어 있으며 EKS 클러스터를 관리할 수 있는 충분한 권한으로 로그인해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
**참고**
동일한 요청에서 컴퓨팅, 블록 스토리지, 로드 밸런싱 기능을 모두 활성화 또는 비활성화해야 합니다.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
다음과 같이 EKS 자율 모드를 비활성화한 후 누출된 EKS 자율 모드 보안 그룹을 삭제하지 못했는지 여부를 확인할 수 있습니다.
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
보안 그룹을 삭제하는 방법:
```
aws ec2 delete-security-group --group-name=
```
# EKS Auto Mode 클러스터의 Kubernetes 버전 업데이트
이 주제에서는 Auto Mode 클러스터의 Kubernetes 버전을 업데이트하는 방법을 설명합니다. Auto Mode는 노드 교체와 컨트롤 플레인 업데이트의 조정을 처리하는 동시에 포드 중단 예산을 통해 워크로드 가용성을 유지하여 버전 업데이트 프로세스를 간소화합니다.
Auto Mode 클러스터를 업그레이드할 때 기존에 수동 업데이트가 필요했던 많은 구성 요소가 이제 서비스의 일부로 관리됩니다. 업그레이드 프로세스의 자동화된 측면과 사용자의 책임을 이해하면 클러스터의 원활한 버전 전환을 보장하는 데 도움이 됩니다.
## EKS Auto Mode를 사용한 업데이트 알아보기
컨트롤 플레인 업그레이드가 시작된 후에 EKS 자동 모드가 클러스터의 노드를 업그레이드합니다. 노드가 만료되면 EKS 자동 모드가 해당 노드를 새 노드로 바꿉니다. 새 노드에는 해당하는 새 Kubernetes 버전이 있습니다. EKS Auto Mode는 노드 업그레이드 시 포드 중단 예산을 관찰합니다.
또한 더 이상 다음과 같은 구성 요소를 업데이트할 필요가 없습니다.
+ Amazon VPC CNI
+ AWS 로드 밸런서 컨트롤러
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI 드라이버
EKS Auto Mode는 이러한 구성 요소를 서비스 기능으로 대체합니다.
여전히 다음을 업데이트할 책임이 있습니다.
+ 클러스터에 배포된 앱 및 워크로드
+ 자체 관리형 추가 기능 및 컨트롤러
+ Amazon EKS 추가 기능
+ [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 방법 알아보기
[클러스터 업그레이드 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) 알아보기
## 클러스터 업데이트 시작
클러스터 업데이트를 시작하려면 [기존 클러스터를 새 Kubernetes 버전으로 업데이트](update-cluster.md) 섹션을 참조하세요.
# 내장 NodePools 활성화 또는 비활성화
EKS Auto Mode에는 내장 NodePools 2개가 있습니다. AWS 콘솔, CLI 또는 API를 사용하여 이러한 NodePools를 활성화 또는 비활성화할 수 있습니다.
## 내장 NodePool 참조
+ `system`
+ 이 NodePool에는 `CriticalAddonsOnly` 테인트가 있습니다. CoreDNS와 같은 많은 EKS 추가 기능은 이 테인트를 허용합니다. 이 시스템 노드 풀을 사용하여 클러스터의 핵심 애플리케이션을 분리합니다.
+ `amd64` 및 `arm64` 아키텍처를 모두 지원합니다.
+ `general-purpose`
+ 이 NodePool은 클러스터에서 범용 워크로드를 위한 노드 시작을 지원합니다.
+ `amd64` 아키텍처만 사용합니다.
두 내장 NodePools의 특성은 다음과 같습니다.
+ 기본 EKS NodeClass 사용
+ 온디맨드 EC2 용량만 사용
+ C, M 및 R EC2 인스턴스 패밀리 사용
+ 5세대 이상의 EC2 인스턴스 필요
**참고**
EKS가 ‘기본’ NodeClass를 프로비저닝하려면 하나 이상의 내장 NodePool을 활성화해야 합니다. 모든 내장 NodePool를 비활성화하는 경우 사용자 지정 NodeClass를 생성하고 이를 사용하도록 NodePool을 구성해야 합니다. NodeClasses에 대한 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 절차
### 사전 조건
+ 장치에 최신 버전의 AWS Command Line Interface(AWS CLI)가 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)을 참조하세요.
+ 충분한 IAM 권한을 사용하여 CLI에 로그인하고 IAM 정책, IAM 역할, EKS 클러스터를 포함한 AWS 리소스를 생성합니다.
### AWS CLI로 활성화
다음 명령을 사용하여 두 내장 NodePools를 모두 활성화합니다.
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
명령을 수정하여 NodePools를 선택적으로 활성화할 수 있습니다.
### AWS CLI로 비활성화
다음 명령을 사용하여 두 내장 NodePools를 모두 비활성화합니다.
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# EKS Auto Mode 노드에 워크로드 배포 여부 제어
EKS Auto Mode를 사용하여 EKS 클러스터에서 워크로드를 실행하는 경우 특정 워크로드가 EKS Auto Mode 노드에서 실행되는지 또는 기타 컴퓨팅 유형에서 실행되는지 여부를 제어해야 할 수 있습니다. 이 주제에서는 노드 선택기 및 선호도 규칙을 사용하여 워크로드가 의도한 컴퓨팅 인프라에 예약되게 하는 방법을 설명합니다.
이 주제의 예제에서는 `eks.amazonaws.com/compute-type` 레이블을 사용하여 EKS Auto Mode 노드에서 워크로드 배포를 요구하거나 방지하는 방법을 보여줍니다. 이는 EKS Auto Mode와 자체 관리형 Karpenter 프로비저너 또는 EKS 관리형 노드 그룹과 같은 기타 컴퓨팅 유형을 모두 실행하는 혼합 모드 클러스터에서 특히 유용합니다.
EKS Auto Mode 노드가 `eks.amazonaws.com/compute-type` 레이블 값을 `auto`로 설정했습니다. 이 레이블을 사용하여 EKS Auto Mode에서 관리하는 노드에 워크로드가 배포되는지 여부를 제어할 수 있습니다.
## 워크로드가 EKS Auto Mode 노드에 배포되어야 함
**참고**
이 `nodeSelector` 값은 EKS Auto Mode에 필요하지 않습니다. 이 `nodeSelector` 값은 EKS Auto Mode에서 관리하지 않는 노드 유형인 혼합 모드에서 클러스터를 실행하는 경우에만 관련이 있습니다. 예를 들어 EKS 관리형 노드 그룹을 사용하여 클러스터에 정적 컴퓨팅 용량을 배포하고 EKS Auto Mode에서 동적 컴퓨팅 용량을 관리할 수 있습니다.
이 `nodeSelector`를 배포 또는 기타 워크로드에 추가하여 Kubernetes가 EKS Auto Mode 노드에서 예약하도록 요구할 수 있습니다.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## 워크로드가 EKS Auto Mode 노드에 배포되지 않아야 함
이 `nodeAffinity`를 배포 또는 기타 워크로드에 추가하여 Kubernetes가 EKS Auto Mode 노드에서 예약하지 **않도록** 요구할 수 있습니다.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# 전용 인스턴스에서 핵심 추가 기능 실행
이 주제에서는 EKS Auto Mode가 `system` 노드 풀에 워크로드를 예약하도록 `CriticalAddonsOnly` 허용 오차가 있는 워크로드를 배포하는 방법을 알아봅니다.
EKS Auto Mode의 내장 `system` 노드 풀은 전용 인스턴스에서 핵심 추가 기능을 실행하도록 설계되었습니다. 이러한 분리를 통해 필수 구성 요소에 전용 리소스가 있고 일반 워크로드에서 격리되어 전반적인 클러스터 안정성과 성능이 향상됩니다.
이 가이드는 `CriticalAddonsOnly` 허용 및 적절한 노드 선택기를 활용하여 `system` 노드 풀에 추가 기능을 배포하는 방법을 보여줍니다. 이러한 단계를 따르면 EKS Auto Mode의 특수 노드 풀 구조에서 제공하는 격리 및 리소스 할당 이점을 활용하여 핵심 애플리케이션이 전용 `system` 노드로 예약되게 할 수 있습니다.
EKS Auto Mode에는 `general-purpose` 및 `system`이라는 기본 제공 노드 풀 2개가 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하십시오.
`system` 노드 풀의 목적은 핵심 추가 기능을 서로 다른 노드로 분리하는 것입니다. `system` 노드 풀에서 프로비저닝한 노드에는 `CriticalAddonsOnly` Kubernetes 테인트가 있습니다. Kubernetes는 해당 허용이 있는 경우에만 이러한 노드에 포드를 예약합니다. 자세한 내용은 Kubernetes 설명서의 [테인트와 허용 오차](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)를 참조하세요.
## 사전 조건
+ EKS Auto Mode 클러스터는 내장 `system` 노드 풀이 활성화되어 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하세요.
+ `kubectl`을 설치하고 구성했습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
## 절차
아래 예제 yaml을 검토합니다. 다음 구성에 유의하세요.
+ `nodeSelector`-워크로드를 내장 `system` 노드 풀과 연결합니다. 이 노드 풀은 AWS API로 활성화해야 합니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하십시오.
+ `tolerations`-이 허용 오차는 `system` 노드 풀의 노드에 있는 `CriticalAddonsOnly` 테인트를 극복합니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
`system` 노드 풀에서 실행할 워크로드를 업데이트하려면 다음을 수행해야 합니다.
1. 기존 워크로드를 업데이트하여 위에 설명된 다음 구성을 추가합니다.
+ `nodeSelector`
+ `tolerations`
1. `kubectl apply`를 사용하여 업데이트된 워크로드를 클러스터에 배포합니다.
워크로드를 업데이트하면 전용 노드에서 실행됩니다.
# EKS Auto Mode에서 네트워크 정책 사용
## 개요
고객이 EKS를 사용하여 애플리케이션 환경을 조정할 때 네트워크 트래픽 격리는 클러스터 내부 및 외부의 리소스에 대한 권한 없는 액세스를 방지하는 기본적인 방식으로 더 많이 사용되고 있습니다. 클러스터에서 여러 관련 없는 워크로드가 나란히 실행되는 다중 테넌트 환경에서 특히 중요합니다. Kubernetes 네트워크 정책을 사용하면 Kubernetes 워크로드의 네트워크 보안 태세 및 클러스터 외부 엔드포인트와의 통합을 강화할 수 있습니다. EKS Auto Mode는 다양한 유형의 네트워크 정책을 지원합니다.
### 계층 3 및 4 격리
표준 Kubernetes 네트워크 정책은 OSI 네트워크 모델의 계층 3 및 4에서 작동하며, 이를 통해 Amazon EKS 클러스터 내 IP 주소 또는 포트 수준에서 트래픽 흐름을 제어할 수 있습니다.
#### 사용 사례
+ 워크로드 간에 네트워크 트래픽을 분할하여 관련 애플리케이션만 서로 통신할 수 있도록 보장합니다.
+ 정책을 통해 네임스페이스 수준에서 테넌트를 격리하여 네트워크 분리를 적용합니다.
### DNS 기반 적용
고객은 일반적으로 더 광범위한 분산 환경의 일부인 EKS에 워크로드를 배포합니다. 이 중 일부는 클러스터 외부의 시스템 및 서비스와 통신해야 합니다(노스바운드 트래픽). 이러한 시스템 및 서비스는 AWS 클라우드에 있거나 AWS 외부에 있을 수 있습니다. 도메인 이름 시스템(DNS) 기반 정책을 사용하면 포드에서 클러스터 외부 리소스 또는 엔드포인트로의 권한 없는 액세스를 방지하기 위해 보다 안정적이고 예측 가능한 접근 방식을 채택하여 보안 태세를 강화할 수 있습니다. 이 메커니즘을 사용하면 특정 IP 주소를 수동으로 추적하고 허용 목록에 추가하지 않아도 됩니다. DNS 기반 접근 방식으로 리소스를 보호하면 업스트림 서버 및 호스트에 대한 변경 중 보안 태세를 완화하거나 네트워크 정책을 수정하지 않고도 외부 인프라를 업데이트할 수 있는 유연성도 향상됩니다. 정규화된 도메인 이름(FQDN) 또는 DNS 도메인 이름과 일치하는 패턴을 사용하여 외부 엔드포인트로 송신 트래픽을 필터링할 수 있습니다. 이를 통해 특정 클러스터 외부 엔드포인트와 연결된 여러 하위 도메인으로 액세스를 확장할 수 있는 유연성이 추가됩니다.
#### 사용 사례
+ Kubernetes 환경에서 클러스터 외부 엔드포인트로의 액세스를 필터링하기 위한 DNS 기반 접근 방식을 표준화합니다.
+ 다중 테넌트 환경에서 AWS 서비스에 대한 보안 액세스.
+ 하이브리드 클라우드 환경의 경우 포드에서 온프레미스 워크로드로의 네트워크 액세스를 관리합니다.
### 관리자 또는 클러스터 범위의 규칙
다중 테넌트 시나리오와 같은 일부 경우 고객은 전체 클러스터에 적용되는 네트워크 보안 표준을 적용해야 할 수 있습니다. 각 네임스페이스에 대해 고유한 정책을 반복적으로 정의하고 유지하는 대신 단일 정책을 사용하여 네임스페이스에 관계없이 클러스터의 여러 워크로드에 대한 네트워크 액세스 제어를 중앙에서 관리할 수 있습니다. 이러한 유형의 정책을 사용하면 계층 3 및 계층 4에서와 DNS 규칙을 사용할 때 적용되는 네트워크 필터링 규칙의 적용 범위를 확장할 수 있습니다.
#### 사용 사례
+ EKS 클러스터의 모든 워크로드와 워크로드의 하위 집합에 대한 네트워크 액세스 제어를 중앙에서 관리합니다.
+ 전체 클러스터에서 기본 네트워크 보안 태세를 정의합니다.
+ 보다 운영 효율적인 방식으로 조직 보안 표준을 클러스터 범위로 확장합니다.
## 시작하기
### 사전 조건
+ EKS Auto Mode가 활성화된 Amazon EKS 클러스터
+ 클러스터에 연결하도록 구성된 kubectl
### 1단계: 네트워크 정책 컨트롤러 활성화
EKS Auto Mode로 네트워크 정책을 사용하려면 먼저 클러스터에 ConfigMap을 적용하여 네트워크 정책 컨트롤러를 활성화해야 합니다.
1. 다음 콘텐츠가 포함된 `enable-network-policy.yaml`이라는 파일을 생성합니다.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. 클러스터에 ConfigMap 적용:
```
kubectl apply -f enable-network-policy.yaml
```
### 2단계: 네트워크 정책 생성 및 테스트
이제 Kubernetes 네트워크 정책을 지원하도록 EKS Auto Mode 클러스터가 구성되었습니다. [Amazon EKS 네트워크 정책에 대한 Stars 데모](network-policy-stars-demo.md)를 사용하여 테스트할 수 있습니다.
### 3단계: 노드 클래스에서 네트워크 정책 에이전트 구성 조정(선택 사항)
선택적으로 새 노드 클래스를 생성하여 노드에서 네트워크 정책 에이전트의 기본 동작을 변경하거나 네트워크 정책 이벤트 로깅을 활성화할 수 있습니다. 이렇게 하려면 다음 단계를 따릅니다.
1. 다음 내용을 사용하여 노드 클래스 YAML 파일(예: `nodeclass-network-policy.yaml`)을 생성하거나 편집합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. 클러스터에 노드 클래스 구성을 적용합니다.
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. 노드 클래스가 생성되었는지 확인합니다.
```
kubectl get nodeclass network-policy-config
```
1. 이 노드 클래스를 사용하도록 노드 풀을 업데이트합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 어떻게 작동하나요?
### DNS 기반 네트워크 정책
![\[EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/apply-dns-policy-2.png)
1. 플랫폼 팀은 DNS 기반 정책을 EKS 클러스터에 적용합니다.
1. 네트워크 정책 컨트롤러는 클러스터 내에서 정책 생성을 모니터링한 다음, 정책 엔드포인트를 조정할 책임이 있습니다. 이 사용 사례에서 네트워크 정책 컨트롤러는 생성된 정책의 허용 목록에 있는 도메인을 기반으로 DNS 요청을 필터링하도록 노드 에이전트에 지시합니다. 도메인 이름은 FQDN 또는 Kubernetes 리소스 구성에 정의된 패턴과 일치하는 도메인 이름을 사용하여 허용 목록에 추가됩니다.
1. 워크로드 A는 클러스터 외부 엔드포인트의 IP를 확인하려고 시도합니다. DNS 요청은 먼저 네트워크 정책을 통해 적용된 허용 목록을 기반으로 이러한 요청을 필터링하는 프록시를 거칩니다.
1. DNS 요청이 DNS 필터 허용 목록을 거치면 CoreDNS로 프록시됩니다.
1. 그러면 CoreDNS는 외부 DNS 해석기(Amazon Route 53 Resolver)에 요청을 보내 도메인 이름 뒤의 IP 주소 목록을 가져옵니다.
1. TTL이 있는 확인된 IP는 DNS 요청에 대한 응답으로 반환됩니다. 그런 다음 IP 계층 적용을 위한 다음 단계에서 사용되는 eBPF 맵에 이러한 IP가 기록됩니다.
1. 그런 다음 포드 veth 인터페이스에 연결된 eBPF 프로브는 적용된 규칙에 따라 워크로드 A에서 클러스터 외부 엔드포인트로의 송신 트래픽을 필터링합니다. 이를 통해 포드는 허용 목록에 추가된 도메인의 IP로만 클러스터 외부 트래픽을 전송할 수 있습니다. 이러한 IP의 유효성은 외부 DNS 해석기(Amazon Route 53 Resolver)에서 검색된 TTL에 기반합니다.
#### 애플리케이션 네트워크 정책 사용
`ApplicationNetworkPolicy`는 단일 사용자 지정 리소스 정의(CRD)를 사용하여 표준 Kubernetes 네트워크 정책의 기능을 네임스페이스 수준에서 DNS 기반 필터링과 결합합니다. 따라서 다음 경우에 `ApplicationNetworkPolicy`를 사용할 수 있습니다.
1. IP 블록 및 포트 번호를 사용하여 네트워크 스택의 계층 3 및 4에서 제한 사항 정의.
1. 네트워크 스택의 계층 7에서 작동하는 규칙을 정의하고 FQDN을 기반으로 트래픽을 필터링할 수 있습니다.
**중요**
`ApplicationNetworkPolicy`를 사용하여 정의된 DNS 기반 규칙은 EKS Auto Mode에서 시작한 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. `ApplicationNetworkPolicy`는 송신 규칙에 대한 추가 FQDN 필터와 함께 표준 Kubernetes `NetworkPolicy`의 모든 필드를 지원합니다.
**주의**
동일한 네임스페이스 내에서 `ApplicationNetworkPolicy` 및 `NetworkPolicy`에 동일한 이름을 사용하지 마세요. 이름이 충돌하면 결과 `PolicyEndpoints` 객체에 두 정책이 올바르게 반영되지 않을 수 있습니다. 두 리소스 모두 오류 없이 수락되므로 이 문제를 진단하기가 어렵습니다.
이름 충돌을 해결하려면 네임스페이스 내에서 고유하도록 `ApplicationNetworkPolicy` 또는 `NetworkPolicy`로 이름을 바꾼 후 해당 `PolicyEndpoints` 객체가 올바르게 업데이트되었는지 확인합니다.
#### 예제
EKS Auto Mode 클러스터에는 DNS 이름을 사용하는 로드 밸런서 뒤에 있는 온프레미스 애플리케이션과 통신해야 하는 워크로드가 있습니다. 다음 네트워크 정책을 사용하여 이를 달성할 수 있습니다.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Kubernetes 네트워크 수준에서는 이를 통해 `role: backend` 레이블이 지정된 'galaxy' 네임스페이스의 모든 포드에서 TCP 포트 8080의 도메인 이름 **myapp.mydomain.com**으로의 송신을 허용합니다. 또한 VPC에서 회사 데이터 센터로의 송신 트래픽에 대한 네트워크 연결을 설정해야 합니다.
![\[온프레미스 애플리케이션과 통신하는 EKS Auto의 워크로드에 대한 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 관리자(또는 클러스터) 네트워크 정책
![\[EKS에서 네트워크 정책의 평가 순서에 대한 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/evaluation-order.png)
#### 클러스터 네트워크 정책 사용
`ClusterNetworkPolicy`를 사용하는 경우 관리자 티어 정책이 먼저 평가되며 이는 재정의할 수 없습니다. 관리자 티어 정책이 평가되면 표준 네임스페이스 범위의 정책을 사용하여 적용된 네트워크 분할 규칙을 실행합니다. 이는 `ApplicationNetworkPolicy` 또는 `NetworkPolicy`를 사용하여 수행할 수 있습니다. 마지막으로 클러스터 워크로드에 대한 기본 네트워크 제한 사항을 정의하는 기준 티어 규칙이 적용됩니다. 이러한 기준 티어 규칙은 필요한 경우 네임스페이스 범위의 정책에 의해 재정의 **가능**합니다.
#### 예제
클러스터에 다른 테넌트 워크로드와 격리하려는 애플리케이션이 있습니다. 다른 네임스페이스의 클러스터 트래픽을 명시적으로 차단하여 민감한 워크로드 네임스페이스에 대한 네트워크 액세스를 방지할 수 있습니다.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 고려 사항
### 정책 평가 순서 이해
EKS에서 지원되는 네트워크 정책 기능은 예측 가능한 보안 트래픽 관리를 보장하기 위해 특정 순서로 평가됩니다. 따라서 환경에 대해 효과적인 네트워크 보안 태세를 설계하려면 평가 흐름을 이해하는 것이 중요합니다.
1. **관리자 티어 정책(먼저 평가됨)**: 모든 관리자 티어 ClusterNetworkPolicies는 다른 정책보다 먼저 평가됩니다. 관리자 티어 내에서 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 작업 유형에 따라 다음 상황이 결정됩니다.
+ **거부 작업(가장 높은 우선순위)**: 거부 작업이 있는 관리자 정책이 트래픽과 일치하면 다른 정책에 관계없이 해당 트래픽이 즉시 차단됩니다. 추가 ClusterNetworkPolicy 또는 NetworkPolicy 규칙은 더 이상 처리되지 않습니다. 이를 통해 조직 전체의 보안 제어가 네임스페이스 수준 정책에 의해 재정의되지 않습니다.
+ **허용 작업**: 거부 규칙을 평가한 후 허용 작업이 있는 관리자 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 허용 작업이 일치하면 트래픽이 수락되고 추가 정책 평가가 수행되지 않습니다. 이러한 정책은 레이블 선택기를 기반으로 여러 네임스페이스에 액세스 권한을 부여하여 특정 리소스에 액세스할 수 있는 워크로드를 중앙에서 제어할 수 있습니다.
+ **통과 작업**: 관리자 티어 정책에서 통과 작업은 의사 결정이 하위 티어로 위임합니다. 트래픽이 통과 규칙과 일치하면 평가는 해당 트래픽에 대한 나머지 모든 관리자 티어 규칙을 건너뛰고 NetworkPolicy 티어로 바로 진행합니다. 이를 통해 관리자는 특정 트래픽 패턴에 대한 제어를 애플리케이션 팀에 명시적으로 위임할 수 있습니다. 예를 들어 통과 규칙을 사용하여 외부 액세스에 대한 엄격한 제어를 유지하면서 네임스페이스 내 트래픽 관리를 네임스페이스 관리자에게 위임할 수 있습니다.
1. **네트워크 정책 티어**: 거부 또는 허용과 일치하는 관리자 티어 정책이 없거나 통과 작업이 일치하는 경우 네임스페이스 범위의 ApplicationNetworkPolicy 및 기존의 NetworkPolicy 리소스가 다음에 평가됩니다. 이러한 정책은 개별 네임스페이스 내에서 세분화된 제어를 제공하며 애플리케이션 팀이 관리합니다. 네임스페이스 범위의 정책은 관리자 정책보다 더 제한적일 수 있습니다. 관리자 정책의 거부 결정을 재정의할 수는 없지만 관리자 정책에서 허용하거나 전달하는 트래픽을 추가로 제한할 수 있습니다.
1. **기준 티어 관리자 정책**: 트래픽과 일치하는 관리자 또는 네임스페이스 범위의 정책이 없는 경우 기준 티어 ClusterNetworkPolicies가 평가됩니다. 이는 네임스페이스 범위의 정책으로 재정의할 수 있는 기본 보안 태세를 제공하므로 관리자는 조직 전체의 기본값을 설정하는 동시에 필요에 따라 팀에 사용자 지정할 수 있는 유연성을 제공할 수 있습니다. 기준 정책은 우선순위에 따라(가장 낮은 우선순위 번호 먼저) 평가됩니다.
1. **기본 거부(정책이 일치하지 않는 경우)**:이러한 기본적으로 거부 동작은 명시적으로 허용된 연결만 허용되도록 보장하여 강력한 보안 태세를 유지 관리합니다.
### 최소 권한 원칙 적용
+ **제한적인 정책으로 시작하고 필요에 따라 점진적으로 권한 추가** - 먼저 클러스터 수준에서 기본적으로 거부 정책을 구현한 다음 정상 연결 요구 사항을 검증할 때 허용 규칙을 점진적으로 추가합니다. 이 접근 방식을 사용하면 팀이 각 외부 연결을 명시적으로 정당화하여 보다 안전하고 감사 가능한 환경을 생성할 수 있습니다.
+ **정기적으로 미사용 정책 규칙 감사 및 제거** - 애플리케이션이 진화하면서 시간이 지남에 따라 네트워크 정책이 누적될 수 있으며 공격 표면을 불필요하게 확장하는 더 이상 사용되지 않는 규칙이 남겨질 수 있습니다. 정기적인 검토 프로세스를 구현하여 더 이상 필요하지 않은 정책 규칙을 식별하고 제거하여 엄격하고 관리 가능한 보안 태세를 보장합니다.
+ **가능하면 광범위한 패턴 대신 특정 도메인 이름 사용** - `*.amazonaws.com`과 같은 와일드카드 패턴은 편의를 제공하지만 다양한 서비스에 대한 액세스 권한도 부여합니다. 가능하면 `s3.us-west-2.amazonaws.com`과 같은 정확한 도메인 이름을 지정하여 애플리케이션에 필요한 특정 서비스로만 액세스를 제한함으로써 워크로드가 손상되는 경우 측면 이동의 위험을 줄입니다.
### EKS에서 DNS 기반 정책 사용
+ `ApplicationNetworkPolicy`를 사용하여 정의된 DNS 기반 규칙은 EKS Auto Mode에서 시작된 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. 혼합 모드 클러스터(EKS Auto 및 비EKS Auto 워커 노드로 구성)를 실행하는 경우 DNS 기반 규칙은 EKS Auto 모드 워커 노드(EC2 관리형 인스턴스)에서만 유효합니다.
### DNS 정책 검증
+ **테스트를 위해 프로덕션 네트워크 토폴로지를 미러링하는 스테이징 클러스터 사용** - 스테이징 환경은 정확한 정책 테스트를 보장하기 위해 프로덕션의 네트워크 아키텍처, 외부 종속성 및 연결 패턴을 복제해야 합니다. 여기에는 VPC 구성 일치, DNS 확인 동작, 프로덕션 워크로드에 필요한 것과 동일한 외부 서비스에 대한 액세스가 포함됩니다.
+ **중요한 네트워크 경로에 대한 자동화된 테스트 구현** - CI/CD 파이프라인의 일부로 필수 외부 서비스에 대한 연결을 검증하는 자동화된 테스트를 빌드합니다. 이러한 테스트는 권한 없는 연결이 차단되는 동안 정상 트래픽 흐름이 허용되도록 확인해야 합니다. 이를 통해 인프라가 진화함에 따라 네트워크 정책이 올바른 보안 태세를 유지 관리하는 지속적 검증을 제공합니다.
+ **정책 변경 후 애플리케이션 동작 모니터링** - 새 네트워크 정책 또는 수정된 네트워크 정책을 프로덕션에 배포한 후 애플리케이션 로그, 오류 발생률 및 성능 지표를 면밀히 모니터링하여 연결 문제를 신속하게 식별합니다. 예기치 않은 애플리케이션 동작 또는 서비스 중단이 발생하는 경우 정책 변경 사항을 신속하게 되돌릴 수 있도록 명확한 롤백 절차를 설정합니다.
### Amazon Route 53 DNS 방화벽과의 상호 작용
EKS 관리자 및 네트워크 정책은 트래픽이 시작될 때 포드 수준에서 먼저 평가됩니다. EKS 네트워크 정책이 특정 도메인으로의 송신을 허용하는 경우 포드는 Route 53 Resolver에 도달하는 DNS 쿼리를 수행합니다. 이때 Route 53 DNS 방화벽 규칙이 평가됩니다. DNS 방화벽이 도메인 쿼리를 차단하면 EKS 네트워크 정책에서 허용했더라도 DNS 확인에 실패하고 연결을 설정할 수 없습니다. 그래서 보완적인 보안 계층을 생성합니다. EKS DNS 기반 네트워크 정책은 애플리케이션 특정 액세스 요구 사항 및 다중 테넌트 보안 경계에 대한 포드 수준의 송신 제어를 제공하는 반면, DNS 방화벽은 알려진 악성 도메인에 대해 VPC 전반의 보호를 제공하고 조직 전체의 차단 목록을 적용합니다.
# EKS 자동 모드의 태그 서브넷
EKS 자동 모드의 로드 밸런싱 기능을 사용하는 경우 VPC 서브넷에 AWS 태그를 추가해야 합니다.
## 배경
이 태그는 클러스터와 연결된 서브넷을 식별하며, 더 중요한 것은 서브넷이 퍼블릭인지 프라이빗인지 식별합니다.
퍼블릭 서브넷은 인터넷 게이트웨이를 통해 인터넷에 직접 액세스할 수 있으며, 로드 밸런서와 같이 공개적으로 액세스해야 하는 리소스에 사용됩니다.
프라이빗 서브넷은 인터넷에 직접 액세스할 수 없고 아웃바운드 트래픽에 NAT 게이트웨이를 사용하며, 퍼블릭 IP가 필요 없는 EKS 노드와 같은 내부 리소스에 사용됩니다.
NAT 게이트웨이 및 인터넷 게이트웨이에 대한 자세한 내용은 Amazon Virtual Private Cloud(VPC) 사용 설명서의 [다른 네트워크에 VPC 연결](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)을 참조하세요.
## 요구 사항
현재 EKS 자동 모드에서 로드 밸런싱에 사용되는 서브넷에는 다음 태그 중 하나가 있어야 합니다.
### 퍼블릭 서브넷
퍼블릭 서브넷은 인터넷에 연결된 로드 밸런서에 사용되며, 다음 태그가 있어야 합니다.
| 키 | 값 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` 또는 `` |
### 프라이빗 서브넷
프라이빗 서브넷은 내부 로드 밸런서에 사용되며, 다음 태그가 있어야 합니다.
| 키 | 값 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` 또는 `` |
## 절차
시작하기 전에 퍼블릭 서브넷(인터넷 게이트웨이 액세스 가능)과 프라이빗 서브넷(NAT 게이트웨이 사용)을 식별합니다. VPC 리소스를 수정하려면 권한이 필요합니다.
### AWS Management Console
1. Amazon VPC 콘솔을 열고 **서브넷**으로 이동하세요.
1. 태그를 지정할 서브넷을 선택하세요.
1. **태그** 탭을 선택하고 **태그 추가**를 선택하세요.
1. 적절한 태그를 추가합니다.
+ 퍼블릭 서브넷의 경우: Key=`kubernetes.io/role/elb`
+ 프라이빗 서브넷의 경우: Key=`kubernetes.io/role/internal-elb`
1. **값**을 `1`로 설정하거나 비워 두세요.
1. 저장하고 나머지 서브넷에 대해 반복하세요.
### AWS CLI
퍼블릭 서브넷의 경우
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
프라이빗 서브넷의 경우
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
`subnet-ID`를 실제 서브넷 ID로 바꿉니다.
# kubectl 디버그를 사용하여 Kubernetes 노드에서 CIS 규정 준수 보고서 생성
이 주제에서는 `kubectl debug` 명령을 사용하여 Amazon EKS 노드에 대한 인터넷 보안 센터(CIS) 규정 준수 보고서를 생성하는 방법을 설명합니다. 이 명령을 사용하면 Kubernetes 노드에 디버깅 컨테이너를 임시로 생성하고 `apiclient` 도구를 사용하여 CIS 규정 준수 검사를 실행할 수 있습니다. `apiclient` 도구는 EKS 자동 모드 노드에서 사용하는 OS인 Bottlerocket OS의 일부입니다.
## 사전 조건
시작하기 전에 다음을 갖추었는지 확인하세요.
+ `kubectl`이 구성된 Amazon EKS 클러스터에 대한 액세스 권한(버전이 v1.32.0 이상이어야 함, 확인하려면 `kubectl version` 입력)
+ 노드를 디버깅할 수 있는 적절한 IAM 권한
+ 디버그 작업을 허용하는 유효한 프로파일(예: `sysadmin`)
`kubectl`을 사용하여 디버깅 프로파일을 사용하는 방법에 대한 자세한 내용은 Kubernetes Documentation의 [Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)을 참조하세요.
## 절차
1. 보고서를 실행할 노드의 AWS 인스턴스 ID를 결정합니다. 다음 명령을 사용하여 클러스터의 노드를 나열합니다. 인스턴스 ID는 이름 열에서 찾을 수 있으며 `i-`로 시작합니다.
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. ``를 쿼리하려는 노드의 인스턴스 ID로 바꿔서 다음 명령을 실행합니다.
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
이 명령의 구성 요소는 다음과 같습니다.
+ `kubectl debug node/` - 지정된 EC2 인스턴스 ID에 디버깅 세션을 생성합니다.
+ `-it` - TTY(명령줄 쉘)를 할당하고 대화형 사용을 위해 stdin을 열어 둡니다.
+ `--profile=sysadmin` - 적절한 권한으로 지정된 `kubectl` 프로파일을 사용합니다.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` - 디버깅을 위한 컨테이너 이미지로 `amazonlinux:2023`을 사용합니다.
+ `bash -c "…"` - bash 쉘에서 다음 명령을 실행합니다.
+ `yum install -q -y util-linux-core` - 필요한 유틸리티 패키지를 자동으로 설치합니다.
+ `nsenter -t 1 -m` - `nsenter`를 실행하여 호스트 프로세스의 네임스페이스(PID 1)로 들어갑니다.
+ `apiclient report cis --level 1 --format text` - 텍스트 출력을 사용하여 레벨 1에서 CIS 규정 준수 보고서를 실행합니다.
1. 보고서 텍스트 출력을 검토합니다.
## 출력 해석
명령은 다양한 CIS 제어의 규정 준수 상태를 보여주는 텍스트 기반 보고서를 생성합니다. 출력에는 다음이 포함됩니다.
+ 개별 CIS 제어 ID
+ 각 제어에 대한 설명
+ 각 검사의 통과, 실패 또는 건너뛰기 상태
+ 규정 준수 문제를 설명하는 세부 정보
다음은 Bottlerocket 인스턴스에서 실행되는 보고서의 출력 예입니다.
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
벤치마크에 대한 자세한 내용은 인터넷 보안 센터(CIS)의 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)를 참조하세요.
## 관련 리소스
+ Bottlerocket OS Documentation의 [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)
+ 쿠버네티스 문서의 [동작 중인 파드 디버그](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)
+ CIS(Center for Internet Security)의 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)
# EKS Auto Mode용 고객 관리형 KMS 키를 사용하여 EBS 볼륨 암호화 활성화
고객 관리형 KMS 키를 사용하여 EKS Auto Mode 인스턴스의 임시 루트 볼륨을 암호화할 수 있습니다.
Amazon EKS Auto Mode는 Kubernetes 클러스터의 암호화된 EBS 볼륨을 관리할 때 서비스 연결 역할을 사용하여 다른 AWS 서비스에 권한을 위임합니다. 이 주제에서는 EKS Auto Mode에서 Amazon EBS 암호화용 고객 관리형 키를 지정할 때 필요한 키 정책을 설정하는 방법에 대해 설명합니다.
고려 사항:
+ EKS Auto Mode는 기본 AWS 관리형 키를 사용하여 계정의 암호화된 볼륨을 보호하는 데 추가 승인이 필요하지 않습니다.
+ 이 주제에서는 EC2 인스턴스의 루트 볼륨인 임시 볼륨의 암호화를 다룹니다. 워크로드에 사용되는 데이터 볼륨 암호화에 대한 자세한 내용은 [스토리지 클래스 생성](create-storage-class.md) 섹션을 참조하세요.
## 개요
다음 AWS KMS 키는 EKS Auto Mode에서 인스턴스를 시작할 때 Amazon EBS 루트 볼륨 암호화에 사용할 수 있습니다.
+ **AWS 관리형 키** - Amazon EBS에서 생성, 소유 및 관리하는 계정의 암호화 키입니다. 이 키는 새 계정을 위한 기본 암호화 키입니다.
+ **고객 관리형 키** - 사용자가 생성, 소유 및 관리하는 사용자 지정 암호화 키입니다.
**참고**
키는 대칭이어야 합니다. Amazon EBS에서는 비대칭 고객 관리형 키를 지원하지 않습니다.
## 1단계: 키 정책 구성
KMS 키에는 EKS Auto Mode가 고객 관리형 키로 암호화된 Amazon EBS 볼륨으로 인스턴스를 시작할 수 있도록 허용하는 키 정책이 있어야 합니다.
다음 구조로 키 정책을 구성합니다.
**참고**
이 정책에는 EKS Auto Mode에 대한 권한만 포함되어 있습니다. 다른 자격 증명이 키를 사용하거나 권한 부여를 관리해야 하는 경우 키 정책에 추가 권한이 필요할 수 있습니다.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
``를 실제 AWS 계정 ID로 바꿔야 합니다.
키 정책을 구성할 때:
+ `ClusterServiceRole`에는 암호화 작업에 KMS 키를 사용하는 데 필요한 IAM 권한이 있어야 합니다.
+ `kms:GrantIsForAWSResource` 조건은 AWS 서비스에 대해서만 권한 부여를 생성할 수 있도록 합니다.
## 2단계: 고객 관리형 키를 사용하여 NodeClass 구성
키 정책을 구성한 후 EKS Auto Mode NodeClass 구성에서 KMS 키를 참조합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
자리 표시자 값을 실제 값으로 바꿉니다.
+ ``을 실제 AWS 리전으로 바꿈
+ ``를 실제 AWS 계정 ID로 바꿈
+ ``를 실제 KMS 키 ID로 바꿈
다음 형식 중 하나를 사용하여 KMS 키를 지정할 수 있습니다.
+ KMS 키 ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS 키 ARN: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ 키 별칭 이름: `alias/eks-auto-mode-key`
+ 키 별칭 ARN: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
kubectl을 사용하여 NodeClass 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
## 관련 리소스
+ [Amazon EKS용 NodeClass 생성](create-node-class.md)
+ AWS Key Management Service 개발자 안내서에서 자세한 내용을 참조하세요.
+ [키 정책의 AWS 서비스에 대한 권한](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [키 정책 변경](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [AWS KMS의 권한 부여](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# EKS 자동 모드에 대한 조직 제어 업데이트
일부 조직 제어로 인해 EKS 자동 모드가 제대로 작동하지 않을 수 있습니다. 이 경우 EKS 자동 모드가 사용자를 대신하여 EC2 인스턴스를 관리하는 데 필요한 권한을 갖도록 해당 제어를 업데이트해야 합니다.
EKS 자동 모드는 서비스 역할을 사용하여 EKS 자동 모드 노드를 지원하는 EC2 인스턴스를 시작합니다. 서비스 역할은 사용자의 계정에서 생성된 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)로, 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임하는 역할입니다. 서비스 역할로 수행되는 작업에는 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)이 항상 적용됩니다. 이를 통해 SCP는 자동 모드의 작동을 억제할 수 있습니다. SCP를 사용하여 시작할 수 있는 Amazon Machine Image(AMI)를 제한하는 경우가 가장 일반적인 예입니다. EKS 자동 모드가 작동하도록 하려면 EKS 자동 모드 계정에서 AMI를 시작할 수 있게 SCP를 수정합니다.
[EC2 허용된 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 기능을 사용하여 다른 계정에 있는 AMI의 가시성을 제한할 수도 있습니다. 이 기능을 사용하는 경우 관심 리전에 EKS 자동 모드 AMI 계정도 포함하도록 이미지 기준을 확장해야 합니다.
## EKS 자동 모드 AMI를 제외한 모든 AMI를 차단하는 SCP 예제
아래 SCP는 AMI가 us-west-2 또는 us-east-1의 EKS 자동 모드 AMI 계정에 속하지 않는 한 `ec2:RunInstances`를 직접적으로 호출하지 못하도록 합니다.
**참고**
`ec2:Owner` 컨텍스트 키를 사용하지 **않는** 것이 중요합니다. Amazon은 EKS 자동 모드 AMI 계정을 소유하며 이 키의 값은 항상 `amazon`입니다. `ec2:Owner`가 `amazon`인 경우 AMI를 시작할 수 있는 SCP를 구성하면 EKS 자동 모드용 AMI뿐만 아니라 Amazon이 소유한 모든 AMI를 시작할 수 있습니다.\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS 자동 모드 AMI 계정
리전별로 다른 AWS 계정이 EKS 자동 모드 퍼블릭 AMI를 호스팅합니다.
| | |
| --- |--- |
| AWS 리전 | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## 퍼블릭 IP 주소 연결
`ec2:RunInstances`가 호출되면 인스턴스 시작의 `AssociatePublicIpAddress` 필드는 인스턴스가 시작되는 서브넷 유형에 따라 자동으로 결정됩니다. SCP를 사용하여 시작되는 서브넷 유형과 무관하게 이 값을 명시적으로 false로 설정할 수 있습니다. 이 경우 SCP의 요구 사항을 충족하기 위해 NodeClass 필드 `spec.advancedNetworking.associatePublicIPAddress`를 false로 설정할 수도 있습니다.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어
[용량 예약](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)으로 워크로드 배포를 제어할 수 있습니다. EKS Auto Mode는 EC2 온디맨드 용량 예약(ODCR) 및 ML용 EC2 용량 블록을 지원합니다.
**작은 정보**
기본적으로 EKS Auto Mode는 오픈 매치를 통해 오픈 ODCR로 시작할 수 있지만 우선순위는 지정되지 않습니다. 오픈 매치를 통해 시작된 인스턴스에는 `reserved`가 아닌 `karpenter.sh/capacity-type: on-demand` 레이블이 지정됩니다. ODCR 사용량의 우선순위를 지정하고 인스턴스에 `karpenter.sh/capacity-type: reserved` 레이블을 지정하려면 NodeClass 정의에서 `capacityReservationSelectorTerms`를 구성합니다. ML에 대한 용량 블록에는 항상 `capacityReservationSelectorTerms`가 필요하며 이 용량 블록은 자동으로 사용되지 않습니다.
## EC2 온디맨드 용량 예약(ODCR)
EC2 온디맨드 용량 예약(ODCR)을 사용하면 특정 가용 영역의 Amazon EC2 인스턴스에 대해 원하는 기간만큼 컴퓨팅 용량을 예약할 수 있습니다. EKS 자동 모드를 사용하는 경우 사전 구매한 용량의 사용률을 극대화하거나 중요한 워크로드가 보장된 리소스에 액세스할 수 있도록 Kubernetes 워크로드를 이러한 예약 인스턴스에 배포할지 여부를 제어할 수 있습니다.
기본적으로 EKS 자동 모드는 개방형 ODCR로 자동 시작됩니다. 그러나 NodeClass에서 `capacityReservationSelectorTerms`를 구성하여 워크로드에서 사용하는 ODCR을 명시적으로 제어할 수 있습니다. 구성된 ODCR을 사용하여 프로비저닝된 노드는 `karpenter.sh/capacity-type: reserved`를 가지며 온디맨드와 스팟보다 우선순위가 높습니다. 이 기능이 활성화되면 EKS 자동 모드는 더 이상 개방형 ODCR을 자동으로 사용하지 않습니다. NodeClass에서 ODCR을 명시적으로 선택해야 하므로 클러스터 전체에서 용량 예약 사용량을 정확하게 제어할 수 있습니다.
**주의**
클러스터의 NodeClass에서 `capacityReservationSelectorTerms`를 구성하는 경우 EKS 자동 모드는 더 이상 클러스터의 *모든* NodeClass에 대해 개방형 ODCR을 자동으로 사용하지 않습니다.
### NodeClass 예제
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
이 예제 NodeClass는 ODCR을 선택하는 두 가지 접근 방식을 보여줍니다. 첫 번째 방법은 ID(`cr-56fac701cc1951b03`)로 특정 ODCR을 직접 참조합니다. 두 번째 방법은 태그 기반 선택을 사용하여 `Name: "targeted-odcr"` 태그가 있는 ODCR을 대상으로 합니다. 예약을 소유한 AWS 계정으로 필터링할 수도 있는데, 이는 특히 여러 계정이 관련된 시나리오나 공유 용량 예약을 처리할 때 유용합니다.
## ML용 EC2 용량 블록 사용
ML용 용량 블록은 향후 날짜에 GPU 기반 가속 컴퓨팅 인스턴스를 예약하여 단기간의 기계 학습(ML) 워크로드를 지원합니다. 용량 블록 내부에서 실행되는 인스턴스는 지연 시간이 짧은 페타비트 규모의 비차단 네트워킹을 위해 Amazon EC2 UltraClusters 내부에 자동으로 서로 가깝게 배치됩니다.
지원되는 플랫폼 및 인스턴스 유형에 대한 자세한 내용은 EC2 사용 설명서의 [ML용 용량 블록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)을 참조하세요.
ODCR(앞에서 설명)과 마찬가지로 ML용 용량 블록을 사용하는 EKS Auto Mode NodeClass를 생성할 수 있습니다.
다음 샘플 정의에서는 세 가지 리소스를 생성합니다.
1. 용량 블록 예약을 참조하는 NodeClass
1. NodeClass를 사용하고 테인트를 적용하는 NodePool
1. 테인트를 허용하고 GPU 리소스를 요청하는 포드 사양
### NodeClass 예제
이 NodeClass는 예약 ID로 ML용 특정 용량 블록을 참조합니다. EC2 콘솔에서 이 ID를 얻을 수 있습니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
### NodePool 예제
이 NodePool은 `gpu` NodeClass를 참조하고 중요한 구성을 지정합니다.
+ `karpenter.sh/capacity-type: reserved`를 설정하여 예약 용량**만** 사용함
+ ML 워크로드에 적합한 특정 GPU 인스턴스 패밀리를 요청함
+ 이러한 노드에 GPU 워크로드만 예약되도록 `nvidia.com/gpu` 테인트를 적용함
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
### 포드 예제
이 포드 예제는 용량 블록 노드에서 실행하도록 워크로드를 구성하는 방법을 보여줍니다.
+ **nodeSelector**를 사용하여 특정 GPU 유형(이 경우 H200 GPUs)을 대상으로 지정함
+ 여기에는 NodePool에서 적용하는 `nvidia.com/gpu` 테인트에 대한 **허용치**가 포함됨
+ `nvidia.com/gpu` 리소스 유형을 사용하여 명시적으로 **GPU 리소스를 요청**함
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
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:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
자세한 내용은 Kubernetes 문서의 [포드](https://kubernetes.io/docs/concepts/workloads/pods/)를 참조하세요.
### 관련 리소스
+ Amazon EC2 사용 설명서의 [ML용 용량 블록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)
+ Amazon EC2 사용 설명서의 [용량 블록 찾기 및 구매](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)
+ [Amazon EKS에서 AI/ML 워크로드의 컴퓨팅 리소스 관리](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ EKS 모범 사례 가이드의 [GPU 리소스 최적화 및 비용 관리](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)
# 로컬 영역에 EKS Auto Mode 노드 배포
EKS Auto Mode는 자동 노드 프로비저닝을 통해 단순화된 클러스터 관리를 제공합니다. AWS 로컬 영역은 AWS 인프라를 최종 사용자에게 더 가까운 지리적 위치로 확장하여 지연 시간에 민감한 애플리케이션의 지연 시간을 줄입니다. 이 가이드에서는 AWS 로컬 영역에 EKS Auto Mode 노드를 배포하는 프로세스를 안내하여 특정 지리적 영역의 사용자가 지연 시간을 줄이면서 컨테이너화된 애플리케이션을 실행할 수 있도록 지원합니다.
또한 이 가이드는 Kubernetes 테인트 및 허용 오차를 사용하여 로컬 영역 노드에서 특정 워크로드만 실행하게 함으로써 비용을 제어하고 리소스 사용을 최적화하는 방법을 보여줍니다.
## 사전 조건
로컬 영역에 EKS Auto Mode 노드 배포를 시작하기 전에 다음 사전 조건이 있는지 확인합니다.
+ [기존 EKS Auto Mode 클러스터](create-auto.md)
+ [AWS 계정에서 로컬 영역에 옵트인됨](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## 1단계: 로컬 영역 서브넷 생성
로컬 영역에 EKS Auto Mode 노드를 배포하는 첫 번째 단계는 해당 로컬 영역에 서브넷을 생성하는 것입니다. 이 서브넷은 노드에 대한 네트워크 인프라를 제공하고 노드가 나머지 VPC와 통신할 수 있게 합니다. [Create a Local Zone subnet](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) 지침(AWS 로컬 영역 사용 설명서)에 따라 선택한 로컬 영역에서 서브넷을 생성합니다.
**작은 정보**
로컬 영역 서브넷의 이름을 기록합니다.
## 2단계: 로컬 영역 서브넷에 대한 NodeClass 생성
로컬 영역 서브넷을 생성한 후 이 서브넷을 참조하는 NodeClass를 정의해야 합니다. NodeClass는 사용할 서브넷, 보안 그룹 및 스토리지 구성을 포함하여 노드의 인프라 속성을 지정하는 Kubernetes 사용자 지정 리소스입니다. 아래 예제에서는 해당 이름을 기반으로 로컬 영역 서브넷을 대상으로 하는 'local-zone'이라는 NodeClass를 생성합니다. 또한 서브넷 ID를 사용할 수도 있습니다. 로컬 영역 서브넷을 대상으로 하도록 이 구성을 조정해야 합니다.
자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## 3단계: NodeClass 및 테인트를 사용하여 NodePool 생성
NodeClass가 구성된 경우 이제 이 NodeClass를 사용하는 NodePool을 생성해야 합니다. NodePool은 인스턴스 유형을 포함하여 노드의 컴퓨팅 특성을 정의합니다. NodePool은 NodeClass를 참조로 사용하여 인스턴스를 시작할 위치를 결정합니다.
아래 예제에서는 'local-zone' NodeClass를 참조하는 NodePool을 생성합니다. 또한 노드에 테인트를 추가하여 이러한 로컬 영역 노드에서 허용 오차가 일치하는 포드만 예약할 수 있도록 합니다. 이는 일반적으로 비용이 더 많이 들고 특별히 지연 시간 단축의 이점을 특별히 활용하는 워크로드에서만 사용해야 하는 로컬 영역 노드에 특히 중요합니다.
자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
키가 `aws.amazon.com/local-zone`이고 효과가 `NoSchedule`인 테인트는 일치하는 허용 오차가 없는 포드가 이러한 노드에서 예약되지 않도록 합니다. 이를 통해 정기적인 워크로드가 로컬 영역에서 실수로 실행되어 예기치 않은 비용이 발생하지 않도록 방지합니다.
## 4단계: 허용 오차 및 노드 선호도를 사용하여 워크로드 배포
로컬 영역 노드에서 워크로드 배치에 대한 최적의 제어를 위해 테인트/허용 오차 및 노드 선호도를 모두 함께 사용합니다. 이러한 결합된 접근 방식에는 다음과 같은 이점이 있습니다.
1. **비용 제어**: 테인트를 사용하면 명시적 허용 오차가 있는 포드만 잠재적으로 비용이 많이 드는 로컬 영역 리소스를 사용할 수 있도록 보장합니다.
1. **보장된 배치**: 노드 선호도는 지연 시간에 민감한 애플리케이션이 일반 클러스터 노드가 아닌 로컬 영역에서만 실행되도록 보장합니다.
다음은 로컬 영역 노드에서 특별히 실행하도록 구성된 배포에 대한 예제입니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
이 배포에는 다음과 같은 두 가지 주요 예약 구성이 있습니다.
1. **허용 오차**를 사용하면 `aws.amazon.com/local-zone` 테인트가 있는 노드에서 포드를 예약할 수 있습니다.
1. **노드 선호도** 요구 사항은 이러한 포드가 레이블 `node-type: local-zone`인 노드에서만 실행되도록 보장합니다.
이렇게 하면 지연 시간에 민감한 애플리케이션이 로컬 영역 노드에서만 실행되고, 일반 애플리케이션은 명시적으로 구성되지 않은 한 로컬 영역 리소스를 사용하지 않도록 보장합니다.
## 5단계: AWS 콘솔로 확인
NodeClass, NodePool 및 배포를 설정한 후 노드가 예상대로 로컬 영역에서 프로비저닝되고 워크로드가 실행 중인지 확인해야 합니다. AWS Management Console을 사용하여 EC2 인스턴스가 올바른 로컬 영역 서브넷에서 시작되고 있는지 확인할 수 있습니다.
또한 `kubectl get nodes -o wide`를 사용하여 Kubernetes 노드 목록을 확인해 노드가 올바른 레이블과 테인트로 클러스터에 조인하고 있는지 확인할 수 있습니다.
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
워크로드 포드가 로컬 영역 노드에서 예약되어 있는지 확인할 수도 있습니다.
```
kubectl get pods -o wide
```
이 접근 방식을 사용하면 로컬 영역 테인트를 특별히 허용하는 워크로드만 이러한 노드에서 예약되므로 비용을 제어하고 로컬 영역 리소스를 가장 효율적으로 사용할 수 있습니다.
# 노드에 대한 고급 보안 설정 구성
이 주제에서는 노드 클래스의 `advancedSecurity` 사양을 사용하여 Amazon EKS Auto Mode 노드에 대한 고급 보안 설정을 구성하는 방법을 설명합니다.
## 사전 조건
시작하기 전에 다음을 갖추었는지 확인하세요.
+ Amazon EKS 자동 모드 클러스터. 자세한 내용은 [Amazon EKS 자율 모드에서 클러스터 생성](create-auto.md) 섹션을 참조하세요.
+ `kubectl`을 설치하고 구성했습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
+ 노드 클래스 구성에 대한 이해. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 고급 보안 설정 구성
노드에 대한 고급 보안 설정을 구성하려면 노드 클래스 사양에서 `advancedSecurity` 필드를 설정합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
이 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
노드 풀 구성에서 이 노드 클래스를 참조합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 필드 설명
+ `fips`(부울, 선택 사항): `true`로 설정하면 FIPS 140-2 검증 암호화 모듈와 함께 AMI를 사용하여 노드를 프로비저닝합니다. 이 설정에서는 FIPS 준수 AMI를 선택하며, 고객은 규정 준수 요구 사항을 관리할 책임이 있습니다. 자세한 내용은 [AWS FIPS compliance](https://aws.amazon.com/compliance/fips/)를 참조하세요. 기본값: `false`.
+ `kernelLockdown`(문자열, 선택 사항): 커널 잠금 보안 모듈 모드를 제어합니다. 허용되는 값:
+ `integrity`: 커널 메모리를 덮어쓰거나 커널 코드를 수정하기 위해 메서드를 차단합니다. 서명되지 않은 커널 모듈을 로드하지 않도록 합니다.
+ `none`: 커널 잠금 보호를 비활성화합니다.
자세한 내용은 [Linux 커널 잠금 설명서](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)를 참조하세요.
## 고려 사항
+ FIPS 준수 AMI는 AWS 미국 동부/서부, AWS GovCloud(미국) 및 AWS 캐나다(중부/서부) 리전에서 사용할 수 있습니다. 자세한 내용은 [AWS FIPS compliance](https://aws.amazon.com/compliance/fips/)를 참조하세요.
+ `kernelLockdown: "integrity"`를 사용하는 경우 워크로드에 서명되지 않은 커널 모듈의 로드나 커널 메모리 수정이 필요하지 않은지 확인합니다.
## 관련 리소스
+ [Amazon EKS용 노드 클래스 생성](create-node-class.md) - 노드 클래스 구성 가이드 작성
+ [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) - 노드 풀 구성
# EKS Auto Mode 작동 방식 알아보기
이 장에서는 Amazon EKS Auto Mode 클러스터의 구성 요소가 작동하는 방법을 알아봅니다.
**Topics**
+ [Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기](automode-learn-instances.md)
+ [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md)
+ [EKS 자율 모드에서 VPC 네트워킹 및 로드 밸런싱에 대해 알아보기](auto-networking.md)
# Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기
이 주제에서는 Amazon EKS Auto Mode가 EKS 클러스터에서 Amazon EC2 인스턴스를 관리하는 방법을 설명합니다. EKS Auto Mode를 활성화하면 클러스터의 컴퓨팅 리소스가 EKS에 의해 자동으로 프로비저닝되고 관리되므로 클러스터의 노드 역할을 하는 EC2 인스턴스와 상호 작용하는 방식이 변경됩니다.
Amazon EKS Auto Mode가 인스턴스를 관리하는 방법을 이해하는 것은 워크로드 배포 전략 및 운영 절차를 계획하는 데 필수적입니다. 기존 EC2 인스턴스 또는 관리형 노드 그룹과 달리 이러한 인스턴스는 EKS가 특정 유형의 액세스 및 사용자 지정을 제한하면서 여러 운영 측면에 대한 책임을 지는 다른 수명 주기 모델을 따릅니다.
Amazon EKS Auto Mode는 새 EC2 인스턴스를 생성하기 위한 일상적인 작업을 자동화하고 이를 EKS 클러스터에 노드로 연결합니다. EKS Auto Mode는 워크로드가 기존 노드에 맞지 않는 시기를 감지하고 새 EC2 인스턴스를 생성합니다.
Amazon EKS Auto Mode는 EC2 인스턴스를 생성 및 삭제하고 패치를 적용하는 역할을 합니다. 인스턴스에 배포된 컨테이너와 포드는 사용자의 책임입니다.
EKS Auto Mode에서 생성한 EC2 인스턴스는 다른 EC2 인스턴스와 차이가 있으며 관리형 인스턴스입니다. 이러한 관리형 인스턴스는 EKS에서 소유하며 더 제한적입니다. EKS Auto Mode에서 관리하는 인스턴스에는 직접 액세스하거나 소프트웨어를 설치할 수 없습니다.
AWS에서는 EKS Auto Mode 또는 자체 관리형 Karpenter를 실행할 것을 제안합니다. 마이그레이션 중에 또는 고급 구성으로 둘 다 설치할 수 있습니다. 둘 다 설치한 경우 워크로드가 Karpenter 또는 EKS Auto Mode와 연결되도록 노드 풀을 구성합니다.
자세한 내용은 Amazon EC2 사용 설명서의 [Amazon EC2 managed instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)를 참조하세요.
## 비교 테이블
| 표준 EC2 인스턴스 | EKS Auto Mode 관리형 인스턴스 |
| --- | --- |
| 인스턴스의 패치 적용 및 업데이트는 사용자의 책임입니다. | AWS는 인스턴스를 자동으로 패치하고 업데이트합니다. |
| EKS는 인스턴스의 소프트웨어에 대해 책임을 지지 않습니다. | EKS는 `kubelet`, 컨테이너 런타임, 운영 체제와 같은 인스턴스의 특정 소프트웨어를 담당합니다. |
| EC2 API를 사용하여 EC2 인스턴스를 삭제할 수 있습니다. | EKS는 계정에 배포된 인스턴스 수를 결정합니다. 워크로드를 삭제하면 EKS가 계정의 인스턴스 수를 줄입니다. |
| SSH를 사용하여 EC2 인스턴스에 액세스할 수 있습니다. | 포드와 컨테이너를 관리형 인스턴스에 배포할 수 있습니다. |
| 운영 체제 및 이미지(AMI)를 결정합니다. | AWS가 운영 체제와 이미지를 결정합니다. |
| Windows 또는 Ubuntu 기능에 의존하는 워크로드를 배포할 수 있습니다. | Linux 기반의 컨테이너를 배포할 수 있지만 특정 OS 종속성은 사용할 수 없습니다. |
| 시작할 인스턴스 유형과 패밀리를 결정합니다. | AWS가 시작할 인스턴스 유형과 패밀리를 결정합니다. 노드 풀을 사용하여 EKS Auto Mode가 선택하는 인스턴스 유형을 제한할 수 있습니다. |
다음 기능은 관리형 인스턴스와 표준 EC2 인스턴스 모두에서 작동합니다.
+ AWS 콘솔에서 인스턴스를 볼 수 있습니다.
+ 인스턴스 스토리지를 워크로드의 임시 스토리지로 사용할 수 있습니다.
### AMI 지원
EKS 자동 모드를 사용하면 AWS가 컴퓨팅 노드에 사용되는 이미지(AMI)를 결정합니다. AWS는 새 EKS 자동 모드 AMI 버전의 롤아웃을 모니터링합니다. AMI 버전과 관련된 워크로드 문제가 발생하는 경우 지원 사례를 생성합니다. 자세한 내용은 AWS Support User Guide의 [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)를 참조하세요.
일반적으로 EKS는 매주 CVE 및 보안 수정 사항이 포함된 새 AMI를 릴리스합니다.
## EKS 자동 모드 지원 인스턴스 참조
EKS 자동 모드는 최소 크기 요구 사항을 충족하는 지원되는 유형의 인스턴스만 생성합니다.
EKS Auto Mode는 다음 인스턴스 유형을 지원합니다.
| Family | 인스턴스 유형 |
| --- | --- |
| 컴퓨팅 최적화(C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| 범용(M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| 메모리 최적화(R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 |
| 버스트 가능(T) | t4g, t3, t3a, t2 |
| 고용량 메모리(Z/X) | z1d, x8g, x2gd |
| 스토리지 최적화(I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| 가속 컴퓨팅(P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| 고성능 컴퓨팅(X2) | x2iezn, x2iedn, x2idn |
또한 EKS 자동 모드는 다음 요구 사항을 충족하는 EC2 인스턴스만 생성합니다.
+ 1개 이상의 vCPU
+ 인스턴스 크기가 나노, 마이크로 또는 스몰이 아님
자세한 내용은 [Amazon EC2 인스턴스 유형 명명 규칙](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)을 참조하세요.
## 인스턴스 메타데이터 서비스
+ EKS 자동 모드는 AWS 보안 모범 사례를 준수하여 기본적으로 홉 제한 1로 IMDSv2를 적용합니다.
+ 자동 모드에서는 이 기본 구성을 수정할 수 없습니다.
+ 일반적으로 IMDS 액세스가 필요한 추가 기능의 경우 IMDS 조회를 방지하기 위해 설치 중 파라미터(예: AWS 리전)를 제공합니다. 자세한 내용은 [Amazon EKS 추가 기능에 대해 사용자 지정할 수 있는 필드 확인](kubernetes-field-management.md) 섹션을 참조하세요.
+ 자동 모드에서 실행할 때 포드에 IMDS 액세스가 절대적으로 필요한 경우 포드를 `hostNetwork: true`로 실행하도록 구성해야 합니다. 이렇게 하면 포드가 인스턴스 메타데이터 서비스에 직접 액세스할 수 있습니다.
+ 포드에 인스턴스 메타데이터에 대한 액세스 권한을 부여할 때 보안 영향을 고려합니다.
Amazon EC2 인스턴스 메타데이터 서비스(IMDS)에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 서비스 옵션 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)을 참조하세요.
## 고려 사항
+ NodeClass에 구성된 임시 스토리지가 인스턴스의 NVMe 로컬 스토리지보다 작으면 EKS 자동 모드는 자동으로 다음 작업을 수행하여 수동 구성이 필요 없습니다.
+ 더 작은 용량(20GiB)의 Amazon EBS 데이터 볼륨을 사용하여 비용을 줄입니다.
+ 임시 데이터 사용을 위해 NVMe 로컬 스토리지를 포맷하고 구성합니다. NVMe 드라이브가 여러 개 있는 경우 RAID 0 어레이 설정이 여기에 포함됩니다.
+ `ephemeralStorage.size`에서 로컬 NVMe 용량과 같거나 초과하는 경우 다음 작업이 발생합니다.
+ 자동 모드는 작은 EBS 볼륨을 건너뜁니다.
+ NVMe 드라이브는 워크로드에 직접 노출됩니다.
+ Amazon EKS Auto Mode는 AWS Fault Injection Service 작업을 지원하지 않습니다.
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS Auto Mode는 AWS Fault Injection Service EKS 포드 작업을 지원합니다. 자세한 내용은 AWS Resilience Hub 사용 설명서의 [Managing Fault Injection Service experiments](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) 및 [Use the AWS FIS aws:eks:pod actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)를 참조하세요.
+ EKS Auto Mode 노드에 `Neuron Device Plugin`을 설치할 필요가 없습니다.
클러스터에 다른 유형의 노드가 있는 경우 자동 모드 노드에서 실행되지 않도록 Neuron Device 플러그인을 구성해야 합니다. 자세한 내용은 [EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md) 섹션을 참조하세요.
# EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기
이 주제에서는 EKS Auto Mode를 사용하는 데 필요한 Identity and Access Management(IAM) 역할 및 권한을 설명합니다. EKS Auto Mode는 클러스터 IAM 역할과 노드 IAM 역할이라는 두 가지 기본 IAM 역할을 사용합니다. 이러한 역할은 EKS Pod Identity 및 EKS 액세스 항목과 함께 작동하여 EKS 클러스터에 대한 포괄적인 액세스 관리를 제공합니다.
EKS Auto Mode를 구성할 때 AWS 서비스가 클러스터 리소스와 상호 작용하도록 허용하는 특정 권한을 사용하여 이러한 IAM 역할을 설정해야 합니다. 여기에는 컴퓨팅 리소스, 스토리지 볼륨, 로드 밸런서, 네트워킹 구성 요소를 관리하는 권한이 포함됩니다. 이러한 역할 구성을 이해하는 것은 적절한 클러스터 작업 및 보안에 필수적입니다.
EKS Auto Mode에서 AWS IAM 역할은 EKS 액세스 항목을 통해 Kubernetes 권한에 자동으로 매핑되므로 `aws-auth` ConfigMaps 또는 사용자 지정 바인딩을 수동으로 구성할 필요가 없습니다. 새 자동 모드 클러스터를 생성할 경우 EKS는 액세스 항목을 사용하여 해당 Kubernetes 권한을 자동으로 생성하여 AWS 서비스 및 클러스터 구성 요소가 AWS 및 Kubernetes 권한 부여 시스템 모두에서 적절한 액세스 수준을 갖도록 합니다. 이 자동 통합은 구성의 복잡성을 줄이고 EKS 클러스터를 관리할 때 일반적으로 발생하는 권한 관련 문제를 방지하는 데 도움이 됩니다.
## 클러스터 IAM 역할
클러스터 IAM 역할은 Amazon EKS에서 Kubernetes 클러스터에 대한 권한을 관리하는 데 사용하는 AWS Identity and Access Management(IAM) 역할입니다. 이 역할은 Amazon EKS에 클러스터를 대신하여 다른 AWS 서비스와 상호 작용하는 데 필요한 권한을 부여하며, EKS 액세스 항목을 사용하여 Kubernetes 권한으로 자동 구성됩니다.
+ AWS IAM 정책을 이 역할에 연결해야 합니다.
+ EKS Auto Mode는 EKS 액세스 항목을 사용하여 이 역할에 Kubernetes 권한을 자동으로 연결합니다.
+ EKS Auto Mode를 사용할 경우 AWS에서는 AWS 계정당 단일 클러스터 IAM 역할을 생성할 것을 제안합니다.
+ AWS는 이 역할의 이름을 `AmazonEKSAutoClusterRole`로 지정할 것을 제안합니다.
+ 이 역할에는 EBS 볼륨, Elastic Load Balancer, EC2 인스턴스를 포함한 리소스를 관리할 수 있는 여러 AWS 서비스에 대한 권한이 필요합니다.
+ 이 역할에 대해 제안된 구성에는 EKS 자동 모드의 다양한 기능과 관련된 여러 AWS 관리형 IAM 정책이 포함되어 있습니다.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
클러스터 IAM 역할 및 AWS 관리형 IAM 정책에 대한 자세한 내용은 다음을 참조하세요.
+ [Amazon Elastic Kubernetes Service에 대한 AWS 관리형 정책](security-iam-awsmanpol.md)
+ [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md)
Kubernetes 액세스에 대한 자세한 내용은 다음을 참조하세요.
+ [액세스 정책 권한 검토](access-policy-permissions.md)
## 노드 IAM 역할
노드 IAM 역할은 Amazon EKS에서 Kubernetes 클러스터의 워커 노드에 대한 권한을 관리하는 데 사용하는 AWS Identity and Access Management(IAM) 역할입니다. 이 역할은 Kubernetes 노드로 실행되는 EC2 인스턴스에 AWS 서비스 및 리소스와 상호 작용하는 데 필요한 권한을 부여하며, EKS 액세스 항목을 사용하여 Kubernetes RBAC 권한으로 자동 구성됩니다.
+ AWS IAM 정책을 이 역할에 연결해야 합니다.
+ EKS Auto Mode는 EKS 액세스 항목을 사용하여 이 역할에 Kubernetes RBAC 권한을 자동으로 연결합니다.
+ AWS는 이 역할의 이름을 `AmazonEKSAutoNodeRole`로 지정할 것을 제안합니다.
+ EKS Auto Mode를 사용할 경우 AWS에서는 AWS 계정당 단일 노드 IAM 역할을 생성할 것을 제안합니다.
+ 이 역할에는 제한된 권한이 있습니다. 주요 권한에는 Pod Identity 역할 수임, ECR에서 이미지 가져오기가 포함됩니다.
+ AWS는 다음과 같은 AWS 관리형 IAM 정책을 제안합니다.
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
클러스터 IAM 역할 및 AWS 관리형 IAM 정책에 대한 자세한 내용은 다음을 참조하세요.
+ [Amazon Elastic Kubernetes Service에 대한 AWS 관리형 정책](security-iam-awsmanpol.md)
+ [Amazon EKS 노드 IAM 역할](create-node-role.md)
Kubernetes 액세스에 대한 자세한 내용은 다음을 참조하세요.
+ [액세스 정책 권한 검토](access-policy-permissions.md)
## 서비스 연결 역할
Amazon EKS는 특정 작업에 서비스 연결 역할(SLR)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 모든 권한을 포함합니다.
AWS는 SLR을 자동으로 생성하고 구성합니다. 먼저 관련 리소스를 삭제해야만 SLR을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다.
SLR 정책은 EC2 리소스(인스턴스, 네트워크 인터페이스, 보안 그룹), ELB 리소스(로드 밸런서, 대상 그룹), CloudWatch 기능(로깅 및 지표), 접두사가 'eks'인 IAM 역할 등 핵심 인프라 구성 요소를 관찰하고 삭제할 수 있는 권한을 Amazon EKS에 부여합니다. 또한 VPC/호스팅 영역 연결을 통해 프라이빗 엔드포인트 네트워킹을 활성화하고 EKS 태그가 지정된 리소스의 EventBridge 모니터링 및 정리에 대한 권한을 포함합니다.
자세한 내용은 다음을 참조하세요.
+ [AWS 관리형 정책: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## EKS Auto 리소스에 대한 사용자 지정 AWS 태그
기본적으로 EKS Auto Mode와 관련된 관리형 정책은 Auto Mode 프로비저닝 AWS 리소스에 사용자 정의 태그를 적용하는 것을 허용하지 않습니다. AWS 리소스에 사용자 정의 태그를 적용하려면 AWS 리소스에 태그를 생성하고 수정할 수 있는 충분한 권한이 있는 클러스터 IAM 역할에 추가 권한을 연결해야 합니다. 다음은 무제한 태그 지정 액세스를 허용하는 정책의 예입니다.
### 사용자 지정 태그 정책 예제 보기
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## 액세스 정책 참조
EKS Auto Mode에서 사용하는 Kubernetes 권한에 대한 자세한 내용은 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요.
# EKS 자율 모드에서 VPC 네트워킹 및 로드 밸런싱에 대해 알아보기
이 주제에서는 EKS Auto Mode에서 가상 프라이빗 클라우드(VPC) 네트워킹 및 로드 밸런싱 기능을 구성하는 방법을 설명합니다. EKS 자동 모드는 대부분의 네트워킹 구성 요소를 자동으로 관리하지만 `NodeClass` 리소스 및 로드 밸런서 주석을 통해 클러스터 네트워킹 구성의 특정 측면을 사용자 지정할 수 있습니다.
EKS Auto Mode를 사용하는 경우 AWS는 클러스터에 대한 VPC 컨테이너 네트워크 인터페이스(CNI) 구성 및 로드 밸런서 프로비저닝을 관리합니다. EKS 자동 모드가 제공하는 자동화된 운영 모델을 유지하면서 `NodeClass` 객체를 정의하고 서비스 및 수신 리소스에 특정 주석을 적용하여 네트워킹 동작에 영향을 미칠 수 있습니다.
## 네트워킹 기능
EKS 자율 모드는 노드 및 포드 네트워킹을 처리하는 새로운 네트워킹 기능을 제공합니다. `NodeClass` Kubernetes 객체를 생성하여 구성할 수 있습니다.
이전 AWS VPC CNI의 구성 옵션은 EKS 자율 모드에 적용되지 않습니다.
### `NodeClass`를 사용하여 네트워킹 구성
EKS 자율 모드의 `NodeClass` 리소스를 사용하면 네트워킹 기능의 특정 측면을 사용자 지정할 수 있습니다. `NodeClass`를 통해 보안 그룹 선택 지정, VPC 서브넷 간 노드 배치 제어, SNAT 정책 설정, 네트워크 정책 구성, 네트워크 이벤트 로깅 활성화가 가능합니다. 이 접근 방식은 EKS Auto Mode의 자동화된 운영 모델을 유지하면서 네트워크 사용자 지정에 유연성을 제공합니다.
`NodeClass`를 사용하여 다음을 수행할 수 있습니다.
+ 노드에 대한 보안 그룹 선택
+ VPC 서브넷에 노드를 배치하는 방법 제어
+ 노드 SNAT 정책을 `random` 또는 `disabled`로 설정
+ 다음을 포함한 Kubernetes *네트워크 정책*을 활성화합니다.
+ 네트워크 정책을 기본 거부 또는 기본 허용으로 설정
+ 파일에 네트워크 이벤트 로깅 활성화
+ 다른 서브넷에 포드를 연결하여 노드 트래픽에서 포드 트래픽을 격리합니다.
[Amazon EKS NodeClass 생성](create-node-class.md) 방법을 알아봅니다.
### 고려 사항
EKS Auto Mode는 다음을 지원합니다.
+ EKS 네트워크 정책
+ Kubernetes 포드의 `HostPort` 및 `HostNetwork` 옵션
+ 퍼블릭 또는 프라이빗 서브넷의 노드 및 포드
+ 노드에서 DNS 쿼리 캐싱.
EKS Auto Mode는 다음을 지원하지 **않습니다**.
+ 포드당 보안 그룹(SGPP) Auto Mode에서 포드 트래픽에 별도의 보안 그룹을 적용하려면 대신 `NodeClass`에서 `podSecurityGroupSelectorTerms`를 사용합니다. 자세한 내용은 [포드에 대한 별도의 서브넷 및 보안 그룹](create-node-class.md#pod-subnet-selector) 섹션을 참조하세요.
+ `ENIConfig`의 사용자 지정 네트워킹. 여러 서브넷에 포드를 배치하거나 [포드에 대한 별도의 서브넷 및 보안 그룹](create-node-class.md#pod-subnet-selector)을 사용하여 노드 트래픽에서 포드를 독점적으로 분리할 수 있습니다.
+ 웜 IP, 웜 접두사, 웜 ENI 구성
+ 최소 IP 대상 구성
+ 오픈 소스 AWS VPC CNI에서 지원하는 기타 구성
+ conntrack 타이머 사용자 지정과 같은 네트워크 정책 구성(기본값은 300초)
+ CloudWatch로 네트워크 이벤트 로그 내보내기
### 네트워크 리소스 관리
EKS 자동 모드는 네트워킹 구성에 대한 NodeClass 리소스를 모니터링하여 접두사, IP 주소 지정 및 네트워크 인터페이스 관리를 처리합니다. 서비스는 여러 키 작업을 자동으로 수행합니다.
**접두사 위임**
EKS Auto Mode는 기본적으로 포드 네트워킹에 접두사 위임(/28 접두사)을 사용하고 예약된 포드 수에 따라 조정되는 사전 정의된 웜 IP 리소스 풀을 유지 관리합니다. 포드 서브넷 조각화가 감지되면 Auto Mode는 보조 IP 주소(/32)를 프로비저닝합니다. 이 기본 포드 네트워킹 알고리즘으로 인해 Auto Mode는 인스턴스 유형별로 지원되는 ENI 및 IP 수를 기반으로(최악의 조각화 사례를 가정함) 노드당 최대 포드 수를 계산합니다. 지원되는 최대 ENI 및 IP 수에 대한 자세한 내용은 EC2 사용 설명서의 [네트워크 인터페이스당 최대 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)를 참조하세요. 최신 세대(Nitro v6 이상)의 인스턴스 패밀리에서는 일반적으로 인스턴스 유형당 ENI 및 IP가 늘었으며, Auto Mode는 적절히 최대 포드 계산을 조정합니다.
IPv6 클러스터의 경우 접두사 위임만 사용되며, Auto Mode는 항상 노드당 포드 110개의 최대 포드 제한을 사용합니다.
**휴지 기간 관리**
이 서비스는 더 이상 사용되지 않는 접두사 또는 보조 IPv4 주소에 대한 휴지 기간 풀을 구현합니다. 휴지 기간이 만료되면 이러한 리소스가 VPC로 다시 릴리스됩니다. 그러나 포드가 휴지 기간 동안 이러한 리소스를 재사용하는 경우, 해당 리소스는 휴지 기간 풀에서 복원됩니다.
**IPv6 지원**
IPv6 클러스터의 경우 EKS 자동 모드는 프라이머리 네트워크 인터페이스에서 노드당 `/80` IPv6 접두사를 프로비저닝합니다. `podSubnetSelectorTerms`를 사용하는 경우 접두사는 대신 포드 서브넷의 보조 네트워크 인터페이스에 할당됩니다.
또한 서비스는 모든 네트워크 인터페이스의 적절한 관리 및 폐영역 회수를 보장합니다.
## 로드 밸런싱
서비스 및 수신 리소스에 대한 주석을 사용하여 EKS Auto Mode에서 프로비저닝한 AWS Elastic Load Balancer를 구성합니다.
자세한 내용은 [IngressClass를 생성하여 Application Load Balancer 구성](auto-configure-alb.md) 또는 [서비스 주석을 사용하여 Network Load Balancer 구성](auto-configure-nlb.md) 섹션을 참조하세요.
### EKS Auto Mode를 사용한 로드 밸런싱 고려 사항
+ 기본 대상 지정 모드는 인스턴스 모드가 아닌 IP 모드입니다.
+ EKS Auto Mode는 Network Load Balancer에 대한 보안 그룹 모드만 지원합니다.
+ AWS는 자체 관리형 AWS 로드 밸런서 컨트롤러에서 EKS Auto Mode의 관리로 로드 밸런서 마이그레이션을 지원하지 않습니다.
+ `TargetGroupBinding` 사양의 `networking.ingress.ipBlock` 필드는 지원되지 않습니다.
+ 워커 노드가 사용자 지정 보안 그룹(`eks-cluster-sg- ` 명명 패턴 아님)을 사용하는 경우 클러스터 역할에 추가 IAM 권한이 필요합니다. 기본 EKS 관리형 정책은 EKS가 `eks-cluster-sg-`라는 보안 그룹만 수정하도록 허용합니다. 사용자 지정 보안 그룹을 수정할 권한이 없는 경우 EKS는 ALB/NLB 트래픽이 포드에 도달하도록 허용하는 필수 수신 규칙을 추가할 수 없습니다.
#### CoreDNS 고려 사항
EKS Auto Mode는 클러스터 내에서 DNS 확인을 제공하기 위해 기존 CoreDNS 배포를 사용하지 않습니다. 대신 Auto Mode 노드는 각 노드에서 직접 시스템 서비스로 실행되는 CoreDNS를 활용합니다. 기존 클러스터를 자동 모드로 전환하는 경우 워크로드가 Auto Mode 노드로 이전되면 클러스터에서 CoreDNS 배포를 제거할 수 있습니다.
**중요**
Auto Mode 노드와 비Auto Mode 노드로 클러스터를 유지 관리하려는 경우 CoreDNS 배포를 유지해야 합니다. 비Auto Mode 노드에서는 Auto Mode가 제공하는 노드 수준의 DNS 서비스에 액세스할 수 없으므로 DNS 확인을 위해 기존 CoreDNS 포드에 의존합니다.
# EKS Auto Mode의 관찰성
이 장을 사용하여 Amazon EKS Auto Mode 클러스터의 관찰성 옵션에 대해 알아봅니다.
**Topics**
+ [EKS Auto에 대한 AWS 관리형 구성 요소 로그에 액세스](auto-managed-component-logs.md)
# EKS Auto에 대한 AWS 관리형 구성 요소 로그에 액세스
EKS Auto Mode에서 AWS 관리형 구성 요소 로그에 액세스하여 클러스터 작업을 더 깊이 관찰할 수 있습니다. EKS Auto Mode는 다음 소스에 대한 로그를 지원합니다.
+ 컴퓨팅 오토 스케일링 - Karpenter
+ 블록 스토리지 - EBS CSI
+ 로드 밸런싱 - AWS 로드 밸런서 컨트롤러
+ 포드 네트워킹 - VPC CNI IP 주소 관리
로그는 선택한 [전송 대상](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)으로 전송할 수 있습니다.
EKS Auto 클러스터를 생성할 때 컨트롤 플레인 로깅(API 서버, 감사, 인증자, 컨트롤러 관리자, 스케줄러)을 활성화하는 옵션이 제공됩니다. EKS 자동 관리형 구성 요소 로그(예: 컴퓨팅, 블록 스토리지, 로드 밸런싱 및 IPAM)는 로그 전송을 통해 별도의 구성이 필요합니다.
## 로그 전송 설정
EKS Auto Mode 클러스터에 대한 AWS 관리형 구성 요소 로그 전송을 구성하려면 Amazon CloudWatch Logs API를 사용합니다. 자세한 설정 지침은 Amazon CloudWatch Logs 사용 설명서의 [Enabling logging from AWS services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)를 참조하세요. 각 Auto Mode 기능을 개별 CloudWatch Vended Logs 전송 소스로 구성할 수 있으므로 액세스하려는 로그를 선택할 수 있습니다.
EKS Auto Mode는 다음 로그 유형을 지원합니다.
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Amazon CloudWatch API 사용
로깅을 설정하려면 다음과 같은 3단계가 필요합니다.
1. CloudWatch PutDeliverySource API를 사용하여 기능에 대한 전송 소스 생성
1. PutDeliveryDestination을 사용하여 전송 대상 생성
1. CreateDelivery를 사용하여 소스와 대상을 연결하기 위한 전송 생성
CloudWatch PutDeliveryDestination API의 deliveryDestinationConfiguration 객체를 사용하여 Auto Mode 로그 대상의 세부 정보를 구성할 수 있습니다. CloudWatch 로그 그룹, S3 버킷 또는 Kinesis Data Firehose 전송 스트림의 ARN을 사용합니다.
여러 전송을 생성하여 여러 대상으로 로그를 전송하도록 단일 Auto Mode 기능(전송 소스)을 구성할 수 있습니다. 또한 여러 전송을 생성하여 동일한 전송 대상으로 로그를 전송하도록 여러 전송 소스를 구성할 수도 있습니다.
### IAM 권한
선택한 대상에 따라 성공적인 로그 전송을 위해 CloudWatch 로그 그룹, S3 버킷 및 Kinesis Data Firehose에 대한 IAM 정책 또는 역할을 구성해야 할 수도 있습니다. 또한 여러 AWS 계정에서 로그를 전송하는 경우 PutDeliveryDestinationPolicy API를 사용하여 대상으로의 전송을 허용하는 IAM 정책을 구성해야 합니다. 자세한 내용은 [CloudWatch Vended Logs 권한 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)를 참조하세요.
## 로그 확인
로그 전송이 구성되면 로그가 지정된 대상으로 전송됩니다. 로그에 액세스하는 방법은 다음과 같이 선택한 대상 유형에 따라 다릅니다.
+ **CloudWatch Logs** - CloudWatch Logs 콘솔에서 로그 보기, AWS CLI 명령 사용 또는 CloudWatch Logs Insights를 사용한 쿼리
+ **Amazon S3** - S3 콘솔, AWS CLI 또는 Amazon Athena와 같은 분석 도구를 통해 S3 버킷의 객체로 로그에 액세스
+ **Amazon Data Firehose** - 로그가 구성된 Firehose 대상(예: S3, OpenSearch Service, Redshift 등)으로 스트리밍됨
## 가격 책정
CloudWatch Vended Logs 요금은 선택한 전송 대상에 따라 로그 전송 및 스토리지에 적용됩니다. CloudWatch Vended Logs를 사용하면 표준 CloudWatch Logs에 비하여 저렴한 가격으로 기본 제공 AWS 인증 및 권한 부여를 통해 신뢰할 수 있고 안전한 방식으로 로그를 전송할 수 있습니다. 자세한 내용은 [CloudWatch 요금 페이지의 Vended Logs 섹션](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
### 관련 리소스
+ [Amazon EKS 컨트롤 영역 로깅](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ CloudWatch Logs API 참조의 [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)
+ CloudWatch Logs API 참조의 [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)
+ CloudWatch Logs API 참조의 [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)
# EKS Auto Mode 문제 해결
EKS Auto Mode를 사용하면 AWS가 AWS 계정의 EC2 인스턴스에 대해 더 많은 책임을 집니다. EKS는 노드의 컨테이너 런타임, 노드의 운영 체제, 특정 컨트롤러에 대한 책임을 집니다. 여기에는 블록 스토리지 컨트롤러, 로드 밸런싱 컨트롤러, 컴퓨팅 컨트롤러가 포함됩니다.
노드 문제를 해결하려면 AWS 및 Kubernetes API를 사용해야 합니다. 다음을 할 수 있습니다.
+ [노드 모니터링 에이전트](#auto-node-monitoring-agent)을 참조해 Kubernetes `NodeDiagnostic` 리소스를 사용하여 노드 로그를 검색합니다. 자세한 단계는 [kubectl 및 S3를 사용하여 관리형 노드에 대한 노드 로그 검색](auto-get-logs.md) 섹션을 참조하세요.
+ AWS EC2 CLI 명령 `get-console-output`을 사용하여 노드에서 콘솔 출력을 검색합니다. 자세한 단계는 [AWS EC2 CLI를 사용하여 EC2 관리형 인스턴스에서 콘솔 출력 가져오기](#auto-node-console) 섹션을 참조하세요.
+ Kubernetes *디버깅 컨테이너*를 사용하여 노드 로그를 검색합니다. 자세한 단계는 [*디버그 컨테이너*와 `kubectl` CLI를 사용하여 노드 로그 가져오기](#auto-node-debug-logs) 섹션을 참조하세요.
**참고**
EKS Auto Mode는 EC2 관리형 인스턴스를 사용합니다. SSH를 포함하여 EC2 관리형 인스턴스에 직접 액세스할 수 없습니다.
EKS 자동 모드 구성 요소와 관련된 해결 방법이 있는 다음과 같은 문제가 있을 수 있습니다.
+ 자동 모드 노드에 예약되지 않은 `Pending` 상태로 멈춘 포드. 해결 방법은 [포드가 자율 모드 노드로 예약되지 않음 문제 해결](#auto-troubleshoot-schedule) 섹션을 참조하세요.
+ 클러스터에 Kubernetes 노드로 조인하지 않는 EC2 관리형 인스턴스. 해결 방법은 [클러스터에 조인하지 않는 노드 문제 해결](#auto-troubleshoot-join) 섹션을 참조하세요.
+ EKS 자동 모드에 포함된 컨트롤러를 사용하는 `NodePools`, `PersistentVolumes` 및 `Services`의 오류 및 문제. 해결 방법은 [자동 모드에서 포함된 컨트롤러 문제 해결](#auto-troubleshoot-controllers) 섹션을 참조하세요.
+ 향상된 포드 보안으로 인해 포드 간에 볼륨을 공유할 수 없음. 해결 방법은 [포드 간 볼륨 공유](#auto-troubleshoot-share-pod-volumes) 섹션을 참조하세요.
다음 방법을 사용하여 EKS 자동 모드 구성 요소의 문제를 해결할 수 있습니다.
+ [AWS EC2 CLI를 사용하여 EC2 관리형 인스턴스에서 콘솔 출력 가져오기](#auto-node-console)
+ [*디버그 컨테이너*와 `kubectl` CLI를 사용하여 노드 로그 가져오기](#auto-node-debug-logs)
+ [AWS 콘솔에서 EKS Auto Mode와 연결된 리소스 보기](#auto-node-ec2-web)
+ [AWS 계정에서 IAM 오류 보기](#auto-node-iam)
+ [`VPC Reachability Analyzer`로 노드 연결 문제 탐지](#auto-node-reachability)
## 노드 모니터링 에이전트
EKS Auto Mode에는 Amazon EKS 노드 모니터링 에이전트가 포함되어 있습니다. 이 에이전트를 사용하여 노드에 관한 문제 해결 및 디버깅 정보를 볼 수 있습니다. 노드 모니터링 에이전트는 Kubernetes `events` 및 노드 `conditions`를 게시합니다. 자세한 내용은 [노드 상태 문제 감지 및 노드 자동 복구 활성화](node-health.md) 섹션을 참조하세요.
## AWS EC2 CLI를 사용하여 EC2 관리형 인스턴스에서 콘솔 출력 가져오기
이 절차는 부팅 시간 또는 커널 수준 문제를 해결하는 데 도움이 됩니다.
먼저 워크로드와 연결된 인스턴스의 EC2 인스턴스 ID를 확인해야 합니다. 둘째, AWS CLI를 사용하여 콘솔 출력을 검색합니다.
1. `kubectl`을 설치하고 클러스터에 연결했는지 확인합니다.
1. (선택 사항) Kubernetes 배포의 이름을 사용하여 연결된 포드를 나열합니다.
```
kubectl get pods -l app=
```
1. Kubernetes 포드의 이름을 사용하여 연결된 노드의 EC2 인스턴스 ID를 확인합니다.
```
kubectl get pod -o wide
```
1. EC2 인스턴스 ID를 사용하여 콘솔 출력을 검색합니다.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## *디버그 컨테이너*와 `kubectl` CLI를 사용하여 노드 로그 가져오기
EKS 자동 모드 노드에서 로그를 검색하는 데 권장되는 방법은 `NodeDiagnostic` 리소스를 사용하는 것입니다. 자세한 단계는 [kubectl 및 S3를 사용하여 관리형 노드에 대한 노드 로그 검색](auto-get-logs.md) 섹션을 참조하세요.
그러나 `kubectl debug node` 명령을 사용하여 인스턴스에서 라이브로 로그를 스트리밍할 수 있습니다. 이 명령은 디버깅하려는 노드에서 대화형으로 사용할 수 있는 새 포드를 시작합니다.
1. 디버그 컨테이너를 시작합니다. 다음 명령은 노드의 인스턴스 ID로 `i-01234567890123456`을 사용하고, `-it`는 대화형 사용을 위해 `tty`를 할당하고 `stdin`을 연결하고, kubeconfig 파일의 `sysadmin` 프로필을 사용합니다.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
예제 출력은 다음과 같습니다.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. 이제 쉘에서 `nsenter` 명령을 제공하는 `util-linux-core`를 설치할 수 있습니다. `nsenter`를 사용하여 호스트의 PID 1(`init`)의 탑재 네임스페이스를 입력하고 `journalctl` 명령을 실행하여 `kubelet`에서 로그를 스트리밍합니다.
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
보안을 위해 Amazon Linux 컨테이너 이미지는 기본적으로 많은 바이너리를 설치하지 않습니다. `yum whatprovides` 명령을 사용하여 지정된 바이너리를 제공하기 위해 설치해야 하는 패키지를 식별할 수 있습니다.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## AWS 콘솔에서 EKS Auto Mode와 연결된 리소스 보기
AWS 콘솔을 사용하여 EKS Auto Mode 클러스터와 연결된 리소스의 상태를 볼 수 있습니다.
+ [EBS 볼륨](https://console.aws.amazon.com/ec2/home#Volumes)
+ 태그 키(`eks:eks-cluster-name`)를 검색하여 EKS Auto Mode 볼륨 보기
+ [로드밸런서](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ 태그 키(`eks:eks-cluster-name`)를 검색하여 EKS Auto Mode 로드 밸런서 보기
+ [EC2 인스턴스](https://console.aws.amazon.com/ec2/home#Instances)
+ 태그 키(`eks:eks-cluster-name`)를 검색하여 EKS Auto Mode 인스턴스 보기
## AWS 계정에서 IAM 오류 보기
1. CloudTrail 콘솔로 이동
1. 왼쪽 탐색 창에서 '이벤트 기록' 선택
1. 오류 코드 필터 적용:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
EKS 클러스터와 관련된 오류를 찾습니다. 오류 메시지를 사용하여 EKS 액세스 항목, 클러스터 IAM 역할 또는 노드 IAM 역할을 업데이트합니다. EKS 자율 모드에 대한 권한이 있는 이러한 역할에 새 정책을 연결해야 할 수 있습니다.
## 포드가 자율 모드 노드로 예약되지 않음 문제 해결
포드가 자율 모드 노드로 예약되지 않은 경우 포드/배포 매니페스트에 `Pending`nodeSelector`nodeSelector`가 있는지 확인합니다. `nodeSelector`가 있는 경우 EKS 자동 모드에서 만든 노드에서 예약할 `eks.amazonaws.com/compute-type: auto`를 사용하고 있는지 확인합니다. EKS 자동 모드에서 사용하는 노드 레이블에 대한 자세한 내용은 [EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md) 섹션을 참조하세요.
## 클러스터에 조인하지 않는 노드 문제 해결
EKS 자동 모드는 클러스터 엔드포인트 클러스터 인증 기관(CA)을 포함하여 클러스터에 조인하는 데 필요한 올바른 정보로 새 EC2 인스턴스를 자동 구성합니다. 그러나 이러한 인스턴스는 여전히 EKS 클러스터에 노드로 조인하지 못할 수 있습니다. 클러스터에 조인하지 않은 인스턴스를 식별하려면 다음 명령을 실행하세요.
1. `kubectl get nodeclaim`를 실행하여 `Ready = False`인 `NodeClaims`를 확인합니다.
```
kubectl get nodeclaim
```
1. `kubectl describe nodeclaim `을 실행하고 **상태** 아래에서 노드가 클러스터에 조인하는 데 방해가 되는 문제를 찾습니다.
```
kubectl describe nodeclaim
```
**일반적인 오류 메시지:**
`Error getting launch template configs`
기본 클러스터 IAM 역할 권한으로 `NodeClass`에서 사용자 지정 태그를 설정하는 경우 이 오류가 수신될 수 있습니다. [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md)을(를) 참조하세요.
`Error creating fleet`
EC2 API에서 `RunInstances`를 직접적으로 호출하는 데 권한 부여 문제가 있을 수 있습니다. AWS CloudTrail에서 오류를 확인하고 [Amazon EKS Auto Mode 클러스터 IAM 역할](auto-cluster-iam-role.md)에서 필요한 IAM 권한을 확인합니다.
### `VPC Reachability Analyzer`로 노드 연결 문제 탐지
**참고**
VPC Reachability Analyzer에서 실행하는 각 분석에 대해 요금이 부과됩니다. 요금 세부 정보는 [Amazon VPC 요금](https://aws.amazon.com/vpc/pricing/)을 참조하세요.
인스턴스가 클러스터에 조인하지 못한 한 가지 이유는 인스턴스가 API 서버에 도달하지 못하게 하는 네트워크 연결 문제입니다. 이 문제를 진단하려면 [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)를 사용하여 클러스터에 조인하지 못한 노드와 API 서버 간의 연결을 분석할 수 있습니다. 두 가지 정보가 필요합니다.
+ 클러스터에 조인할 수 없는 노드의 **인스턴스 ID**
+ **Kubernetes API 서버 엔드포인트**의 IP 주소
**인스턴스 ID**를 가져오려면 클러스터에서 워크로드를 생성하여 EKS 자동 모드가 EC2 인스턴스를 시작하도록 해야 합니다. 또한 클러스터에 인스턴스 ID가 있는 `NodeClaim` 객체가 생성됩니다. `kubectl get nodeclaim -o yaml`을 실행하여 클러스터의 모든 `NodeClaims`를 인쇄합니다. 각 `NodeClaim`에 인스턴스 ID가 필드로 포함되고 providerID에 다시 포함됩니다.
```
kubectl get nodeclaim -o yaml
```
예제 출력은 다음과 같습니다.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
`kubectl get endpoint kubernetes -o yaml`을 실행하여 **Kubernetes API 서버 엔드포인트**를 확인할 수 있습니다. 주소는 주소 필드에 있습니다.
```
kubectl get endpoints kubernetes -o yaml
```
예제 출력은 다음과 같습니다.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
이 두 가지 정보를 사용하여 분석을 수행할 수 있습니다. 먼저 AWS Management Console에서 VPC Reachability Analyzer로 이동합니다.
1. ‘경로 생성 및 분석’을 클릭합니다.
1. 분석 이름을 입력합니다(예: '노드 조인 실패').
1. '소스 유형'에서 '인스턴스'를 선택합니다.
1. 실패한 노드의 인스턴스 ID를 '소스'로 입력합니다.
1. '경로 대상'에서 'IP 주소'를 선택합니다.
1. API 서버의 IP 주소 중 하나를 '대상 주소'로 입력합니다.
1. '추가 패킷 헤더 구성 섹션'을 확장합니다.
1. '대상 포트'로 443을 입력합니다.
1. 아직 선택하지 않은 경우 '프로토콜'을 TCP로 선택합니다.
1. ‘경로 생성 및 분석’을 클릭합니다.
1. 분석을 완료하는 데 몇 분 정도 걸릴 수 있습니다. 분석 결과에 연결 실패가 표시되는 경우 네트워크 경로에 실패 위치가 표시되므로 문제를 해결할 수 있습니다.
## 포드 간 볼륨 공유
EKS 자동 모드 노드는 동일한 노드에서 실행 중인 포드 간에 더 많은 격리를 제공하는 적용 모드의 SELinux로 구성됩니다. SELinux가 활성화되면 권한이 없는 대부분의 포드에 자동으로 자체 다중 범주 보안(MCS) 레이블이 적용됩니다. 이 MCS 레이블은 포드마다 고유하며 한 포드의 프로세스가 다른 포드나 호스트의 프로세스를 조작할 수 없도록 설계되었습니다. 레이블이 지정된 포드가 루트로 실행되고 호스트 파일 시스템에 액세스할 수 있더라도 파일을 조작하거나, 호스트에서 민감한 시스템 직접 호출을 수행하거나, 컨테이너 런타임에 액세스하거나, kubelet의 보안 암호 키 자료를 가져올 수 없습니다.
이로 인해 포드 간에 데이터를 공유하려고 할 때 문제가 발생할 수 있습니다. 예를 들어 액세스 모드가 `ReadWriteOnce`인 `PersistentVolumeClaim`은 여전히 여러 포드가 볼륨에 동시에 액세스하는 것을 허용하지 않습니다.
포드 간에 이러한 공유를 활성화하려면 포드의 `seLinuxOptions`를 사용하여 해당 포드에 동일한 MCS 레이블을 구성하면 됩니다. 이 예제에서는 포드에 세 가지 범주인 `c123,c456,c789`를 할당합니다. 이는 노드의 포드에 자동으로 할당된 범주와 충돌하지 않습니다. 두 가지 범주만 할당되기 때문입니다.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## 컨트롤 플레인 로그에서 Karpenter 이벤트 보기
컨트롤 플레인 로그가 활성화된 EKS 클러스터의 경우 로그를 쿼리하여 Karpenter의 작업 및 의사 결정 프로세스와 관련된 인사이트를 얻을 수 있습니다. 특히 노드 프로비저닝, 스케일링 및 종료와 관련된 EKS Auto Mode 문제를 해결하는 데 유용할 수 있습니다. 다음 CloudWatch Logs Insights 쿼리를 사용하여 Karpenter 관련 이벤트 보기:
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
이 쿼리는 kube-apiserver 감사 로그에서 특정 [Karpenter 관련 이벤트](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)를 필터링합니다. 이벤트에는 다양한 중단 상태, 예약 실패, 용량 문제 및 노드 관련 문제가 있습니다. 로그를 분석하면 다음에 관한 이해를 높일 수 있습니다.
+ Karpenter가 특정 작업을 수행하는 이유.
+ 적절한 노드 프로비저닝, 스케일링 또는 종료가 되지 않는 원인인 모든 문제.
+ 인스턴스 유형의 잠재적 용량 또는 호환성 문제.
+ 중단, 제거 또는 종료와 같은 노드 수명 주기 이벤트.
쿼리 사용:
1. CloudWatch 콘솔로 이동
1. 왼쪽 탐색 창에서 “Logs Insights” 선택
1. EKS 클러스터의 컨트롤 플레인 로그에 대한 로그 그룹 선택
1. 쿼리 편집기 창에 쿼리 붙여넣기
1. 필요한 경우 시간 범위 조정
1. 쿼리 실행
결과에 Karpenter 관련 이벤트의 타임라인이 표시되어 문제를 해결하고 클러스터에서 EKS Auto Mode의 동작을 이해하는 데 도움이 됩니다. 특정 노드에서 Karpenter 작업을 검토하려면 앞서 언급한 쿼리의 아래 줄에 인스턴스 ID를 지정하는 필터를 추가할 수 있습니다.
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**참고**
이 쿼리를 사용하려면 EKS 클러스터에서 컨트롤 플레인 로깅이 활성화되어야 합니다. 아직 활성화하지 않은 경우 [CloudWatch Logs에 컨트롤 플레인 로그 전송](control-plane-logs.md) 섹션을 참조하세요.
## 자동 모드에서 포함된 컨트롤러 문제 해결
컨트롤러에 문제가 있는 경우 다음을 조사해야 합니다.
+ 해당 컨트롤러와 연결된 리소스의 형식이 적절하고 유효한지 여부.
+ AWS IAM 및 Kubernetes RBAC 리소스가 클러스터에 대해 올바르게 구성되었는지 여부. 자세한 내용은 [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md) 섹션을 참조하세요.
## 관련 리소스
고급 문제 해결 단계를 위해 AWS re:Post의 다음 문서를 사용합니다.
+ [EKS Auto-Mode에서 일반적인 조정 문제를 해결하려면 어떻게 해야 하나요?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [How do I troubleshoot custom nodepool and nodeclass provisioning issues in Amazon EKS Auto Mode?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [How do I troubleshoot EKS Auto Mode built-in node pools with Unknown Status?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# EKS 자동 모드 릴리스 정보 검토
이 페이지에서는 Amazon EKS 자동 모드에 대한 업데이트를 설명합니다. 이 페이지에서 기능, 버그 수정, 알려진 문제, 더 이상 지원되지 않는 기능에 대한 공지 사항을 주기적으로 확인할 수 있습니다.
이 특정 설명서 페이지의 모든 소스 파일 변경 사항에 대한 알림을 받으려면 RSS 리더를 사용하여 다음 URL을 구독하세요.
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2026년 2월 2일
**기능**: EKS Auto Mode IPv6 클러스터의 IPv6 포드에서 v4Egress 트래픽을 비활성화하기 위한 지원을 추가했습니다. 자세한 내용은 [IPv6 클러스터의 IPv6 포드에서 IPv4 송신 비활성화.](create-node-class.md#enableV4Egress) 섹션을 참조하세요.
## 2025년 12월 19일
**기능**: Auto 노드에 접두사 대신 보조 IP 주소를 프로비저닝하는 보조 IP 모드에 대한 지원을 추가했습니다. 이 모드에서는 하나의 보조 IP를 MinimalIPTarget으로 유지 관리하고 추가적인 보조 IP 또는 접두사를 워밍업할 필요가 없는 고객을 위해 IP 리소스를 절약합니다. 자세한 내용은 [노드 클래스 사양](create-node-class.md#auto-node-class-spec) 및 [포드에 대한 보조 IP 모드](create-node-class.md#secondary-IP-mode)(을)를 참조하세요.
## 2025년 11월 19일
**주요 사항**: 로컬 NVMe 스토리지를 사용하여 G, P 및 Trn 패밀리 인스턴스에 대해 Seekable OCI(SOCI) 병렬 기반 가져오기 및 압축 풀기 기능을 활성화했습니다. SOCI 병렬 기반 가져오기 및 압축 풀기는 항상 EKS Auto Mode를 사용하는 이러한 인스턴스 패밀리에 사용되며, 이를 활성화하기 위해 구성을 변경하지 않아도 됩니다. SOCI에 대한 자세한 내용은 [시작 블로그](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/)를 참조하세요.
## 2025년 11월 19일
**주요 사항**: 고정된 수의 노드를 유지 관리하는 정적 용량 노드 풀에 대한 지원을 추가했습니다. 자세한 내용은 [EKS Auto Mode에서 정적 용량 노드 풀](auto-static-capacity.md) 섹션을 참조하세요.
## 2025년 10월 23일
**주요 사항:** 이제 미국 리전에 클러스터가 있는 사용자는 NodeClass 정의에 `spec.advancedSecurity.fips`를 지정하여 FIPS 호환 AMI 사용을 요청할 수 있습니다.
## 2025년 10월 1일
**주요 사항:** 이제 EKS Auto Mode는 AWS 로컬 영역으로의 노드 배포를 지원합니다. 자세한 내용은 [로컬 영역에 EKS Auto Mode 노드 배포](auto-local-zone.md) 섹션을 참조하세요.
## 2025년 9월 30일
**주요 사항:** instanceProfile에 대한 지원을 `spec.role` 필드에서 상호 배타적인 NodeClass `spec.instanceProfile`에 추가했습니다.
## 2025년 9월 29일
현재 DRA는 EKS Auto Mode에서 지원되지 않습니다.
## 2025년 9월 10일
**부수적 사항:** 이제 Auto Mode 컴퓨팅 컨트롤러에서 실행된 이벤트는 `karpenter` 대신 `eks-auto-mode/compute` 이름을 사용합니다.
## 2025년 8월 24일
**버그 수정:** 대문자가 포함된 사용자 지정 도메인 이름으로 DHCP 옵션 세트를 사용한 VPC의 경우 유효하지 않은 호스트 이름을 생성하여 노드가 클러스터에 조인하지 못하게 됩니다. 이 문제는 해결되었으며 이제 대문자가 포함된 도메인 이름이 올바르게 작동합니다.
## 2025년 8월 15일
**버그 수정:** 이제 Pod Identity 에이전트는 IPv4 EKS 클러스터의 IPv4 링크 로컬 주소에서만 수신 대기하여 포드가 IPv6 주소에 도달할 수 없는 문제를 방지합니다.
## 2025년 8월 6일
**기능:** EKS Auto Mode 노드에 퍼블릭 IP 주소가 할당되지 않도록 하는 데 사용할 수 있는 NodeClass `spec.advancedNetworking.associatePublicIPAddress`에 새 구성 추가
## 2025년 6월 30일
**기능:** 이제 자동 모드 NodeClass는 구성된 사용자 지정 KMS 키를 사용하여 읽기/쓰기 데이터 볼륨 외에 인스턴스의 읽기 전용 루트 볼륨을 암호화합니다. 이전에는 사용자 지정 KMS 키가 데이터 볼륨 암호화에만 사용되었습니다.
## 2025년 6월 20일
**기능:** EC2 온디맨드 용량 예약(ODCR)으로 워크로드 배포 제어를 지원합니다. 이를 통해 NodeClass에 선택적 키인 `capacityReservationSelectorTerms`가 추가되어 워크로드에서 사용할 ODCR을 명시적으로 제어할 수 있습니다. 자세한 내용은 [EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어](auto-odcr.md) 섹션을 참조하세요.
## 2025년 6월 13일
**기능:** `NodeClass`에서 별도의 포드 서브넷 지원. 포드의 서브넷과 보안 그룹을 설정하기 위해 선택적 키 ``podSubnetSelectorTerms`와 `podSecurityGroupSelectorTerms`가 추가되었습니다. 자세한 내용은 [포드에 대한 별도의 서브넷 및 보안 그룹](create-node-class.md#pod-subnet-selector) 섹션을 참조하세요.
## 2025년 4월 30일
**기능:** `NodeClass`에서 순방향 네트워크 프록시를 지원합니다. 이로 인해 HTTPS 프록시를 설정하는 선택적 키 `advancedNetworking`이 추가됩니다. 자세한 내용은 [노드 클래스 사양](create-node-class.md#auto-node-class-spec) 섹션을 참조하세요.
## 2025년 4월 18일
**기능:** 유니캐스트 DNS를 통해 .local 도메인(일반적으로 멀티캐스트 DNS용으로 예약됨)을 확인할 수 있도록 지원합니다.
## 2025년 4월 11일
**기능:** `NodeClass`에 `certificateBundles`와 `ephemeralStorage.kmsKeyID`가 추가되었습니다. 자세한 내용은 [노드 클래스 사양](create-node-class.md#auto-node-class-spec) 섹션을 참조하세요.
**기능:** 이미지 풀 속도가 개선되었습니다. 더 빠른 이미지 압축 해제를 활용할 수 있는 로컬 인스턴스 스토리지가 있는 인스턴스 유형의 경우 특히 그렇습니다.
**버그 수정:** 시작 즉시 노드로 예약하는 포드에 대해 FailedCreatePodSandBox(‘다이얼링 중 오류 발생: dial tcp 127.0.0.1:50051: connect: connection refused’)가 가끔 발생하는 경합 상태가 해결되었습니다.
## 2025년 4월 4일
**기능:** `registryPullQPS`를 5에서 25로 늘리고 `registryBurst`를 10에서 50으로 늘려 클라이언트가 강제로 적용하는 이미지 풀 스로틀링을 줄입니다(`Failed to pull image xyz: pull QPS exceeded`).
## 2025년 3월 31일
**버그 수정:** 코어 DNS 포드가 자동 모드 노드에서 실행 중일 때 노드의 포드에서 보내는 DNS 쿼리가 노드 로컬 DNS 서버가 아닌 해당 코어 DNS 포드에 도달하는 문제를 해결합니다. 자동 모드 노드의 포드에서 보내는 DNS 쿼리는 항상 노드 로컬 DNS로 갑니다.
## 2025년 3월 21일
**버그 수정:** 이제 클러스터에 `kube-dns` 서비스가 설치되어 있지 않아도 자동 모드 노드가 `kube-dns.kube-system.svc.cluster.local`을 올바르게 확인합니다. GitHub 문제 [\$12546](https://github.com/aws/containers-roadmap/issues/2546)을 해결합니다.
## 2025년 3월 14일
**기능**: `IPv6` 클러스터에서 `IPv4` 송신이 활성화되었습니다. `IPv6` 자동 모드 클러스터에서 송신되는 `IPv4` 트래픽은 이제 노드 프라이머리 ENI의 `v4` 주소로 자동 변환됩니다.