**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # EKS Auto Mode 작동 방식 알아보기 이 장에서는 Amazon EKS Auto Mode 클러스터의 구성 요소가 작동하는 방법을 알아봅니다. **Topics** + [Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기](automode-learn-instances.md) + [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md) + [EKS 자율 모드에서 VPC 네트워킹 및 로드 밸런싱에 대해 알아보기](auto-networking.md) # Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기 이 주제에서는 Amazon EKS Auto Mode가 EKS 클러스터에서 Amazon EC2 인스턴스를 관리하는 방법을 설명합니다. EKS Auto Mode를 활성화하면 클러스터의 컴퓨팅 리소스가 EKS에 의해 자동으로 프로비저닝되고 관리되므로 클러스터의 노드 역할을 하는 EC2 인스턴스와 상호 작용하는 방식이 변경됩니다. Amazon EKS Auto Mode가 인스턴스를 관리하는 방법을 이해하는 것은 워크로드 배포 전략 및 운영 절차를 계획하는 데 필수적입니다. 기존 EC2 인스턴스 또는 관리형 노드 그룹과 달리 이러한 인스턴스는 EKS가 특정 유형의 액세스 및 사용자 지정을 제한하면서 여러 운영 측면에 대한 책임을 지는 다른 수명 주기 모델을 따릅니다. Amazon EKS Auto Mode는 새 EC2 인스턴스를 생성하기 위한 일상적인 작업을 자동화하고 이를 EKS 클러스터에 노드로 연결합니다. EKS Auto Mode는 워크로드가 기존 노드에 맞지 않는 시기를 감지하고 새 EC2 인스턴스를 생성합니다. Amazon EKS Auto Mode는 EC2 인스턴스를 생성 및 삭제하고 패치를 적용하는 역할을 합니다. 인스턴스에 배포된 컨테이너와 포드는 사용자의 책임입니다. EKS Auto Mode에서 생성한 EC2 인스턴스는 다른 EC2 인스턴스와 차이가 있으며 관리형 인스턴스입니다. 이러한 관리형 인스턴스는 EKS에서 소유하며 더 제한적입니다. EKS Auto Mode에서 관리하는 인스턴스에는 직접 액세스하거나 소프트웨어를 설치할 수 없습니다. AWS에서는 EKS Auto Mode 또는 자체 관리형 Karpenter를 실행할 것을 제안합니다. 마이그레이션 중에 또는 고급 구성으로 둘 다 설치할 수 있습니다. 둘 다 설치한 경우 워크로드가 Karpenter 또는 EKS Auto Mode와 연결되도록 노드 풀을 구성합니다. 자세한 내용은 Amazon EC2 사용 설명서의 [Amazon EC2 managed instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)를 참조하세요. ## 비교 테이블 | 표준 EC2 인스턴스 | EKS Auto Mode 관리형 인스턴스 | | --- | --- | | 인스턴스의 패치 적용 및 업데이트는 사용자의 책임입니다. | AWS는 인스턴스를 자동으로 패치하고 업데이트합니다. | | EKS는 인스턴스의 소프트웨어에 대해 책임을 지지 않습니다. | EKS는 `kubelet`, 컨테이너 런타임, 운영 체제와 같은 인스턴스의 특정 소프트웨어를 담당합니다. | | EC2 API를 사용하여 EC2 인스턴스를 삭제할 수 있습니다. | EKS는 계정에 배포된 인스턴스 수를 결정합니다. 워크로드를 삭제하면 EKS가 계정의 인스턴스 수를 줄입니다. | | SSH를 사용하여 EC2 인스턴스에 액세스할 수 있습니다. | 포드와 컨테이너를 관리형 인스턴스에 배포할 수 있습니다. | | 운영 체제 및 이미지(AMI)를 결정합니다. | AWS가 운영 체제와 이미지를 결정합니다. | | Windows 또는 Ubuntu 기능에 의존하는 워크로드를 배포할 수 있습니다. | Linux 기반의 컨테이너를 배포할 수 있지만 특정 OS 종속성은 사용할 수 없습니다. | | 시작할 인스턴스 유형과 패밀리를 결정합니다. | AWS가 시작할 인스턴스 유형과 패밀리를 결정합니다. 노드 풀을 사용하여 EKS Auto Mode가 선택하는 인스턴스 유형을 제한할 수 있습니다. | 다음 기능은 관리형 인스턴스와 표준 EC2 인스턴스 모두에서 작동합니다. + AWS 콘솔에서 인스턴스를 볼 수 있습니다. + 인스턴스 스토리지를 워크로드의 임시 스토리지로 사용할 수 있습니다. ### AMI 지원 EKS 자동 모드를 사용하면 AWS가 컴퓨팅 노드에 사용되는 이미지(AMI)를 결정합니다. AWS는 새 EKS 자동 모드 AMI 버전의 롤아웃을 모니터링합니다. AMI 버전과 관련된 워크로드 문제가 발생하는 경우 지원 사례를 생성합니다. 자세한 내용은 AWS Support User Guide의 [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)를 참조하세요. 일반적으로 EKS는 매주 CVE 및 보안 수정 사항이 포함된 새 AMI를 릴리스합니다. ## EKS 자동 모드 지원 인스턴스 참조 EKS 자동 모드는 최소 크기 요구 사항을 충족하는 지원되는 유형의 인스턴스만 생성합니다. EKS Auto Mode는 다음 인스턴스 유형을 지원합니다. | Family | 인스턴스 유형 | | --- | --- | | 컴퓨팅 최적화(C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 | | 범용(M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 | | 메모리 최적화(R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 | | 버스트 가능(T) | t4g, t3, t3a, t2 | | 고용량 메모리(Z/X) | z1d, x8g, x2gd | | 스토리지 최적화(I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | 가속 컴퓨팅(P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | 고성능 컴퓨팅(X2) | x2iezn, x2iedn, x2idn | 또한 EKS 자동 모드는 다음 요구 사항을 충족하는 EC2 인스턴스만 생성합니다. + 1개 이상의 vCPU + 인스턴스 크기가 나노, 마이크로 또는 스몰이 아님 자세한 내용은 [Amazon EC2 인스턴스 유형 명명 규칙](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)을 참조하세요. ## 인스턴스 메타데이터 서비스 + EKS 자동 모드는 AWS 보안 모범 사례를 준수하여 기본적으로 홉 제한 1로 IMDSv2를 적용합니다. + 자동 모드에서는 이 기본 구성을 수정할 수 없습니다. + 일반적으로 IMDS 액세스가 필요한 추가 기능의 경우 IMDS 조회를 방지하기 위해 설치 중 파라미터(예: AWS 리전)를 제공합니다. 자세한 내용은 [Amazon EKS 추가 기능에 대해 사용자 지정할 수 있는 필드 확인](kubernetes-field-management.md) 섹션을 참조하세요. + 자동 모드에서 실행할 때 포드에 IMDS 액세스가 절대적으로 필요한 경우 포드를 `hostNetwork: true`로 실행하도록 구성해야 합니다. 이렇게 하면 포드가 인스턴스 메타데이터 서비스에 직접 액세스할 수 있습니다. + 포드에 인스턴스 메타데이터에 대한 액세스 권한을 부여할 때 보안 영향을 고려합니다. Amazon EC2 인스턴스 메타데이터 서비스(IMDS)에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 서비스 옵션 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)을 참조하세요. ## 고려 사항 + NodeClass에 구성된 임시 스토리지가 인스턴스의 NVMe 로컬 스토리지보다 작으면 EKS 자동 모드는 자동으로 다음 작업을 수행하여 수동 구성이 필요 없습니다. + 더 작은 용량(20GiB)의 Amazon EBS 데이터 볼륨을 사용하여 비용을 줄입니다. + 임시 데이터 사용을 위해 NVMe 로컬 스토리지를 포맷하고 구성합니다. NVMe 드라이브가 여러 개 있는 경우 RAID 0 어레이 설정이 여기에 포함됩니다. + `ephemeralStorage.size`에서 로컬 NVMe 용량과 같거나 초과하는 경우 다음 작업이 발생합니다. + 자동 모드는 작은 EBS 볼륨을 건너뜁니다. + NVMe 드라이브는 워크로드에 직접 노출됩니다. + Amazon EKS Auto Mode는 AWS Fault Injection Service 작업을 지원하지 않습니다. + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + Amazon EKS Auto Mode는 AWS Fault Injection Service EKS 포드 작업을 지원합니다. 자세한 내용은 AWS Resilience Hub 사용 설명서의 [Managing Fault Injection Service experiments](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) 및 [Use the AWS FIS aws:eks:pod actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)를 참조하세요. + EKS Auto Mode 노드에 `Neuron Device Plugin`을 설치할 필요가 없습니다. 클러스터에 다른 유형의 노드가 있는 경우 자동 모드 노드에서 실행되지 않도록 Neuron Device 플러그인을 구성해야 합니다. 자세한 내용은 [EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md) 섹션을 참조하세요. # EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기 이 주제에서는 EKS Auto Mode를 사용하는 데 필요한 Identity and Access Management(IAM) 역할 및 권한을 설명합니다. EKS Auto Mode는 클러스터 IAM 역할과 노드 IAM 역할이라는 두 가지 기본 IAM 역할을 사용합니다. 이러한 역할은 EKS Pod Identity 및 EKS 액세스 항목과 함께 작동하여 EKS 클러스터에 대한 포괄적인 액세스 관리를 제공합니다. EKS Auto Mode를 구성할 때 AWS 서비스가 클러스터 리소스와 상호 작용하도록 허용하는 특정 권한을 사용하여 이러한 IAM 역할을 설정해야 합니다. 여기에는 컴퓨팅 리소스, 스토리지 볼륨, 로드 밸런서, 네트워킹 구성 요소를 관리하는 권한이 포함됩니다. 이러한 역할 구성을 이해하는 것은 적절한 클러스터 작업 및 보안에 필수적입니다. EKS Auto Mode에서 AWS IAM 역할은 EKS 액세스 항목을 통해 Kubernetes 권한에 자동으로 매핑되므로 `aws-auth` ConfigMaps 또는 사용자 지정 바인딩을 수동으로 구성할 필요가 없습니다. 새 자동 모드 클러스터를 생성할 경우 EKS는 액세스 항목을 사용하여 해당 Kubernetes 권한을 자동으로 생성하여 AWS 서비스 및 클러스터 구성 요소가 AWS 및 Kubernetes 권한 부여 시스템 모두에서 적절한 액세스 수준을 갖도록 합니다. 이 자동 통합은 구성의 복잡성을 줄이고 EKS 클러스터를 관리할 때 일반적으로 발생하는 권한 관련 문제를 방지하는 데 도움이 됩니다. ## 클러스터 IAM 역할 클러스터 IAM 역할은 Amazon EKS에서 Kubernetes 클러스터에 대한 권한을 관리하는 데 사용하는 AWS Identity and Access Management(IAM) 역할입니다. 이 역할은 Amazon EKS에 클러스터를 대신하여 다른 AWS 서비스와 상호 작용하는 데 필요한 권한을 부여하며, EKS 액세스 항목을 사용하여 Kubernetes 권한으로 자동 구성됩니다. + AWS IAM 정책을 이 역할에 연결해야 합니다. + EKS Auto Mode는 EKS 액세스 항목을 사용하여 이 역할에 Kubernetes 권한을 자동으로 연결합니다. + EKS Auto Mode를 사용할 경우 AWS에서는 AWS 계정당 단일 클러스터 IAM 역할을 생성할 것을 제안합니다. + AWS는 이 역할의 이름을 `AmazonEKSAutoClusterRole`로 지정할 것을 제안합니다. + 이 역할에는 EBS 볼륨, Elastic Load Balancer, EC2 인스턴스를 포함한 리소스를 관리할 수 있는 여러 AWS 서비스에 대한 권한이 필요합니다. + 이 역할에 대해 제안된 구성에는 EKS 자동 모드의 다양한 기능과 관련된 여러 AWS 관리형 IAM 정책이 포함되어 있습니다. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` 클러스터 IAM 역할 및 AWS 관리형 IAM 정책에 대한 자세한 내용은 다음을 참조하세요. + [Amazon Elastic Kubernetes Service에 대한 AWS 관리형 정책](security-iam-awsmanpol.md) + [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) Kubernetes 액세스에 대한 자세한 내용은 다음을 참조하세요. + [액세스 정책 권한 검토](access-policy-permissions.md) ## 노드 IAM 역할 노드 IAM 역할은 Amazon EKS에서 Kubernetes 클러스터의 워커 노드에 대한 권한을 관리하는 데 사용하는 AWS Identity and Access Management(IAM) 역할입니다. 이 역할은 Kubernetes 노드로 실행되는 EC2 인스턴스에 AWS 서비스 및 리소스와 상호 작용하는 데 필요한 권한을 부여하며, EKS 액세스 항목을 사용하여 Kubernetes RBAC 권한으로 자동 구성됩니다. + AWS IAM 정책을 이 역할에 연결해야 합니다. + EKS Auto Mode는 EKS 액세스 항목을 사용하여 이 역할에 Kubernetes RBAC 권한을 자동으로 연결합니다. + AWS는 이 역할의 이름을 `AmazonEKSAutoNodeRole`로 지정할 것을 제안합니다. + EKS Auto Mode를 사용할 경우 AWS에서는 AWS 계정당 단일 노드 IAM 역할을 생성할 것을 제안합니다. + 이 역할에는 제한된 권한이 있습니다. 주요 권한에는 Pod Identity 역할 수임, ECR에서 이미지 가져오기가 포함됩니다. + AWS는 다음과 같은 AWS 관리형 IAM 정책을 제안합니다. + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` 클러스터 IAM 역할 및 AWS 관리형 IAM 정책에 대한 자세한 내용은 다음을 참조하세요. + [Amazon Elastic Kubernetes Service에 대한 AWS 관리형 정책](security-iam-awsmanpol.md) + [Amazon EKS 노드 IAM 역할](create-node-role.md) Kubernetes 액세스에 대한 자세한 내용은 다음을 참조하세요. + [액세스 정책 권한 검토](access-policy-permissions.md) ## 서비스 연결 역할 Amazon EKS는 특정 작업에 서비스 연결 역할(SLR)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 모든 권한을 포함합니다. AWS는 SLR을 자동으로 생성하고 구성합니다. 먼저 관련 리소스를 삭제해야만 SLR을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. SLR 정책은 EC2 리소스(인스턴스, 네트워크 인터페이스, 보안 그룹), ELB 리소스(로드 밸런서, 대상 그룹), CloudWatch 기능(로깅 및 지표), 접두사가 'eks'인 IAM 역할 등 핵심 인프라 구성 요소를 관찰하고 삭제할 수 있는 권한을 Amazon EKS에 부여합니다. 또한 VPC/호스팅 영역 연결을 통해 프라이빗 엔드포인트 네트워킹을 활성화하고 EKS 태그가 지정된 리소스의 EventBridge 모니터링 및 정리에 대한 권한을 포함합니다. 자세한 내용은 다음을 참조하세요. + [AWS 관리형 정책: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## EKS Auto 리소스에 대한 사용자 지정 AWS 태그 기본적으로 EKS Auto Mode와 관련된 관리형 정책은 Auto Mode 프로비저닝 AWS 리소스에 사용자 정의 태그를 적용하는 것을 허용하지 않습니다. AWS 리소스에 사용자 정의 태그를 적용하려면 AWS 리소스에 태그를 생성하고 수정할 수 있는 충분한 권한이 있는 클러스터 IAM 역할에 추가 권한을 연결해야 합니다. 다음은 무제한 태그 지정 액세스를 허용하는 정책의 예입니다. ### 사용자 지정 태그 정책 예제 보기 ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## 액세스 정책 참조 EKS Auto Mode에서 사용하는 Kubernetes 권한에 대한 자세한 내용은 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요. # EKS 자율 모드에서 VPC 네트워킹 및 로드 밸런싱에 대해 알아보기 이 주제에서는 EKS Auto Mode에서 가상 프라이빗 클라우드(VPC) 네트워킹 및 로드 밸런싱 기능을 구성하는 방법을 설명합니다. EKS 자동 모드는 대부분의 네트워킹 구성 요소를 자동으로 관리하지만 `NodeClass` 리소스 및 로드 밸런서 주석을 통해 클러스터 네트워킹 구성의 특정 측면을 사용자 지정할 수 있습니다. EKS Auto Mode를 사용하는 경우 AWS는 클러스터에 대한 VPC 컨테이너 네트워크 인터페이스(CNI) 구성 및 로드 밸런서 프로비저닝을 관리합니다. EKS 자동 모드가 제공하는 자동화된 운영 모델을 유지하면서 `NodeClass` 객체를 정의하고 서비스 및 수신 리소스에 특정 주석을 적용하여 네트워킹 동작에 영향을 미칠 수 있습니다. ## 네트워킹 기능 EKS 자율 모드는 노드 및 포드 네트워킹을 처리하는 새로운 네트워킹 기능을 제공합니다. `NodeClass` Kubernetes 객체를 생성하여 구성할 수 있습니다. 이전 AWS VPC CNI의 구성 옵션은 EKS 자율 모드에 적용되지 않습니다. ### `NodeClass`를 사용하여 네트워킹 구성 EKS 자율 모드의 `NodeClass` 리소스를 사용하면 네트워킹 기능의 특정 측면을 사용자 지정할 수 있습니다. `NodeClass`를 통해 보안 그룹 선택 지정, VPC 서브넷 간 노드 배치 제어, SNAT 정책 설정, 네트워크 정책 구성, 네트워크 이벤트 로깅 활성화가 가능합니다. 이 접근 방식은 EKS Auto Mode의 자동화된 운영 모델을 유지하면서 네트워크 사용자 지정에 유연성을 제공합니다. `NodeClass`를 사용하여 다음을 수행할 수 있습니다. + 노드에 대한 보안 그룹 선택 + VPC 서브넷에 노드를 배치하는 방법 제어 + 노드 SNAT 정책을 `random` 또는 `disabled`로 설정 + 다음을 포함한 Kubernetes *네트워크 정책*을 활성화합니다. + 네트워크 정책을 기본 거부 또는 기본 허용으로 설정 + 파일에 네트워크 이벤트 로깅 활성화 + 다른 서브넷에 포드를 연결하여 노드 트래픽에서 포드 트래픽을 격리합니다. [Amazon EKS NodeClass 생성](create-node-class.md) 방법을 알아봅니다. ### 고려 사항 EKS Auto Mode는 다음을 지원합니다. + EKS 네트워크 정책 + Kubernetes 포드의 `HostPort` 및 `HostNetwork` 옵션 + 퍼블릭 또는 프라이빗 서브넷의 노드 및 포드 + 노드에서 DNS 쿼리 캐싱. EKS Auto Mode는 다음을 지원하지 **않습니다**. + 포드당 보안 그룹(SGPP) Auto Mode에서 포드 트래픽에 별도의 보안 그룹을 적용하려면 대신 `NodeClass`에서 `podSecurityGroupSelectorTerms`를 사용합니다. 자세한 내용은 [포드에 대한 별도의 서브넷 및 보안 그룹](create-node-class.md#pod-subnet-selector) 섹션을 참조하세요. + `ENIConfig`의 사용자 지정 네트워킹. 여러 서브넷에 포드를 배치하거나 [포드에 대한 별도의 서브넷 및 보안 그룹](create-node-class.md#pod-subnet-selector)을 사용하여 노드 트래픽에서 포드를 독점적으로 분리할 수 있습니다. + 웜 IP, 웜 접두사, 웜 ENI 구성 + 최소 IP 대상 구성 + 오픈 소스 AWS VPC CNI에서 지원하는 기타 구성 + conntrack 타이머 사용자 지정과 같은 네트워크 정책 구성(기본값은 300초) + CloudWatch로 네트워크 이벤트 로그 내보내기 ### 네트워크 리소스 관리 EKS 자동 모드는 네트워킹 구성에 대한 NodeClass 리소스를 모니터링하여 접두사, IP 주소 지정 및 네트워크 인터페이스 관리를 처리합니다. 서비스는 여러 키 작업을 자동으로 수행합니다. **접두사 위임** EKS Auto Mode는 기본적으로 포드 네트워킹에 접두사 위임(/28 접두사)을 사용하고 예약된 포드 수에 따라 조정되는 사전 정의된 웜 IP 리소스 풀을 유지 관리합니다. 포드 서브넷 조각화가 감지되면 Auto Mode는 보조 IP 주소(/32)를 프로비저닝합니다. 이 기본 포드 네트워킹 알고리즘으로 인해 Auto Mode는 인스턴스 유형별로 지원되는 ENI 및 IP 수를 기반으로(최악의 조각화 사례를 가정함) 노드당 최대 포드 수를 계산합니다. 지원되는 최대 ENI 및 IP 수에 대한 자세한 내용은 EC2 사용 설명서의 [네트워크 인터페이스당 최대 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)를 참조하세요. 최신 세대(Nitro v6 이상)의 인스턴스 패밀리에서는 일반적으로 인스턴스 유형당 ENI 및 IP가 늘었으며, Auto Mode는 적절히 최대 포드 계산을 조정합니다. IPv6 클러스터의 경우 접두사 위임만 사용되며, Auto Mode는 항상 노드당 포드 110개의 최대 포드 제한을 사용합니다. **휴지 기간 관리** 이 서비스는 더 이상 사용되지 않는 접두사 또는 보조 IPv4 주소에 대한 휴지 기간 풀을 구현합니다. 휴지 기간이 만료되면 이러한 리소스가 VPC로 다시 릴리스됩니다. 그러나 포드가 휴지 기간 동안 이러한 리소스를 재사용하는 경우, 해당 리소스는 휴지 기간 풀에서 복원됩니다. **IPv6 지원** IPv6 클러스터의 경우 EKS 자동 모드는 프라이머리 네트워크 인터페이스에서 노드당 `/80` IPv6 접두사를 프로비저닝합니다. `podSubnetSelectorTerms`를 사용하는 경우 접두사는 대신 포드 서브넷의 보조 네트워크 인터페이스에 할당됩니다. 또한 서비스는 모든 네트워크 인터페이스의 적절한 관리 및 폐영역 회수를 보장합니다. ## 로드 밸런싱 서비스 및 수신 리소스에 대한 주석을 사용하여 EKS Auto Mode에서 프로비저닝한 AWS Elastic Load Balancer를 구성합니다. 자세한 내용은 [IngressClass를 생성하여 Application Load Balancer 구성](auto-configure-alb.md) 또는 [서비스 주석을 사용하여 Network Load Balancer 구성](auto-configure-nlb.md) 섹션을 참조하세요. ### EKS Auto Mode를 사용한 로드 밸런싱 고려 사항 + 기본 대상 지정 모드는 인스턴스 모드가 아닌 IP 모드입니다. + EKS Auto Mode는 Network Load Balancer에 대한 보안 그룹 모드만 지원합니다. + AWS는 자체 관리형 AWS 로드 밸런서 컨트롤러에서 EKS Auto Mode의 관리로 로드 밸런서 마이그레이션을 지원하지 않습니다. + `TargetGroupBinding` 사양의 `networking.ingress.ipBlock` 필드는 지원되지 않습니다. + 워커 노드가 사용자 지정 보안 그룹(`eks-cluster-sg- ` 명명 패턴 아님)을 사용하는 경우 클러스터 역할에 추가 IAM 권한이 필요합니다. 기본 EKS 관리형 정책은 EKS가 `eks-cluster-sg-`라는 보안 그룹만 수정하도록 허용합니다. 사용자 지정 보안 그룹을 수정할 권한이 없는 경우 EKS는 ALB/NLB 트래픽이 포드에 도달하도록 허용하는 필수 수신 규칙을 추가할 수 없습니다. #### CoreDNS 고려 사항 EKS Auto Mode는 클러스터 내에서 DNS 확인을 제공하기 위해 기존 CoreDNS 배포를 사용하지 않습니다. 대신 Auto Mode 노드는 각 노드에서 직접 시스템 서비스로 실행되는 CoreDNS를 활용합니다. 기존 클러스터를 자동 모드로 전환하는 경우 워크로드가 Auto Mode 노드로 이전되면 클러스터에서 CoreDNS 배포를 제거할 수 있습니다. **중요** Auto Mode 노드와 비Auto Mode 노드로 클러스터를 유지 관리하려는 경우 CoreDNS 배포를 유지해야 합니다. 비Auto Mode 노드에서는 Auto Mode가 제공하는 노드 수준의 DNS 서비스에 액세스할 수 없으므로 DNS 확인을 위해 기존 CoreDNS 포드에 의존합니다.