**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# 접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당
**적용 대상**: Amazon EC2 인스턴스가 있는 Linux 및 Windows 노드
**적용 대상:** 퍼블릭 및 프라이빗 서브넷
각 Amazon EC2 인스턴스는 최대 탄력적 네트워크 인터페이스 수와 각 네트워크 인터페이스에 할당할 수 있는 최대 IP 주소 수를 지원합니다. 각 노드에는 네트워크 인터페이스마다 IP 주소가 하나씩 필요합니다. 사용 가능한 다른 모든 IP 주소를 `Pods`에 할당할 수 있습니다. 각 `Pod`에는 자체 IP 주소가 필요합니다. 따라서 사용 가능한 컴퓨팅 및 메모리 리소스가 있지만 `Pods`에 할당할 IP 주소가 부족하여 추가 `Pods`를 수용할 수 없는 노드가 있을 수 있습니다.
노드에 개별 보조 IP 주소를 할당하는 대신 IP 접두사를 할당하여 노드가 `Pods`에 할당할 수 있는 IP 주소 수를 크게 늘릴 수 있습니다. 각 접두사에는 여러 IP 주소가 포함됩니다. IP 접두사 할당을 위해 클러스터를 구성하지 않는 경우 클러스터는 포드 연결에 필요한 네트워크 인터페이스와 IP 주소를 구성하기 위해 더 많은 Amazon EC2 애플리케이션 프로그래밍 인터페이스(API)를 직접적으로 직접 호출해야 합니다. 클러스터가 더 큰 규모로 성장함에 따라 이러한 API 직접 호출의 빈도가 증가하여 포드 및 인스턴스 시작 시간이 더 길어질 수 있습니다. 이로 인해 규모가 크고 까다로운 워크로드의 수요를 충족하기 위해 확장이 지연되고 확장 요구 사항을 충족하기 위해 추가 클러스터와 VPC를 프로비저닝해야 하므로 비용 및 관리 오버헤드가 추가됩니다. 자세한 내용은 GitHub의 [Kubernetes Scalability thresholds](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md)를 참조하세요.
## Kubernetes용 Amazon VPC CNI 플러그인 기능과의 호환성
IP 접두사를 다음 기능과 함께 사용할 수 있습니다.
+ IPv4 소스 네트워크 주소 변환-자세한 내용은 [포드에 대한 아웃바운드 인터넷 액세스 활성화](external-snat.md) 섹션을 참조하세요.
+ 클러스터, 포드 및 서비스에 대한 IPv6 주소-자세한 내용은 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 섹션을 참조하세요.
+ Kubernetes 네트워크 정책을 사용하여 트래픽 제한-자세한 내용은 [Kubernetes 네트워크 정책을 통해 pod 트래픽 제한](cni-network-policy.md) 섹션을 참조하세요.
다음 목록에서는 적용되는 Amazon VPC CNI 플러그인 설정에 대한 정보를 제공합니다. 각 설정에 대한 자세한 내용은 GitHub의 [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)를 참조하세요.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## 고려 사항
이 기능을 사용할 때 다음 사항을 고려하세요.
+ 각 Amazon EC2 인스턴스 유형은 최대 포드 수를 지원합니다. 관리형 노드 그룹이 여러 인스턴스 유형으로 구성된 경우 클러스터의 인스턴스에 대한 최대 포드 수 가운데 최소 수가 클러스터의 모든 노드에 적용됩니다.
+ 기본적으로 노드에서 실행할 수 있는 최대 `Pods` 수는 110개이지만 이 수를 변경할 수 있습니다. 숫자를 변경하고 기존 관리형 노드 그룹이 있는 경우 노드 그룹의 다음 AMI 또는 시작 템플릿 업데이트로 인해 새 노드에 변경된 값이 나타납니다.
+ IP 주소 할당에서 IP 접두사 할당으로 전환할 때 기존 노드를 순차적으로 바꾸는 대신 새 노드 그룹을 생성하여 사용 가능한 IP 주소 수를 늘리는 것이 좋습니다. IP 주소와 접두사가 모두 할당된 노드에서 포드를 실행하면 광고된 IP 주소 용량에 불일치가 발생하여 노드의 향후 워크로드에 영향을 줄 수 있습니다. 전환을 수행하는 데 있어 권장되는 방법은 *Amazon EKS 모범 사례 가이드*의 [Prefix Delegation mode for Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html)를 참조하세요.
+ 보안 그룹 범위는 노드 수준입니다. 자세한 내용은 [보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하세요.
+ 네트워크 인터페이스에 할당된 IP 접두사는 노드당 높은 포드 밀도를 지원하며, 시작 시간이 가장 빠릅니다.
+ IP 접두사 및 IP 주소는 표준 Amazon EC2 탄력적 네트워크 인터페이스와 연결됩니다. 특정 보안 그룹이 필요한 포드에는 브랜치 네트워크 인터페이스의 기본 IP 주소가 할당됩니다. IP 주소 또는 IP 접두사의 IP 주소를 얻는 포드와 동일한 노드에서 브랜치 네트워크 인터페이스를 얻는 포드와 혼합할 수 있습니다.
+ Linux 노드만 있는 클러스터의 경우
+ 네트워크 인터페이스에 접두사를 할당하도록 추가 기능을 구성한 후에는 클러스터의 모든 노드 그룹에 있는 모든 노드를 제거하지 않으면 `1.9.0`(또는 `1.10.1`) 이전 버전으로 Kubernetes용 Amazon VPC CNI 플러그인 추가 기능을 다운그레이드할 수 없습니다.
+ `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` 및 `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false`로 설정하고 포드에 보안 그룹도 사용하는 경우 포드가 VPC 외부의 엔드포인트와 통신할 때 포드에 할당한 보안 그룹이 아닌 노드의 보안 그룹이 사용됩니다.
또한 [포드에 보안 그룹](security-groups-for-pods.md)을 사용하고 `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`인 경우 `Pods`가 VPC 외부의 엔드포인트와 통신할 때 `Pod’s` 보안 그룹이 사용됩니다.
# Amazon EKS 노드에 대해 사용 가능한 IP 주소 증가
노드에 개별 보조 IP 주소를 할당하는 대신 IP 접두사를 할당하여 노드가 포드에 할당할 수 있는 IP 주소 수를 크게 늘릴 수 있습니다.
## 사전 조건
+ 기존 클러스터가 있어야 합니다. 배포하려면 [Amazon EKS 클러스터 생성](create-cluster.md) 부분을 참조하세요.
+ Amazon EKS 노드가 있는 서브넷에는 충분한 연속 `/28`(`IPv4` 클러스터용) 또는 `/80`(`IPv6` 클러스터용) CIDR(Classless Inter-Domain Routing) 블록이 있어야 합니다. `IPv6` 클러스터에는 Linux 노드만 있을 수 있습니다. IP 주소가 서브넷 CIDR 전체에 분산되어 있는 경우 IP 접두사를 사용하지 못할 수 있습니다. 다음과 같이 하는 것이 좋습니다:
+ 서브넷 CIDR 예약을 사용하여 예약된 범위 내의 IP 주소가 아직 사용 중이더라도 릴리스 시 IP 주소가 다시 할당되지 않도록 합니다. 이렇게 하면 분할 없이 접두사를 할당할 수 있습니다.
+ IP 접두사가 할당된 워크로드 실행에 특별히 사용되는 새 서브넷을 사용합니다. IP 접두사를 할당할 때 Windows 및 Linux 워크로드를 모두 동일한 서브넷에서 실행할 수 있습니다.
+ 노드에 IP 접두사를 할당하려면 노드가 AWS Nitro를 기반으로 해야 합니다. NITO 기반이 아닌 인스턴스는 계속해서 개별 보조 IP 주소를 할당하지만 NITO 기반 인스턴스보다 포드에 할당할 IP 주소 수가 상당히 적습니다.
+ **Linux 노드만 있는 클러스터의 경우** – 클러스터가 `IPv4` 패밀리용으로 구성된 경우 버전 `1.9.0` 이상의 Kubernetes용 Amazon VPC CNI 플러그인 추가 기능이 설치되어 있어야 합니다. 현재 설치된 버전은 다음과 같은 명령으로 확인할 수 있습니다.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
클러스터가 `IPv6` 패밀리용으로 구성된 경우 버전 `1.10.1`의 추가 기능이 설치되어 있어야 합니다. 플러그인 버전이 필요한 버전보다 이전인 경우 업데이트해야 합니다. 자세한 내용은 [Amazon VPC CNI를 사용하여 포드에 IP 할당](managing-vpc-cni.md)의 업데이트 섹션을 참조하세요.
+ **Windows 노드만 있는 클러스터의 경우**
+ 클러스터에 대해 Windows 지원이 활성화되어 있어야 합니다. 자세한 내용은 [EKS 클러스터에 Windows 노드 배포](windows-support.md) 섹션을 참조하세요.
## 노드에 IP 주소 접두사 할당
노드에 IP 주소 접두사를 할당하도록 클러스터를 구성합니다. 해당 노드의 운영 체제와 일치하는 절차를 완료합니다.
### Linux
1. 파라미터를 활성화하여 Amazon VPC CNI DaemonSet의 네트워크 인터페이스에 접두사를 할당합니다. 클러스터를 배포하는 경우 Kubernetes용 Amazon VPC CNI 플러그인 버전 `1.10.1` 이상의 추가 기능이 함께 배포됩니다. `IPv6` 패밀리를 사용하여 클러스터를 생성한 경우 이 설정은 기본적으로 `true`로 설정되었습니다. `IPv4` 패밀리를 사용하여 클러스터를 생성한 경우 이 설정은 기본적으로 `false`로 설정되었습니다.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**중요**
서브넷에 사용 가능한 IP 주소가 있더라도 서브넷이 인접한 `/28` 블록을 사용할 수 없는 경우 Kubernetes용 Amazon VPC CNI 플러그인 로그에 다음 오류가 표시됩니다.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
이는 서브넷에 분산된 기존 보조 IP 주소의 조각화로 인해 발생할 수 있습니다. 이 오류를 해결하려면 새 서브넷을 생성하고 거기서 포드를 시작하거나 Amazon EC2 서브넷 CIDR 예약을 사용하여 접두사 할당과 함께 사용할 서브넷 내에 공간을 예약합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [서브넷 CIDR 예약](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)을 참조하세요.
1. 시작 템플릿이 없는 관리형 노드 그룹을 배포하거나 AMI ID를 지정하지 않은 시작 템플릿을 사용하여 배포할 계획이고, 필수 구성 요소에 나열된 버전보다 늦거나 같은 버전의 Kubernetes용 Amazon VPC CNI 플러그인을 사용하는 경우 다음 단계로 건너뛰세요. 관리형 노드 그룹은 자동으로 최대 포드 수를 계산합니다.
AMI ID를 지정한 시작 템플릿을 사용하여 자체 관리형 노드 그룹 또는 관리형 노드 그룹을 배포하는 경우 Amazon EKS 권장 노드의 최대 포드 수를 결정해야 합니다. `--cni-prefix-delegation-enabled`를 3단계에 추가하여 의 지침을 따릅니다. 이후 단계에서 사용하기 위해 출력을 적어 둡니다.
**중요**
관리형 노드 그룹은 `maxPods`의 값에 최대 수를 적용합니다. vCPU가 30개 미만인 인스턴스의 경우 최대 수는 110이고 다른 모든 인스턴스의 경우 최대 수는 250입니다. 이 최대 수는 접두사 위임의 활성화 여부에 관계없이 적용됩니다.
1. `IPv6`용으로 구성된 클러스터를 사용하는 경우 다음 단계로 건너뜁니다.
다음 옵션 중 하나에서 파라미터를 지정합니다. 자신에게 적합한 옵션과 제공할 값을 확인하려면 GitHub의 [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md)을 참조하세요.
예제 값을 0보다 큰 값으로 바꿀 수 있습니다.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` 또는 `MINIMUM_IP_TARGET` - 둘 중 하나의 값이 설정되면 `WARM_PREFIX_TARGET`에 설정된 모든 값을 재정의합니다.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. 하나 이상의 Amazon EC2 Nitro Amazon Linux 2023 인스턴스 유형으로 다음 유형의 노드 그룹 중 하나를 생성합니다. Nitro 인스턴스 유형의 목록은 Amazon EC2 사용 설명서에서 [Nitro 시스템에 구축된 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) 섹션을 참조하세요. 이 기능은 Windows에서 지원되지 않습니다. *110*을 포함하는 옵션의 경우, 3단계의 값(권장) 또는 고유한 값으로 바꿉니다.
+ **자체 관리형**-[자체 관리형 Amazon Linux 노드 생성](launch-workers.md)의 지침에 따라 노드 그룹을 배포합니다. CloudFormation 스택을 생성하기 전에 템플릿 파일을 열고 `NodeLaunchTemplate`의 `UserData`를 다음과 같이 조정합니다.
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
`eksctl`을 사용하여 노드 그룹을 생성하려면 다음 명령을 사용합니다.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **관리형** - 다음 옵션 중 하나를 사용하여 노드 그룹을 배포합니다.
+ **시작 템플릿이 없거나 AMI ID가 지정되지 않은 시작 템플릿**-[클러스터에 대한 관리형 노드 그룹 생성](create-managed-node-group.md)의 절차를 완료합니다. 관리형 노드 그룹은 자동으로 Amazon EKS 권장 최대 `max-pods` 값을 계산합니다.
+ **AMI ID가 지정된 시작 템플릿을 사용하는 경우(With a launch template with a specified AMI ID)** - 시작 템플릿에서 Amazon EKS 최적화 AMI ID 또는 Amazon EKS 최적화 AMI에서 빌드한 사용자 지정 AMI를 지정한 다음 [시작 템플릿을 사용하여 노드 그룹 배포](launch-templates.md)를 지정하고 시작 템플릿에 다음 사용자 데이터를 입력합니다. 이 사용자 데이터는 노드의 `nodeadm` 도구에서 읽을 `NodeConfig` 객체를 전달합니다. `nodeadm`에 대한 자세한 내용은 [nodeadm 설명서](https://awslabs.github.io/amazon-eks-ami/nodeadm)를 참조하세요.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
`eksctl`을 사용하여 노드 그룹을 생성하려면 다음 명령을 사용합니다.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Amazon EKS 최적화 AMI에서 빌드되지 않은 사용자 지정 AMI를 생성한 경우 직접 구성을 사용자 지정하여 생성해야 합니다.
**참고**
또한 인스턴스의 서브넷과 다른 서브넷의 포드에 IP 주소를 할당하려면 이 단계에서 기능을 활성화해야 합니다. 자세한 내용은 [사용자 지정 네트워킹을 통해 대체 서브넷에 포드 배포](cni-custom-network.md) 섹션을 참조하세요.
### Windows
1. IP 접두사의 할당을 활성화합니다.
1. 편집을 위해 `amazon-vpc-cni` `ConfigMap`을 엽니다.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. 다음 줄을 `data` 섹션에 추가합니다.
```
enable-windows-prefix-delegation: "true"
```
1. 파일을 저장하고 편집기를 닫습니다.
1. 이 줄이 `ConfigMap`에 추가되었는지 확인합니다.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
반환된 출력이 `true`가 아닌 경우 오류가 있을 수 있습니다. 단계를 다시 완료해 봅니다.
**중요**
서브넷에 사용 가능한 IP 주소가 있더라도 서브넷이 인접한 `/28` 블록을 사용할 수 없는 경우 Kubernetes용 Amazon VPC CNI 플러그인 로그에 다음 오류가 표시됩니다.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
이는 서브넷에 분산된 기존 보조 IP 주소의 조각화로 인해 발생할 수 있습니다. 이 오류를 해결하려면 새 서브넷을 생성하고 거기서 포드를 시작하거나 Amazon EC2 서브넷 CIDR 예약을 사용하여 접두사 할당과 함께 사용할 서브넷 내에 공간을 예약합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [서브넷 CIDR 예약](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)을 참조하세요.
1. (선택 사항) 클러스터의 사전 규모 조정 및 동적 규모 조정 동작을 제어하기 위한 추가 구성을 지정합니다. 자세한 내용은 GitHub에서 [Windows의 접두사 위임 모드를 사용한 구성 옵션](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)을 참조하세요.
1. 편집을 위해 `amazon-vpc-cni` `ConfigMap`을 엽니다.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. 예제 값을 0보다 큰 값으로 바꾸고 필요한 항목을 `ConfigMap`의 `data` 섹션에 추가하세요. `warm-ip-target` 또한 `minimum-ip-target`에 대한 값을 설정하면 해당 값이 `warm-prefix-target`에 대해 설정된 모든 값을 재정의합니다.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. 파일을 저장하고 편집기를 닫습니다.
1. 하나 이상의 Amazon EC2 Nitro 인스턴스 유형으로 Windows 노드 그룹을 생성합니다. Nitro 인스턴스 유형의 목록은 Amazon EC2 사용 설명서에서 [Nitro 시스템에 구축된 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) 섹션을 참조하세요. 기본적으로 노드에 배포할 수 있는 최대 포드 수는 110개입니다. 이 수를 늘리거나 줄이려면 부트스트랩 구성의 사용자 데이터에 다음을 지정합니다. *max-pods-quantity*를 최대 포드 값으로 바꿉니다.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
관리형 노드 그룹을 배포하는 경우 시작 템플릿에 이 구성을 추가해야 합니다. 자세한 내용은 [시작 템플릿을 사용한 관리형 노드 사용자 지정](launch-templates.md) 섹션을 참조하세요. Windows 부트스트랩 스크립트의 구성 파라미터에 대한 자세한 내용은 [부트스트랩 스크립트 구성 파라미터](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) 섹션을 참조하세요.
## 최대 포드 및 사용 가능한 IP 주소 확인
1. 노드가 배포되면 클러스터의 노드를 확인합니다.
```
kubectl get nodes
```
예제 출력은 다음과 같습니다.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. 노드 중 하나를 설명하여 노드에 대한 `max-pods` 값과 사용 가능한 IP 주소 수를 결정합니다. *192.168.30.193*을 이전 출력에서 반환된 노드 중 하나의 이름에 있는 `IPv4` 주소로 바꿉니다.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
예제 출력은 다음과 같습니다.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
이전 출력에서 `110`은 *144*개의 IP 주소를 사용할 수 있더라도 Kubernetes가 노드에 배포할 최대 포드 수입니다.