**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# Amazon EKS 클러스터 수명 주기 및 구성
이 섹션에서는 Kubernetes 클러스터의 전체 수명 주기 관리와 이를 구성하는 다양한 방법에 관한 심층적인 지침을 제공합니다. 클러스터 생성, 클러스터 상태 모니터링, Kubernetes 버전 업데이트, 클러스터 삭제를 다룹니다. 또한 엔드포인트 액세스 구성, Windows 지원 활성화/비활성화, 프라이빗 클러스터 설정, 오토 스케일링 구현, 다중 AZ 설정에서 트래픽 리디렉션을 위한 영역 전환으로 복원력 개선 방법에 관한 고급 주제도 포함되어 있습니다.
**Topics**
+ [
# Amazon EKS Auto Mode 클러스터 생성
](create-cluster-auto.md)
+ [
# Amazon EKS 클러스터 생성
](create-cluster.md)
+ [
# Amazon EKS 프로비저닝된 컨트롤 플레인
](eks-provisioned-control-plane.md)
+ [
# 클러스터 인사이트를 사용한 Kubernetes 버전 업그레이드 준비 및 잘못된 구성 문제 해결
](cluster-insights.md)
+ [
# 기존 클러스터를 새 Kubernetes 버전으로 업데이트
](update-cluster.md)
+ [
# 클러스터 삭제
](delete-cluster.md)
+ [
# 클러스터 API 서버 엔드포인트
](cluster-endpoint.md)
+ [
# EKS 클러스터에 Windows 노드 배포
](windows-support.md)
+ [
# Windows 지원 사용 중지
](disable-windows-support.md)
+ [
# 인터넷 액세스가 제한된 프라이빗 클러스터 배포
](private-clusters.md)
+ [
# Karpenter 및 Cluster Autoscaler를 사용한 클러스터 컴퓨팅 규모 조정
](autoscaling.md)
+ [
# Amazon EKS에서 Amazon Application Recovery Controller(ARC)의 영역 전환에 대해 알아보기
](zone-shift.md)
+ [
# 손상된 가용 영역을 방지하기 위해 EKS 영역 전환 활성화
](zone-shift-enable.md)
# Amazon EKS Auto Mode 클러스터 생성
이 주제에서는 고급 구성 옵션을 사용하여 Amazon EKS Auto Mode 클러스터를 생성하는 방법에 대한 자세한 지침을 제공합니다. 사전 조건, 네트워킹 옵션, 추가 기능 구성을 다룹니다. 이 프로세스에는 IAM 역할 설정, 클러스터 설정 구성, 네트워킹 파라미터 지정, 추가 기능 선택이 포함됩니다. 사용자는 AWS Management Console 또는 AWS CLI를 사용하여 클러스터를 생성할 수 있으며, 두 방법 모두에 대한 단계별 지침이 제공됩니다.
덜 복잡한 설정 프로세스를 원하는 사용자의 경우 간소화된 클러스터 생성 단계는 다음을 참조하세요.
+ [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)
이 고급 구성 가이드는 EKS Auto Mode 클러스터 설정을 보다 세밀하게 제어해야 하고 Amazon EKS 개념 및 요구 사항을 잘 알고 있는 사용자를 대상으로 합니다. 고급 구성을 진행하기 전에 모든 사전 요구 사항을 충족하고 EKS Auto Mode 클러스터의 네트워킹 및 IAM 요구 사항을 철저히 이해해야 합니다.
EKS Auto Mode에는 추가 IAM 권한이 필요합니다. 자세한 내용은 다음을 참조하세요.
+ [EKS Auto Mode 클러스터에 대한 IAM 역할](automode-get-started-cli.md#auto-mode-create-roles)
+ [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md)
**참고**
EKS Auto Mode 없이 클러스터를 생성하려면 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요.
이 주제에서는 고급 구성을 다룹니다. EKS Auto Mode를 시작하려면 [Amazon EKS 자율 모드에서 클러스터 생성](create-auto.md) 섹션을 참조하세요.
## 사전 조건
+ [Amazon EKS 요구 사항](network-reqs.md)을 충족하는 기존 VPC 및 서브넷 보유. 프로덕션 용도로 클러스터를 배포하기 전에 VPC 및 서브넷 요구 사항을 충분히 이해하는 것이 좋습니다. VPC 및 서브넷이 없는 경우 [Amazon EKS 제공 AWS CloudFormation 템플릿](creating-a-vpc.md)을 사용하여 생성할 수 있습니다.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version`을 사용합니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요.
+ EKS 및 IAM 리소스를 생성하고 수정할 권한이 있는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)입니다.
## 클러스터 생성 - AWS 콘솔
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. **클러스터 추가**를 선택하고 **생성**을 선택합니다.
1. *구성 옵션*에서 **사용자 지정 구성**을 선택합니다.
+ 이 주제에서는 사용자 지정 구성을 다룹니다. 빠른 구성에 대한 자세한 내용은 [AWS Management Console을 사용하여 EKS 자동 모드 클러스터 생성](automode-get-started-console.md) 섹션을 참조하세요.
1. **EKS Auto Mode 사용**이 활성화되어 있는지 확인합니다.
+ 이 주제에서는 EKS Auto Mode를 사용하여 클러스터를 생성하는 방법을 다룹니다. EKS Auto Mode 없이 클러스터를 생성하는 방법에 관한 자세한 내용은 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요.
1. **클러스터 구성** 페이지에서 다음 필드를 입력합니다.
+ **이름** - 클러스터의 이름 이름에는 영숫자(대소문자 구분)와 하이픈, 밑줄만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
+ **클러스터 IAM 역할**-생성한 Amazon EKS 클러스터 IAM 역할을 선택하여 Kubernetes 컨트롤 플레인이 사용자 대신 AWS 리소스를 관리하게 할 수 있습니다. 이전에 EKS Auto Mode에 대한 클러스터 IAM 역할을 생성하지 않은 경우 **권장 역할 생성** 버튼을 선택하여 IAM 콘솔에서 필요한 권한을 가진 역할을 생성합니다.
+ **Kubernetes 버전(Kubernetes version)** - 클러스터에 대해 사용할 Kubernetes 버전 이전 버전이 필요한 경우가 아니면 최신 버전을 선택하는 것이 좋습니다.
+ **업그레이드 정책** - 클러스터에 설정하려는 Kubernetes 버전 정책입니다. 클러스터가 표준 지원 버전에서만 실행되게 하려면 **표준**을 선택할 수 있습니다. 버전에 대한 표준 지원이 종료될 때 클러스터가 확장 지원을 시작하게 하려면 **확장**을 선택할 수 있습니다. 현재 확장 지원 중인 Kubernetes 버전을 선택한 경우에는 표준 지원을 옵션으로 선택할 수 없습니다.
1. 클러스터 구성 페이지의 **Auto Mode Compute** 섹션에 다음 필드를 입력합니다.
+ **노드 풀**-노드 풀에서 빌드를 사용할지 여부를 결정합니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
+ **노드 IAM 역할**-내장 노드 풀을 활성화하는 경우 노드 IAM 역할을 선택해야 합니다. EKS Auto Mode는 이 역할을 새 노드에 할당합니다. 클러스터가 생성된 후에는 이 값을 변경할 수 없습니다. 이전에 EKS Auto Mode에 대한 노드 IAM 역할을 생성하지 않은 경우 권장 역할 생성 버튼을 선택하여 필요한 권한을 가진 역할을 생성합니다. 이에 대한 자세한 내용은 [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md) 섹션을 참조하세요.
1. 클러스터 구성 페이지의 **클러스터 액세스** 섹션에 다음 필드를 입력합니다.
+ **부트스트랩 클러스터 관리자 액세스**-클러스터 생성자는 자동으로 Kubernetes 관리자입니다. 이를 비활성화하려면 **클러스터 관리자 액세스 허용 안 함**을 선택합니다.
+ **클러스터 인증 모드**-EKS Auto Mode에는 EKS API 인증 모드인 EKS 액세스 항목이 필요합니다. 필요에 따라 **EKS API 및 ConfigMap**을 선택하여 `ConfigMap` 인증 모드를 활성화할 수 있습니다.
1. 클러스터 구성 페이지에서 나머지 필드를 입력합니다.
+ **비밀 암호화(Secrets encryption)** - (선택 사항) KMS 키를 사용하여 Kubernetes 비밀의 비밀 암호화를 사용 설정하도록 선택합니다. 클러스터를 생성한 후에도 이 기능을 사용 설정할 수 있습니다. 이 기능을 사용 설정하기 전에 [기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화](enable-kms.md)의 정보를 숙지해야 합니다.
+ **ARC 영역 전환**-EKS Auto Mode는 Arc 영역 전환을 지원하지 않습니다.
+ **태그**-(선택사항) 클러스터에 태그를 추가합니다. 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **네트워킹 지정** 페이지에서 다음 필드의 값을 선택합니다.
+ **VPC**-클러스터를 생성하려면 [Amazon EKS VPC 요구 사항](network-reqs.md#network-requirements-vpc)을 충족하는 기존 VPC를 선택합니다. VPC를 선택하기 전에 [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md)의 요구 사항 및 고려 사항 모두를 숙지하는 것이 좋습니다. 클러스터 생성 후에는 사용하려는 VPC를 변경할 수 없습니다. 목록에 기존 VPC가 없는 경우 먼저 VPC를 생성해야 합니다. 자세한 내용은 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md) 섹션을 참조하세요.
+ **서브넷**-기본적으로 이전 필드에서 지정한 VPC에서 사용 가능한 모든 서브넷이 사전 선택됩니다. 두 개 이상을 선택해야 합니다.
선택한 서브넷은 [Amazon EKS 서브넷 요구 사항](network-reqs.md#network-requirements-subnets)을 충족해야 합니다. 서브넷을 선택하기 전에 [Amazon EKS VPC 및 서브넷 요구 사항 및 고려 사항](network-reqs.md) 모두를 숙지하는 것이 좋습니다.
**보안 그룹** – (선택사항) 생성하는 네트워크 인터페이스에 Amazon EKS가 연결하려는 보안 그룹을 하나 이상 지정합니다.
보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다.
+ **클러스터 IP 주소 패밀리 선택** - **IPv4**와 **IPv6** 중 하나를 선택할 수 있습니다.
Kubernetes는 기본적으로 포드와 서비스에 `IPv4` 주소를 할당합니다. `IPv6` 제품군 사용을 결정하기 전에 [VPC 요구 사항 및 고려 사항](network-reqs.md#network-requirements-vpc), [서브넷 요구 사항 및 고려 사항](network-reqs.md#network-requirements-subnets), [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 항목의 모든 고려 사항과 요구 사항을 숙지하고 있는지 확인하세요. `IPv6` 패밀리를 선택하면 `IPv4` 패밀리처럼 Kubernetes가 `IPv6` 서비스 주소를 할당할 주소 범위를 지정할 수 없습니다. Kubernetes는 고유한 로컬 주소 범위(`fc00::/7`)에서 서비스 주소를 할당합니다.
+ (선택 사항) **Kubernetes 서비스 IP 주소 범위 구성(Configure Kubernetes Service IP address range)**을 선택하고 **서비스 `IPv4` 범위(Service range)**를 지정합니다.
자체 범위를 지정하면 VPC에 피어링되거나 연결된 Kubernetes 서비스와 기타 네트워크 사이의 충돌을 방지할 수 있습니다. CIDR 표기법으로 범위를 입력합니다. 예를 들면 `10.2.0.0/16`입니다.
CIDR 블록은 다음 요구 사항을 충족해야 합니다.
+ 다음 범위 `10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16` 중 하나 내에 있어야 합니다..
+ 최소 크기는 `/24`고 최대 크기는 `/12`입니다.
+ Amazon EKS 리소스의 VPC 범위와 겹치지 않습니다.
이 옵션은 `IPv4` 주소 패밀리를 사용할 때 및 클러스터 생성 시에만 지정할 수 있습니다. 이 옵션을 지정하지 않은 경우 Kubernetes는 `10.100.0.0/16` 또는 `172.20.0.0/16` CIDR 블록 중 하나에서 서비스 IP 주소를 할당합니다.
+ **클러스터 엔드포인트 액세스**에서 옵션을 선택합니다. 클러스터를 생성한 후에는 이 옵션을 변경할 수 있습니다. 기본값이 아닌 옵션을 선택하기 전에 옵션과 그 의미를 숙지해야 합니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. (선택사항) **관찰성 구성** 페이지에서 설정할 **지표** 및 **컨트롤 플레인 로깅** 옵션을 선택합니다. 기본적으로 각 로그 유형은 해제되어 있습니다.
+ Prometheus 지표 옵션에 자세한 내용은 [1단계: Prometheus 지표 켜기](prometheus.md#turn-on-prometheus-metrics) 섹션을 참조하세요.
+ **컨트롤 플레인 로깅** 옵션에 대한 자세한 내용은 [CloudWatch Logs에 컨트롤 플레인 로그 전송](control-plane-logs.md) 섹션을 참조하세요.
+ 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **추가 기능 선택** 페이지에서 클러스터에 추가할 추가 기능을 선택합니다. 필요한 만큼 **Amazon EKS 애드온** 및 **AWS 마켓플레이스 애드온**을 선택할 수 있습니다. 설치하려는 **AWS 마켓플레이스 추가 기능**이 목록에 없는 경우 페이지 번호를 클릭하여 추가 페이지 결과를 확인하거나 검색창에 텍스트를 입력하여 사용 가능한 **AWS 마켓플레이스 추가 기능**을 검색할 수 있습니다. **카테고리**, **공급업체** 또는 **가격 모델**별로 필터링한 다음 검색 결과 중에서 추가 기능을 선택할 수도 있습니다. 클러스터를 생성할 때 [EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md)에 설명된 대로 EKS Pod Identity를 지원하는 추가 기능을 보고, 선택하고, 설치할 수 있습니다.
+ EKS Auto Mode는 특정 추가 기능을 자동화합니다. EKS 관리형 노드 그룹을 EKS Auto Mode 클러스터에 배포하려는 경우 **추가 Amazon EKS 추가 기능**을 선택하고 옵션을 검토합니다. CoreDNS 및 kube-proxy와 같은 추가 기능을 설치해야 할 수 있습니다. EKS는 이 섹션의 추가 기능만 자체 관리형 노드 및 노드 그룹에 설치합니다.
+ 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 설치할 버전을 선택합니다. 클러스터 생성 후 언제든지 최신 버전으로 업데이트할 수 있습니다.
EKS Pod Identity를 지원하는 추가 기능의 경우 콘솔을 사용하여 추가 기능에 대해 미리 채워진 이름, AWS 관리형 정책, 신뢰 정책에 따라 역할을 자동으로 생성할 수 있습니다. 지원되는 추가 기능에 기존 역할을 재사용하거나 새 역할을 생성할 수 있습니다. 콘솔을 사용하여 EKS Pod Identity를 지원하는 추가 기능에 대한 역할을 생성하는 단계는 [추가 기능 생성(AWS 콘솔)](creating-an-add-on.md#create_add_on_console) 섹션을 참조하세요. 추가 기능이 EKS Pod Identity를 지원하지 않는 경우 클러스터가 생성된 후 마법사를 사용하여 서비스 계정에 대한 IAM 역할(IRSA)을 생성하는 지침이 포함된 메시지가 표시됩니다.
클러스터 생성 후 각 추가 기능의 구성을 업데이트할 수 있습니다. 추가 기능 구성에 대한 자세한 내용은 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 섹션을 참조하세요. 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 이전 페이지에서 입력하거나 선택한 정보를 검토합니다. 변경해야 하는 경우 **편집**을 선택합니다 만족하는 경우 **생성**을 선택합니다. 클러스터가 프로비저닝되는 동안 **상태** 필드에는 **생성 중**이 표시됩니다.
**참고**
요청의 가용 영역 중 하나에 Amazon EKS 클러스터를 생성하는 데 충분한 용량이 없다는 오류가 표시될 수 있습니다. 이 경우 오류 출력에는 새 클러스터를 지원할 수 있는 가용 영역이 포함됩니다. 사용자 계정의 지원 가용 영역에 있는 2개 이상의 서브넷을 사용하여 클러스터를 다시 생성합니다. 자세한 내용은 [용량 부족](troubleshooting.md#ice) 섹션을 참조하세요.
클러스터 프로비저닝에는 몇 분 정도 걸립니다.
## 클러스터 생성-AWS CLI
다음 CLI 지침에서는 IAM 리소스 생성 및 클러스터 생성을 다룹니다.
### 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
```
### 클러스터 생성
1. 다음 명령을 사용하여 클러스터를 생성합니다. 명령을 실행하기 전에 다음과 같은 바꾸기를 합니다.
+ *region-code*를 클러스터를 생성할 AWS 리전으로 바꿉니다.
+ *my-cluster*를 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈, 밑줄만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
+ *1.30*를 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 바꿉니다.
+ *111122223333*을 계정 ID로 바꿉니다.
+ 클러스터 및 노드 역할에 대해 이름이 다른 IAM 역할을 생성한 경우 ARN을 교체합니다.
+ `subnetIds`의 값을 고유한 값으로 바꿉니다. 또한 추가 ID를 추가할 수 있습니다. 2개 이상의 서브넷 ID를 지정해야 합니다.
선택한 서브넷은 [Amazon EKS 서브넷 요구 사항](network-reqs.md#network-requirements-subnets)을 충족해야 합니다. 서브넷을 선택하기 전에 [Amazon EKS VPC 및 서브넷 요구 사항 및 고려 사항](network-reqs.md) 모두를 숙지하는 것이 좋습니다.
+ 보안 그룹 ID를 지정하지 않으려면 명령에서 `,securityGroupIds=sg-`을 제거합니다. 하나 이상의 보안 그룹 ID를 지정하려는 경우 `securityGroupIds`의 값을 고유한 값으로 바꿉니다. 또한 추가 ID를 추가할 수 있습니다.
보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**참고**
요청의 가용 영역 중 하나에 Amazon EKS 클러스터를 생성하는 데 충분한 용량이 없다는 오류가 표시될 수 있습니다. 이 경우 오류 출력에는 새 클러스터를 지원할 수 있는 가용 영역이 포함됩니다. 사용자 계정의 지원 가용 영역에 있는 2개 이상의 서브넷을 사용하여 클러스터를 다시 생성합니다. 자세한 내용은 [용량 부족](troubleshooting.md#ice) 섹션을 참조하세요.
다음은 필요한 경우 이전 명령에 추가해야 하는 선택 가능한 설정입니다. 클러스터 생성 후가 아닌 생성할 때만 이러한 옵션을 사용 설정할 수 없습니다.
+ Kubernetes가 서비스 IP 주소를 할당하는 `IPv4` Classless Inter-Domain Routing(CIDR) 블록을 지정하려는 경우 다음 명령에 `--kubernetes-network-config serviceIpv4Cidr=`을 추가하여 해당 블록을 지정해야 합니다.
자체 범위를 지정하면 VPC에 피어링되거나 연결된 Kubernetes 서비스와 기타 네트워크 사이의 충돌을 방지할 수 있습니다. CIDR 표기법으로 범위를 입력합니다. 예를 들면 `10.2.0.0/16`입니다.
CIDR 블록은 다음 요구 사항을 충족해야 합니다.
+ 다음 범위 `10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16` 중 하나 내에 있어야 합니다..
+ 최소 크기는 `/24`고 최대 크기는 `/12`입니다.
+ Amazon EKS 리소스의 VPC 범위와 겹치지 않습니다.
이 옵션은 `IPv4` 주소 패밀리를 사용할 때 및 클러스터 생성 시에만 지정할 수 있습니다. 이 옵션을 지정하지 않은 경우 Kubernetes는 `10.100.0.0/16` 또는 `172.20.0.0/16` CIDR 블록 중 하나에서 서비스 IP 주소를 할당합니다.
+ 클러스터를 생성하고 클러스터가 `IPv4` 주소 대신 포드와 서비스에 `IPv6` 주소를 할당하도록 하려면 다음 명령에 `--kubernetes-network-config ipFamily=ipv6`를 추가합니다.
Kubernetes는 기본적으로 포드와 서비스에 `IPv4` 주소를 할당합니다. `IPv6` 제품군 사용을 결정하기 전에 [VPC 요구 사항 및 고려 사항](network-reqs.md#network-requirements-vpc), [서브넷 요구 사항 및 고려 사항](network-reqs.md#network-requirements-subnets), [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 항목의 모든 고려 사항과 요구 사항을 숙지하고 있는지 확인하세요. `IPv6` 패밀리를 선택하면 `IPv4` 패밀리처럼 Kubernetes가 `IPv6` 서비스 주소를 할당할 주소 범위를 지정할 수 없습니다. Kubernetes는 고유한 로컬 주소 범위(`fc00::/7`)에서 서비스 주소를 할당합니다.
1. 클러스터를 프로비저닝하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 상태를 쿼리할 수 있습니다.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## 다음 단계
+ [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md)
+ [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md)
+ [클러스터에서 보안 암호 암호화 활성화](enable-kms.md)
+ [클러스터에서 로깅 구성](control-plane-logs.md)
+ [클러스터에 노드 추가](eks-compute.md)
# Amazon EKS 클러스터 생성
**참고**
이 주제에서는 EKS Auto Mode 없이 Amazon EKS 클러스터를 생성하는 방법을 다룹니다.
EKS Auto Mode 크러스터 생성 관련 지침은 [Amazon EKS Auto Mode 클러스터 생성](create-cluster-auto.md) 섹션을 참조하세요.
EKS Auto Mode를 시작하려면 [Amazon EKS 시작하기-EKS Auto Mode](getting-started-automode.md) 섹션을 참조하세요.
이 주제에서는 사용 가능한 옵션에 대한 개요와 Amazon EKS 클러스터를 생성할 때 고려해야 할 사항을 설명합니다. 온프레미스 인프라를 노드용 컴퓨팅으로 사용하여 클러스터를 생성해야 하는 경우 [하이브리드 노드를 사용하여 Amazon EKS 클러스터 생성](hybrid-nodes-cluster-create.md) 섹션을 참조하세요. Amazon EKS 클러스터를 처음 생성하는 경우 [Amazon EKS 시작하기](getting-started.md)의 가이드 중 한 가지를 따르는 것이 좋습니다. 이 가이드를 사용하면 사용 가능한 모든 옵션으로 확장하지 않고 간단한 기본 클러스터를 생성할 수 있습니다.
## 사전 조건
+ [Amazon EKS 요구 사항](network-reqs.md)을 충족하는 기존 VPC 및 서브넷 보유. 프로덕션 용도로 클러스터를 배포하기 전에 VPC 및 서브넷 요구 사항을 충분히 이해하는 것이 좋습니다. VPC 및 서브넷이 없는 경우 [Amazon EKS 제공 AWS CloudFormation 템플릿](creating-a-vpc.md)을 사용하여 생성할 수 있습니다.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용합니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 * AWS CloudShell 사용 설명서*의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ Amazon EKS 클러스터를 `create` 및 `describe` 할 수 있는 권한이 있는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal). 자세한 내용은 [Outpost에서 로컬 Kubernetes 클러스터 생성](security-iam-id-based-policy-examples.md#policy-create-local-cluster) 및 [모든 클러스터 나열 또는 설명](security-iam-id-based-policy-examples.md#policy-example2) 섹션을 참조하세요.
## 1단계: 클러스터 IAM 역할 만들기
1. 이미 클러스터 IAM 역할이 있거나 `eksctl`을 사용하여 클러스터를 생성하려는 경우 이 단계를 건너뛸 수 있습니다. 기본적으로 `eksctl`은 사용자를 위한 역할을 생성합니다.
1. 다음 명령을 실행하여 IAM 신뢰 정책 JSON 파일을 생성합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Amazon EKS 클러스터 IAM 역할을 생성합니다. 필요한 경우 *eks-cluster-role-trust-policy.json* 앞에 이전 단계에서 파일을 작성한 컴퓨터의 경로를 붙입니다. 명령은 사용자가 이전 단계에서 생성한 신뢰 정책을 역할에 연결합니다. [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)을 생성하려면 역할을 생성하는 IAM 보안 주체에 `iam:CreateRole` 작업(권한)을 할당해야 합니다.
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Amazon EKS 관리형 정책을 할당하거나 사용자 지정 정책을 생성할 수 있습니다. 사용자 지정 정책에서 사용해야 하는 최소 권한은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md)을(를) 참조하세요.
역할에 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json)라는 Amazon EKS 관리 정책을 연결합니다. IAM 정책을 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에 연결하려면 정책을 연결하는 보안 주체에 `iam:AttachUserPolicy` 또는 `iam:AttachRolePolicy`의 IAM 작업(권한) 중 하나를 할당해야 합니다.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### 서비스 연결 역할
Amazon EMR은 `AWSServiceRoleForAmazonEKS`라고 하는 서비스 연결 역할을 자동으로 생성합니다.
이 역할은 클러스터 IAM 역할에 추가되었습니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 이 역할을 통해 Amazon EKS는 계정의 클러스터를 관리할 수 있습니다. 자세한 내용은 [Amazon EKS 클러스터에 대한 역할 사용](using-service-linked-roles-eks.md) 섹션을 참조하세요.
EKS 클러스터를 생성하는 데 사용하는 IAM ID에는 서비스 연결 역할을 생성할 수 있는 권한이 있어야 합니다. 여기에는 `iam:CreateServiceLinkedRole` 권한이 포함되어 있습니다.
서비스 연결 역할이 아직 존재하지 않고 현재 IAM 역할에 클러스터를 생성할 수 있는 충분한 권한이 없는 경우 클러스터 생성 작업이 실패합니다.
## 2단계: 클러스터 생성
다음을 사용하여 클러스터를 만들 수 있습니다.
+ [`eksctl`](#step2-eksctl)
+ [AWS Management Console](#step2-console)
+ [AWS CLI](#step2-cli)
### 클러스터 생성 - eksctl
1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
1. 기본 AWS 리전에서 Amazon EKS 기본 Kubernetes 버전으로 Amazon EKS `IPv4` 클러스터를 생성합니다. 명령을 실행하기 전에 다음과 같은 바꾸기를 합니다.
1. *region-code*를 클러스터를 생성할 AWS 리전으로 바꿉니다.
1. *my-cluster*를 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
1. *1.35*를 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 바꿉니다.
1. 요구 사항을 충족하는 `vpc-private-subnets`의 값을 변경합니다. 또한 추가 ID를 추가할 수 있습니다. 2개 이상의 서브넷 ID를 지정해야 합니다. 퍼블릭 서브넷을 지정하려는 경우 `--vpc-private-subnets`을 `--vpc-public-subnets`으로 변경할 수 있습니다. 퍼블릭 서브넷에는 인터넷 게이트웨이에 대한 경로가 포함된 연결된 라우팅 테이블이 있지만 프라이빗 서브넷에는 연결된 라우팅 테이블이 없습니다. 가능하면 프라이빗 서브넷을 사용하는 것이 좋습니다.
선택한 서브넷은 [Amazon EKS 서브넷 요구 사항](network-reqs.md#network-requirements-subnets)을 충족해야 합니다. 서브넷을 선택하기 전에 [Amazon EKS VPC 및 서브넷 요구 사항 및 고려 사항](network-reqs.md) 모두를 숙지하는 것이 좋습니다.
1. 다음 명령을 실행합니다.
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
클러스터 프로비저닝에는 몇 분 정도 걸립니다. 클러스터가 생성되는 동안 여러 줄의 출력이 나타납니다. 출력의 마지막 줄은 다음 예제와 유사합니다.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. [3단계: kubeconfig 업데이트](#step3) 계속 진행
#### 선택적 설정
`eksctl`을 사용하여 클러스터를 생성할 때 지정할 수 있는 대부분의 옵션을 보려면 `eksctl create cluster --help` 명령을 사용합니다. 사용 가능한 옵션을 모두 확인하려면 `config` 파일을 사용할 수 있습니다. 자세한 내용은 `eksctl` 설명서에서 [config 파일 사용](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) 및 [config 파일 스키마](https://eksctl.io/usage/schema/) 부분을 참조하세요. GitHub에서 [구성 파일 예제](https://github.com/weaveworks/eksctl/tree/master/examples)를 찾을 수 있습니다.
다음은 필요한 경우 이전 명령에 추가해야 하는 선택 가능한 설정입니다. 클러스터 생성 후가 아닌 생성할 때만 이러한 옵션을 사용 설정할 수 없습니다. 이러한 옵션을 지정해야 하는 경우 [eksctl 구성 파일](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files)을 사용하여 클러스터를 생성한 다음 이전 명령을 사용하지 않고 설정을 지정해야 합니다.
+ 생성하는 네트워크 인터페이스에 Amazon EKS가 할당하는 보안 그룹을 하나 이상 지정하는 경우 [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup) 옵션을 지정합니다.
보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다.
+ 가 서비스 IP 주소를 할당하는 `IPv4` CIDR(Classless Inter-Domain Routing) 블록을 지정하려면 [serviceIPv4CIDR](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR) 옵션을 지정합니다.
자체 범위를 지정하면 VPC에 피어링되거나 연결된 Kubernetes 서비스와 기타 네트워크 사이의 충돌을 방지할 수 있습니다. CIDR 표기법으로 범위를 입력합니다. 예를 들면 `10.2.0.0/16`입니다.
CIDR 블록은 다음 요구 사항을 충족해야 합니다.
+ 다음 범위 `10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16` 중 하나 내에 있어야 합니다..
+ 최소 크기는 `/24`고 최대 크기는 `/12`입니다.
+ Amazon EKS 리소스의 VPC 범위와 겹치지 않습니다.
이 옵션은 `IPv4` 주소 패밀리를 사용할 때 및 클러스터 생성 시에만 지정할 수 있습니다. 이 옵션을 지정하지 않은 경우 Kubernetes는 `10.100.0.0/16` 또는 `172.20.0.0/16` CIDR 블록 중 하나에서 서비스 IP 주소를 할당합니다.
+ 클러스터를 만들 때 클러스터가 포드와 서비스에 `IPv4` 주소 대신 `IPv6` 주소를 할당하도록 하려면 [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily) 옵션을 지정하세요.
Kubernetes는 기본적으로 포드와 서비스에 `IPv4` 주소를 할당합니다. `IPv6` 패밀리를 사용하기로 결정하기 전에 [VPC 요구 사항 및 고려 사항](network-reqs.md#network-requirements-vpc), [서브넷 요구 사항 및 고려 사항](network-reqs.md#network-requirements-subnets), [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 주제의 모든 고려 사항 및 요구 사항을 숙지해야 합니다. `IPv6` 패밀리를 선택하면 `IPv4` 패밀리처럼 Kubernetes가 `IPv6` 서비스 주소를 할당할 주소 범위를 지정할 수 없습니다. Kubernetes는 고유한 로컬 주소 범위(`fc00::/7`)에서 서비스 주소를 할당합니다.
### 클러스터 생성 - AWS 콘솔
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. **클러스터 추가**를 선택하고 **생성**을 선택합니다.
1. **구성 옵션**에서 **사용자 지정 구성**을 선택합니다.
+ EKS Auto Mode를 사용하여 클러스터를 빠르게 생성하는 방법에 대한 자세한 내용은 [AWS Management Console을 사용하여 EKS 자동 모드 클러스터 생성](automode-get-started-console.md) 섹션을 참조하세요.
1. **EKS Auto Mode**에서 **EKS Auto Mode 사용**을 끕니다.
+ 사용자 지정 구성을 사용하여 EKS Auto Mode 클러스터를 생성하는 방법에 대한 자세한 내용은 [Amazon EKS Auto Mode 클러스터 생성](create-cluster-auto.md) 섹션을 참조하세요.
1. **클러스터 구성** 페이지에서 다음 필드를 입력합니다.
+ **이름** - 클러스터의 이름 이름에는 영숫자(대소문자 구분)와 하이픈, 밑줄만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
+ **클러스터 IAM 역할**-생성한 Amazon EKS 클러스터 IAM 역할을 선택하여 Kubernetes 컨트롤 플레인이 사용자 대신 AWS 리소스를 관리하게 할 수 있습니다.
+ **Kubernetes 버전(Kubernetes version)** - 클러스터에 대해 사용할 Kubernetes 버전 이전 버전이 필요한 경우가 아니면 최신 버전을 선택하는 것이 좋습니다.
+ **지원 유형** - 클러스터에 설정하려는 Kubernetes 버전 정책입니다. 클러스터가 표준 지원 버전에서만 실행되도록 하려면 **표준 지원**을 선택할 수 있습니다. 버전에 대한 표준 지원이 종료될 때 클러스터가 추가 지원을 시작하도록 하려면 **추가 지원**을 선택할 수 있습니다. 현재 확장 지원 중인 Kubernetes 버전을 선택한 경우에는 표준 지원을 옵션으로 선택할 수 없습니다.
+ **비밀 암호화(Secrets encryption)** - (선택 사항) KMS 키를 사용하여 Kubernetes 비밀의 비밀 암호화를 사용 설정하도록 선택합니다. 클러스터를 생성한 후에도 이 기능을 사용 설정할 수 있습니다. 이 기능을 사용 설정하기 전에 [기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화](enable-kms.md)의 정보를 숙지해야 합니다.
+ **태그**-(선택사항) 클러스터에 태그를 추가합니다. 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요.
+ **ARC 영역 전환**-(선택 사항) Route53 Application Recovery 컨트롤러를 사용하여 손상된 가용 영역을 완화할 수 있습니다. 자세한 내용은 [Amazon EKS에서 Amazon Application Recovery Controller(ARC)의 영역 전환에 대해 알아보기](zone-shift.md) 섹션을 참조하세요.
1. 클러스터 구성 페이지의 **클러스터 액세스** 섹션에 다음 필드를 입력합니다.
+ **부트스트랩 클러스터 관리자 액세스**-클러스터 생성자는 자동으로 Kubernetes 관리자입니다. 이를 비활성화하려면 **클러스터 관리자 액세스 허용 안 함**을 선택합니다.
+ **클러스터 인증 모드**-IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한을 부여하는 방법을 결정합니다. 자세한 내용은 [클러스터 인증 모드 설정](grant-k8s-access.md#set-cam) 섹션을 참조하세요.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **네트워킹 지정** 페이지에서 다음 필드의 값을 선택합니다.
+ **VPC**-클러스터를 생성하려면 [Amazon EKS VPC 요구 사항](network-reqs.md#network-requirements-vpc)을 충족하는 기존 VPC를 선택합니다. VPC를 선택하기 전에 [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md)의 요구 사항 및 고려 사항 모두를 숙지하는 것이 좋습니다. 클러스터 생성 후에는 사용하려는 VPC를 변경할 수 없습니다. 목록에 기존 VPC가 없는 경우 먼저 VPC를 생성해야 합니다. 자세한 내용은 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md) 섹션을 참조하세요.
+ **서브넷**-기본적으로 이전 필드에서 지정한 VPC에서 사용 가능한 모든 서브넷이 사전 선택됩니다. 두 개 이상을 선택해야 합니다.
선택한 서브넷은 [Amazon EKS 서브넷 요구 사항](network-reqs.md#network-requirements-subnets)을 충족해야 합니다. 서브넷을 선택하기 전에 [Amazon EKS VPC 및 서브넷 요구 사항 및 고려 사항](network-reqs.md) 모두를 숙지하는 것이 좋습니다.
**보안 그룹** – (선택사항) 생성하는 네트워크 인터페이스에 Amazon EKS가 연결하려는 보안 그룹을 하나 이상 지정합니다.
보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다.
+ **클러스터 IP 주소 패밀리 선택** - **IPv4**와 **IPv6** 중 하나를 선택할 수 있습니다.
Kubernetes는 기본적으로 포드와 서비스에 `IPv4` 주소를 할당합니다. `IPv6` 제품군 사용을 결정하기 전에 [VPC 요구 사항 및 고려 사항](network-reqs.md#network-requirements-vpc), [서브넷 요구 사항 및 고려 사항](network-reqs.md#network-requirements-subnets), [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 항목의 모든 고려 사항과 요구 사항을 숙지하고 있는지 확인하세요. `IPv6` 패밀리를 선택하면 `IPv4` 패밀리처럼 Kubernetes가 `IPv6` 서비스 주소를 할당할 주소 범위를 지정할 수 없습니다. Kubernetes는 고유한 로컬 주소 범위(`fc00::/7`)에서 서비스 주소를 할당합니다.
+ (선택 사항) **Kubernetes 서비스 IP 주소 범위 구성(Configure Kubernetes Service IP address range)**을 선택하고 **서비스 `IPv4` 범위(Service range)**를 지정합니다.
자체 범위를 지정하면 VPC에 피어링되거나 연결된 Kubernetes 서비스와 기타 네트워크 사이의 충돌을 방지할 수 있습니다. CIDR 표기법으로 범위를 입력합니다. 예를 들면 `10.2.0.0/16`입니다.
CIDR 블록은 다음 요구 사항을 충족해야 합니다.
+ 다음 범위 `10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16` 중 하나 내에 있어야 합니다..
+ 최소 크기는 `/24`고 최대 크기는 `/12`입니다.
+ Amazon EKS 리소스의 VPC 범위와 겹치지 않습니다.
이 옵션은 `IPv4` 주소 패밀리를 사용할 때 및 클러스터 생성 시에만 지정할 수 있습니다. 이 옵션을 지정하지 않은 경우 Kubernetes는 `10.100.0.0/16` 또는 `172.20.0.0/16` CIDR 블록 중 하나에서 서비스 IP 주소를 할당합니다.
+ **클러스터 엔드포인트 액세스**에서 옵션을 선택합니다. 클러스터를 생성한 후에는 이 옵션을 변경할 수 있습니다. 기본값이 아닌 옵션을 선택하기 전에 옵션과 그 의미를 숙지해야 합니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. (선택사항) **관찰성 구성** 페이지에서 설정할 **지표** 및 **컨트롤 플레인 로깅** 옵션을 선택합니다. 기본적으로 각 로그 유형은 해제되어 있습니다.
+ Prometheus 지표 옵션에 자세한 내용은 [1단계: Prometheus 지표 켜기](prometheus.md#turn-on-prometheus-metrics) 섹션을 참조하세요.
+ **컨트롤 플레인 로깅** 옵션에 대한 자세한 내용은 [CloudWatch Logs에 컨트롤 플레인 로그 전송](control-plane-logs.md) 섹션을 참조하세요.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **추가 기능 선택** 페이지에서 클러스터에 추가할 추가 기능을 선택합니다. 특정 추가 기능은 미리 선택되어 있습니다. 필요한 만큼 **Amazon EKS 애드온** 및 **AWS 마켓플레이스 애드온**을 선택할 수 있습니다. 설치하려는 **AWS 마켓플레이스 추가 기능**이 목록에 없는 경우 페이지 번호를 클릭하여 추가 페이지 결과를 확인하거나 검색창에 텍스트를 입력하여 사용 가능한 **AWS 마켓플레이스 추가 기능**을 검색할 수 있습니다. **카테고리**, **공급업체** 또는 **가격 모델**별로 필터링한 다음 검색 결과 중에서 추가 기능을 선택할 수도 있습니다. 클러스터를 생성할 때 [EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md)에 설명된 대로 EKS Pod Identity를 지원하는 추가 기능을 보고, 선택하고, 설치할 수 있습니다.
이 페이지를 모두 완료하면 **다음**을 선택합니다.
Amazon VPC CNI, CoreDNS, kube-proxy와 같은 일부 추가 기능은 기본적으로 설치됩니다. 기본 추가 기능을 비활성화하면 Kubernetes 애플리케이션 실행 기능에 영향을 미칠 수 있습니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 설치할 버전을 선택합니다. 클러스터 생성 후 언제든지 최신 버전으로 업데이트할 수 있습니다.
EKS Pod Identity를 지원하는 추가 기능의 경우 콘솔을 사용하여 추가 기능에 대해 미리 채워진 이름, AWS 관리형 정책, 신뢰 정책에 따라 역할을 자동으로 생성할 수 있습니다. 지원되는 추가 기능에 기존 역할을 재사용하거나 새 역할을 생성할 수 있습니다. 콘솔을 사용하여 EKS Pod Identity를 지원하는 추가 기능에 대한 역할을 생성하는 단계는 [추가 기능 생성(AWS 콘솔)](creating-an-add-on.md#create_add_on_console) 섹션을 참조하세요. 추가 기능이 EKS Pod Identity를 지원하지 않는 경우 클러스터가 생성된 후 마법사를 사용하여 서비스 계정에 대한 IAM 역할(IRSA)을 생성하는 지침이 포함된 메시지가 표시됩니다.
클러스터 생성 후 각 추가 기능의 구성을 업데이트할 수 있습니다. 추가 기능 구성에 대한 자세한 내용은 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 섹션을 참조하세요. 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 이전 페이지에서 입력하거나 선택한 정보를 검토합니다. 변경해야 하는 경우 **편집**을 선택합니다 만족하는 경우 **생성**을 선택합니다. 클러스터가 프로비저닝되는 동안 **상태** 필드에는 **생성 중**이 표시됩니다.
**참고**
요청의 가용 영역 중 하나에 Amazon EKS 클러스터를 생성하는 데 충분한 용량이 없다는 오류가 표시될 수 있습니다. 이 경우 오류 출력에는 새 클러스터를 지원할 수 있는 가용 영역이 포함됩니다. 사용자 계정의 지원 가용 영역에 있는 2개 이상의 서브넷을 사용하여 클러스터를 다시 생성합니다. 자세한 내용은 [용량 부족](troubleshooting.md#ice) 섹션을 참조하세요.
클러스터 프로비저닝에는 몇 분 정도 걸립니다.
1. [3단계: kubeconfig 업데이트](#step3) 계속 진행
### 클러스터 생성-AWS CLI
1. 다음 명령을 사용하여 클러스터를 생성합니다. 명령을 실행하기 전에 다음과 같은 바꾸기를 합니다.
+ *region-code*를 클러스터를 생성할 AWS 리전으로 바꿉니다.
+ *my-cluster*를 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈, 밑줄만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
+ *1.35*를 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 바꿉니다.
+ *111122223333*을 계정 ID로, *myAmazonEKSClusterRole*을 클러스터 IAM 역할 이름으로 바꿉니다.
+ `subnetIds`의 값을 고유한 값으로 바꿉니다. 또한 추가 ID를 추가할 수 있습니다. 2개 이상의 서브넷 ID를 지정해야 합니다.
선택한 서브넷은 [Amazon EKS 서브넷 요구 사항](network-reqs.md#network-requirements-subnets)을 충족해야 합니다. 서브넷을 선택하기 전에 [Amazon EKS VPC 및 서브넷 요구 사항 및 고려 사항](network-reqs.md) 모두를 숙지하는 것이 좋습니다.
+ 보안 그룹 ID를 지정하지 않으려면 명령에서 `,securityGroupIds=sg-`을 제거합니다. 하나 이상의 보안 그룹 ID를 지정하려는 경우 `securityGroupIds`의 값을 고유한 값으로 바꿉니다. 또한 추가 ID를 추가할 수 있습니다.
보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws:iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**참고**
요청의 가용 영역 중 하나에 Amazon EKS 클러스터를 생성하는 데 충분한 용량이 없다는 오류가 표시될 수 있습니다. 이 경우 오류 출력에는 새 클러스터를 지원할 수 있는 가용 영역이 포함됩니다. 사용자 계정의 지원 가용 영역에 있는 2개 이상의 서브넷을 사용하여 클러스터를 다시 생성합니다. 자세한 내용은 [용량 부족](troubleshooting.md#ice) 섹션을 참조하세요.
다음은 필요한 경우 이전 명령에 추가해야 하는 선택 가능한 설정입니다. 클러스터 생성 후가 아닌 생성할 때만 이러한 옵션을 사용 설정할 수 없습니다.
+ 기본적으로 EKS는 클러스터 생성 중에 여러 네트워킹 추가 기능을 설치합니다. 여기에는 Amazon VPC CNI, CoreDNS, kube-proxy가 포함되어 있습니다.
이러한 기본 네트워킹 추가 기능의 설치를 비활성화하려면 아래 파라미터를 사용하세요. 이는 Cilium과 같은 대체 CNI에 사용될 수 있습니다. 자세한 내용은 [EKS API 참조](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html)를 검토하세요.
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Kubernetes가 서비스 IP 주소를 할당하는 `IPv4` Classless Inter-Domain Routing(CIDR) 블록을 지정하려는 경우 다음 명령에 `--kubernetes-network-config serviceIpv4Cidr=`을 추가하여 해당 블록을 지정해야 합니다.
자체 범위를 지정하면 VPC에 피어링되거나 연결된 Kubernetes 서비스와 기타 네트워크 사이의 충돌을 방지할 수 있습니다. CIDR 표기법으로 범위를 입력합니다. 예를 들면 `10.2.0.0/16`입니다.
CIDR 블록은 다음 요구 사항을 충족해야 합니다.
+ 다음 범위 `10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16` 중 하나 내에 있어야 합니다..
+ 최소 크기는 `/24`고 최대 크기는 `/12`입니다.
+ Amazon EKS 리소스의 VPC 범위와 겹치지 않습니다.
이 옵션은 `IPv4` 주소 패밀리를 사용할 때 및 클러스터 생성 시에만 지정할 수 있습니다. 이 옵션을 지정하지 않은 경우 Kubernetes는 `10.100.0.0/16` 또는 `172.20.0.0/16` CIDR 블록 중 하나에서 서비스 IP 주소를 할당합니다.
+ 클러스터를 생성하고 클러스터가 `IPv4` 주소 대신 포드와 서비스에 `IPv6` 주소를 할당하도록 하려면 다음 명령에 `--kubernetes-network-config ipFamily=ipv6`를 추가합니다.
Kubernetes는 기본적으로 포드와 서비스에 `IPv4` 주소를 할당합니다. `IPv6` 제품군 사용을 결정하기 전에 [VPC 요구 사항 및 고려 사항](network-reqs.md#network-requirements-vpc), [서브넷 요구 사항 및 고려 사항](network-reqs.md#network-requirements-subnets), [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 항목의 모든 고려 사항과 요구 사항을 숙지하고 있는지 확인하세요. `IPv6` 패밀리를 선택하면 `IPv4` 패밀리처럼 Kubernetes가 `IPv6` 서비스 주소를 할당할 주소 범위를 지정할 수 없습니다. Kubernetes는 고유한 로컬 주소 범위(`fc00::/7`)에서 서비스 주소를 할당합니다.
1. 클러스터를 프로비저닝하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 상태를 쿼리할 수 있습니다.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
반환되는 출력이 `ACTIVE`가 되면 다음 단계로 진행하세요.
1. [3단계: kubeconfig 업데이트](#step3) 계속 진행
## 3단계: kubeconfig 업데이트
1. `eksctl`을 사용하여 클러스터를 생성한 경우 이 단계를 건너뛸 수 있습니다. 이는 `eksctl`이 사용자 대신 이 단계를 이미 완료했기 때문입니다. `kubectl` `config` 파일에 새 컨텍스트를 추가하여 `kubectl`이 클러스터와 통신하도록 사용 설정합니다. 파일 생성 및 업데이트 방법에 대한 자세한 내용을 알아보려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 부분을 참조하세요.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
예제 출력은 다음과 같습니다.
```
Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. 다음 명령을 실행하여 클러스터와의 통신을 확인합니다.
```
kubectl get svc
```
예제 출력은 다음과 같습니다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## 4단계: 클러스터 설정
1. (권장 사항) 일부 Amazon EKS 추가 기능을 사용하거나 개별 Kubernetes 워크로드가 특정 AWS Identity and Access Management(IAM) 권한을 갖도록 하려면 클러스터에 대한 [IAM OpenID Connect(OIDC) 제공자](enable-iam-roles-for-service-accounts.md)를 만드세요. 클러스터에 대해 IAM OIDC 공급자를 한 번만 생성하면 됩니다. Amazon EKS 추가 기능에 대한 자세한 내용은 [Amazon EKS 추가 기능](eks-add-ons.md) 부분을 참조하세요. 워크로드에 특정 IAM 권한을 할당하는 방법에 대한 자세한 내용은 [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md) 부분을 참조하세요.
1. (권장 사항) Amazon EC2 노드를 클러스터에 배포하기 전에 Kubernetes용 Amazon VPC CNI 플러그인에 대한 클러스터를 구성합니다. 기본적으로 플러그 인은 클러스터와 함께 설치되어 있습니다. 클러스터에 Amazon EC2 노드를 추가하면 추가하는 각 Amazon EC2 노드에 플러그 인이 자동으로 배포됩니다. 플러그 인을 사용하려면 다음 IAM 정책 중 하나를 IAM 역할에 연결해야 합니다. 클러스터가 `IPv4` 제품군을 사용하는 경우 [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) 관리형 IAM 정책을 사용합니다. 클러스터에서 `IPv6` 제품군을 사용하는 경우 [사용자가 만든 IAM 정책](cni-iam-role.md#cni-iam-role-create-ipv6-policy)을 사용합니다.
정책을 연결하는 IAM 역할은 노드 IAM 역할이거나 플러그 인에만 사용되는 전용 역할일 수 있습니다. 이 역할에 정책을 연결하는 것이 좋습니다. 역할 생성에 대한 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 또는 [Amazon EKS 노드 IAM 역할 섹션](create-node-role.md)을 참조하세요.
1. AWS Management Console을 사용하여 클러스터를 배포한 경우 이 단계를 건너뛸 수 있습니다. AWS Management Console는 기본적으로 Kubernetes용 Amazon VPC CNI 플러그인, CoreDNS 및 `kube-proxy` Amazon EKS 추가 기능을 배포합니다.
`eksctl` 또는 AWS CLI 중 하나를 사용하여 클러스터를 배포하는 경우 Kubernetes용 Amazon VPC CNI 플러그인, CoreDNS 및 `kube-proxy` 자체 관리형 추가 기능이 배포됩니다. 클러스터와 함께 배포되는 Kubernetes용 Amazon VPC CNI 플러그인, CoreDNS 및 `kube-proxy` 자체 관리형 추가 기능을 Amazon EKS 추가 기능으로 마이그레이션할 수 있습니다. 자세한 내용은 [Amazon EKS 추가 기능](eks-add-ons.md) 섹션을 참조하세요.
1. (선택 사항) 아직 수행하지 않은 경우 클러스터의 Prometheus 지표를 활성화할 수 있습니다. 자세한 내용은 **Prometheus용 Amazon 관리형 서비스 사용 설명서의 [스크레이퍼 생성](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create)을 참조하세요.
1. Amazon EBS 볼륨을 사용하는 클러스터에 워크로드를 배포할 계획인 경우 워크로드를 배포하기 전에 클러스터에 [Amazon EBS CSI](ebs-csi.md)를 설치해야 합니다.
## 다음 단계
+ 클러스터를 생성한 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 클러스터에 대한 액세스 권한이 있는 유일한 보안 주체입니다. 클러스터에 액세스할 수 있도록 [다른 IAM 보안 주체에 권한을 부여](grant-k8s-access.md)합니다.
+ 클러스터를 생성한 IAM 보안 주체에 사전 조건에서 참조하는 최소 IAM 권한만 있는 경우 해당 보안 주체에 대한 Amazon EKS 권한을 추가할 수 있습니다. IAM 보안 주체에 Amazon EKS 권한 부여에 대한 자세한 내용을 알아보려면 [Amazon EKS용 자격 증명 및 액세스 관리](security-iam.md) 부분을 참조하세요.
+ 클러스터를 생성한 IAM 위탁자 또는 다른 위탁자가 Amazon EKS 콘솔에서 Kubernetes 리소스를 보도록 하려면 엔터티에 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions)을 부여합니다.
+ 노드와 IAM 보안 주체가 VPC 내에서 클러스터에 액세스하도록 하려면 클러스터에 대한 프라이빗 엔드포인트를 활성화합니다. 퍼블릭 엔드포인트는 기본적으로 활성화되어 있습니다. 원하는 경우 프라이빗 엔드포인트를 활성화한 후 퍼블릭 엔드포인트를 비활성화할 수 있습니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요.
+ [클러스터에서 보안 암호 암호화 활성화](enable-kms.md)
+ [클러스터에서 로깅 구성](control-plane-logs.md)
+ [클러스터에 노드 추가](eks-compute.md)
# Amazon EKS 프로비저닝된 컨트롤 플레인
## 개요
Amazon EKS 프로비저닝된 컨트롤 플레인은 클러스터 관리자가 조정 티어 세트에서 선택하고 클러스터의 컨트롤 플레인에서 예측 가능한 매우 뛰어난 성능을 위해 선택한 티어를 지정할 수 있는 기능입니다. 이를 통해 클러스터 관리자는 컨트롤 플레인이 항상 지정된 용량으로 프로비저닝되도록 보장할 수 있습니다.
Amazon EKS는 클러스터의 컨트롤 플레인에 대해 두 가지 작업 모드를 제공합니다. 기본적으로 Amazon EKS 클러스터는 워크로드 수요에 따라 컨트롤 플레인이 자동으로 스케일 업 및 스케일 다운되는 **표준 모드**를 사용합니다. 표준 모드는 워크로드 요구 사항을 충족하기에 충분한 컨트롤 플레인 용량을 동적으로 할당하며, 대부분의 사용 사례에 권장되는 솔루션입니다. 그러나 컨트롤 플레인 조정으로 인한 성능 변동성을 허용할 수 없거나 매우 많은 컨트롤 플레인 용량이 필요한 특수 워크로드의 경우 선택적으로 **프로비저닝된 모드**를 사용할 수 있습니다. 프로비저닝된 모드를 사용하면 항상 까다로운 워크로드 요구 사항을 처리할 준비가 되어 있는 컨트롤 플레인 용량을 사전 할당할 수 있습니다.
**참고**
프로비저닝 모드는 기본 표준 모드와 함께 추가적인 컨트롤 플레인 작업 모드입니다. 프로비저닝된 모드를 도입해도 표준 모드 동작은 변경되지 않습니다.
EKS 프로비저닝된 컨트롤 플레인을 사용하면 클러스터 관리자가 원하는 컨트롤 플레인 용량을 사전에 프로비저닝하여 클러스터의 컨트롤 플레인에서 항상 사용할 수 있는 예측 가능한 뛰어난 성능을 제공할 수 있습니다. 또한 EKS 프로비저닝된 컨트롤 플레인을 사용하면 클러스터 관리자가 스테이징에서 프로덕션 및 재해 복구 사이트에 이르기까지 여러 환경에서 동일한 컨트롤 플레인 용량을 프로비저닝할 수 있습니다. 이는 여러 환경에서 얻은 컨트롤 플레인 성능이 일관되고 예측 가능한지 확인하는 데 중요합니다. 마지막으로 EKS 프로비저닝된 컨트롤 플레인을 사용하면 매우 높은 수준의 컨트롤 플레인 성능에 액세스할 수 있으므로, Kubernetes에서 대규모로 조정 가능한 AI 워크로드, 고성능 컴퓨팅 및 대규모 데이터 처리 워크로드를 실행할 수 있습니다.
모든 기존 및 새 Amazon EKS 클러스터는 기본적으로 표준 모드에서 작동합니다. 컨트롤 플레인에서 예측 가능한 뛰어난 성능이 필요한 클러스터의 경우 EKS 프로비저닝된 컨트롤 플레인 기능을 사용하도록 옵트인할 수 있습니다. 표준 또는 확장 지원 EKS의 시간당 요금 외에도 특정 컨트롤 플레인 조정 티어에 대한 시간당 요금이 청구됩니다. 요금에 대한 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/)을 참조하세요.
![\[Amazon EKS 컨트롤 플레인 모드\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/control-plane-modes.png)
## 사용 사례
EKS 프로비저닝된 컨트롤 플레인은 예측 가능한 뛰어난 컨트롤 플레인 성능이 운영에 중요한 특정 시나리오를 해결하도록 설계되었습니다. 이러한 사용 사례를 이해하면 EKS 프로비저닝된 컨트롤 플레인이 워크로드에 적합한 솔루션인지 확인하는 데에도 도움이 될 수 있습니다.
**성능이 중요한 워크로드** - Kubernetes 컨트롤 플레인의 지연 시간을 최소화하고 성능을 극대화해야 하는 워크로드의 경우 EKS 프로비저닝된 컨트롤 플레인은 컨트롤 플레인 조정을 통해 성능 변동성을 없앤 용량을 제공합니다.
**대규모로 조정 가능한 워크로드** - 클러스터에서 많은 노드를 실행해야 하는 AI 훈련 및 추론, 고성능 컴퓨팅 또는 대규모 데이터 처리와 같은 확장성이 뛰어난 워크로드를 실행하는 경우 프로비저닝된 컨트롤 플레인은 이러한 까다로운 워크로드를 지원하는 데 필요한 컨트롤 플레인 용량을 제공합니다.
**예상되는 수요가 많은 이벤트** - 전자 상거래 판매 또는 프로모션, 제품 출시, 휴일 쇼핑 시즌, 주요 스포츠 또는 엔터테인먼트 이벤트와 같은 예정된 이벤트로 인해 컨트롤 플레인 요청이 갑자기 급증할 것으로 예상되는 경우 프로비저닝된 컨트롤 플레인을 사용하면 컨트롤 플레인 용량을 사전에 조정할 수 있습니다. 이러한 선제적 접근 방식을 사용하면 자동 조정이 수요에 대응할 때까지 기다리지 않고도 늘어난 로드를 처리할 수 있습니다.
**환경 일관성** - 프로비저닝된 컨트롤 플레인을 사용하면 스테이징 및 프로덕션 환경 전반에서 컨트롤 플레인 용량과 성능을 일치시켜 프로덕션에 배포하기 전에 잠재적 문제를 조기에 식별할 수 있습니다. 여러 환경에서 동일한 컨트롤 플레인 티어를 유지 관리하면 테스트 결과가 프로덕션 동작을 정확하게 반영하도록 보장함으로써 롤아웃 중에 성능과 관련된 예상치 못한 상황이 발생할 위험을 줄일 수 있습니다.
**재해 복구 및 비즈니스 연속성** - 재해 복구 시나리오의 경우 프로비저닝된 컨트롤 플레인을 사용하면 기본 환경과 동일한 수준의 용량으로 장애 조치 환경을 프로비저닝할 수 있습니다. 이를 통해 재해 복구 클러스터가 활성화되는 순간부터 프로덕션 클러스터와 동일한 컨트롤 플레인 성능 특성을 보유하므로 장애 조치 이벤트 중에 중단을 최소화하고 신속하게 복구할 수 있습니다.
## 컨트롤 플레인 조정 티어
EKS 프로비저닝된 컨트롤 플레인에서는 티셔츠 크기(XL, 2XL, 4XL, 8XL)를 사용하여 명명된 조정 티어를 제공합니다. 각 티어는 클러스터 컨트롤 플레인의 성능 특성을 결정하는 세 가지 주요 Kubernetes 속성을 통해 해당 용량을 정의합니다. 이러한 속성을 이해하면 워크로드 요구 사항에 적합한 티어를 선택하는 데 도움이 됩니다.
**API 요청 동시성**은 Kubernetes 컨트롤 플레인의 API 서버가 동시에 처리할 수 있는 요청 수를 측정합니다. 이는 처리량이 많은 워크로드에 매우 중요합니다.
**포드 예약 속도**는 기본 Kubernetes 스케줄러가 노드에서 포드를 예약할 수 있는 속도를 나타내며, 초당 포드 수로 측정됩니다.
**클러스터 데이터베이스 크기**는 클러스터 상태/메타데이터를 보유한 데이터베이스인 etcd에 할당된 스토리지 공간을 나타냅니다.
프로비저닝된 컨트롤 플레인을 사용하여 특정 조정 티어에서 클러스터의 컨트롤 플레인을 프로비저닝하면 EKS는 클러스터의 컨트롤 플레인이 해당 티어에 해당하는 제한을 유지 관리하도록 합니다. 컨트롤 플레인 조정 티어의 제한은 다음 표와 같이 Kubernetes 버전에 따라 다릅니다.
### EKS v1.28 및 v1.29
| 프로비저닝된 컨트롤 플레인 조정 티어 | API 요청 동시성(시트 수) | 포드 예약 속도(포드/초) | 클러스터 데이터베이스 크기(GB) |
| --- | --- | --- | --- |
| XL | 1,700 | 100 | 16 |
| 2XL | 3,400 | 100 | 16 |
| 4XL | 6,800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 이상
| 프로비저닝된 컨트롤 플레인 조정 티어 | API 요청 동시성(시트 수) | 포드 예약 속도(포드/초) | 클러스터 데이터베이스 크기(GB) |
| --- | --- | --- | --- |
| XL | 1,700 | 167 | 16 |
| 2XL | 3,400 | 283 | 16 |
| 4XL | 6,800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### 컨트롤 플레인 조정 티어 사용률 모니터링
Amazon EKS는 컨트롤 플레인의 티어 사용률을 모니터링하는 데 도움이 되는 여러 지표를 제공합니다. 이러한 지표는 [Amazon CloudWatch 지표](cloudwatch.md)로 게시되며 CloudWatch 및 EKS 콘솔을 통해 액세스할 수 있습니다. 또한 이러한 지표는 EKS 클러스터의 Prometheus 엔드포인트([여기](prometheus.md) 참조)에서 스크래핑할 수 있습니다.
| | **Prometheus 지표** | **CloudWatch 지표** |
| --- | --- | --- |
| **API 요청 동시성** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **포드 예약 속도** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, scheduler\$1schedule\$1attempts\$1SCHEDULED, scheduler\$1schedule\$1attempts\$1UNSCHEDULABLE |
| **클러스터 데이터베이스 크기** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Amazon EKS 콘솔에서 컨트롤 플레인 사용률을 볼 수 있습니다. 클러스터의 개요 페이지에서 **클러스터 모니터링**을 선택하여 관찰성 대시보드에 액세스한 다음, **컨트롤 플레인 모니터링** 탭을 선택하여 **컨트롤 플레인 조정** 섹션에서 컨트롤 플레인 사용률을 확인합니다.
![\[EKS 클러스터 모니터링\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/monitor-cluster.png)
![\[EKS 컨트롤 플레인 모니터링\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/control-plane-monitoring.png)
### 티어 용량 및 실제 성능 이해
프로비저닝된 컨트롤 플레인 조정 티어를 선택하는 경우 티어 속성은 Amazon EKS가 컨트롤 플레인에 적용하는 기본 구성을 나타냅니다. 그러나 실제 성능은 특정 워크로드 패턴, 구성 및 Kubernetes 모범 사례 준수에 따라 달라집니다. 예를 들어 4XL 티어는 6,800개의 동시 요청 시트로 API 우선순위 및 공정성(APF)을 구성하지만 컨트롤 플레인에서 얻은 실제 요청 처리량은 수행 중인 작업 유형에 따라 달라집니다. 예를 들어 Kubernetes는 가져오기보다 목록 요청에 페널티를 적용하므로 컨트롤 플레인이 동시에 처리하는 유효한 목록 요청 수는 가져오기 요청보다 적습니다([여기](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) 참조). 마찬가지로 4XL 티어의 경우 기본 스케줄러 QPS가 400으로 설정되었어도 실제 포드 예약 속도는 여러 요인(예: 예약 상태 및 준비 중인 노드)에 따라 달라집니다. 최적의 성능을 얻으려면 애플리케이션이 Kubernetes 모범 사례([여기](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html) 참조)를 따르고 워크로드 특성에 맞게 올바르게 구성되었는지 확인합니다.
## 고려 사항
+ **표준 컨트롤 플레인 용량** - EKS 표준 컨트롤 플레인 모드는 최고의 가격 대비 성능 비율을 제공하며 대부분의 사용 사례에 권장되는 옵션입니다. 그러나 컨트롤 플레인 조정으로 인한 성능 변동성을 허용할 수 없거나 매우 많은 컨트롤 플레인 용량이 필요한 특수 워크로드의 경우 선택적으로 프로비저닝된 모드 사용을 고려할 수 있습니다.
+ **옵트인 필요** - 기존 클러스터는 표준 컨트롤 플레인에서 더 높은 [요금](https://aws.amazon.com/eks/pricing/)의 EKS 프로비저닝된 컨트롤 플레인 티어로 자동 확장되지 않습니다. 새로운 EKS 프로비저닝된 컨트롤 플레인 조정 티어 중 하나에 명시적으로 옵트인해야 합니다.
+ **종료 제한 사항** - 표준 컨트롤 플레인 모드는 최대 8GB의 클러스터 데이터베이스(etcd) 크기를 지원합니다. 프로비저닝된 모드를 사용하는 동안 클러스터의 데이터베이스 크기가 8GB를 초과하는 경우 데이터베이스 크기를 8GB 미만으로 줄일 때까지 표준 모드로 다시 전환할 수 없습니다. 예를 들어 프로비저닝된 모드에서 14GB의 데이터베이스 스토리지를 사용하는 경우 표준 모드로 돌아가기 전에 먼저 데이터베이스 사용률을 8GB 미만으로 줄여야 합니다.
+ **자동 티어 조정 없음** - EKS 프로비저닝된 컨트롤 플레인은 티어 사이에서 자동으로 조정되지 않습니다. 조정 티어를 선택하면 클러스터의 컨트롤 플레인이 해당 티어에 고정된 상태로 남아 일관되고 예측 가능한 성능을 보장합니다. 그러나 티어 사용률 지표를 모니터링하고 EKS 프로비저닝된 컨트롤 플레인 API를 사용하여 이러한 지표가 사용자가 정의한 임계치를 초과할 때 스케일 업 또는 스케일 다운함으로써 자체 오토 스케일링 솔루션을 유연하게 구현할 수 있으므로 조정 전략 및 비용 최적화를 완벽하게 제어할 수 있습니다.
+ **현재 티어 보기** - Amazon EKS 콘솔, Amazon Web Services CLI 또는 API를 사용하여 현재 컨트롤 플레인 조정 티어를 볼 수 있습니다. CLI에서 `describe-cluster` 명령(`aws eks describe-cluster --name cluster-name`)을 실행할 수 있습니다.
+ **티어 전환 시간** - Amazon EKS 콘솔, Amazon EKS API 또는 CLI를 사용하여 조정 티어를 종료하거나 조정 티어 사이를 이전할 수 있습니다. Amazon EKS는 전환 진행 상황을 모니터링하기 위해 검사할 수 있는 `ScalingTierConfigUpdate`라는 새로운 클러스터 업데이트 유형을 도입했습니다. 티어 변경 명령을 실행한 후 클러스터의 업데이트를 나열하여 상태가 `Updating`인 `ScalingTierConfigUpdate` 유형의 새 업데이트를 볼 수 있습니다. 업데이트가 완료되면 `Successful` 상태로 변경되고 오류가 발생하면 `Failed` 상태로 변경됩니다. 업데이트의 오류 필드는 실패 이유를 나타냅니다. 티어 간 전환 빈도에는 제한 사항이 없습니다. 컨트롤 플레인 티어 변경을 완료하는 데 몇 분 정도 걸립니다. EKS는 이전 API 서버를 종료하기 전에 새 API 서버를 가져오므로 이 프로세스 중에는 API 서버 가동 중지 시간이 없습니다.
+ **최적의 티어 선택** - 클러스터에 대한 최적의 프로비저닝된 컨트롤 플레인 조정 티어를 결정하기 위해 최상위 티어(8XL)에 클러스터를 프로비저닝하여 로드 테스트를 수행할 수 있습니다. 그런 다음 로드 테스트를 수행하여 클러스터의 컨트롤 플레인에서 피크 수요를 시뮬레이션합니다. 피크 로드 시 컨트롤 플레인 티어 사용률 지표를 관찰하고 이러한 관찰을 지침 요소로 사용하여 프로비저닝 모드에 적합한 티어를 선택합니다.
+ **프로비저닝된 컨트롤 플레인 요금** - 클러스터가 있는 프로비저닝된 컨트롤 플레인 조정 티어에 대해 시간당 요금이 청구됩니다. 표준 또는 확장 지원의 시간당 요금 외에 이 요금이 적용됩니다. 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/) 페이지를 참조하세요.
+ **더 큰 조정 티어** - 8XL보다 더 큰 조정 티어에서 클러스터를 실행하려는 경우 Amazon Web Services 계정 팀에 추가 요금 정보를 문의하세요.
+ **Kubernetes 버전 및 리전 지원** - EKS 프로비저닝된 컨트롤 플레인은 모든 Amazon Web Services 상용, GovCloud 및 중국 리전에서 지원됩니다. 프로비저닝된 컨트롤 플레인은 EKS v1.28 이상에서 작동합니다.
# Amazon EKS 프로비저닝된 컨트롤 플레인 시작하기
이 가이드에서는 AWS CLI 및 AWS Management Console을 사용하여 EKS 프로비저닝된 컨트롤 플레인을 설정하고 사용하는 단계를 안내합니다.
## 사전 조건
시작하기 전에 다음을 갖추었는지 확인하세요.
+ ** AWS CLI **- Amazon EKS를 비롯한 AWS 서비스를 사용한 작업을 위한 명령줄 도구입니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)를 참조하세요. AWS CLI 설치 후, 구성 작업도 수행하는 것이 좋습니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*에서 [aws configure를 사용한 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. 이 페이지에 나와 있는 **update-kubeconfig** 옵션을 사용하려면 AWS CLI v2가 필요합니다.
+ **필요한 IAM 권한** - 사용하는 IAM 보안 주체에 Amazon EKS IAM 역할, 서비스 연결 역할, AWS CloudFormation, VPC 및 관련 리소스를 사용할 수 있는 권한이 있어야 합니다. 자세한 내용은 [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) 및 *IAM 사용 설명서*의 [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)을 참조하세요. 이 가이드의 모든 단계를 동일한 사용자로 완료해야 합니다. 현재 사용자를 확인하려면 다음 명령을 실행합니다.
```
aws sts get-caller-identity
```
**참고**
Bash 셸에서 이 주제의 단계를 완료하는 것이 좋습니다. Bash 셸을 사용하지 않는 경우 줄 연속 문자 및 변수 설정 및 사용 방식과 같은 일부 스크립트 명령을 통해 셸이 조정되어야 합니다. 또한 쉘의 인용 및 이스케이프 규칙이 다를 수 있습니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS CLI에서 문자열에 따옴표 사용](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html)을 참조하세요.
## EKS 프로비저닝된 컨트롤 플레인 - AWS CLI
### EKS 프로비저닝된 컨트롤 플레인 조정 티어를 사용하여 클러스터 생성
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
응답:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### 클러스터의 컨트롤 플레인 조정 티어 보기
```
aws eks describe-cluster --name prod-cluster
```
응답:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### EKS 프로비저닝된 컨트롤 플레인을 사용하도록 클러스터 업데이트
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
응답:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### 컨트롤 플레인 조정 업데이트 보기
```
aws eks list-updates --name example
```
응답:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### 프로비저닝된 컨트롤 플레인을 표준 컨트롤 플레인으로 종료
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
응답:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## EKS 프로비저닝된 컨트롤 플레인 - AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. **클러스터 생성**을 선택합니다.
1. *구성 옵션*에서 **사용자 지정 구성**을 선택합니다.
1. 아래로 스크롤하여 **컨트롤 플레인 조정 티어**로 이동하세요. **조정 티어 사용**을 선택하여 프로비저닝된 제어 플레인을 활성화하세요.
1. XL, 2XL, 4XL, 8XL과 같은 다양한 조정 티어 옵션에서 클러스터에 대해 프로비저닝할 컨트롤 플레인 조정 계층을 선택하세요.
1. 필요에 따라 다른 클러스터 구성 옵션을 선택하세요. 마지막 단계에서 **클러스터 생성**을 선택하세요. 클러스터 생성을 완료하는 데 몇 분 정도 걸릴 수 있습니다.
# 클러스터 인사이트를 사용한 Kubernetes 버전 업그레이드 준비 및 잘못된 구성 문제 해결
Amazon EKS 클러스터 인사이트는 문제를 탐지하고 이를 해결하기 위한 권장 사항을 제공하여 클러스터 관리를 돕습니다. 모든 Amazon EKS 클러스터는 Amazon EKS에서 선별한 인사이트 목록을 대상으로 자동 반복 검사를 거칩니다. 이러한 *인사이트 검사*는 Amazon EKS에서 모두 관리되며, 결과를 처리하는 방법에 대한 권장 사항을 제공합니다.
## 클러스터 인사이트 유형
+ **구성 인사이트**: EKS Hybrid Nodes 설정에서 클러스터나 워크로드의 기능을 손상시킬 수 있는 잘못된 구성을 식별합니다.
+ **업그레이드 인사이트**: 새 버전의 Kubernetes로 업그레이드하는 기능에 영향을 미칠 수 있는 문제를 식별합니다.
## 고려 사항
+ **빈도**: Amazon EKS는 24시간마다 클러스터 인사이트를 새로 고쳐집니다. 또는 수동으로 새로 고쳐 최신 상태를 확인할 수 있습니다. 예를 들어 문제를 해결한 후 클러스터 인사이트를 수동으로 새로 고쳐 문제가 해결되었는지 여부를 확인할 수 있습니다.
+ **권한**: Amazon EKS는 모든 EKS 클러스터의 클러스터 인사이트에 대한 클러스터 액세스 항목을 자동으로 생성합니다. 이 항목은 EKS에 클러스터에 대한 정보를 볼 수 있는 권한을 부여합니다. Amazon EKS는 이 정보를 사용하여 인사이트를 생성합니다. 자세한 내용은 [AmazonEKSClusterInsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy) 섹션을 참조하세요.
## 사용 사례
Amazon EKS의 클러스터 인사이트는 Kubernetes 클러스터의 상태, 신뢰성 및 최적의 구성을 유지하는 데 도움이 되는 자동 확인을 제공합니다. 다음은 업그레이드 준비 및 구성 문제 해결을 포함한 클러스터 인사이트의 주요 사용 사례입니다.
### 업그레이드 인사이트
업그레이드 인사이트는 클러스터 인사이트 내 특정 유형의 인사이트 검사입니다. 이 검사는 Kubernetes 버전 업그레이드 준비와 관련된 인사이트를 반환합니다. Amazon EKS는 모든 EKS 클러스터에서 업그레이드 인사이트 검사를 실행합니다.
**중요**
Amazon EKS는 특정 클러스터 인사이트 문제가 있을 때 `--force` 플래그를 사용하여 클러스터를 업그레이드해야 하는 기능을 일시적으로 롤백했습니다. 자세한 내용은 GitHub의 [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)을 참조하세요.
클라이언트 업데이트에 대한 자세한 내용은 [3단계: 클러스터 제어 영역 업데이트](update-cluster.md#update-cluster-control-plane) 섹션을 참조하세요.
클러스터 Kubernetes 버전을 업데이트하기 전에 [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 관찰성 대시보드의 **업그레이드 인사이트** 탭을 사용할 수 있습니다. 클러스터에서 문제가 식별된 경우 문제를 검토하고 적절하게 수정하세요. 문제에는 Amazon EKS 및 Kubernetes 설명서에 대한 링크가 포함됩니다. 문제를 해결한 후 온디맨드로 클러스터 인사이트를 새로 고쳐 최신 인사이트를 가져옵니다. 모든 문제가 해결되었으면 [클러스터를 업데이트](update-cluster.md)하세요.
Amazon EKS는 Kubernetes 버전 업그레이드 준비와 관련된 인사이트를 반환합니다. 업그레이드 인사이트는 Kubernetes 클러스터 업그레이드에 영향을 미칠 수 있는 잠재적 문제를 식별합니다. 이를 통해 관리자가 업그레이드를 준비하는 데 드는 노력을 최소화하고 최신 Kubernetes 버전에서 애플리케이션의 신뢰성을 높일 수 있습니다. Amazon EKS는 문제에 영향을 줄 수 있는 가능한 Kubernetes 버전 업그레이드 목록을 대상으로 클러스터를 자동으로 스캔합니다. Amazon EKS는 각 Kubernetes 버전 릴리스의 변경 사항 검토를 기반으로 인사이트 검사 목록을 자주 업데이트합니다.
Amazon EKS 업그레이드 인사이트는 새 버전에 대한 테스트 및 확인 프로세스를 가속화합니다. 또한 클러스터 관리자 및 애플리케이션 개발자는 우려 사항을 강조하고 문제 해결 조언을 제공하여 최신 Kubernetes 기능을 활용할 수 있습니다.
### 구성 인사이트
EKS 클러스터 인사이트는 하이브리드 노드가 있는 Amazon EKS 클러스터를 자동으로 스캔하여 Kubernetes 컨트롤 플레인과 웹후크 간 통신, exec 및 로그와 같은 kubectl 명령 등을 손상시키는 구성 문제를 식별합니다. 구성 인사이트는 문제를 표면화하고 문제 해결 권장 사항을 제공하여 완벽하게 작동하는 하이브리드 노드 설정에 걸리는 시간을 단축합니다.
## 시작
수행된 인사이트 검사 목록과 Amazon EKS에서 식별한 관련 문제를 확인하려면 AWS Management Console, AWS CLI, AWS SDK 및 Amazon EKS `ListInsights` API 작업을 사용할 수 있습니다. 시작하려면 [클러스터 인사이트 보기](view-cluster-insights.md) 섹션을 참조하세요.
# 클러스터 인사이트 보기
Amazon EKS는 **구성 인사이트**와 **업그레이드 인사이트**라는 2가지 유형의 인사이트를 제공합니다. **구성 인사이트**는 EKS Hybrid Nodes 설정에서 클러스터나 워크로드의 기능을 손상시킬 수 있는 잘못된 구성을 식별합니다. **업그레이드 인사이트**는 새 버전의 Kubernetes로 업그레이드하는 기능에 영향을 미칠 수 있는 문제를 식별합니다.
수행된 인사이트 검사 목록과 Amazon EKS에서 식별한 관련 문제를 확인하려면 AWS Management Console, AWS CLI, AWS SDK 및 Amazon EKS `ListInsights` API 작업에서 모양을 직접적으로 호출합니다.
## 구성 인사이트 보기(콘솔)
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 클러스터 목록에서 인사이트를 확인하려는 Amazon EKS 클러스터 이름을 선택합니다.
1. **클러스터 모니터링**을 선택합니다.
1. **클러스터 상태** 탭을 선택합니다.
1. **구성 인사이트** 테이블에는 다음 열이 표시됩니다.
+ **이름** - 클러스터를 대상으로 Amazon EKS에서 수행한 검사입니다.
+ **인사이트 상태** - 상태가 `Error`인 인사이트는 클러스터 기능에 영향을 미칠 수 있는 잘못된 구성이 있음을 의미합니다. 상태가 `Warning`인 인사이트는 구성이 문서화된 접근 방식과 일치하지 않지만 의도적으로 구성한 경우 클러스터 기능이 작동할 수 있음을 의미합니다. `Passing` 상태의 인사이트는 Amazon EKS가 클러스터에서 이 인사이트 검사와 관련된 문제를 발견하지 못했음을 의미합니다.
+ **버전** - 적용 가능한 버전입니다.
+ **마지막 새로 고침 시간**-이 클러스터에서 인사이트 상태를 마지막으로 새로 고친 시간입니다.
+ **설명** - 알림 및 문제 해결을 위한 권장 작업을 포함하는 인사이트 검사 정보입니다.
## 업그레이드 인사이트 보기(콘솔)
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 클러스터 목록에서 인사이트를 확인하려는 Amazon EKS 클러스터 이름을 선택합니다.
1. **클러스터 모니터링**을 선택합니다.
1. **업그레이드 인사이트** 탭을 선택합니다.
1. 최신 데이터를 보려면 **인사이트 새로 고침** 버튼을 선택하고 새로 고침 작업이 완료될 때까지 기다립니다.
1. **업그레이드 인사이트** 테이블에는 다음 열이 표시됩니다.
+ **이름** - 클러스터를 대상으로 Amazon EKS에서 수행한 검사입니다.
+ **인사이트 상태** - '오류' 상태의 인사이트는 일반적으로 영향을 받는 Kubernetes 버전이 현재 클러스터 버전의 N\$11임을 의미하고, '경고' 상태는 인사이트가 향후 Kubernetes 버전 N\$12 이상에 적용됨을 의미합니다. '통과' 상태의 인사이트는 Amazon EKS가 클러스터에서 이 인사이트 검사와 관련된 문제를 발견하지 못했음을 의미합니다. '알 수 없음' 상태의 인사이트는 Amazon EKS가 클러스터가 이 인사이트 검사의 영향을 받는지 여부를 판단할 수 없음을 의미합니다.
+ **버전** - 인사이트가 잠재적 문제가 있는지 검사한 Kubernetes 버전입니다.
+ **마지막 새로 고침 시간**-이 클러스터에서 인사이트 상태를 마지막으로 새로 고친 시간입니다.
+ **마지막 전환 시간**-이 인사이트의 상태가 마지막으로 전환된 시간입니다.
+ **설명** - 알림 및 문제 해결을 위한 권장 작업을 포함하는 인사이트 검사 정보입니다.
## 클러스터 인사이트 보기(AWS CLI)
1. 최신 데이터를 보려면 지정된 클러스터의 인사이트를 새로 고칩니다. 필요에 따라 명령을 다음과 같이 수정한 다음에 수정한 명령을 실행합니다.
+ AWS 리전을 *region-code*로 바꿉니다.
+ *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. 인사이트 새로 고침 상태를 추적하려면 다음 명령을 실행합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
예제 출력은 다음과 같습니다.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. 지정된 클러스터의 모든 인사이트를 나열합니다. 필요에 따라 명령을 다음과 같이 수정한 다음에 수정한 명령을 실행합니다.
+ AWS 리전을 *region-code*로 바꿉니다.
+ *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
예제 출력은 다음과 같습니다.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. 인사이트에 대한 설명 정보를 보려면 다음 명령을 실행합니다. 필요에 따라 명령을 다음과 같이 수정한 다음에 수정한 명령을 실행합니다.
+ AWS 리전을 *region-code*로 바꿉니다.
+ *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222*를 클러스터 인사이트 목록에서 검색된 인사이트 ID로 바꿉니다.
+ *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
예제 출력은 다음과 같습니다.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# 기존 클러스터를 새 Kubernetes 버전으로 업데이트
**작은 정보**
향후 예정된 Amazon EKS 워크숍에 [등록](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)합니다.
Amazon EKS에서 새 Kubernetes 버전을 사용할 수 있는 경우 Amazon EKS 클러스터를 최신 버전으로 업데이트할 수 있습니다.
**중요**
클러스터를 업그레이드한 후에는 이전 버전으로 다운그레이드할 수 없습니다. 새 Kubernetes 버전으로 업데이트하기 전에 [EKS의 Kubernetes 버전 수명 주기 이해](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)의 정보 및 이 주제의 업데이트 단계를 검토하는 것이 좋습니다.
새로운 Kubernetes 버전에는 때로는 큰 변화가 도입되기도 합니다. 따라서 프로덕션 클러스터를 업데이트하기 전에 새 Kubernetes 버전에 대해 애플리케이션의 동작을 테스트하는 것이 좋습니다. 새 Kubernetes 버전으로 이동하기 전에 애플리케이션 동작을 테스트하기 위한 지속적인 통합 워크플로를 구축하여 이 작업을 수행할 수 있습니다.
업데이트 프로세스는 Amazon EKS에서 업데이트된 Kubernetes 버전으로 새 API 서버 노드를 시작해 기존 노드를 대체합니다. Amazon EKS는 이러한 새 노드에서 네트워크 트래픽의 표준 인프라 및 준비 상태 검사를 수행하여 예상대로 작동하고 있는지 확인합니다. 하지만 클러스터 업그레이드를 시작한 후에는 일시 중지하거나 중지할 수 없습니다. 이러한 검사 중 하나라도 실패하면 Amazon EKS는 인프라 배포를 되돌리고, 클러스터는 이전 Kubernetes 버전으로 남아 있게 됩니다. 실행 중인 애플리케이션은 영향을 받지 않으며, 클러스터가 불확정적 또는 복구 불가능 상태로 남아 있는 일은 없습니다. Amazon EKS는 모든 관리형 클러스터를 정기적으로 백업하고, 필요할 경우 클러스터를 복구하는 메커니즘이 있습니다. Kubernetes 인프라 관리 프로세스를 지속적으로 평가 및 개선하고 있습니다.
클러스터를 업데이트하려면 Amazon EKS에서 클러스터를 생성할 때 지정된 서브넷의 사용 가능한 IP 주소 최대 5개가 필요합니다. Amazon EKS에서는 지정한 서브넷에 새 클러스터 탄력적 네트워크 인터페이스(네트워크 인터페이스)를 생성합니다. 네트워크 인터페이스는 기존 네트워크 인터페이스가 있는 다른 서브넷에 생성될 수 있으므로 보안 그룹 규칙에서 클러스터를 생성할 때 지정한 모든 서브넷에 대해 [필수 클러스터 통신](sec-group-reqs.md)을 허용해야 합니다. 클러스터를 생성할 때 지정한 서브넷이 없거나, 해당 서브넷에 사용 가능한 IP 주소가 충분하지 않거나 필요한 클러스터 통신을 허용하는 보안 그룹 규칙이 없는 경우 업데이트가 실패할 수 있습니다.
Amazon EKS는 클러스터의 API 서버 엔드포인트에 항상 액세스할 수 있도록 가용성 높은 Kubernetes 컨트롤 플레인을 제공하고 업데이트 작업 중에 API 서버 인스턴스의 롤링 업데이트를 수행합니다. Kubernetes API 서버 엔드포인트를 지원하는 API 서버 인스턴스의 IP 주소 변경을 고려하려면 API 서버 클라이언트가 재연결을 효과적으로 관리하도록 해야 합니다. `kubectl`의 최신 버전과 공식적으로 지원되는 Kubernetes 클라이언트 [라이브러리](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api), 재연결 프로세스는 이 재연결 프로세스를 투명하게 수행합니다.
**참고**
클러스터 업데이트에 대한 자세한 내용은 EKS 모범 사례 가이드의 [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)를 참조하세요. 이 리소스는 업그레이드를 계획하고 클러스터 업그레이드 전략을 이해하는 데 도움이 됩니다.
## Amazon EKS Auto Mode 고려 사항
+ Amazon EKS Auto Mode의 컴퓨팅 기능은 노드의 Kubernetes 버전을 제어합니다. 컨트롤 플레인을 업그레이드하면 EKS Auto Mode가 관리형 노드를 점진적으로 업데이트하기 시작합니다. EKS Auto Mode는 포드 중단 예산을 준수합니다.
+ 컴퓨팅 오토 스케일링, 블록 스토리지, 로드 밸런싱 기능을 포함하여 Amazon EKS Auto Mode의 기능을 수동으로 업그레이드할 필요가 없습니다.
## 요약
Amazon EKS 클러스터 업그레이드 프로세스의 대략적인 요약은 다음과 같습니다.
1. 클러스터가 업그레이드를 지원하는 상태인지 확인합니다. 여기에는 클러스터에 배포된 리소스에서 사용하는 Kubernetes API를 검사하여 클러스터에 상태 문제가 없는지 확인하는 작업이 포함됩니다. 클러스터의 업그레이드 준비 상태를 평가할 때 Amazon EKS 업그레이드 인사이트를 사용해야 합니다.
1. 다음 마이너 버전으로 컨트롤 플레인을 업그레이드합니다(예: 1.34에서 1.35으로).
1. 컨트롤 플레인의 노드와 일치하도록 데이터 플레인의 노드를 업그레이드합니다.
1. 클러스터에서 실행되는 추가 애플리케이션(예: `cluster-autoscaler`)을 업그레이드합니다.
1. 기본적으로 포함된 추가 기능과 같이 Amazon EKS에서 제공하는 추가 기능을 업그레이드합니다.
+ [Amazon VPC CNI 권장 버전](managing-vpc-cni.md)
+ [CoreDNS 권장 버전](managing-coredns.md)
+ [`kube-proxy` 권장 버전](managing-kube-proxy.md)
1. 클러스터와 통신하는 클라이언트를 업그레이드합니다(예: `kubectl`).
## 1단계: 업그레이드 준비
클러스터 제어 영역의 Kubernetes 버전과 사용자 노드의 Kubernetes 버전을 비교합니다.
+ 클러스터 컨트롤 플레인의 Kubernetes 버전을 가져옵니다.
```
kubectl version
```
+ 노드의 Kubernetes 버전을 가져옵니다. 이 명령은 자체 관리형 및 관리형 Amazon EC2, Fargate 및 하이브리드 노드를 모두 반환합니다. 각 Fargate 포드는 자체 노드로 나열됩니다.
```
kubectl get nodes
```
컨트롤 플레인을 새 Kubernetes 버전으로 업데이트하기 전에 클러스터에 있는 관리형 노드 및 Fargate 노드 모두의 Kubernetes 마이너 버전이 컨트롤 플레인의 현재 버전과 동일한지 확인합니다. 예를 들어, 컨트롤 플레인에서 버전 `1.29`을 실행 중이고 노드 중 하나에서 버전 `1.28`을 실행 중인 경우에는 컨트롤 플레인을 1.30으로 업데이트하기 전에 노드를 버전 `1.29`로 업데이트해야 합니다. 또한 컨트롤 플레인을 업데이트하기 전에 자체 관리형 노드와 하이브리드 노드를 컨트롤 플레인과 동일한 버전으로 업데이트하는 것이 좋습니다. 자세한 내용은 [클러스터에 대한 관리형 노드 그룹 업데이트](update-managed-node-group.md), [클러스터의 자체 관리형 노드 업데이트](update-workers.md), [클러스터의 하이브리드 노드 업그레이드](hybrid-nodes-upgrade.md) 섹션을 참조하세요. 컨트롤 플레인 버전보다 낮은 마이너 버전이 적용된 Fargate 노드가 있는 경우 먼저 이 노드로 대표되는 포드를 삭제합니다. 그런 다음 컨트롤 플레인을 업데이트합니다. 나머지 포드는 모두 다시 배포한 후 새 버전으로 업데이트됩니다.
## 2단계: 업그레이드 고려 사항 검토
Amazon EKS 클러스터 인사이트는 더 이상 사용되지 않는 Kubernetes API 사용 등의 문제에 영향을 미치는 가능한 Kubernetes 버전 업그레이드 목록을 대상으로 클러스터를 자동으로 스캔합니다. Amazon EKS는 Kubernetes 프로젝트의 변경 사항 평가를 기반으로 수행할 인사이트 검사 목록을 주기적으로 업데이트합니다. 또한 Amazon EKS 서비스에 새 버전과 함께 변경 사항이 도입되면 인사이트 검사 목록도 업데이트됩니다. 자세한 내용은 [클러스터 인사이트를 사용한 Kubernetes 버전 업그레이드 준비 및 잘못된 구성 문제 해결](cluster-insights.md) 섹션을 참조하세요.
Kubernetes Documentation의 [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/)를 검토합니다.
### 업그레이드 인사이트 검토
Amazon EKS 업그레이드 인사이트를 사용하여 문제를 식별합니다. 자세한 내용은 [업그레이드 인사이트 보기(콘솔)](view-cluster-insights.md#view-upgrade-insights-console) 섹션을 참조하세요.
### 세부 고려 사항
+ Amazon EKS는 가용성 높은 제어 영역을 실행하므로 한 번에 하나의 마이너 버전만 업데이트할 수 있습니다. 이 요구 사항에 대한 자세한 내용을 알아보려면 [Kubernetes 버전 및 버전 차이 지원 정책](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver)을 참조하세요. 현재 클러스터 버전이 `1.28` 버전이고 `1.30` 버전으로 업데이트하려는 경우를 예로 들어보겠습니다. 먼저 `1.28` 버전 클러스터를 `1.29` 버전으로 업데이트한 다음에 `1.29` 버전 클러스터를 `1.30` 버전으로 업데이트해야 합니다.
+ 노드의 Kubernetes `kube-apiserver`와 `kubelet` 사이에서 버전 차이를 검토합니다.
+ Kubernetes 버전 `1.28`부터 `kubelet`은 `kube-apiserver`보다 오래된 최대 3개의 마이너 버전에 해당할 수 있습니다. [Kubernetes upstream version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubelet)를 참조하세요.
+ Fargate 노드와 관리형 노드의 `kubelet`이 Kubernetes 버전 `1.25` 이상인 경우 `kubelet` 버전을 업데이트하지 않고도 클러스터를 최대 3개 버전까지 미리 업데이트할 수 있습니다. 예를 들어, `kubelet` 버전이 `1.25`인 경우 `kubelet` 버전은 `1.25`로 유지하면서 Amazon EKS 클러스터 버전을 `1.25`에서 `1.26`, `1.27`, `1.28`로 업데이트할 수 있습니다.
+ 업데이트를 시작하기 전에 모범 사례는 노드의 `kubelet`이 컨트롤 플레인과 동일한 Kubernetes 버전인지 확인하는 것입니다.
+ 클러스터가 `1.8.0` 이전 버전의 Kubernetes용 Amazon VPC CNI 플러그인으로 구성된 경우에는 클러스터를 업데이트하기 전에 플러그인을 최신 버전으로 업데이트하는 것이 좋습니다. 플러그인을 업데이트하려면 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md)을 참조하세요.
+ 업그레이드 프로세스 중에 장애가 발생할 경우 Amazon EKS 클러스터 상태와 영구 스토리지를 복원할 수 있도록 Amazon EKS 클러스터를 백업할 수 있습니다. [AWS Backup을 사용하여 EKS 클러스터 백업](integration-backup.md) 섹션을 참조하세요
## 3단계: 클러스터 제어 영역 업데이트
**중요**
Amazon EKS는 특정 클러스터 인사이트 문제가 있을 때 `--force` 플래그를 사용하여 클러스터를 업그레이드해야 하는 기능을 일시적으로 롤백했습니다. 자세한 내용은 GitHub의 [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)을 참조하세요.
Amazon EKS는 ‘마지막 새로 고침 시간’으로부터 24시간 후에 클러스터 인사이트를 새로 고칩니다. 문제를 해결한 시간을 클러스터 인사이트의 ‘마지막 새로 고침 시간’과 비교할 수 있습니다.
또한 더 이상 사용되지 않는 API 사용을 처리한 후 인사이트 상태가 업데이트되는 데 최대 30일이 걸릴 수 있습니다. 업그레이드 인사이트는 항상 30일 동안 더 이상 사용되지 않는 API 사용을 찾습니다.
다음을 사용하여 EKS 컨트롤 플레인 버전 업그레이드 요청을 제출할 수 있습니다.
+ [eksctl](#step3-eksctl)
+ [AWS 콘솔](#step3-console)
+ [AWS CLI](#step3-cli)
### 클러스터 업데이트-eksctl
이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다.
```
eksctl version
```
`eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
Amazon EKS 컨트롤 플레인의 Kubernetes 버전을 업데이트합니다. ``을 클러스터 이름으로 교체합니다. ``를 클러스터를 업데이트하려는 Amazon EKS에서 지원하는 버전 번호로 바꿉니다. 지원되는 버전 번호 목록은 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 참조하세요.
```
eksctl upgrade cluster --name --version --approve
```
업데이트를 완료하는 데 몇 분 정도 걸립니다.
계속해서 [4단계: 클러스터 구성 요소 업데이트](#step4)로 이동하세요.
### 클러스터 업데이트 - AWS 콘솔
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 업그레이드하려는 클러스터에 대해 **지금 업그레이드**를 선택합니다.
1. 클러스터를 업데이트할 버전을 선택하고 **업그레이드**를 선택합니다.
1. 업데이트를 완료하는 데 몇 분 정도 걸립니다. 계속해서 [4단계: 클러스터 구성 요소 업데이트](#step4)로 이동하세요.
### 클러스터 업데이트 - AWS CLI
1. AWS CLI가 설치되어 있고 로그인했는지 확인합니다. 자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 AWS CLI명령을 사용하여 Amazon EKS 클러스터를 업데이트합니다. 업그레이드하려는 클러스터의 ``와 ``을 바꿉니다. ``를 클러스터를 업데이트하려는 Amazon EKS에서 지원하는 버전 번호로 바꿉니다. 지원되는 버전 번호 목록은 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 참조하세요.
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
예제 출력은 다음과 같습니다.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. 업데이트를 완료하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 업데이트 상태를 모니터링할 수 있습니다. 동일한 ``과 ``를 사용하는 것 외에도 이전 명령에서 반환한 ``를 사용합니다.
```
aws eks describe-update --name \
--region --update-id
```
`Successful` 상태가 표시되면 업데이트가 완료됩니다.
1. 계속해서 [4단계: 클러스터 구성 요소 업데이트](#step4)로 이동하세요.
## 4단계: 클러스터 구성 요소 업데이트
1. 클러스터 업데이트가 완료된 후 업데이트한 클러스터와 동일한 Kubernetes 마이너 버전으로 노드를 업데이트합니다. 자세한 내용은 [클러스터의 자체 관리형 노드 업데이트](update-workers.md), [클러스터에 대한 관리형 노드 그룹 업데이트](update-managed-node-group.md), [클러스터의 하이브리드 노드 업그레이드](hybrid-nodes-upgrade.md) 섹션을 참조하세요. Fargate에서 시작된 새 포드에는 클러스터 버전과 일치하는 `kubelet` 버전이 있습니다. 기존 Fargate 포드는 변경되지 않습니다.
1. (선택 사항) 클러스터를 업데이트하기 전에 Kubernetes Cluster Autoscaler를 클러스터에 배포한 경우 업그레이드한 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 버전으로 Cluster Autoscaler를 업데이트합니다.
1. 웹 브라우저에서 Cluster Autoscaler [릴리스](https://github.com/kubernetes/autoscaler/releases) 페이지를 열고 클러스터의 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 Cluster Autoscaler 버전을 검색합니다. 예를 들어 클러스터의 Kubernetes 버전이 `1.30`이라면 `1.30`으로 시작하는 Cluster Autoscaler 릴리스를 검색합니다. 다음 단계에서 사용할 해당 릴리스의 의미 체계 버전 번호(예: `1.30.n`)를 기록합니다.
1. 다음 명령을 사용하여 Cluster Autoscaler 이미지 태그를 이전 단계에서 적어 둔 버전으로 설정합니다. 필요한 경우 `X.XX.X`을 고유 값으로 바꿉니다.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (GPU 노드가 있는 클러스터만 해당) 클러스터에 GPU 지원이 포함된 노드 그룹이 있는 경우(예: `p3.2xlarge`) 클러스터에서 [Kubernetes용 NVIDIA 디바이스 플러그인](https://github.com/NVIDIA/k8s-device-plugin) DaemonSet을 업데이트해야 합니다. 다음 명령을 실행하기 전에 ``을(를) 원하는 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) 버전으로 교체합니다.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Kubernetes용 Amazon VPC CNI 플러그인, CoreDNS 및 `kube-proxy` 추가 기능을 업데이트합니다. [서비스 계정 토큰](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)에 나열된 최소 버전으로 추가 기능을 업데이트하는 것이 좋습니다.
+ Amazon EKS 추가 기능을 사용하는 경우 Amazon EKS 콘솔에서 **클러스터**를 선택한 다음 왼쪽 검색 창에서 업데이트한 클러스터의 이름을 선택합니다. 콘솔에 알림이 표시됩니다. 사용 가능한 업데이트가 있는 추가 기능마다 새 버전을 사용할 수 있다는 알림이 표시됩니다. 추가 기능을 업데이트하려면 **추가 기능** 탭을 선택합니다. 사용 가능한 업데이트가 있는 추가 기능의 상자 중 하나에서 **지금 업데이트**를 선택하고 사용 가능한 버전을 선택한 다음 **업데이트**를 선택합니다.
+ AWS CLI 또는 `eksctl`을 사용하여 추가 기능을 업데이트할 수도 있습니다. 자세한 내용은 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 섹션을 참조하세요.
1. 필요하면 `kubectl`의 버전을 업데이트합니다. Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 `kubectl` 버전을 사용해야 합니다.
## Amazon EKS 클러스터에 대한 Kubernetes 버전 다운그레이드
Amazon EKS 클러스터의 Kubernetes는 다운그레이드할 수 없습니다. 대신 이전 Amazon EKS 버전에서 새 클러스터를 생성하고 워크로드를 마이그레이션하세요.
# 클러스터 삭제
Amazon EKS 클러스터 사용을 완료한 경우 불필요한 비용이 발생하지 않도록 클러스터와 연결된 리소스를 삭제해야 합니다.
`eksctl`, AWS Management Console 또는 AWS CLI를 사용하여 클러스터를 삭제할 수 있습니다.
## 고려 사항
+ 클러스터 생성자가 제거되어 오류가 발생하는 경우 문제를 해결하려면 [이 문서](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error)를 참조하세요.
+ Prometheus용 Amazon 관리형 서비스 리소스는 클러스터 수명 주기를 벗어나며 클러스터에 독립적으로 유지 관리되어야 합니다. 클러스터를 삭제할 때 해당 스크레이퍼도 모두 삭제하여 관련 비용을 줄여야 합니다. 자세한 내용은 **Prometheus용 Amazon 관리형 서비스 사용자 가이드의 [스크레이퍼 찾기 및 삭제](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete)를 참조하세요.
+ 연결된 클러스터를 제거하려면 [Amazon EKS 콘솔에서 Kubernetes 클러스터 등록 취소](deregister-connected-cluster.md) 섹션을 참조하세요.
+ 클러스터를 삭제하기 전에 클러스터에 대해 삭제 방지 기능이 비활성화되었는지 확인합니다.
### EKS Auto Mode 고려 사항
+ EC2 관리형 인스턴스를 포함하여 모든 EKS Auto Mode 노드가 삭제됩니다.
+ 모든 로드 밸런서가 삭제됩니다.
자세한 내용은 [EKS Auto Mode 비활성화](auto-disable.md) 섹션을 참조하세요.
## 사전 요구 사항 단계
다음은 클러스터를 삭제하기 전에 먼저 수행해야 하는 단계입니다. 이러한 단계는 클러스터를 삭제하는 데 사용하는 방법에 관계없이 적용됩니다.
1. 클러스터에서 실행 중인 모든 서비스를 나열합니다.
```
kubectl get svc --all-namespaces
```
1. `EXTERNAL-IP` 값과 연결된 모든 서비스를 삭제합니다. 이러한 서비스는 Elastic Load Balancing 로드 밸런서에 의해 설정되고, Kubernetes에서 이를 삭제하여 로드 밸런서 및 연결된 리소스가 적절하게 릴리스되어야 합니다. 설명과 같이 *service-name*을 나열된 각 서비스의 이름으로 바꿉니다.
```
kubectl delete svc service-name
```
1. 수신 리소스도 모두 삭제하세요. 수신 리소스를 삭제하지 않으면 클러스터를 삭제했어도 Application Load Balancer는 유지됩니다. *ingress-name*을 수신 리소스의 이름으로 바꾸세요.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## 클러스터 삭제(eksctl)
이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다.
```
eksctl version
```
`eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서의 [Installation](https://eksctl.io/installation)를 참조하세요.
1. [사전 조건 단계](#prerequisite-steps)로 진행하세요. 그리고 다음 명령으로 클러스터 및 연결된 노드를 삭제하되, *prod*를 클러스터 이름으로 변경하세요.
```
eksctl delete cluster --name prod
```
출력:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## 클러스터 삭제(AWS 콘솔)
1. [사전 조건 단계](#prerequisite-steps)로 진행하세요. 그리고 모든 노드 그룹 및 Fargate 프로파일을 삭제하세요.
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 왼쪽 탐색 창에서 Amazon EKS **클러스터**를 선택한 다음 탭으로 구분된 클러스터 목록에서 삭제할 클러스터의 이름을 선택합니다.
1. **컴퓨팅**탭을 선택하고 삭제할 노드 그룹을 선택합니다. **삭제**를 선택하고 노드 그룹의 이름을 입력한 다음 **삭제**를 선택합니다. 클러스터의 모든 노드 그룹을 삭제합니다.
**참고**
[관리형 노드 그룹](managed-node-groups.md)만 나열됩니다.
1. 삭제할 **Fargate 프로필**에 이어 **삭제**를 선택하고 프로필의 이름을 입력한 다음 **삭제**를 선택합니다. 클러스터의 모든 Fargate 프로필을 삭제합니다.
1. 모든 [자체 관리형 노드 AWS CloudFormation 스택](https://docs.aws.amazon.com/eks/latest/userguide/worker)을 삭제하세요.
1. [AWSCloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다.
1. 삭제할 노드 스택을 선택하고 **삭제**를 선택합니다.
1. **스택 삭제** 확인 대화 상자에서 **스택 삭제**를 선택합니다. 클러스터의 모든 자체 관리형 노드 스택을 삭제합니다.
1. 클러스터를 삭제합니다.
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 삭제할 클러스터를 선택하고 **삭제**를 선택합니다.
1. 클러스터 삭제 확인 화면에서 **삭제**를 선택합니다.
1. (선택사항) VPC AWS CloudFormation 스택을 삭제합니다.
1. [AWSCloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다.
1. 삭제할 VPC 스택을 선택하고 **삭제**를 선택합니다.
1. **스택 삭제** 확인 대화 상자에서 **스택 삭제**를 선택합니다.
## 클러스터를 삭제(AWS CLI)
1. [사전 조건 단계](#prerequisite-steps)로 진행하세요. 그리고 모든 노드 그룹 및 Fargate 프로파일을 삭제하세요.
1. 다음 명령을 사용하여 클러스터의 노드 그룹을 나열합니다.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**참고**
[관리형 노드 그룹](managed-node-groups.md)만 나열됩니다.
1. 다음 명령을 사용하여 각 노드 그룹을 삭제합니다. 클러스터의 모든 노드 그룹을 삭제합니다.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. 다음 명령을 사용하여 클러스터에 Fargate 프로필을 나열합니다.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. 다음 명령을 사용하여 각 Fargate 프로필을 삭제합니다. 클러스터의 모든 Fargate 프로필을 삭제합니다.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. 모든 [자체 관리형 노드 AWS CloudFormation 스택](https://docs.aws.amazon.com/eks/latest/userguide/worker)을 삭제하세요.
1. 다음 명령으로 사용 가능한 AWS CloudFormation 스택을 나열합니다. 결과 출력에서 노드 템플릿의 이름을 찾습니다.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 다음 명령으로 각 노드 스택을 삭제하되, *node-stack*을 노드 스택 이름으로 변경합니다. 클러스터의 모든 자체 관리형 노드 스택을 삭제합니다.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. 다음 명령으로 클러스터를 삭제하되, *my-cluster*를 사용할 클러스터 이름으로 변경합니다.
```
aws eks delete-cluster --name my-cluster
```
1. (선택사항) VPC AWS CloudFormation 스택을 삭제합니다.
1. 다음 명령으로 사용 가능한 AWS CloudFormation 스택을 나열합니다. 결과 출력에서 VPC 템플릿의 이름을 찾습니다.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 다음 명령으로 VPC 스택을 삭제하되, *my-vpc-stack*을 사용할 VPC 스택의 이름으로 변경합니다.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# 실수로 인한 삭제로부터 EKS 클러스터 보호
실수로 EKS 클러스터를 삭제하면 Kubernetes 클러스터 작업이 손상될 수 있습니다.
실수로 삭제되지 않도록 EKS 클러스터를 보호할 수 있습니다. 클러스터에서 삭제 방지를 활성화한 경우 클러스터를 삭제하기 전에 삭제 방지를 비활성화해야 합니다.
삭제 방지의 목적은 사고 방지입니다. 클러스터를 삭제할 권한이 있는 사용자를 신중하게 제한해야 합니다.
삭제 방지 기능이 설정된 활성 클러스터를 삭제하려고 하면 `InvalidRequestException`이 표시됩니다.
**중요**
클러스터에서 삭제 방지를 활성화한 경우 먼저 삭제 방지를 제거하고 마지막으로 클러스터를 삭제하려면 UpdateClusterConfig 및 DeleteCluster IAM 권한이 **모두** 있어야 합니다.
**참고**
클러스터 상태가 생성, 실패 또는 삭제 중인 경우 삭제 방지 기능이 설정되어 있어도 클러스터를 삭제할 수 있습니다.
## 기존 클러스터의 삭제 방지 활성화
활성 상태의 클러스터에서만 이 작업을 실행할 수 있습니다.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## 기존 클러스터의 삭제 방지 비활성화
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# 클러스터 API 서버 엔드포인트
이 주제에서는 Amazon EKS 클러스터의 Kubernetes API 서버 엔드포인트에 대한 프라이빗 액세스를 활성화하거나 인터넷에서 퍼블릭 액세스를 완전히 비활성화하는 방법을 설명합니다.
새 클러스터를 생성할 때 Amazon EKS에서는 클러스터와 통신하는 데 사용하는 관리형 Kubernetes API 서버에 대한 엔드포인트를 생성합니다(`kubectl`과 같은 Kubernetes 관리 도구 사용). 기본적으로 이 API 서버 엔드포인트는 인터넷에 공개되어 있으며, API 서버에 대한 액세스는 AWS Identity and Access Management(IAM) 및 기본 Kubernetes [역할 기반 액세스 제어](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)(RBAC)의 조합을 통해 보호됩니다. 이 엔드포인트를 *클러스터 퍼블릭 엔드포인트*라고 합니다. *클러스터 프라이빗 엔드포인트*도 있습니다. 클러스터 프라이빗 엔드포인트에 대한 자세한 내용은 다음 [클러스터 프라이빗 엔드포인트](#cluster-endpoint-private) 섹션을 참조하세요.
## `IPv6` 클러스터 엔드포인트 형식
EKS는 2024년 10월 이후에 만들어진 새 `IPv6` 클러스터에 대해 다음과 같은 형식으로 고유한 듀얼 스택 엔드포인트를 생성합니다. *IPv6 클러스터*는 클러스터의 IP 패밀리(`ipFamily`) 설정에서 `IPv6`를 선택하는 클러스터입니다.
**Example**
EKS 클러스터 퍼블릭/프라이빗 엔드포인트: `eks-cluster.region.api.aws`
EKS 클러스터 퍼블릭/프라이빗 엔드포인트: `eks-cluster.region.api.aws`
EKS 클러스터 퍼블릭/프라이빗 엔드포인트: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**참고**
이중 스택 클러스터 엔드포인트는 2024년 10월에 도입되었습니다. `IPv6` 클러스터에 대한 자세한 내용은 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md)을 참조하세요. 2024년 10월 이전에 생성된 클러스터는 대신 다음 엔드포인트 형식을 사용합니다.
## `IPv4` 클러스터 엔드포인트 형식
EKS는 클러스터의 IP 패밀리(ipFamily) 설정에서 `IPv4`를 선택하는 각 클러스터에 대해 다음 형식으로 고유한 엔드포인트를 생성합니다.
**Example**
EKS 클러스터 퍼블릭/프라이빗 엔드포인트 `eks-cluster.region.eks.amazonaws.com`
EKS 클러스터 퍼블릭/프라이빗 엔드포인트 `eks-cluster.region.eks.amazonaws.com`
EKS 클러스터 퍼블릭/프라이빗 엔드포인트 `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**참고**
2024년 10월 이전에 `IPv6` 클러스터는 이 엔드포인트 형식도 사용했습니다. 이러한 클러스터의 경우 퍼블릭 엔드포인트와 프라이빗 엔드포인트 모두 이 엔드포인트에서 확인된 `IPv4` 주소만 있습니다.
## 클러스터 프라이빗 엔드포인트
노드와 API 서버 간의 모든 통신이 VPC 내에 유지되도록 Kubernetes API 서버에 대한 프라이빗 액세스를 활성화할 수 있습니다. 인터넷에서 API 서버로 액세스하는 IP 주소를 제한하거나 API 서버로의 인터넷 액세스를 완전히 비활성화할 수 있습니다.
**참고**
이 엔드포인트는 Kubernetes API 서버이며 AWS API와 통신하기 위한 기존 AWS PrivateLink 엔드포인트가 아니므로 Amazon VPC 콘솔에서 엔드포인트로 표시되지 않습니다.
클러스터에 대해 엔드포인트 프라이빗 액세스를 활성화하면 Amazon EKS에서는 사용자 대신 Route 53 프라이빗 호스팅 영역을 생성하고 클러스터의 VPC에 연결합니다. 이 프라이빗 호스팅 영역은 Amazon EKS에서 관리하며, 사용자 계정의 Route 53 리소스에는 표시되지 않습니다. 프라이빗 호스팅 영역이 API 서버로 트래픽을 올바로 라우팅하려면 VPC에서 `enableDnsHostnames` 및 `enableDnsSupport`가 `true`로 설정되어야 하고, VPC에 설정된 DHCP 옵션이 도메인 이름 서버 목록에 `AmazonProvidedDNS`를 포함해야 합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC에 대한 DNS 지원 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)를 참조하세요.
새 클러스터를 생성할 때 API 서버 엔드포인트 액세스 요구 사항을 정의할 수 있으며, 언제든지 클러스터에 대한 API 서버 엔드포인트 액세스를 업데이트할 수 있습니다.
## 클러스터 엔드포인트 액세스 수정
이 섹션의 절차를 통해 기존 클러스터에 대한 엔드포인트 액세스를 수정합니다. 다음 표에는 지원되는 API 서버 엔드포인트 액세스 조합과 연결된 동작이 나와 있습니다.
| 엔드포인트 퍼블릭 액세스 | 엔드포인트 프라이빗 액세스 | 동작 |
| --- | --- | --- |
| 활성화됨 | 비활성 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-endpoint.html) |
| 활성화됨 | 활성화됨 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-endpoint.html) |
| 비활성 | 활성화됨 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-endpoint.html) |
**엔드포인트 액세스 제어**
엔드포인트 액세스를 제어하는 다음의 각 방법은 각 엔드포인트에만 영향을 미칩니다.
*클러스터 보안 그룹*
클러스터 보안 그룹은 *kubelet API*에 대한 연결과 프라이빗 엔드포인트에 대한 연결이라는 두 가지 유형의 연결을 제어합니다. `kubelet` API에 대한 연결은 `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs`, `kubectl port-forward` 명령에서 사용됩니다. 클러스터 보안 그룹은 퍼블릭 엔드포인트에 영향을 주지 않습니다.
*퍼블릭 액세스 CIDR*
*퍼블릭 액세스 CIDR*은 CIDR 블록 목록에 따라 퍼블릭 엔드포인트에 대한 액세스를 제어합니다. 퍼블릭 액세스 CIDR은 프라이빗 엔드포인트에 영향을 주지 않습니다. 퍼블릭 액세스 CIDR은 생성된 날짜에 따라 `IPv6` 클러스터와 `IPv4` 클러스터에서 다르게 동작하며, 이는 다음과 같습니다.
**퍼블릭 엔드포인트의 CIDR 블록(`IPv6` 클러스터)**
퍼블릭 엔드포인트는 듀얼 스택이므로 `IPv6` 클러스터의 퍼블릭 엔드포인트에 `IPv6` 및 `IPv4` CIDR 블록을 추가할 수 있습니다. 이는 2024년 10월 이후에 생성하고 `ipFamily`가 `IPv6`로 설정된 새 클러스터에만 적용됩니다. 새 엔드포인트 도메인 이름인 `api.aws`로 이러한 클러스터를 식별할 수 있습니다.
**퍼블릭 엔드포인트의 CIDR 블록(`IPv4` 클러스터)**
`IPv4` 클러스터의 퍼블릭 엔드포인트에 `IPv4` CIDR 블록을 추가할 수 있습니다. `IPv4` 클러스터의 퍼블릭 엔드포인트에 `IPv6` CIDR 블록을 추가할 수 없습니다. 시도하면 EKS에서 다음 오류 메시지를 반환합니다. `The following CIDRs are invalid in publicAccessCidrs`
**퍼블릭 엔드포인트의 CIDR 블록(2024년 10월 이전에 만들어진 `IPv6` 클러스터)**
2024년 10월 이전에 만든 이전 `IPv6` 클러스터의 퍼블릭 엔드포인트에 `IPv4` CIDR 블록을 추가할 수 있습니다. `eks.amazonaws.com` 엔드포인트로 이러한 클러스터를 식별할 수 있습니다. 2024년 10월 이전에 만든 이러한 이전 `IPv6` 클러스터의 퍼블릭 엔드포인트에 `IPv6` CIDR 블록을 추가할 수 없습니다. 시도하면 EKS에서 다음 오류 메시지를 반환합니다. `The following CIDRs are invalid in publicAccessCidrs`
## 프라이빗 전용 API 서버 액세스
클러스터의 Kubernetes API 서버 엔드포인트에 대해 퍼블릭 액세스를 비활성화하면 VPC 또는 [연결된 네트워크](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 내에서만 API 서버에 액세스할 수 있습니다. Kubernetes API 서버 엔드포인트에 액세스하는 방법은 다음과 같습니다.
**연결된 네트워크**
[AWS 전송 게이트웨이](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 또는 기타 [연결](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) 옵션을 사용하여 네트워크를 VPC에 연결한 다음 연결된 네트워크의 컴퓨터를 사용합니다. Amazon EKS 제어 영역 보안 그룹에 연결된 네트워크의 포트 443에서 수신 트래픽을 허용하는 규칙이 포함되어 있는지 확인해야 합니다.
**Amazon EC2 Bastion Host**
Amazon EC2 인스턴스를 클러스터의 VPC에 있는 퍼블릭 서브넷으로 시작한 다음 SSH를 통해 해당 인스턴스에 로그인하여 `kubectl` 명령을 실행할 수 있습니다. 자세한 내용은 [AWS 기반 Linux Bastion 호스트](https://aws.amazon.com/quickstart/architecture/linux-bastion/)를 참조하세요. Amazon EKS 제어 영역 보안 그룹에 Bastion 호스트의 포트 443에서 수신 트래픽을 허용하는 규칙이 포함되어 있는지 확인해야 합니다. 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요.
Bastion Host에 대해 `kubectl`을 구성할 때 클러스터의 RBAC 구성에 이미 매핑된 AWS 자격 증명을 사용하거나, 엔드포인트 퍼블릭 액세스를 제거하기 전에 Bastion에서 사용할 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)를 RBAC 구성에 추가해야 합니다. 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 및 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 섹션을 참조하세요.
** AWS Cloud9 IDE**
AWS Cloud9는 브라우저만으로 코드를 작성, 실행 및 디버깅할 수 있는 클라우드 기반 통합 개발 환경(IDE)입니다. 클러스터의 VPC에 AWS Cloud9 IDE를 생성할 수 있으며, IDE를 사용하여 클러스터와 통신할 수 있습니다. 자세한 내용은 [AWS Cloud9에서 환경 생성](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html)을 참조하세요. Amazon EKS 제어 영역 보안 그룹에 IDE 보안 그룹의 포트 443에서 수신 트래픽을 허용하는 규칙이 포함되어 있는지 확인해야 합니다. 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요.
AWS Cloud9 IDE에 대해 `kubectl`을 구성할 때 클러스터의 RBAC 구성에 이미 매핑된 AWS 자격 증명을 사용하거나, 엔드포인트 퍼블릭 액세스를 제거하기 전에 IDE에서 사용할 IAM 보안 주체를 RBAC 구성에 추가해야 합니다. 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 및 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized)(을)를 참조하세요.
📝 [GitHub에서 이 페이지 편집](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# 클러스터 API 서버 엔드포인트에 대한 네트워크 액세스 구성
다음 섹션에서 AWS Management Console 또는 AWS CLI를 사용하여 클러스터 API 서버 엔드포인트 액세스를 수정할 수 있습니다.
## 엔드포인트 액세스 구성 - AWS 콘솔
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 정보를 표시합니다.
1. **네트워킹** 탭과 **엔드포인트 액세스 관리**를 차례대로 선택합니다.
1. **프라이빗 액세스**에서 클러스터의 Kubernetes API 서버 엔드포인트에 대해 프라이빗 액세스를 활성화할지 아니면 비활성화할지를 선택합니다. 프라이빗 액세스를 활성화하면 클러스터의 VPC 내에서 비롯된 Kubernetes API 요청이 프라이빗 VPC 엔드포인트를 사용합니다. 퍼블릭 액세스를 비활성화하려면 프라이빗 액세스를 활성화해야 합니다.
1. **퍼블릭 액세스**에서 클러스터의 Kubernetes API 서버 엔드포인트에 대해 퍼블릭 액세스를 활성화할지 아니면 비활성화할지를 선택합니다. 퍼블릭 액세스를 비활성화하면 클러스터의 Kubernetes API 서버가 클러스터의 VPC 내에서 비롯된 요청만 수신할 수 있습니다.
1. (선택사항) **퍼블릭 액세스**를 활성화한 경우, 인터넷에서 퍼블릭 엔드포인트와 통신할 수 있는 주소를 지정할 수 있습니다. **고급 설정**을 선택합니다. CIDR 블록(예: *203.0.113.5/32)*을 입력합니다. 블록에는 [예약된 주소](https://en.wikipedia.org/wiki/Reserved_IP_addresses)가 포함될 수 없습니다. **Add Source(소스 추가)**를 선택하여 추가 블록을 입력할 수 있습니다. 지정할 수 있는 최대 CIDR 블록 수가 있습니다. 자세한 내용은 [Amazon EKS 및 Fargate Service Quotas 보기 및 관리](service-quotas.md) 섹션을 참조하세요. 블록을 지정하지 않으면 퍼블릭 API 서버 엔드포인트는 듀얼 스택 `IPv6` 클러스터에 대한 `IPv4`(`0.0.0.0/0`)와 `IPv6`(`::/0`)의 모든 IP 주소에서 요청을 수신합니다. CIDR 블록을 사용하여 퍼블릭 엔드포인트에 대한 액세스를 제한하는 경우, 노드와 Fargate Pods(사용하는 경우)가 클러스터와 통신할 수 있도록 프라이빗 엔드포인트 액세스도 활성화하는 것이 좋습니다. 프라이빗 엔드포인트를 활성화하지 않은 경우, 퍼블릭 액세스 엔드포인트 CIDR 소스에는 VPC의 송신 소스가 포함되어야 합니다. 예를 들어, NAT 게이트웨이를 통해 인터넷과 통신하는 프라이빗 서브넷에 노드가 있는 경우, 퍼블릭 엔드포인트에서 허용하는 CIDR 블록의 일부로 NAT 게이트웨이의 아웃바운드 IP 주소를 추가해야 합니다.
1. **업데이트**를 선택하여 완료합니다.
## 엔드포인트 액세스 구성 - AWS CLI
AWS CLI 버전 `1.27.160` 이상을 사용하여 다음 단계를 완료합니다. `aws --version`을 사용하여 현재 버전을 확인할 수 있습니다. AWS CLI를 설치하거나 업그레이드하려면 [AWS CLI 설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)를 참조하세요.
1. 다음 AWS CLI 명령을 통해 클러스터 API 서버 엔드포인트 액세스를 업데이트합니다. 클러스터 이름과 원하는 엔드포인트 액세스 값을 대체합니다. `endpointPublicAccess=true`를 설정한 경우 선택적으로 단일 CIDR 블록 또는 `publicAccessCidrs`에 대한 쉼표로 구분된 CIDR 블록 목록을 입력할 수 있습니다. 블록에는 [예약된 주소](https://en.wikipedia.org/wiki/Reserved_IP_addresses)가 포함될 수 없습니다. CIDR 블록을 지정한 경우 퍼블릭 API 서버 엔드포인트는 나열된 블록에서만 요청을 수신합니다. 지정할 수 있는 최대 CIDR 블록 수가 있습니다. 자세한 내용은 [Amazon EKS 및 Fargate Service Quotas 보기 및 관리](service-quotas.md) 섹션을 참조하세요. CIDR 블록을 사용하여 퍼블릭 엔드포인트에 대한 액세스를 제한하는 경우, 노드와 Fargate Pods(사용하는 경우)가 클러스터와 통신할 수 있도록 프라이빗 엔드포인트 액세스도 활성화하는 것이 좋습니다. 프라이빗 엔드포인트를 활성화하지 않은 경우, 퍼블릭 액세스 엔드포인트 CIDR 소스에는 VPC의 송신 소스가 포함되어야 합니다. 예를 들어, NAT 게이트웨이를 통해 인터넷과 통신하는 프라이빗 서브넷에 노드가 있는 경우, 퍼블릭 엔드포인트에서 허용하는 CIDR 블록의 일부로 NAT 게이트웨이의 아웃바운드 IP 주소를 추가해야 합니다. CIDR 블록을 지정하지 않으면 퍼블릭 API 서버 엔드포인트는 듀얼 스택 `IPv6` 클러스터에 대한 모든 (0.0.0.0/0) IP 주소와 `IPv6`(`::/0`)에서 요청을 수신합니다.
**참고**
다음 명령은 API 서버 엔드포인트에 대한 단일 IP 주소에서 프라이빗 액세스 및 퍼블릭 액세스를 활성화합니다. *203.0.113.5/32*를 단일 CIDR 블록 또는 네트워크 액세스를 제한할 쉼표로 구분된 CIDR 블록 목록으로 바꿉니다.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
예제 출력은 다음과 같습니다.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. 이전 명령에서 반환된 클러스터 이름과 업데이트 ID를 사용하여 다음 명령으로 엔드포인트 액세스 업데이트의 상태를 모니터링합니다. 상태가 `Successful`로 표시되면 업데이트가 완료된 것입니다.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
예제 출력은 다음과 같습니다.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [GitHub에서 이 페이지 편집](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# EKS 클러스터에 Windows 노드 배포
Amazon EKS 클러스터에 대한 Windows 지원을 활성화하고 관리하여 Linux 컨테이너와 함께 Windows 컨테이너를 실행하는 방법을 알아봅니다.
## 고려 사항
Windows 노드를 배포하기 전에 다음 사항을 고려해야 합니다.
+ EKS Auto Mode는 Windows 노드를 지원하지 않습니다.
+ `HostProcess` 포드로 Windows 노드에서 호스트 네트워킹을 사용할 수 있습니다. 자세한 내용은 Kubernetes Documentation의 [Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)를 참조하세요.
+ Amazon EKS 클러스터에는 CoreDNS와 같이 Linux에서만 실행되는 코어 시스템 포드를 실행하기 위한 Linux 또는 Fargate 노드가 하나 이상 있어야 합니다.
+ `kubelet` 및 `kube-proxy` 이벤트 로그는 `EKS Windows` 이벤트 로그로 리디렉션되며 200MB 제한으로 설정됩니다.
+ Windows 노드에서 실행 중인 포드가 있는 [개별 포드에 보안 그룹 할당](security-groups-for-pods.md)을 사용할 수 없습니다.
+ Windows 노드에서는 [사용자 지정 네트워킹](cni-custom-network.md)을 사용할 수 없습니다.
+ Windows 노드에서는 `IPv6`를 사용할 수 없습니다.
+ Windows 노드는 노드당 하나의 탄력적 네트워크 인터페이스를 지원합니다. 기본적으로 Windows 노드당 실행할 수 있는 포드 수는 노드의 인스턴스 유형에 대해 탄력적 네트워크 인터페이스당 사용 가능한 IP 주소 수에서 1을 뺀 값과 같습니다. 자세한 내용은 Amazon EC2 사용 설명서의 [IP addresses per network interface per instance type](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)를 참조하세요.**
+ Amazon EKS 클러스터에서 로드 밸런서가 있는 단일 서비스는 최대 1,024개의 백엔드 포드를 지원할 수 있습니다. 각 포드에는 고유한 IP 주소가 있습니다. [OS 빌드 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4)부터 [Windows Server 업데이트](https://github.com/microsoft/Windows-Containers/issues/93) 후 이전의 포드 64개 제한이 더 이상 적용되지 않습니다.
+ Windows 컨테이너는 Fargate의 Amazon EKS 포드에 대해 지원되지 않습니다.
+ Amazon EKS Hybrid Nodes를 Windows와 함께 호스트의 운영 체제로 사용할 수 없습니다.
+ `vpc-resource-controller` 포드에서 로그를 검색할 수 없습니다. 이전에는 컨트롤러를 데이터 영역에 배포할 때 가능했습니다.
+ `IPv4` 주소가 새 포드에 할당되기 전에 휴지 기간이 있습니다. 이렇게 하면 오래된 `kube-proxy` 규칙으로 인해 동일한 `IPv4` 주소를 사용하는 이전 포드로 트래픽이 흐르는 것을 방지할 수 있습니다.
+ 컨트롤러의 소스는 GitHub에서 관리됩니다. 컨트롤러에 기여하거나 컨트롤러에 대한 문제를 제기하려면 GitHub의 [project](https://github.com/aws/amazon-vpc-resource-controller-k8s)를 방문하세요.
+ Windows 관리형 노드 그룹에 사용자 지정 AMI ID를 지정할 때는 AWS IAM Authenticator 구성 맵에 `eks:kube-proxy-windows`를 추가합니다. 자세한 내용은 [AMI ID 지정 시 제한과 조건](launch-templates.md#mng-ami-id-conditions) 섹션을 참조하세요.
+ 사용 가능한 IPv4 주소를 유지하는 것이 서브넷에 중요한 경우 [EKS Best Practices Guide - Windows Networking IP Address Management](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management)를 참조하세요.
+ EKS 액세스 항목에 대한 고려 사항
+ Windows 노드와 함께 사용할 액세스 항목에는 `EC2_WINDOWS` 유형이 필요합니다. 자세한 내용은 [액세스 항목 생성](creating-access-entries.md) 섹션을 참조하세요.
Windows 노드에 대한 액세스 항목을 생성하려면 다음을 수행하세요.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## 사전 조건
+ 기존 클러스터가 있어야 합니다.
+ CoreDNS를 실행하려면 클러스터에 Linux 노드 또는 Fargate 포드가 1개 이상(최소 2개 권장) 있어야 합니다. 레거시 Windows 지원을 사용 설정하는 경우 Linux 노드(Fargate 포드 사용 불가)를 사용하여 CoreDNS를 실행해야 합니다.
+ 기존 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md).
## Windows 지원 사용
1. 클러스터에 Amazon Linux 노드가 없고 포드에 보안 그룹을 사용하는 경우 다음 단계로 건너뜁니다. 그렇지 않으면 `AmazonEKSVPCResourceController` 관리형 정책이 [클러스터 역할](cluster-iam-role.md)에 연결되어 있는지 확인합니다. *eksClusterRole*을 클러스터 역할 이름으로 바꿉니다.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
예제 출력은 다음과 같습니다.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
이전 출력에서와 같이 정책이 연결된 경우 다음 단계를 건너뜁니다.
1. ** [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html) ** 관리형 정책을 [Amazon EKS 클러스터 IAM 역할 ](cluster-iam-role.md)에 연결합니다. *eksClusterRole*을 클러스터 역할 이름으로 바꿉니다.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. VPC CNI ConfigMap을 업데이트하여 Windows IPAM을 활성화합니다. 참고로, 헬름 차트를 사용하거나 Amazon EKS 추가 기능으로 클러스터에 VPC CNI를 설치한 경우 ConfigMap을 직접 수정하지 못할 수 있습니다. Amazon EKS 추가 기능 구성에 대한 자세한 내용은 [Amazon EKS 추가 기능에 대해 사용자 지정할 수 있는 필드 확인](kubernetes-field-management.md) 섹션을 참조하세요.
1. 다음 내용이 포함된 *vpc-resource-controller-configmap.yaml*이라는 파일을 생성합니다.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. 클러스터에 `ConfigMap` 적용.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. 클러스터에 `aws-auth` configmap을 활성화하도록 인증 모드가 설정된 경우
+ `aws-auth` `ConfigMap`에 Windows 노드의 인스턴스 역할에 대한 매핑이 포함되어 `eks:kube-proxy-windows` RBAC 권한 그룹을 포함하는지 확인합니다. 다음 명령을 실행하여 확인할 수 있습니다.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
예제 출력은 다음과 같습니다.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
그룹 아래에 `eks:kube-proxy-windows`가 표시될 것입니다. 그룹이 지정되지 않은 경우 `ConfigMap`을 업데이트하거나 생성하여 필수 그룹을 포함해야 합니다. `aws-auth` `ConfigMap`에 대한 자세한 내용은 [클러스터에 `aws-auth` `ConfigMap` 적용](auth-configmap.md#aws-auth-configmap) 섹션을 참조하세요.
1. 클러스터에 `aws-auth` configmap을 비활성화하도록 인증 모드가 설정된 경우 EKS 액세스 항목을 사용할 수 있습니다. Windows 인스턴스와 함께 사용할 새 노드 역할을 생성하면 EKS가 `EC2_WINDOWS` 유형의 액세스 항목을 자동으로 생성합니다.
## Windows 포드 배포
클러스터에 포드를 배포할 때 노드 유형을 혼합하여 실행하는 경우 사용되는 운영 체제를 지정해야 합니다.
Linux 포드의 경우 매니페스트에서 다음 노드 선택기 텍스트를 사용합니다.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Windows 포드의 경우 매니페스트에서 다음 노드 선택기 텍스트를 사용합니다.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
[샘플 애플리케이션](sample-deployment.md)을 배포하여 사용 중인 노드 선택기를 볼 수 있습니다.
## Windows 노드에서 더 높은 포드 밀도 지원
Amazon EKS에서 각 포드에는 VPC의 `IPv4` 주소가 할당됩니다. 이로 인해 노드에서 더 많은 포드를 실행하기에 충분한 리소스가 있더라도 노드에 배포할 수 있는 포드 수는 사용 가능한 IP 주소에 의해 제한됩니다. Windows 노드에서는 탄력적 네트워크 인터페이스를 하나만 지원하므로 기본적으로 Windows 노드에서 사용 가능한 최대 IP 주소 수는 다음과 같습니다.
```
Number of private IPv4 addresses for each interface on the node - 1
```
하나의 IP 주소는 네트워크 인터페이스의 기본 IP 주소로 사용되므로 포드에 할당할 수 없습니다.
IP 접두사 위임을 활성화하여 Windows 노드에서 더 높은 포드 밀도를 활성화할 수 있습니다. 이 기능을 사용하면 보조 `IPv4` 주소를 할당하는 대신 기본 네트워크 인터페이스에 `/28` `IPv4` 접두사를 할당할 수 있습니다. IP 접두사를 할당하면 노드에서 사용 가능한 최대 `IPv4` 주소가 다음으로 증가합니다.
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
이렇게 사용 가능한 IP 주소의 수가 상당히 많기 때문에 사용 가능한 IP 주소가 노드의 포드 수를 확장하는 기능을 제한하지는 않습니다. 자세한 내용은 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md) 섹션을 참조하세요.
# Windows 지원 사용 중지
1. 클러스터에 Amazon Linux 노드가 포함되어 있고 [포드에 보안 그룹](security-groups-for-pods.md)을 함께 사용하는 경우 이 단계를 건너뜁니다.
[클러스터 역할](cluster-iam-role.md)에서 `AmazonVPCResourceController` 관리형 IAM 정책을 제거합니다. *eksClusterRole*을 클러스터 역할의 이름으로 바꿉니다.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. `amazon-vpc-cni` ConfigMap에서 Windows IPAM을 사용 중지합니다.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# 인터넷 액세스가 제한된 프라이빗 클러스터 배포
이 주제에서는 아웃바운드 인터넷 액세스 권한이 없는 AWS 클라우드에 대해, Amazon EKS 클러스터를 배포하는 방법을 설명합니다. AWS Outposts에 로컬 클러스터가 있는 경우 이 항목 대신 [AWS Outposts에 Amazon Linux 노드 생성](eks-outposts-self-managed-nodes.md)를 참조하세요.
Amazon EKS 네트워킹에 익숙하지 않은 경우 [Amazon EKS 작업자 노드에 대한 클러스터 네트워킹 설명](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes)을 참조하세요. 클러스터에 아웃바운드 인터넷 액세스 권한이 없는 경우에는 다음과 같은 요구 사항을 충족해야 합니다.
## 클러스터 아키텍처 요구 사항
+ 클러스터에서는 VPC에 있는 컨테이너 레지스트리에서 이미지를 가져와야 합니다. VPC에서 Amazon Elastic Container Registry를 생성하고 노드에서 가져올 컨테이너 이미지를 복사할 수 있습니다. 자세한 내용은 [한 리포지토리에서 다른 리포지토리로 컨테이너 이미지 복사](copy-image-to-repository.md) 섹션을 참조하세요.
+ 클러스터에 활성화된 엔드포인트 프라이빗 액세스 권한이 있어야 합니다. 노드에서 클러스터 엔드포인트에 등록하려면 이 권한이 필요합니다. 엔드포인트 퍼블릭 액세스는 선택 사항입니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요.
## 노드 요구 사항
+ 자체 관리형 Linux 노드와 Windows 노드에서는 시작하기 전에 다음과 같은 부트스트랩 인수가 포함되어야 합니다. 이러한 인수에서는 Amazon EKS 내부 검사를 우회하며 VPC 내에서 Amazon EKS API에 액세스하는 권한이 필요하지 않습니다.
1. 다음과 같은 명령으로 클러스터의 엔드포인트 값을 결정합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
예제 출력은 다음과 같습니다.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. 다음과 같은 명령으로 클러스터의 인증 기관 값을 결정합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
반환된 출력은 긴 문자열입니다.
1. NodeConfig 객체의 `apiServerEndpoint` 및 `certificateAuthority` 값을 이전 명령의 출력에서 반환된 값으로 바꾸세요. 자체 관리형 Amazon Linux 2023 노드 시작 시 부트스트랩 인수 지정에 대한 자세한 내용은 [자체 관리형 Amazon Linux 노드 생성](launch-workers.md) 및 [자체 관리형 Microsoft Windows 노드 생성](launch-windows-workers.md) 섹션을 참조하세요.
+ Linux 노드의 경우:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
추가 인수는 GitHub에서 [부트스트랩 스크립트](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)를 참조하세요.
+ Windows 노드의 경우:
**참고**
사용자 지정 서비스 CIDR을 사용하는 경우`-ServiceCIDR` 파라미터를 사용하여 CIDR을 지정해야 합니다. 그렇지 않으면 클러스터의 포드에 대한 DNS 확인이 실패합니다.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
추가 인수는 [부트스트랩 스크립트 구성 파라미터](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) 부분을 참조하세요.
+ 클러스터의 `aws-auth` `ConfigMap`은 VPC 내에서 생성해야 합니다. 항목을 생성하고 `aws-auth` `ConfigMap`에 추가하는 방법에 대한 자세한 내용을 보려면 터미널에 `eksctl create iamidentitymapping --help`를 입력합니다. `ConfigMap`이 서버에 없는 경우 `eksctl`에서는 명령을 사용해 ID 매핑을 추가할 때 해당 항목을 생성합니다.
## 포드 요구 사항
+ **Pod Identity** - EKS Pod Identity로 구성된 포드는 EKS Auth API에서 자격 증명을 획득합니다. 아웃바운드 인터넷 액세스 권한이 없는 경우 EKS Auth API에 대해 `com.amazonaws.region-code.eks-auth` VPC 엔드포인트를 생성하고 사용해야 합니다. EKS 및 EKS Auth VPC 엔드포인트에 대한 자세한 내용은 [AWS PrivateLink를 사용하여 Amazon EKS에 액세스](vpc-interface-endpoints.md) 섹션을 참조하세요.
+ **IRSA** - [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)로 구성된 포드에서는 AWS Security Token Service(AWS STS) API 직접 호출에서 자격 증명을 취득합니다. 아웃바운드 인터넷 액세스 권한이 없는 경우 VPC에서 AWS STS VPC 엔드포인트를 생성하고 사용해야 합니다. 대부분의 AWS `v1` SDK는 기본적으로 글로벌 AWS STS 엔드포인트를 사용하며(`sts.amazonaws.com`), AWS STS VPC 엔드포인트는 사용하지 않습니다. AWS STS VPC 엔드포인트를 사용하려면 리전별 AWS 엔드포인트(`sts.region-code.amazonaws.com`)를 사용하도록 SDK를 구성해야 할 수도 있습니다. 자세한 내용은 [서비스 계정의 AWS 보안 토큰 서비스 엔드포인트 구성](configure-sts-endpoint.md) 섹션을 참조하세요.
+ 클러스터의 VPC 서브넷에는 포드에서 액세스해야 하는 모든 AWS 서비스에 대한 VPC 인터페이스 엔드포인트가 있어야 합니다. 자세한 내용은 [인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스에 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)를 참조하세요. 일반적으로 사용하는 몇 가지 서비스와 엔드포인트가 아래 표에 나열되어 있습니다. 엔드포인트의 전체 목록은 [AWS PrivateLink 가이드](https://docs.aws.amazon.com/vpc/latest/privatelink/)에서 [AWS PrivateLink와 통합되는 AWS 서비스](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)를 참조하세요.
VPC 엔드포인트의 [프라이빗 DNS 이름을 활성화](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names)하는 것이 좋습니다. 이렇게 하면 워크로드가 문제 없이 퍼블릭 AWS 서비스 엔드포인트를 계속 사용할 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/private-clusters.html)
+ 자체 관리형 노드는 필요한 VPC 인터페이스 엔드포인트가 있는 서브넷에 배포해야 합니다. 관리형 노드 그룹을 생성하는 경우 VPC 인터페이스 엔드포인트 보안 그룹에서 서브넷에 대한 CIDR을 허용하거나 본인이 생성된 노드 보안 그룹을 VPC 인터페이스 엔드포인트 보안 그룹에 추가해야 합니다.
+ **EFS 스토리지** - 포드에서 Amazon EFS 볼륨을 사용하는 경우 [Amazon EFS로 저장된 탄력적 파일 시스템](efs-csi.md)을 배포하기 전에 컨테이너 이미지가 Amazon EKS 클러스터와 동일한 AWS 리전을 사용하도록 설정하도록 드라이버의 [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) 파일을 변경해야 합니다.
+ Route53는 AWS PrivateLink를 지원하지 않습니다. 프라이빗 Amazon EKS 클러스터에서는 Route53 DNS 레코드를 관리할 수 없습니다. 이는 Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns)에 영향을 미칩니다.
+ EKS 최적화 AMI를 사용하는 경우 위 표의`ec2` 엔드포인트를 활성화해야 합니다. 또는 노드 DNS 이름을 수동으로 설정할 수 있습니다. 최적화된 AMI는 EC2 API를 사용하여 노드 DNS 이름을 자동으로 설정합니다.
+ [AWS 로드 밸런서 컨트롤러](aws-load-balancer-controller.md)를 사용하여 AWS 애플리케이션 로드 밸런서(ALB) 및 네트워크 로드 밸런서를 프라이빗 클러스터에 배포할 수 있습니다. 배포할 때 [명령줄 플래그](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags)를 사용하여 `enable-shield`, `enable-waf` 및 `enable-wafv2`를 false로 설정해야 합니다. 수신 객체의 호스트 이름을 사용한 [인증서 검색](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host)은 지원되지 않습니다. 이는 컨트롤러가 VPC 인터페이스 엔드포인트가 없는 AWS 인증서 관리자에 연결해야 하기 때문입니다.
컨트롤러는 Fargate와 함께 사용하는 데 필요한 IP 대상이 있는 Network Load Balancer를 지원합니다. 자세한 내용은 [Application Load Balancer를 사용하여 애플리케이션 및 HTTP 트래픽 라우팅](alb-ingress.md) 및 [Network Load Balancer 생성](network-load-balancing.md#network-load-balancer)(을)를 참조하세요.
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)가 지원됩니다. Cluster Autoscaler 포드를 배포할 때 명령줄이 `--aws-use-static-instance-list=true`를 포함하는지 확인하세요. 자세한 내용은 GitHub에서 [정적 인스턴스 목록 사용](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list)을 참조하세요. 작업자 노드 VPC에는 AWS STS VPC 엔드포인트 및 자동 크기 조정 VPC 엔드포인트도 포함되어야 합니다.
+ 일부 컨테이너 소프트웨어 제품은 사용량을 모니터링하는 AWS Marketplace 미터링 서비스에 액세스하는 API 직접 호출을 사용합니다. 프라이빗 클러스터에서는 이러한 직접 호출이 허용되지 않으므로 이러한 컨테이너 유형은 프라이빗 클러스터에서 사용할 수 없습니다.
# Karpenter 및 Cluster Autoscaler를 사용한 클러스터 컴퓨팅 규모 조정
자동 크기 조정은 변화하는 요구 사항에 맞게 리소스 규모를 자동으로 조정하는 기능입니다. 이는 Kubernetes의 주요 기능이며 그렇지 않으면 수동으로 수행하기 위한 광범위한 인적 자원을 필요로 할 것입니다.
## EKS Auto Mode
Amazon EKS Auto Mode는 클러스터 컴퓨팅 리소스의 규모를 자동으로 조정합니다. 포드를 기존 노드에 맞출 수 없는 경우 EKS Auto Mode가 새 포드를 생성합니다. 또한 EKS Auto Mode는 워크로드를 통합하고 노드를 삭제합니다. EKS Auto Mode는 Karpenter를 기반으로 빌드됩니다.
자세한 내용은 다음을 참조하세요.
+ [EKS Auto Mode를 사용하여 클러스터 인프라 자동화](automode.md)
+ [EKS Auto Mode용 노드 풀 생성](create-node-pool.md)
+ [Amazon EKS Auto Mode 클러스터에 샘플 팽창 워크로드 배포](automode-workload.md)
## 추가 솔루션
Amazon EKS는 두 가지 자동 크기 조정 제품을 추가로 지원합니다.
**Karpenter**
Karpenter는 애플리케이션 가용성과 클러스터 효율성을 개선하는 데 도움이 되는 유연한 고성능 Kubernetes Cluster Autoscaler입니다. Karpenter는 1분 이내에 애플리케이션 로드의 변화에 대응하여 적절한 크기의 컴퓨팅 리소스(예: Amazon EC2 인스턴스)를 시작합니다. Kubernetes를 AWS와 통합함으로써 Karpenter는 워크로드의 요구 사항을 정확하게 충족하는 JIT(Just-In-Time) 컴퓨팅 리소스를 프로비저닝할 수 있습니다. Karpenter는 클러스터 워크로드의 특정 요구 사항을 기반으로 새로운 컴퓨팅 리소스를 자동으로 프로비저닝합니다. 여기에는 컴퓨팅, 스토리지, 가속화 및 예약 요구 사항이 포함됩니다. Amazon EKS는 Karpenter를 사용하는 클러스터를 지원하지만 Karpenter는 호환되는 모든 Kubernetes 클러스터에서 작동합니다. 자세한 내용은 [Karpenter](https://karpenter.sh/docs/) 설명서를 참조하세요.
Karpenter는 AWS 고객이 Kubernetes 클러스터에서 설치, 구성 및 관리할 책임이 있는 오픈 소스 소프트웨어입니다. 는 Karpenter가 Amazon EKS 클러스터의 호환 버전을 사용하여 수정되지 않은 상태로 실행될 때 기술 지원을 AWS 제공합니다. 고객이 다른 고객 관리형 소프트웨어와 마찬가지로 Karpenter 컨트롤러를 업그레이드하거나 실행 중인 Kubernetes 클러스터를 업그레이드할 때 Karpenter 컨트롤러의 가용성 및 보안과 적절한 테스트 절차를 유지하는 것이 중요합니다. Karpenter에 대한 AWS 서비스 수준 계약(SLA)은 없으며 고객은 Karpenter가 시작한 EC2 인스턴스가 비즈니스 요구 사항을 충족하는지 확인할 책임이 있습니다.
**Cluster Autoscaler**
Kubernetes Cluster Autoscaler는 포드가 실패하거나 다른 노드로 다시 예약될 때 클러스터의 노드 수를 자동으로 조정합니다. Cluster Autoscaler는 Auto Scaling을 사용합니다. 자세한 내용은 [AWS의 Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 참조하세요.
# Amazon EKS에서 Amazon Application Recovery Controller(ARC)의 영역 전환에 대해 알아보기
Kubernetes에는 가용 영역(AZ)의 상태 저하 또는 손상과 같은 이벤트에 대해 애플리케이션을 보다 탄력적으로 만들 수 있는 기본 기능이 있습니다. Amazon EKS 클러스터에서 워크로드를 실행하는 경우때 [Amazon Application Recovery Controller(ARC) 영역 전환](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) 또는 [영역 자동 전환](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html)을 사용하여 애플리케이션 환경의 내결함성 및 애플리케이션 복구를 추가적으로 개선할 수 있습니다. ARC 영역 전환은 영역 전환이 만료되거나 사용자가 이를 취소할 때까지 리소스에 대한 트래픽을 장애가 발생한 AZ에서 다른 위치로 이전할 수 있는 임시 조치로 설계되었습니다. 필요한 경우 영역 전환을 확장할 수 있습니다.
EKS 클러스터에 대한 영역 전환을 시작하거나 영역 자동 전환을 활성화하여 AWS가 대신 수행하도록 허용할 수 있습니다. 이 변경은 클러스터의 동서 네트워크 트래픽 흐름을 업데이트하여 정상 AZ의 워커 노드에서 실행 중인 포드에 대한 네트워크 엔드포인트만 고려하도록 합니다. 또한 EKS 클러스터의 애플리케이션에 대한 인그레스 트래픽을 처리하는 모든 ALB 또는 NLB는 트래픽을 정상 AZ의 타깃으로 자동 라우팅합니다. 고가용성 목표를 추구하는 고객의 경우, AZ가 장애가 발생하는 경우 복구될 때까지 모든 트래픽을 장애가 발생한 AZ로부터 멀리 이동시키는 것이 중요할 수 있습니다. 이를 위해 [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)할 수도 있습니다.
## 포드 간 동서 네트워크 트래픽 흐름 이해
다음 다이어그램은 주문과 제품이라는 두 가지 워크로드 예시를 보여줍니다. 이 예시의 목적은 서로 다른 AZ의 워크로드와 포드가 통신하는 방법을 보여주기 위한 것이다.
![\[네트워크 트래픽 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[네트워크 트래픽 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. 주문이 제품과 통신하려면 먼저 주문에서 대상 서비스의 DNS 이름을 확인해야 합니다. 주문은 CoreDNS와 통신하여 해당 서비스의 가상 IP 주소(클러스터 IP)를 가져옵니다. 주문이 제품 서비스 이름을 확인하면 해당 대상 IP로 트래픽을 전송합니다.
1. kube-proxy는 클러스터의 모든 노드에서 실행되며 서비스의 [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)를 지속적으로 감시합니다. 서비스가 생성되면 EndpointSlice 컨트롤러에 의해 백그라운드에서 EndpointSlice가 생성 및 관리됩니다. 각 EndpointSlice에는 엔드포인트가 실행 중인 노드와 함께 포드 주소의 하위 집합을 포함하는 엔드포인트 목록 또는 테이블이 있습니다. kube-proxy는 노드에서 `iptables`를 사용하여 이러한 각 Pod 엔드포인트에 대한 라우팅 규칙을 설정합니다. 또한 kube-proxy는 서비스의 클러스터 IP로 향하는 트래픽을 대신 포드의 IP 주소로 직접 전송하도록 리디렉션하여 기본적인 형태의 로드 밸런싱도 담당합니다. kube-proxy는 발신 연결에서 대상 IP 주소를 다시 작성하여 이를 수행합니다.
1. 그런 다음 위 다이어그램에 표시된 대로 각 노드의 ENI를 사용하여 AZ 2의 제품 포드로 네트워크 패킷이 전송됩니다.
### Amazon EKS에서 ARC 영역 전환 이해
사용자 환경에 AZ 장애가 있는 경우 EKS 클러스터 환경에 대한 영역 전환을 시작할 수 있습니다. 또는 AWS가 영역 자동 전환을 사용하여 트래픽 전환을 관리하도록 허용할 수 있습니다. 영역 자동 전환을 사용하면 AWS는 클러스터 환경에서 장애가 발생한 AZ에서 다른 위치로 트래픽을 자동으로 전환하여 전체 AZ 상태를 모니터링하고 잠재적인 AZ 장애에 대응합니다.
Amazon EKS 클러스터에서 ARC로 영역 전환이 활성화된 후, ARC 콘솔, AWS CLI 또는 영역 전환 및 영역 자동 전환 API를 사용하여 영역 전환을 시작하거나 영역 자동 전환을 활성화할 수 있습니다. EKS 영역 전환 중에는 다음이 자동으로 수행됩니다.
+ 영향을 받는 가용 영역의 모든 노드가 폐쇄됩니다. 이렇게 하면 Kubernetes 스케줄러가 비정상 AZ의 노드에 새 포드를 예약하지 못합니다.
+ [관리형 노드 그룹](managed-node-groups.md)을 사용하는 경우 [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)이 일시 중단되고 새 EKS 데이터 플레인 노드가 정상 AZ에서만 시작되도록 Auto Scaling 그룹이 업데이트됩니다.
+ 비정상 AZ의 노드는 종료되지 않으며, 포드는 이러한 노드에서 제거되지 않습니다. 영역 전환이 만료되거나 취소될 때 전체 용량을 위해 트래픽이 AZ로 안전하게 돌아갈 수 있도록 하기 위해서입니다.
+ EndpointSlice 컨트롤러는 장애가 발생한 AZ에서 모든 포드 엔드포인트를 찾아 관련 EndpointSlices에서 제거합니다. 이렇게 하면 정상 가용 영역에 있는 포드 엔드포인트만 네트워크 트래픽을 수신하도록 타겟팅됩니다. 영역 전환이 취소되거나 만료되면, EndpointSlice 컨트롤러는 복원된 가용 영역에 엔드포인트를 포함하도록 EndpointSlices를 업데이트합니다.
아래 다이어그램에서는 EKS 영역 전환이 클러스터 환경에서 정상 상태의 포드 엔드포인트만 대상으로 지정하도록 하는 방법에 대한 대략적인 개요를 보여줍니다.
![\[네트워크 트래픽 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[네트워크 트래픽 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## EKS 영역 전환 요구 사항
EKS에서 영역 전환이 성공적으로 작동하려면 AZ 장애에 탄력적으로 대응할 수 있도록 클러스터 환경을 미리 설정해야 합니다. 다음은 복원력을 보장하는 데 도움이 되는 구성 옵션 목록입니다.
+ 여러 AZ에 걸쳐 클러스터의 워커 노드 프로비저닝하기
+ 단일 AZ 제거 상황을 수용할 수 있도록 충분한 컴퓨팅 용량 프로비저닝
+ 모든 AZ에서 포드(CoreDNS 포함) 사전 조정
+ 모든 AZ에 걸쳐 여러 포드 복제본을 분산하여 단일 AZ에서 다른 위치로 전환해도 계속 충분한 용량을 확보할 수 있도록 하세요.
+ 동일한 AZ에 상호 의존적이거나 관련된 포드의 콜로케이션
+ 수동으로 AZ에서 다른 위치로 영역 전환을 시작하여 단일 AZ 손실 상황에서 클러스터 환경이 예상대로 작동하는지 테스트합니다. 또는 영역 자동 전환을 활성화하고 자동 전환 사례 실행에 의존할 수 있습니다. 영역 전환이 EKS에서 작동하려면 수동 또는 연습 영역 전환을 사용한 테스트가 필요하지 않아도 강력히 권장됩니다.
### 여러 AZ에 걸쳐 EKS 워커 노드 프로비저닝
AWS 리전에는 가용 영역(AZ)이라고 하는 물리적 데이터 센터가 있는 여러 개별 위치가 있습니다. AZ는 리전 전체에 영향을 미칠 수 있는 동시 영향을 피하기 위해 서로 물리적으로 격리되도록 설계되었습니다. EKS 클러스터를 프로비저닝할 때 리전 내 여러 AZ에서 워커 노드를 배포하는 것이 좋습니다. 그러면 클러스터 환경이 단일 AZ의 장애에 더 탄력적으로 대응하고 다른 AZ에서 실행 중인 애플리케이션의 고가용성(HA)을 유지할 수 있습니다. 영향을 받는 AZ에서 다른 위치로 영역 전환을 시작하면 클러스터의 고가용성 상태를 유지하면서 정상 AZ만 사용하도록 EKS 환경의 클러스터 내 네트워크가 자동으로 업데이트됩니다.
EKS 환경에 대해 다중 AZ를 설정하면 시스템의 전반적인 신뢰성을 향상시킬 수 있습니다. 그러나 다중 AZ 환경은 애플리케이션 데이터가 전송 및 처리되는 방식에 중요한 영향을 주며, 결국 환경의 네트워크 요금에도 영향을 줄 수 있습니다. 특히 잦은 송신 교차 영역 트래픽(AZ 사이에서 분산되는 트래픽)은 네트워크 관련 비용에 큰 영향을 줄 수 있습니다. 다양한 전략을 적용하여 EKS 클러스터의 포드 간 영역 간 트래픽 양을 제어하고 관련 비용을 절감할 수 있습니다. 고가용성 EKS 환경을 실행할 때 네트워크 비용을 최적화하는 방법에 대한 자세한 내용은 [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/)를 참조하세요.
다음 다이어그램에서는 3개의 정상 AZ가 있는 고가용성 EKS 환경을 보여줍니다.
![\[네트워크 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-ha-before-failure.png)
아래 다이어그램에서는 3개의 AZ가 있는 EKS 환경이 AZ 장애에 탄력적으로 대응하고 남아 있는 2개의 정상 AZ를 통해 높은 가용성을 유지하는 방법을 보여줍니다.
![\[네트워크 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-ha-after-failure.png)
### 단일 AZ 제거 상황을 견딜 수 있도록 충분한 컴퓨팅 용량 프로비저닝
EKS 데이터 플레인에서 컴퓨팅 인프라의 리소스 사용률과 비용을 최적화하려면 워크로드 요구 사항에 따라 컴퓨팅 용량을 조정하는 것이 모범 사례입니다. 그러나 **모든 워커 노드가 최대 용량에 도달하는 경우** 새 포드를 예약하기 전에 새 워커 노드를 EKS 데이터 플레인에 추가하는 방식에 의존하고 있습니다. 중요한 워크로드를 실행할 때는 갑작스러운 로드 증가, 노드 상태 문제 등과 같은 시나리오에 대처하기 위해 온라인에서 여분의 용량을 확보하고 실행하는 것이 보통 바람직한 사례입니다. 영역 전환을 사용하려는 경우 장애가 발생하면 용량의 전체 AZ를 제거하려고 합니다. 즉, AZ 중 하나가 오프라인 상태인 경우에도 충분히 로드를 처리할 수 있도록 중복 컴퓨팅 용량을 조정해야 합니다.
컴퓨팅 리소스를 조정할 때 EKS 데이터 플레인에 새 노드를 추가하는 프로세스는 다소 시간이 걸립니다. 특히 영역 장애가 발생한 경우 애플리케이션의 실시간 성능과 가용성에 영향을 미칠 수 있습니다. 최종 사용자나 클라이언트의 경험에서 성능 저하를 방지하기 위해 EKS 환경은 하나의 AZ 손실로 인한 로드를 흡수할 수 있어야 합니다. 즉, 새 포드가 필요한 시점과 워커 노드에서 실제로 예약된 시점 사이의 지연을 최소화하거나 없애야 합니다.
또한 영역 장애가 발생하는 경우 컴퓨팅 용량 제약으로 인해 새로 필요한 노드를 정상 AZ의 EKS 데이터 플레인에 추가하지 못하게 되는 위험을 완화할 것을 목표로 해야 합니다.
이러한 잠재적인 부정적 영향의 위험을 줄이려면 각 AZ의 일부 워커 노드에서 컴퓨팅 용량을 과다 프로비저닝하는 것이 좋습니다. 그러면 Kubernetes 스케줄러는 새 포드 배치에 사용할 수 있는 기존 용량을 확보합니다. 이는 환경에서 AZ 중 하나를 손실할 때 특히 중요합니다.
### 여러 가용 영역에서 Pod 복제본 실행 및 분산
Kubernetes를 사용하면 단일 애플리케이션의 여러 인스턴스(포드 복제본)를 실행하여 워크로드를 사전 확장할 수 있습니다. 애플리케이션에 대해 여러 포드 복제본을 실행하면 단일 장애 지점을 없애고 단일 복제본의 리소스 부담을 줄임으로써 전반적인 성능을 높일 수 있습니다. 그러나 애플리케이션의 고가용성과 내결함성을 모두 지원하려면 애플리케이션의 여러 복제본을 실행하고 여러 장애 도메인(이 경우 토폴로지 도메인이라고도 함)에 분산시켜야 합니다. 이 시나리오에서 장애 도메인은 가용 영역입니다. [토폴로지 분산 제약 조건](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 사용하면 기존의 정적 안정성을 지원하도록 애플리케이션을 설정할 수 있습니다. 그런 다음 AZ 장애가 발생한 경우 환경의 정상 AZ에 충분한 복제본이 있으므로 이를 통해 트래픽 급증을 즉시 처리할 수 있습니다.
아래 다이어그램에서는 모든 AZ가 정상일 때 동서 방향 트래픽 흐름이 있는 EKS 환경을 보여줍니다.
![\[네트워크 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-spread-constraints.png)
다음 다이어그램에서는 단일 AZ에서 장애가 발생하고 영역 전환을 시작한, 동서 트래픽 흐름이 있는 EKS 환경을 보여줍니다.
![\[네트워크 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-spread-constraints-2.png)
다음 코드 조각은 Kubernetes에서 여러 복제본을 사용하여 워크로드를 설정하는 방법에 대한 예입니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
가장 중요한 점은 DNS 서버 소프트웨어(CoreDNS/kube-dns)의 여러 복제본을 실행하고, 기본적으로 구성되지 않은 경우 유사한 토폴로지 분산 제약 조건을 적용해야 한다는 것입니다. 그러면 단일 AZ 장애가 발생하는 경우 클러스터에서 통신하는 다른 포드에 대한 서비스 검색 요청을 계속 처리할 수 있도록 정상 AZ에 충분한 DNS 포드를 확보할 수 있습니다. [CoreDNS EKS 추가 기능](managing-coredns.md)에는 AZ에 사용 가능한 노드가 여러 개 있는 경우 클러스터의 가용 영역에 분산되도록 보장하는 CoreDNS 포드의 기본 설정이 있습니다. 원하면 이러한 기본 설정을 사용자 지정 구성으로 바꿀 수 있습니다.
[헬름을 통해 CoreDNS](https://github.com/coredns/helm/tree/master)를 설치할 때 [value.yaml 파일](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml)의 `replicaCount`를 업데이트하여 각 AZ에 충분한 수의 복제본이 있는지 확인할 수 있습니다. 또한 이러한 복제본이 클러스터 환경의 여러 AZ에 분산되도록 하려면 동일한 `values.yaml` 파일에서 `topologySpreadConstraints` 속성을 업데이트해야 합니다. 다음 코드 조각에서는 이 작업을 수행하도록 CoreDNS를 구성하는 방법을 보여줍니다.
**CoreDNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
AZ 장애가 발생하는 경우 CoreDNS에 대한 오토 스케일링 시스템을 사용하여 CoreDNS 포드에서 늘어난 로드를 흡수할 수 있습니다. 필요한 DNS 인스턴스 수는 클러스터에서 실행 중인 워크로드 수에 따라 달라집니다. CoreDNS는 [Horizontal Pod Autoscaler(HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa)를 사용하여 CPU에 기반해 규모를 조정할 수 있는 CPU 바운드 기능입니다. 아래는 필요에 맞게 수정할 수 있는 예제입니다.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
또는 EKS는 CoreDNS의 EKS 추가 기능 버전에서 CoreDNS 배포의 오토 스케일링을 관리할 수 있습니다. 이 CoreDNS 오토스케일러는 노드 수와 CPU 코어 수를 포함하여 클러스터 상태를 지속적으로 모니터링합니다. 해당 정보를 기반으로 컨트롤러는 EKS 클러스터에서 CoreDNS 배포의 복제본 수를 동적으로 조정합니다.
[CoreDNS EKS 추가 기능에서 오토 스케일링 구성](coredns-autoscaling.md)을 활성화하려면 다음과 같은 구성 설정을 사용합니다.
```
{
"autoScaling": {
"enabled": true
}
}
```
[NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) 또는 [클러스터 비례 오토 스케일러](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)를 사용하여 CoreDNS 를 조정할 수도 있습니다. 자세한 내용은 [Scaling CoreDNS horizontally](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally)를 참조하세요.
### 동일한 가용 영역에 상호 의존적인 포드의 콜로케이션
일반적으로 애플리케이션에는 포괄적인 프로세스를 성공적으로 완료하기 위해 서로 통신해야 하는 개별 워크로드가 있습니다. 이러한 개별 애플리케이션이 서로 다른 AZ에 분산되어 있고 동일한 AZ에 콜로케이션되지 않은 경우 단일 AZ 장애가 포괄적인 프로세스에 영향을 미칠 수 있습니다. 예를 들어 **애플리케이션 A**에는 AZ 1과 AZ 2에 복제본이 여러 개 있지만 **애플리케이션 B**에는 AZ 3에 모든 복제본이 있는 경우 AZ 3 손실이 발생하면 **애플리케이션 A**와 **애플리케이션 B**라는 두 워크로드 사이의 포괄적인 프로세스에 영향을 미칩니다. 토폴로지 분산 제약 조건을 포드 선호도와 결합하면 모든 AZ에 포드를 분산하여 애플리케이션의 복원력을 개선할 수 있습니다. 또한 포드가 콜로케이션되도록 특정 포드 간 관계를 구성합니다.
[포드 선호도 규칙](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)을 사용하면 워크로드 간의 관계를 정의하여 Kubernetes 스케줄러의 동작에 영향을 주어 동일한 워커 노드 또는 동일한 AZ에서 포드를 공동 배치할 수 있습니다. 예약 제약 조건을 얼마나 엄격하게 설정할지 구성할 수도 있습니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
다음 다이어그램에서는 포드 선호도 규칙을 사용하여 동일한 노드에 콜로케이션된 여러 포드를 보여줍니다.
![\[네트워크 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### 클러스터 환경이 AZ 손실을 처리할 수 있는지 테스트
이전 섹션에서 설명된 요구 사항을 완료한 후 다음 단계는 AZ 손실을 처리하기 위해 충분한 컴퓨팅 및 워크로드 용량을 보유하고 있는지 테스트하는 것입니다. EKS에서 영역 전환을 수동으로 시작하여 이를 수행할 수 있습니다. 또는 영역 자동 전환을 활성화하고 연습 실행을 구성할 수 있습니다. 이를 통해 클러스터 환경에서 AZ가 하나 손실된 상태에서 애플리케이션이 예상대로 작동하는지도 테스트할 수 있습니다.
## 자주 묻는 질문(FAQ)
**왜 이 기능을 사용해야 하나요?**
EKS 클러스터에서 ARC 구역 이동 또는 구역 자동 이동을 사용하면 클러스터 내 네트워크 트래픽을 손상된 AZ에서 멀리 이동시키는 빠른 복구 프로세스를 자동화하여 Kubernetes 애플리케이션 가용성을 더 잘 유지할 수 있습니다. ARC를 사용하면 AZ에서 장애 이벤트가 발생한 동안 복구 기간이 늘어날 수 있는 길고 복잡한 단계를 피할 수 있습니다.
**이 기능은 다른 AWS 서비스에서 어떻게 작동하나요?**
EKS는 ARC와 통합됩니다. ARC는 AWS에서 복구 작업을 수행할 수 있는 기본 인터페이스를 제공합니다. 클러스터 내 트래픽이 장애가 발생한 AZ에서 다른 위치로 적절히 라우팅되도록 하기 위해 EKS는 Kubernetes 데이터 플레인에서 실행되는 포드의 네트워크 엔드포인트 목록을 수정합니다. 외부 트래픽을 클러스터로 라우팅하기 위해 탄력적 로드 밸런싱을 사용하는 경우 로드 밸런서를 ARC에 등록하고 여기에서 영역 전환을 시작하여 성능이 저하된 AZ로 트래픽이 유입되지 않도록 할 수 있습니다. 영역 전환은 EKS 관리형 노드 그룹에 의해 생성된 Amazon EC2 Auto Scaling 그룹에서도 작동합니다. 장애가 발생한 AZ가 새로운 Kubernetes 포드 또는 노드 실행에 사용되지 않도록 하기 위해 EKS는 장애가 발생한 AZ를 Auto Scaling 그룹에서 제거합니다.
**이 기능은 기본 Kubernetes 보호와 어떻게 다른가요?**
이 기능은 고객 애플리케이션의 복원력에 도움이 되는 여러 Kubernetes 기본 제공 보호 기능과 함께 작동합니다. 포드가 트래픽을 수신해야 하는 시기를 결정하는 포드 준비 상태 및 활성 프로브를 구성할 수 있습니다. 이러한 프로브에 실패하면 Kubernetes는 이러한 포드를 서비스의 대상으로 제거하고 트래픽은 더 이상 포드로 전송되지 않습니다. 이 기능은 유용하지만, AZ 성능이 저하될 때 실패하도록 고객이 이러한 상태 확인을 구성하는 것은 간단하지 않습니다. ARC 영역 전환 기능은 Kubernetes의 기본 보호 기능으로 충분하지 않은 경우 성능 저하된 AZ를 완전히 격리하는 데 도움이 되는 추가적인 안전망을 제공합니다. 또한 영역 전환은 아키텍처의 운영 준비 상태와 복원력을 쉽게 테스트할 수 있는 방법을 제공하기도 합니다.
**AWS가 사용자 대신 영역 전환을 트리거할 수 있나요?**
예, ARC 구역 전환를 완전히 자동화된 방식으로 사용하려면 ARC 구역 자동 전환를 사용하도록 설정할 수 있습니다. 영역 자동 전환을 사용하면 AWS를 통해 EKS 클러스터의 AZ 상태를 모니터링하고 AZ 장애가 감지될 때 자동으로 영역 전환을 트리거할 수 있습니다.
**이 기능을 사용하는데 워커 노드와 워크로드가 사전 확장되지 않은 경우 어떻게 되나요?**
사전에 조정하지 않고 영역 전환 중에 추가 노드 또는 포드 프로비저닝에 의존하는 경우 복구가 지연될 위험이 있습니다. Kubernetes 데이터 플레인에 새 노드를 추가하는 프로세스는 시간이 다소 걸리며, 이는 특히 영역 장애가 발생하는 경우 애플리케이션의 실시간 성능과 가용성에 영향을 미칠 수 있습니다. 또한 영역 장애가 발생하면 잠재적인 컴퓨팅 용량 제약이 발생하여 새로 필요한 노드를 정상 AZ에 추가하지 못할 수도 있습니다.
워크로드가 사전 조정되지 않고 클러스터의 모든 AZ에 분산되어 있는 경우, 영역 장애는 영향을 받는 AZ의 워커 노드에서만 실행되는 애플리케이션의 가용성에 영향을 미칠 수 있습니다. 애플리케이션의 완전한 가용성 중단 위험을 완화하기 위해 EKS는 워크로드의 모든 엔드포인트가 비정상적인 AZ에 있는 경우 트래픽이 손상된 영역의 포드 엔드포인트로 전송되지 않도록 하는 장애 세이프 기능을 제공합니다. 그러나 영역에서 문제 발생 시 가용성을 유지하기 위해 애플리케이션을 사전 조정하고 모든 AZ에 분산하는 것이 좋습니다.
**상태 저장 애플리케이션을 실행하는 경우 어떻게 작동하나요?**
상태 저장 애플리케이션을 실행하는 경우 사용 사례와 아키텍처에 따라 내결함성을 평가해야 합니다. 액티브/대기 아키텍처 또는 패턴이 있는 경우 액티브가 손상된 AZ에 있을 수 있습니다. 애플리케이션 수준에서 대기 모드가 활성화되어 있지 않으면 애플리케이션에 문제가 발생할 수 있습니다. 정상 AZ에서 새 Kubernetes 포드가 시작되면 장애가 발생한 AZ에 바인드된 영구 볼륨에 연결할 수 없으므로 문제가 발생할 수도 있습니다.
**이 기능은 Karpenter와 함께 작동하나요?**
현재 EKS의 ARC 구역 전환 및 영역 자동 전환에서는 Karpenter 지원을 사용할 수 없습니다. AZ에서 장애가 발생한 경우 새 워커 노드가 정상 AZ에서만 시작되도록 비정상적인 AZ를 제거하여 관련 Karpenter NodePool 구성을 조정할 수 있습니다.
**이 기능은 EKS Fargate에서 작동하나요?**
이 기능은 EKS Fargate에서 작동하지 않습니다. 기본적으로 EKS Fargate가 영역 상태 이벤트를 인식하면 포드는 다른 AZ에서 실행되는 것을 선호합니다.
**EKS 관리형 Kubernetes 컨트롤 플레인이 영향을 받나요?**
아니요, 기본적으로 Amazon EKS는 고가용성을 보장하기 위해 여러 AZ에서 Kubernetes 컨트롤 플레인을 실행하고 확장합니다. ARC 영역 전환 및 영역 자동 전환은 Kubernetes 데이터 플레인에서만 작동합니다.
**이 새로운 기능과 관련된 비용이 있습니까?**
EKS 클러스터에서 추가 비용 없이 ARC 구역 교대근무 및 구역 자동 교대근무를 사용할 수 있습니다. 그러나 프로비저닝된 인스턴스에 대한 비용은 계속 지불해야 하며, 이 기능을 사용하기 전에 Kubernetes 데이터 플레인을 사전 조정하는 것이 좋습니다. 비용과 애플리케이션 가용성 사이에서 균형을 고려해야 합니다.
## 추가 리소스
+ [영역 전환이 작동하는 방식](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [ARC의 영역 전환 모범 사례](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [영역 전환 및 영역 자동 전환에 지원되는 리소스 및 시나리오](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Amazon EKS에서 탄력적인 워크로드 운영](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [포드 우선순위 및 오버프로비저닝으로 Kubernetes 노드 스케일링 지연 제거](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [높은 DNS 트래픽을 위한 CoreDNS 포드 확장](coredns-autoscaling.md)
# 손상된 가용 영역을 방지하기 위해 EKS 영역 전환 활성화
Amazon Application Recovery Controller(ARC)는 가용 영역(AZs)에서 애플리케이션에 대한 복구를 관리 및 조정하는 데 도움이 되며 Amazon EKS를 비롯한 많은 서비스와 함께 작동합니다. ARC 영역 전환에 대한 EKS 지원을 통해 클러스터 내 네트워크 트래픽을 손상된 AZ에서 멀리 이동할 수 있습니다. 또한 AZs의 상태를 AWS 모니터링하고 사용자를 대신하여 비정상 AZ에서 네트워크 트래픽을 일시적으로 이동할 수 있는 권한을 부여할 수 있습니다.
**EKS 영역 전환을 사용하는 방법:**
1. Amazon Application Recovery Controller(ARC)를 사용하여 EKS 클러스터를 활성화합니다. 이는 Amazon EKS 콘솔, AWS CLI, CloudFormation 또는 eksctl을 사용하여 클러스터 수준에서 수행됩니다.
1. 활성화되면 ARC 콘솔, AWS CLI 또는 영역 전환 및 영역 자동 전환 API를 사용하여 영역 전환 또는 영역 자동 전환을 관리할 수 있습니다.
EKS 클러스터를 ARC에 등록한 후에도 ARC를 구성해야 합니다. 예를 들어 ARC 콘솔을 사용하여 영역 자동 전환을 구성할 수 있습니다.
EKS 영역 전환의 작동 방식과 손상된 가용 영역을 처리하도록 워크로드를 설계하는 방법에 대한 자세한 내용은 [Amazon EKS에서 Amazon Application Recovery Controller(ARC)의 영역 전환에 대해 알아보기](zone-shift.md) 섹션을 참조하세요.
## 고려 사항
+ EKS Auto Mode는 Amazon Application Recovery Controller, 영역 전환, 영역 자동 전환을 지원하지 않습니다.
+ 각 요청이 제대로 처리되도록 영역 전환 작업 사이에 60초 이상 기다리는 것이 좋습니다.
영역 전환을 60초 이내 간격으로 빠르게 연속해서 수행하려고 하면 Amazon EKS 서비스가 모든 영역 전환 요청을 제대로 처리하지 못할 수 있습니다. 이는 클러스터의 영역 상태를 업데이트하는 현재 폴링 메커니즘 때문입니다. 여러 영역 전환을 수행해야 하는 경우 시스템에서 각 변경 사항을 처리할 수 있도록 작업 간에 충분한 시간이 있는지 확인하세요.
## Amazon Application Recovery Controller란 무엇입니까?
Amazon Application Recovery Controller(ARC)는 AWS에서 실행 중인 애플리케이션의 복구를 준비하고 더 빠르게 수행할 수 있도록 도와줍니다. 영역 전환을 사용하면 지원되는 리소스의 트래픽을 AZ에서 AWS 리전의 정상 AZ로 일시적으로 이동하여 가용 영역(AZ) 장애에서 빠르게 복구할 수 있습니다.
[Amazon Application Recovery Controller(ARC)에 대해 자세히 알아보기](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## 영역 전환이란 무엇입니까?
영역 전환은 EKS 클러스터 또는 Elastic Load Balancer와 같은 리소스에 대한 트래픽을 AWS 리전의 가용 영역에서 멀리 이동하여 문제를 빠르게 완화하고 애플리케이션을 빠르게 복구할 수 있는 ARC의 기능입니다. 예를 들어, 잘못된 배포로 인해 지연 시간이 발생하거나 가용 영역이 손상되어 트래픽을 이동하도록 선택할 수 있습니다. 영역 전환에는 사전 구성 단계가 필요하지 않습니다.
[ARC 영역 전환에 대해 자세히 알아보기](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## 영역 자동 전환이란 무엇입니까?
영역 자동 이동은 AWS가 고객을 대신하여 지원되는 리소스에 대한 트래픽을 AZ에서 AWS 리전의 정상 AZ로 이동하도록 승인할 수 있도록 설정할 수 있는 ARC의 기능입니다. AWS는 내부 원격 분석 결과 리전 내 한 AZ에 잠재적으로 고객에게 영향을 미칠 수 있는 장애가 있는 것으로 나타나면 자동 전환을 시작합니다. 내부 원격 측정에는 AWS 네트워크, Amazon EC2 및 Elastic Load Balancing 서비스를 비롯한 멀티 소스의 지표가 통합되어 있습니다.
AWS는 표시기에 더 이상 문제 또는 잠재적 문제가 없는 것으로 표시되면 자동 전환을 종료합니다.
[ARC 영역 자동 전환에 대해 자세히 알아보기](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## EKS는 자동 전환 중에 무엇을 합니까?
EKS는 네트워킹 구성을 업데이트하여 트래픽이 손상된 AZ로 연결되지 않도록 합니다. 또한 관리형 노드 그룹을 사용하는 경우 EKS는 영역 전환 중에만 정상 AZs의 새 노드를 시작합니다. 교대가 만료되거나 취소되면 이전에 비정상으로 감지된 AZ를 포함하도록 네트워킹 구성이 복원됩니다.
[EKS 영역 전환에 대해 자세히 알아보기](zone-shift.md)
## Amazon Application Recovery Controller(ARC)에 EKS 클러스터 등록(AWS 콘솔)
1. ARC에 등록할 EKS 클러스터의 이름과 리전을 찾습니다.
1. 해당 리전의 [EKS 콘솔](https://console.aws.amazon.com/eks)로 이동하여 클러스터를 선택합니다.
1. **클러스터 정보** 페이지에서 **개요** 탭을 선택합니다.
1. **영역 전환** 제목에서 **관리** 버튼을 선택합니다.
1. *EKS 영역 전환*에 대해 **활성화** 또는 **비활성화**를 선택하세요.
이제 EKS 클러스터가 ARC에 등록됩니다.
AWS가 장애가 발생한 가용 영역을 감지하고 이를 피하게 하려면 ARC 영역 자동 전환을 구성해야 합니다. 예를 들어, ARC 콘솔에서 이 작업을 수행할 수 있습니다.
## 다음 단계
+ [영역 자동 전환을 활성화](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html)하는 방법을 알아봅니다.
+ 수동으로 [영역 전환을 시작](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html)하는 방법을 알아봅니다.