**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# EKS 자율 모드 설정 구성
이 장에서는 Amazon Elastic Kubernetes Service(EKS) Auto Mode 클러스터의 특정 측면을 구성하는 방법을 설명합니다. EKS Auto Mode는 대부분의 인프라 구성 요소를 자동으로 관리하지만 워크로드 요구 사항에 맞게 특정 기능을 사용자 지정할 수 있습니다.
이 주제에 설명된 구성 옵션을 사용하여 자동화된 인프라 관리의 이점을 유지하면서 네트워킹 설정, 컴퓨팅 리소스, 로드 밸런싱 동작을 수정할 수 있습니다. 구성을 변경하기 전에 다음 섹션에서 사용 가능한 옵션을 검토하여 필요에 가장 적합한 접근 방식을 결정합니다.
| 구성하려는 기능 | 구성 옵션 |
| --- | --- |
| **노드 네트워킹 및 스토리지** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [Amazon EKS용 노드 클래스 생성](create-node-class.md) |
| **노드 컴퓨팅 리소스** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) |
| **정적 용량 노드 풀** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode에서 정적 용량 노드 풀](auto-static-capacity.md) |
| **Application Load Balancer 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [IngressClass를 생성하여 Application Load Balancer 구성](auto-configure-alb.md) |
| **Network Load Balancer 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [서비스 주석을 사용하여 Network Load Balancer 구성](auto-configure-nlb.md) |
| **스토리지 클래스 설정** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [스토리지 클래스 생성](create-storage-class.md) |
| **ODCR 사용량 제어** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어](auto-odcr.md) |
| **노드 고급 보안** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/settings-auto.html) | [노드에 대한 고급 보안 설정 구성](auto-advanced-security.md) |
# Amazon EKS용 노드 클래스 생성
Amazon EKS 노드 클래스는 EKS 자동 모드 관리형 노드의 구성을 세부적으로 제어할 수 있는 템플릿입니다. 노드 클래스는 네트워크 구성, 스토리지 설정, 리소스 태그 지정을 포함하여 EKS 클러스터의 노드 그룹에 적용되는 인프라 수준 설정을 정의합니다. 이 주제에서는 특정 운영 요구 사항에 맞게 노드 클래스를 생성하고 구성하는 방법을 설명합니다.
EKS Auto Mode가 기본 설정 이상으로 EC2 인스턴스를 프로비저닝하고 구성하는 방법을 사용자 지정해야 하는 경우, 노드 클래스를 생성하면 중요한 인프라 파라미터를 정확하게 제어할 수 있습니다. 예를 들어 보안 강화를 위해 프라이빗 서브넷 배치를 지정하거나, 성능에 민감한 워크로드에 대해 인스턴스 임시 스토리지를 구성하거나, 비용 할당을 위해 사용자 지정 태그 지정을 적용할 수 있습니다.
## 노드 클래스 생성
`NodeClass`를 생성하려면 다음 단계를 따르세요.
1. 노드 클래스 구성으로 YAML 파일(예: `nodeclass.yaml`) 생성
1. `kubectl`을 사용하여 클러스터에 해당 구성 적용
1. 노드 풀 구성에서 노드 클래스를 참조하세요. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
`kubectl`을 설치하고 구성해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
### 기본 노드 클래스 예제
다음은 노드 클래스 예제입니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
이 NodeClass는 노드의 임시 스토리지 양을 늘립니다.
다음을 사용하여 이 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
그런 다음 노드 풀 구성에서 노드 클래스를 참조합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 노드 클래스 액세스 항목 생성
사용자 지정 노드 클래스를 생성하는 경우 노드가 클러스터에 조인할 수 있도록 EKS 액세스 항목을 생성해야 합니다. EKS는 내장 노드 클래스와 노드 풀을 사용할 때 액세스 항목을 자동으로 생성합니다.
Access Entries 작동 방법에 대한 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
EKS 자동 모드 노드 클래스에 대한 액세스 항목을 생성할 때 `EC2` 액세스 항목 유형을 사용해야 합니다.
### CLI를 사용하여 액세스 항목 생성
**EC2 노드에 대한 액세스 항목 생성 및 EKS 자동 모드 정책 연결**
클러스터 이름과 노드 역할 ARN으로 다음 CLI 명령을 업데이트합니다. 노드 역할 ARN은 노드 클래스 YAML에 지정됩니다.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### CloudFormation을 사용하여 액세스 항목 생성
**EC2 노드에 대한 액세스 항목 생성 및 EKS 자동 모드 정책 연결**
클러스터 이름과 노드 역할 ARN으로 다음 CLI 명령을 업데이트합니다. 노드 역할 ARN은 노드 클래스 YAML에 지정됩니다.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
CloudFormation 스택 배포에 대한 자세한 내용은 [CloudFormation 시작하기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)를 참조하세요.
## 노드 클래스 사양
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 고려 사항
+ 인스턴스에 있는 로컬 스토리지의 양을 확인하려면 노드를 설명하여 임시 스토리지 리소스를 확인할 수 있습니다.
+ **볼륨 암호화** - EKS는 구성된 사용자 지정 KMS 키를 사용하여 인스턴스의 읽기 전용 루트 볼륨과 읽기/쓰기 데이터 볼륨을 암호화합니다.
+ **노드 IAM 역할 바꾸기** - `NodeClass`와 연결된 노드 IAM 역할을 변경하는 경우 새 액세스 항목을 생성해야 합니다. EKS는 클러스터 생성 중 노드 IAM 역할에 대한 액세스 항목을 자동으로 생성합니다. 노드 IAM 역할에는 `AmazonEKSAutoNodePolicy` EKS 액세스 정책이 필요합니다. 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
+ **최대 포드 밀도** - EKS는 노드의 최대 포드 수를 110개로 제한합니다. 이 제한은 기존의 최대 포드 계산 후에 적용됩니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요.
+ **태그** - Kubernetes에서 EC2로 태그를 전파하려면 추가 IAM 권한을 구성해야 합니다. 자세한 내용은 [EKS Auto Mode의 자격 증명 및 액세스에 대해 알아보기](auto-learn-iam.md) 섹션을 참조하세요.
+ **기본 노드 클래스** - 사용자 지정 노드 클래스의 이름을 `default`로 지정하지 마세요. 이는 EKS 자동 모드에 내장 `NodePool`을 하나 이상 활성화하면 자동으로 프로비저닝되는 `default`라는 `NodeClass`가 포함되어 있기 때문입니다. 내장 `NodePools` 활성화에 대한 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
+ **여러 서브넷이 있는 `subnetSelectorTerms` 동작** - `subnetSelectorTerms` 조건과 일치하거나 ID로 제공하는 서브넷이 여러 개 있는 경우 EKS 자동 모드는 서브넷 전체에 분산된 노드를 생성합니다.
+ 서브넷이 서로 다른 가용 영역(AZ)에 있는 경우 [포드 토폴로지 확산 제약 조건](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) 및 [토폴로지 인식 라우팅](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)과 같은 Kubernetes 기능을 사용하여 각각 영역에 걸쳐 포드와 트래픽을 확산할 수 있습니다.
+ *동일한 AZ*에 `subnetSelectorTerms`와 일치하는 서브넷이 여러 개 있는 경우 EKS 자동 모드는 해당 AZ의 서브넷에 분산된 각 노드에 포드를 생성합니다. EKS 자동 모드는 동일한 AZ의 다른 서브넷에 있는 각 노드에 보조 네트워크 인터페이스를 생성합니다. 각 서브넷에서 사용 가능한 IP 주소 수를 기준으로 선택하여 서브넷을 보다 효율적으로 사용합니다. 하지만 EKS 자동 모드가 각 포드에 대해 어떤 서브넷을 사용할지는 지정할 수 없습니다. 포드가 특정 서브넷에서 실행되도록 하려면 대신 [포드에 대한 별도의 서브넷 및 보안 그룹](#pod-subnet-selector)를 사용합니다.
## 포드에 대한 별도의 서브넷 및 보안 그룹
`podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms` 필드는 포드가 노드와 다른 서브넷을 사용하도록 허용함으로써 고급 네트워킹 구성을 지원합니다. 두 필드를 함께 지정해야 합니다. 이 분리는 네트워크 트래픽 라우팅 및 보안 정책에 대한 향상된 제어를 제공합니다.
**참고**
이 기능은 EKS Auto Mode 이외 컴퓨팅을 위해 AWS VPC CNI와 함께 사용되는 [포드 보안 그룹](security-groups-for-pods.md)(SGPP) 기능과 다릅니다. SGPP는 EKS Auto Mode에서 지원되지 않습니다. 대신 `NodeClass`에서 `podSecurityGroupSelectorTerms`를 사용하여 포드 트래픽에 별도의 보안 그룹을 적용합니다. 보안 그룹은 `NodeClass` 수준에서 적용됩니다. 즉, 해당 `NodeClass`를 사용하는 노드의 모든 포드가 동일한 포드 보안 그룹을 공유합니다.
### 작동 방식
`podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms`를 구성하는 경우:
1. 노드의 기본 ENI는 `subnetSelectorTerms` 및 `securityGroupSelectorTerms`의 서브넷 및 보안 그룹을 사용합니다. 노드의 고유 IP 주소만 이 인터페이스에 할당됩니다.
1. EKS Auto Mode는 `podSecurityGroupSelectorTerms`의 보안 그룹이 연결된 `podSubnetSelectorTerms`와 일치하는 서브넷에서 보조 ENI를 생성합니다. 포드 IP 주소는 기본적으로 /28 접두사를 사용하여 이러한 보조 ENI에서 할당되며, 연속 접두사 블록을 사용할 수 없는 경우 보조 IP(/32)로 자동 폴백됩니다. `ipv4PrefixSize`가 `advancedNetworking`에서 `"32"`로 설정된 경우 보조 IP만 사용됩니다.
1. `podSecurityGroupSelectorTerms`에 지정된 보안 그룹은 VPC 내 포드 트래픽에 적용됩니다. VPC 외부로 향하는 트래픽의 경우 소스 네트워크 주소 변환(SNAT)이 포드 IP를 노드 IP로 변환하기 때문에 포드는 노드의 기본 ENI 및 해당 보안 그룹을 사용합니다. `NodeClass`에서 `snatPolicy` 필드를 사용하여 이 동작을 수정할 수 있습니다.
### 사용 사례
다음 수행해야 하는 경우 `podSubnetSelectorTerms` 및 `podSecurityGroupSelectorTerms`를 사용합니다.
+ 서로 다른 보안 그룹을 적용하여 노드와 포드의 트래픽을 개별적으로 제어합니다.
+ 애플리케이션 트래픽(포드 간 통신)에서 인프라 트래픽(노드 간 통신)을 분리합니다.
+ 포드 서브넷과 다른 네트워크 구성을 노드 서브넷에 적용합니다.
+ 포드 트래픽에 영향을 주지 않고 노드 트래픽에 대해 특히 역방향 프록시 또는 네트워크 필터링을 구성합니다. `advancedNetworking` 및 `certificateBundles`를 사용하여 역방향 프록시와 프록시에 대한 자체 서명 또는 프라이빗 인증서를 정의합니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 별도의 포드 서브넷 및 보안 그룹에 대한 고려 사항
+ **보안 그룹 범위**: `podSecurityGroupSelectorTerms`의 보안 그룹은 보조 ENI에 연결되며 VPC 내의 포드 트래픽에 적용됩니다. SNAT가 활성화되면(기본값 `snatPolicy: Random`) VPC에서 나가는 트래픽이 노드의 기본 ENI IP 주소로 변환되므로 대신 `securityGroupSelectorTerms`의 노드 보안 그룹이 대신 해당 트래픽에 적용됩니다. `snatPolicy: Disabled`를 설정하면 포드가 모든 트래픽에 대해 자체 IP 주소를 사용하므로 라우팅 및 보안 그룹이 적절히 구성되어야 합니다.
+ **NodeClass 수준 세부 수준**: 포드 보안 그룹은 `NodeClass`를 사용하여 노드에 예약된 모든 포드에 적용됩니다. 서로 다른 보안 그룹을 서로 다른 워크로드에 적용하려면 별도의 `NodeClass` 및 `NodePool` 리소스를 생성하고 테인트, 허용 오차 또는 노드 선택기를 사용하여 워크로드를 적절한 노드로 예약합니다.
+ **포드 밀도 감소**: 노드의 기본 네트워크 인터페이스가 노드 IP에 대해 예약되었고 포드에 대해 사용할 수 없으므로 각 노드에서 더 적은 포드를 실행할 수 있습니다.
+ **서브넷 선택기 제한 사항**: 포드 서브넷 또는 보안 그룹 선택에는 표준 `subnetSelectorTerms` 및 `securityGroupSelectorTerms` 구성이 적용되지 않습니다.
+ **네트워크 계획**: 워크로드 요구 사항을 지원하기 위해 노드와 포드 서브넷 모두에서 적절한 IP 주소 공간을 확보합니다.
+ **라우팅 구성**: 포드 서브넷의 라우팅 테이블과 네트워크 액세스 제어 목록(ACL)이 노드와 포드 서브넷 간의 통신을 위해 올바르게 구성되어 있는지 확인합니다.
+ **가용 영역**: 여러 AZ에 걸쳐 포드 서브넷을 생성했는지 확인합니다. 특정 포드 서브넷을 사용하는 경우 노드 서브넷 AZ와 동일한 AZ에 있어야 합니다.
## 포드에 대한 보조 IP 모드
`ipv4PrefixSize` 필드는 노드에 보조 IP 주소만 할당하여 고급 네트워킹 구성을 지원합니다. 이 기능은 노드에 접두사(/28)를 할당하지 않으며 하나의 보조 IP만 MinimalIPTarget으로 유지 관리합니다.
### 사용 사례
다음 작업 시 `ipv4PrefixSize`를 사용합니다.
+ **IP 사용률 감소**: 모든 노드에서 하나의 IP 주소만 워밍업됩니다.
+ **낮은 포드 이탈 속도**: 포드 생성 속도는 주요 사안이 아닙니다.
+ **접두사 조각화 없음**: 접두사로 인한 조각화는 Auto Mode를 사용하는 데 주요 사안 또는 차단 요인입니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### 보조 IP 모드에 대한 고려 사항
+ **포드 생성 속도 감소**: 하나의 보조 IP만 워밍업되므로 IPAM 서비스에는 더 많은 포드 생성 시 IP를 프로비저닝하는 데 더 많은 시간이 필요합니다.
## IPv6 클러스터의 IPv6 포드에서 IPv4 송신 비활성화.
`enableV4Egress` 필드는 기본적으로 `true`입니다. Auto Mode IPv6 클러스터의 경우 기능을 비활성화할 수 있으므로 Auto Mode에서는 IPv6 포드에 대한 송신 전용 IPv4 인터페이스를 생성하지 않습니다. 이는 IPv4 송신 인터페이스에 네트워크 정책이 적용되지 않기 때문에 중요합니다. 네트워크 정책은 포드의 기본 인터페이스(eth0)에만 적용됩니다.
### 사용 사례
다음 작업 시 `enableV4Egress`를 사용합니다.
+ **IPv6 클러스터 사용**: IPv4 송신 트래픽이 기본적으로 허용됩니다.
+ **네트워크 정책 사용**: 현재 EKS 네트워크 정책은 듀얼 스택을 지원하지 않습니다. `enableV4Egress`를 비활성화하면 포드 트래픽이 예기치 않게 IPv4를 통해 나가는 것을 방지할 수 있습니다.
### 구성의 예
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### enableV4Egress 비활성화 시 고려 사항
+ **IPv6 클러스터의 네트워크 정책**: IPv6 클러스터는 기본적으로 IPv4 트래픽을 허용합니다. `enableV4Egress: false`를 설정하면 IPv4 송신 트래픽이 차단되어 특히 네트워크 정책과 함께 사용할 때 향상된 보안을 제공합니다.
# EKS Auto Mode용 노드 풀 생성
Amazon EKS 노드 풀은 Kubernetes 클러스터에서 컴퓨팅 리소스를 관리하는 유연한 방법을 제공합니다. 이 주제에서는 클러스터 조정 및 리소스 사용률을 최적화하는 데 도움이 되는 노드 프로비저닝 도구인 Karpenter를 사용하여 노드 풀을 생성하고 구성하는 방법을 보여줍니다. Karpenter의 NodePool 리소스를 사용하면 인스턴스 유형, 가용 영역, 아키텍처, 용량 유형을 포함한 컴퓨팅 리소스에 대한 특정 요구 사항을 정의할 수 있습니다.
내장 `system` 및 `general-purpose` 노드 풀은 수정할 수 없습니다. 활성화 또는 비활성화만 가능합니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
NodePool 사양을 사용하면 지원되는 다양한 레이블 및 요구 사항을 통해 EKS 클러스터의 컴퓨팅 리소스를 세밀하게 제어할 수 있습니다. 여기에는 EC2 인스턴스 범주, CPU 구성, 가용 영역, 아키텍처(ARM64/AMD64), 용량 유형(스팟 또는 온디맨드)을 지정하는 옵션이 포함됩니다. 또한 CPU 및 메모리 사용량에 대한 리소스 제한을 설정하여 클러스터가 필요한 운영 경계 내에 있게 할 수 있습니다.
EKS Auto Mode는 잘 알려진 Kubernetes 레이블을 활용하여 일관되고 표준화된 노드 특성 식별 방법을 제공합니다. 가용 영역의 `topology.kubernetes.io/zone` 및 CPU 아키텍처의 `kubernetes.io/arch`와 같은 이러한 레이블은 설정된 Kubernetes 규칙을 따릅니다. 또한 EKS별 레이블(접두사 `eks.amazonaws.com/`)은 인스턴스 유형, CPU 제조업체, GPU 기능, 네트워킹 사양 등의 AWS 특정 속성으로 이 기능을 확장합니다. 이 표준화된 레이블 지정 시스템을 사용하면 기존 Kubernetes 도구와 원활하게 통합하는 동시에 심층적인 AWS 인프라 통합을 제공할 수 있습니다.
## NodePool 생성
다음 단계에 따라 Amazon EKS 클러스터용 NodePool을 생성합니다.
1. 필요한 NodePool 구성으로 `nodepool.yaml`이라는 YAML 파일을 생성합니다. 아래 샘플 구성을 사용할 수 있습니다.
1. 클러스터에 NodePool을 적용합니다.
```
kubectl apply -f nodepool.yaml
```
1. NodePool이 성공적으로 생성되었는지 확인합니다.
```
kubectl get nodepools
```
1. (선택 사항) NodePool 상태를 모니터링합니다.
```
kubectl describe nodepool default
```
NodePool이 클러스터에 있는 유효한 NodeClass를 참조하는지 확인합니다. NodeClass는 컴퓨팅 리소스에 대한 AWS 특정 구성을 정의합니다. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 샘플 NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## EKS 자동 모드 지원 레이블
EKS Auto Mode는 다음과 같이 잘 알려진 레이블을 지원합니다.
**참고**
EKS Auto Mode는 Karpenter와 다른 레이블을 사용합니다. EC2 관리형 인스턴스와 관련된 레이블은 `eks.amazonaws.com`으로 시작합니다.
| 레이블 | 예제 | 설명 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS 리전 |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS 인스턴스 유형 |
| kubernetes.io/arch | amd64 | 아키텍처는 인스턴스의 [GOARCH 값](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)으로 정의됨 |
| karpenter.sh/capacity-type | spot | 용량 유형에 `spot`, `on-demand` 포함 |
| eks.amazonaws.com/instance-hypervisor | nitro | 특정 하이퍼바이저를 사용하는 인스턴스 유형 |
| eks.amazonaws.com/compute-type | auto | EKS Auto Mode 관리형 노드 식별 |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | 전송 중 암호화를 지원하는(또는 지원하지 않는) 인스턴스 유형 |
| eks.amazonaws.com/instance-category | g | 동일한 범주의 인스턴스 유형, 일반적으로 생성 번호 앞의 문자열 |
| eks.amazonaws.com/instance-generation | 4 | 인스턴스 범주 내의 인스턴스 유형 생성 번호 |
| eks.amazonaws.com/instance-family | g4dn | 속성이 유사하지만 리소스 수량이 다른 인스턴스 유형 |
| eks.amazonaws.com/instance-size | 8xlarge | 리소스 수량은 비슷하지만 속성이 다른 인스턴스 유형 |
| eks.amazonaws.com/instance-cpu | 32 | 인스턴스의 CPU 수 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU 제조업체 이름 |
| eks.amazonaws.com/instance-memory | 131072 | 인스턴스의 메모리 메비바이트 수 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 인스턴스에서 사용 가능한 EBS의 [최대 메가비트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) 수 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | 인스턴스에서 사용 가능한 [기준 메가비트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) 수 |
| eks.amazonaws.com/instance-gpu-name | t4 | 사용 가능한 경우 인스턴스의 GPU 이름 |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU 제조업체 이름 |
| eks.amazonaws.com/instance-gpu-count | 1 | 인스턴스의 GPU 수 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU의 메모리 메비바이트 수 |
| eks.amazonaws.com/instance-local-nvme | 900 | 인스턴스의 로컬 nvme 스토리지 기비바이트 수 |
**참고**
EKS 자동 모드는 특정 인스턴스만 지원하며 최소 크기 요구 사항이 있습니다. 자세한 내용은 [EKS 자동 모드 지원 인스턴스 참조](automode-learn-instances.md#auto-supported-instances) 섹션을 참조하세요.
## EKS 자동 모드 미지원 레이블
EKS Auto Mode는 다음 레이블을 지원하지 않습니다.
+ EKS Auto Mode는 Linux만 지원
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 내장 노드 풀 비활성화
사용자 지정 노드 풀을 생성하는 경우 내장 노드 풀을 비활성화할 수 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 섹션을 참조하세요.
## 내장 노드 풀이 없는 클러스터
내장 노드 풀 없이 클러스터를 생성할 수 있습니다. 이는 조직에서 사용자 지정 노드 풀을 생성한 경우에 유용합니다.
**참고**
내장 노드 풀 없이 클러스터를 생성하면 `default` NodeClass가 자동으로 프로비저닝되지 않습니다. 사용자 지정 NodeClass를 생성해야 합니다. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
**개요:**
1. `nodePools` 및 `nodeRoleArn` 값을 모두 비워두고 EKS 클러스터를 생성합니다.
+ 샘플 eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
자세한 내용은 [eksctl CLI를 사용하여 EKS Auto Mode 클러스터 생성](automode-get-started-eksctl.md) 섹션을 참조하세요.
1. 노드 역할 ARN을 사용하여 사용자 지정 노드 클래스 생성
+ 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
1. 사용자 지정 노드 클래스에 대한 액세스 항목 생성
+ 자세한 내용은 [노드 클래스 액세스 항목 생성](create-node-class.md#auto-node-access-entry) 섹션을 참조하세요.
1. 위에서 설명한 대로 사용자 지정 노드 풀을 생성합니다.
## 중단
여러 가지 방법으로 NodePool을 통해 노드를 중단하도록 EKS 자동 모드를 구성할 수 있습니다. `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` 또는 `spec.template.spec.expireAfter`를 사용할 수 있습니다. 또한 NodePool의 `spec.disruption.budgets`를 통해 EKS 자동 모드의 중단 비율을 제한할 수 있습니다. 시간 범위와 중단된 동시 노드 수를 제어할 수도 있습니다. 이 동작을 구성하는 방법은 Karpenter 설명서의 [Disruption](https://karpenter.sh/docs/concepts/disruption/)을 참조하세요.
노드 풀에 대한 중단을 구성하여 다음을 수행할 수 있습니다.
+ 인스턴스 활용도가 낮은 시기를 식별하고 워크로드를 통합합니다.
+ 노드 풀 중단 예산을 생성하여 드리프트, 비우기 및 통합으로 인한 노드 종료 비율을 제한합니다.
기본적으로 EKS 자동 모드는 다음을 수행합니다.
+ 활용도가 낮은 인스턴스를 통합합니다.
+ 336시간 후에 인스턴스를 종료합니다.
+ 단일 중단 예산을 노드의 10%로 설정합니다.
+ 약 일주일에 한 번씩 발생하는 새로운 자동 모드 AMI가 릴리스될 때 드리프트로 인한 노드 교체가 가능합니다.
## 종료 유예 기간
`terminationGracePeriod`가 EKS Auto NodePool에 명시적으로 정의되지 않은 경우 시스템은 연결된 NodeClaim에 기본 24시간 종료 유예 기간을 자동으로 적용합니다. EKS 자동 고객은 사용자 지정 NodePool 구성에서 `terminationGracePeriod`가 기본값으로 설정되어 있는 것을 볼 수 없지만 NodeClaim에서는 이 기본값이 표시됩니다. 이 기능은 유예 기간이 NodePool에 명시적으로 설정되어 있든, NodeClaim에 기본값으로 설정되어 있든 일관되게 유지되므로 클러스터 전체에서 예측 가능한 노드 종료 동작을 보장합니다.
# EKS Auto Mode에서 정적 용량 노드 풀
Amazon EKS Auto Mode는 포드 수요에 관계없이 고정된 수의 노드를 유지 관리하는 정적 용량 노드 풀을 지원합니다. 정적 용량 노드 풀은 일관된 인프라 공간을 유지 관리해야 하는 예측 가능한 용량, 예약 인스턴스 또는 특정 규정 준수 요구 사항이 필요한 워크로드에 유용합니다.
포드 예약 수요에 따라 조정되는 동적 노드 풀과 달리 정적 용량 노드 풀은 사용자가 구성한 노드 수를 유지 관리합니다.
## 정적 용량 노드 풀 구성
정적 용량 노드 풀을 생성하려면 NodePool 사양에서 `replicas` 필드를 설정합니다. `replicas` 필드에서는 노드 풀에서 유지 관리할 정확한 노드 수를 정의합니다. `replicas` 구성 방법은 [예제](#static-capacity-examples) 섹션을 참조하세요.
## 정적 용량 노드 풀 고려 사항
정적 용량 노드 풀에는 다음과 같이 여러 중요한 제약 조건과 동작이 있습니다.
**구성 제약 조건:**
+ **모드 전환 불가**: 노드 풀에 `replicas`를 설정한 후에는 노드 풀을 제거할 수 없습니다. 노드 풀에서는 정적 모드와 동적 모드 사이를 전환할 수 없습니다.
+ **제한된 리소스 제한**: 제한 섹션에서 `limits.nodes` 필드만 지원됩니다. CPU 및 메모리 제한은 적용되지 않습니다.
+ **가중치 필드 없음**: 노드 선택이 우선순위를 기반으로 하지 않으므로 정적 용량 노드 풀에서 `weight` 필드를 설정할 수 없습니다.
**운영 동작:**
+ **통합 없음**: 정적 용량 풀의 노드는 통합 시 고려되지 않습니다.
+ **조정 작업**: 조정 작업은 노드 중단 예산을 우회하지만 여전히 PodDisruptionBudgets를 고려합니다.
+ **노드 교체**: 구성에 따라 드리프트(예: AMI 업데이트) 및 만료에 대해 여전히 노드가 교체됩니다.
## 모범 사례
**용량 계획:**
+ 노드 교체 작업 중에 임시 조정을 허용하려면 `limits.nodes`를 `replicas`보다 높게 설정합니다.
+ 제한을 설정할 때 노드 드리프트 또는 AMI 업데이트 중에 필요한 최대 용량을 고려합니다.
**인스턴스 선택:**
+ 예약 인스턴스 또는 특정 하드웨어 요구 사항이 있는 경우 특정 인스턴스 유형을 사용합니다.
+ 조정 중에 인스턴스 가용성을 제한할 수 있는 지나치게 제한적인 요구 사항을 피합니다.
**중단 관리:**
+ 가용성과 유지 관리 작업의 균형을 맞추도록 적절한 중단 예산을 구성합니다.
+ 예산 백분율을 설정할 때 노드 교체에 대한 애플리케이션의 허용 오차를 고려합니다.
**모니터링:**
+ `status.nodes` 필드를 정기적으로 모니터링하여 원하는 용량이 유지되는지 확인합니다.
+ 실제 노드 수가 원하는 복제본에서 벗어나는 경우에 대한 알림을 설정합니다.
**영역 분산:**
+ 고가용성을 위해 여러 가용 영역으로 정적 용량을 분산합니다.
+ 여러 가용 영역에 걸쳐 분산된 정적 용량 노드 풀을 생성하면 EKS Auto Mode는 지정된 영역에 노드를 분산하지만 균등한 분산을 보장하지는 않습니다.
+ 여러 가용 영역에서 예측 가능하고 균등하게 배포하려면 `topology.kubernetes.io/zone` 요구 사항을 사용하여 각 특정 가용 영역에 고정되는 별도의 정적 용량 노드 풀을 생성합니다.
+ 3개 영역에 균등하게 분산된 노드 12개가 필요한 경우 3개 영역에 복제본 12개가 있는 노드 풀 1개가 아니라 각각 복제본 4개가 있는 노드 풀 3개를 생성합니다.
## 정적 용량 노드 풀 규모 조정
`kubectl scale` 명령을 사용하여 정적 용량 노드 풀의 복제본 수를 변경할 수 있습니다.
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
스케일 다운 시 EKS Auto Mode는 PodDisruptionBudgets를 고려하고 실행 중인 포드를 나머지 노드로 다시 예약할 수 있도록 노드를 정상적으로 종료합니다.
## 정적 용량 노드 풀 모니터링
다음 명령을 사용하여 정적 용량 노드 풀을 모니터링합니다.
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` 필드에는 노드 풀에서 관리하는 현재 노드 수가 표시되며, 이는 정상 조건에서 원하는 `replicas` 수와 일치해야 합니다.
## 문제 해결
**노드가 원하는 복제본에 도달하지 않음:**
+ `limits.nodes` 값이 충분한지 확인
+ 요구 사항이 인스턴스 선택을 지나치게 제한하지 않는지 확인
+ 사용하는 인스턴스 유형 및 리전에 대한 AWS 서비스 할당량 검토
**노드 교체 시간이 너무 오래 걸림:**
+ 더 많은 동시 교체를 허용하도록 중단 예산 조정
+ PodDisruptionBudgets가 노드 종료를 방지하는지 확인
**예기치 않은 노드 종료:**
+ `expireAfter` 및 `terminationGracePeriod` 설정 검토
+ 수동 노드 종료 또는 AWS 유지 관리 이벤트 확인
## 예제
### 기본 정적 용량 노드 풀
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 특정 인스턴스 유형을 사용하는 정적 용량
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### 다중 영역 정적 용량 노드 풀
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### 용량 예약을 사용하는 정적 용량
다음 예제에서는 EC2 용량 예약과 함께 정적 용량 노드 풀을 사용하는 방법을 보여줍니다. EKS Auto Mode에서 EC2 용량 예약을 사용하는 방법에 대한 자세한 내용은 [EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어](auto-odcr.md) 섹션을 참조하세요.
`capacityReservationSelectorTerms`를 정의하는 `NodeClass`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
위의 `NodeClass`를 참조하고 `karpenter.sh/capacity-type: reserved`를 사용하는 `NodePool`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# IngressClass를 생성하여 Application Load Balancer 구성
EKS Auto Mode는 클러스터 앱을 인터넷에 노출하는 등 로드 밸런싱을 위한 일상적인 작업을 자동화합니다.
AWS에서는 Application Load Balancer(ALB)를 사용하여 HTTP 및 HTTPS 트래픽을 제공할 것을 제안합니다. Application Load Balancer는 요청의 내용을 기반으로 요청을 라우팅할 수 있습니다. Application Load Balancer에 대한 자세한 내용은 [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)을 참조하세요.
EKS Auto Mode는 Application Load Balancer(ALB)를 생성하고 구성합니다. 예를 들어 EKS Auto Mode는 `Ingress` Kubernetes 객체를 생성할 때 로드 밸런서를 생성하고 클러스터 워크로드로 트래픽을 라우팅하도록 구성합니다.
**개요**
1. 인터넷에 노출하려는 워크로드를 생성합니다.
1. SSL/TLS 및 VPC 서브넷에 사용할 인증서와 같은 AWS 특정 구성 값을 지정하여 `IngressClassParams` 리소스를 생성합니다.
1. EKS Auto Mode가 `IngressClass` 리소스의 컨트롤러가 되도록 지정하는 리소스를 생성합니다.
1. HTTP 경로 및 포트를 클러스터 워크로드와 연결하는 `Ingress` 리소스를 생성합니다.
EKS Auto Mode는 `Ingress` 리소스에 지정된 로드 밸런서 구성을 사용하여 `IngressClassParams` 리소스에 지정된 워크로드를 가리키는 Application Load Balancer를 생성합니다.
## 사전 조건
+ Amazon EKS 클러스터에서 활성화된 EKS Auto Mode
+ 클러스터에 연결하도록 구성된 Kubectl
+ `kubectl apply -f `를 사용하여 아래의 샘플 구성 YAML 파일을 클러스터에 적용할 수 있습니다.
**참고**
EKS 자동 모드에서는 퍼블릭 및 프라이빗 서브넷을 식별하기 위해 서브넷 태그가 필요합니다.
`eksctl`로 클러스터를 생성한 경우 이미 이러한 태그가 있는 것입니다.
[EKS 자동 모드의 태그 서브넷](tag-subnets-auto.md) 방법에 대해 알아봅니다.
## 1단계: 워크로드 생성
먼저 인터넷에 공개하려는 워크로드를 생성합니다. 배포 또는 서비스와 같이 HTTP 트래픽을 제공하는 모든 Kubernetes 리소스일 수 있습니다.
이 예제에서는 포트 `80`에서 수신 대기하는 `service-2048`이라는 간단한 HTTP 서비스를 사용합니다. `2048-deployment-service.yaml` 매니페스트를 적용하여 이 서비스와 해당 배포를 생성합니다.
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f 2048-deployment-service.yaml
```
위에 나열된 리소스는 기본 네임스페이스에서 생성됩니다. 다음 명령을 실행하여 확인할 수 있습니다.
```
kubectl get all -n default
```
## 2단계: IngressClassParams 생성
`IngressClassParams` 객체를 생성하여 Application Load Balancer에 대한 AWS 특정 구성 옵션을 지정합니다. 이 예제에서는 다음 단계에서 사용할 `alb`라는 `IngressClassParams` 리소스를 생성합니다. 이 리소스는 `alb-ingressclassparams.yaml`이라는 파일에서 로드 밸런서 체계를 `internet-facing`으로 지정합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingressclassparams.yaml
```
## 3단계: IngressClass 생성
`alb-ingressclass.yaml`이라는 파일에 `IngressClassParams` 리소스에 설정된 AWS 특정 구성 값을 참조하는 `IngressClass`를 생성합니다. `IngressClass`의 이름을 기록해 둡니다. 이 예제에서는 `IngressClass` 및 `IngressClassParams`의 이름이 모두 `alb`입니다.
`is-default-class` 주석을 사용하여 `Ingress` 리소스가 기본적으로 이 클래스를 사용해야 하는지 여부를 제어합니다.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
구성 옵션에 대한 자세한 내용은 [IngressClassParams 참조](#ingress-reference) 섹션을 참조하세요.
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingressclass.yaml
```
## 4단계: 수신 생성
`alb-ingress.yaml`이라는 파일에 `Ingress` 리소스를 생성합니다. 이 리소스의 목적은 Application Load Balancer의 경로 및 포트를 클러스터의 워크로드와 연결하는 것입니다. 이 예제에서는 포트 80에서 `service-2048`이라는 서비스로 트래픽을 라우팅하는 `2048-ingress`라는 `Ingress` 리소스를 생성합니다.
이 리소스 구성에 대한 자세한 내용은 Kubernetes 설명서의 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) 섹션을 참조하세요.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
클러스터에 구성을 적용합니다.
```
kubectl apply -f alb-ingress.yaml
```
## 5단계: 상태 확인
`kubectl`을 사용하여 `Ingress`의 상태를 찾습니다. 로드 밸런서를 사용할 수 있기까지 몇 분 정도 걸릴 수 있습니다.
이전 단계에서 설정한 `Ingress` 리소스의 이름을 사용합니다. 예제:
```
kubectl get ingress 2048-ingress
```
리소스가 준비되면 로드 밸런서의 도메인 이름을 검색합니다.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
웹 브라우저에서 서비스를 보려면 `Ingress` 복구에 지정된 포트와 경로를 검토합니다.
## 6단계: 정리
로드 밸런서를 정리하려면 다음 명령을 사용합니다.
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode는 AWS 계정에서 연결된 로드 밸런서를 자동으로 삭제합니다.
## IngressClassParams 참조
아래 표는 일반적으로 사용되는 구성 옵션에 대한 빠른 참조입니다.
| 필드 | 설명 | 예시 값 |
| --- | --- | --- |
| `scheme` | ALB가 내부인지 인터넷 연결인지를 정의 | `internet-facing` |
| `namespaceSelector` | 이 IngressClass를 사용할 수 있는 네임스페이스 제한 | `environment: prod` |
| `group.name` | 여러 수신을 그룹화하여 단일 ALB 공유 | `retail-apps` |
| `ipAddressType` | ALB의 IP 주소 유형 설정 | `dualstack` |
| `subnets.ids` | ALB 배포를 위한 서브넷 ID 목록 | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | 필터에 태그를 지정하여 ALB의 서브넷 선택 | `Environment: prod` |
| `certificateARNs` | 사용할 SSL 인증서의 ARN | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | AWS 리소스에 대한 사용자 지정 태그 | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | 로드 밸런서별 속성 | `idle_timeout.timeout_seconds: 60` |
## 고려 사항
+ IngressClass에서 주석을 사용하여 EKS Auto Mode로 로드 밸런서를 구성할 수 없습니다. IngressClass 구성은 IngressClassParams를 통해 완료되어야 합니다. 그러나 개별 수신 리소스에 주석을 사용하여 로드 밸런서 동작(예: `alb.ingress.kubernetes.io/security-group-prefix-lists` 또는 `alb.ingress.kubernetes.io/conditions.*`)을 구성할 수 있습니다.
+ EKS 자동 모드에서 [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)를 설정할 수 없습니다.
+ Kubernetes에서 AWS 로드 밸런서 리소스로 태그 전파를 활성화하려면 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EKS Auto Mode 또는 자체 관리형 AWS 로드 밸런서 컨트롤러와 리소스를 연결하는 방법에 대한 자세한 내용은 [마이그레이션 참조](migrate-auto.md#migration-reference) 섹션을 참조하세요.
+ 로드 밸런서 관련 문제 해결에 대한 자세한 내용은 [EKS Auto Mode 문제 해결](auto-troubleshoot.md) 섹션을 참조하세요.
+ EKS Auto Mode의 로드 밸런싱 기능 사용에 대한 자세한 고려 사항은 [로드 밸런싱](auto-networking.md#auto-lb-consider) 섹션을 참조하세요.
다음 표에서는 EKS Auto Mode에 대한 IngressClassParams, Ingress 주석, TargetGroupBinding 구성의 변경 사항을 자세히 비교합니다. 이 표에서는 API 버전 변경, 사용 중단된 기능, 업데이트된 파라미터 이름을 포함하여 EKS Auto Mode의 로드 밸런싱 기능과 오픈 소스 로드 밸런서 컨트롤러 간의 주요 차이점을 강조합니다.
### IngressClassParams
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.certificateArn` | `spec.certificateARNs` | 여러 인증서 ARN 지원 |
| `spec.subnets.tags` | `spec.subnets.matchTags` | 서브넷 일치 스키마가 변경됨 |
| `spec.listeners.listenerAttributes` | 지원되지 않음 | 아직 EKS 자동 모드에서 지원하지 않음 |
### 수신 주석
| 이전 | New | 설명 |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | 지원되지 않음 | 수신 객체에서 `spec.ingressClassName` 사용 |
| `alb.ingress.kubernetes.io/group.name` | 지원되지 않음 | IngressClass에서만 그룹 지정 |
| `alb.ingress.kubernetes.io/waf-acl-id` | 지원되지 않음 | 대신 WAF v2 사용 |
| `alb.ingress.kubernetes.io/web-acl-id` | 지원되지 않음 | 대신 WAF v2 사용 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | 지원되지 않음 | Shield 통합 비활성화됨 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | 지원되지 않음 | OIDC 인증 유형은 현재 지원되지 않습니다. |
### TargetGroupBinding
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.targetType` 선택 사항 | `spec.targetType` 필수 | 명시적 대상 유형 사양 |
| `spec.networking.ingress.from` | 지원되지 않음 | 보안 그룹 없이 더 이상 NLB를 지원하지 않음 |
사용자 지정 TargetGroupBinding 기능을 사용하려면 대상 그룹에 클러스터 이름을 포함하는 eks:eks-cluster-name 태그를 지정하여 컨트롤러에 필요한 IAM 권한을 부여해야 합니다. TargetGroupBinding 리소스 또는 클러스터가 삭제되면 컨트롤러가 대상 그룹을 삭제합니다.
# 서비스 주석을 사용하여 Network Load Balancer 구성
Kubernetes 서비스 주석을 사용하여 Amazon EKS에서 Network Load Balancer(NLB)를 구성하는 방법을 알아봅니다. 이 주제에서는 인터넷 접근성, 상태 확인, SSL/TLS 종료, IP 대상 지정 모드를 포함하여 NLB 동작을 사용자 지정하기 위해 EKS Auto Mode에서 지원하는 주석에 대해 설명합니다.
EKS Auto Mode에서 `LoadBalancer` 유형의 Kubernetes 서비스를 생성하면 EKS는 사용자가 지정한 주석을 기반으로 AWS Network Load Balancer를 자동으로 프로비저닝하고 구성합니다. 이 선언적 접근 방식을 사용하면 Kubernetes 매니페스트를 통해 직접 로드 밸런서 구성을 관리하여 코드형 인프라 관행을 유지할 수 있습니다.
EKS Auto Mode는 기본적으로 LoadBalancer 유형의 모든 서비스에 대해 Network Load Balancer 프로비저닝을 처리합니다. 추가 컨트롤러 설치 또는 구성은 필요하지 않습니다. `loadBalancerClass: eks.amazonaws.com/nlb` 사양은 클러스터 기본값으로 자동 설정되므로 기존 Kubernetes 워크로드와의 호환성을 유지하면서 배포 프로세스를 간소화합니다.
**참고**
EKS 자동 모드에서는 퍼블릭 및 프라이빗 서브넷을 식별하기 위해 서브넷 태그가 필요합니다.
`eksctl`로 클러스터를 생성한 경우 이미 이러한 태그가 있는 것입니다.
[EKS 자동 모드의 태그 서브넷](tag-subnets-auto.md) 방법에 대해 알아봅니다.
## 샘플 서비스
Kubernetes `Service` 리소스에 대한 자세한 내용은 [the Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/service/)를 참조하세요.
아래의 샘플 `Service` 리소스를 검토합니다.
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 일반적으로 사용되는 주석
다음 표에는 EKS Auto Mode에서 지원하는 일반적으로 사용되는 주석이 나열되어 있습니다. EKS Auto Mode가 일부 주석을 지원하지 않을 수 있습니다.
**작은 정보**
다음 주석은 모두 `service.beta.kubernetes.io/` 접두사로 지정해야 합니다.
| 필드 | 설명 | 예제 |
| --- | --- | --- |
| `aws-load-balancer-type` | 로드 밸런서 유형을 지정합니다. 새 배포에 `external`을 사용합니다. | `external` |
| `aws-load-balancer-nlb-target-type` | 트래픽을 노드 인스턴스로 라우팅할지 아니면 포드 IP로 직접 라우팅할지 지정합니다. 표준 배포에 `instance` 또는 직접 포드 라우팅에 `ip`를 사용합니다. | `instance` |
| `aws-load-balancer-scheme` | 로드 밸런서가 내부인지 인터넷 연결인지를 제어합니다. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | 대상 그룹에 대한 상태 확인 프로토콜입니다. 일반적인 옵션은 `TCP`(기본값) 또는 `HTTP`입니다. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | HTTP/HTTPS 프로토콜을 사용할 때 상태 확인을 위한 HTTP 경로입니다. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | 상태 확인에 사용되는 포트입니다. 특정 포트 번호 또는 `traffic-port`일 수 있습니다. | `traffic-port` |
| `aws-load-balancer-subnets` | 로드 밸런서를 생성할 서브넷을 지정합니다. 서브넷 ID 또는 이름일 수 있습니다. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | HTTPS/TLS용 AWS Certificate Manager의 SSL 인증서 ARN입니다. | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | SSL/TLS를 사용해야 하는 포트를 지정합니다. | `443, 8443` |
| `load-balancer-source-ranges` | 로드 밸런서에 액세스할 수 있는 CIDR 범위입니다. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | 로드 밸런서 및 관련 리소스에 적용할 추가 AWS 태그입니다. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | 로드 밸런서가 IPv4 또는 듀얼 스택(IPv4 \$1 IPv6)을 사용할지 여부를 지정합니다. | `ipv4` 또는 `dualstack` |
## 고려 사항
+ Kubernetes에서 AWS 로드 밸런서 리소스로 태그 전파를 활성화하려면 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EKS Auto Mode 또는 자체 관리형 AWS 로드 밸런서 컨트롤러와 리소스를 연결하는 방법에 대한 자세한 내용은 [마이그레이션 참조](migrate-auto.md#migration-reference) 섹션을 참조하세요.
+ 로드 밸런서 관련 문제 해결에 대한 자세한 내용은 [EKS Auto Mode 문제 해결](auto-troubleshoot.md) 섹션을 참조하세요.
+ EKS Auto Mode의 로드 밸런싱 기능 사용에 대한 자세한 고려 사항은 [로드 밸런싱](auto-networking.md#auto-lb-consider) 섹션을 참조하세요.
로드 밸런싱을 위해 EKS Auto Mode로 마이그레이션할 때 서비스 주석 및 리소스 구성을 여러 번 변경해야 합니다. 다음 표에는 지원되지 않는 옵션과 권장 대안을 포함하여 이전 구현과 새 구현 간의 주요 차이점이 요약되어 있습니다.
### 서비스 주석
| 이전 | New | 설명 |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | 지원되지 않음 | 서비스에서 `spec.loadBalancerSourceRanges` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-type` | 지원되지 않음 | 서비스에서 `spec.loadBalancerClass` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | 지원되지 않음 | `service.beta.kubernetes.io/aws-load-balancer-scheme` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` 사용 |
| 다양한 로드 밸런서 속성 | 지원되지 않음 | `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | 지원되지 않음 | 대신 `service.beta.kubernetes.io/aws-load-balancer-attributes` 사용 |
더 이상 사용되지 않는 로드 밸런서 속성 주석에서 마이그레이션하려면 이러한 설정을 `service.beta.kubernetes.io/aws-load-balancer-attributes` 주석으로 통합합니다. 이 주석은 다양한 로드 밸런서 속성에 대해 쉼표로 구분된 키-값 페어 목록을 허용합니다. 예를 들어 액세스 로깅, 교차 영역 로드 밸런싱을 지정하려면 다음 형식을 사용합니다.
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
이 통합 형식은 필요한 개별 주석 수를 줄이면서 로드 밸런서 속성을 구성하는 더욱 일관되고 유연한 방법을 제공합니다. 기존 서비스 구성을 검토하고 이 통합 형식을 사용하도록 업데이트합니다.
### TargetGroupBinding
| 이전 | New | 설명 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 버전 변경 |
| `spec.targetType` 선택 사항 | `spec.targetType` 필수 | 명시적 대상 유형 사양 |
| `spec.networking.ingress.from` | 지원되지 않음 | 보안 그룹 없이 더 이상 NLB를 지원하지 않음 |
참고: 사용자 지정 TargetGroupBinding 기능을 사용하려면 대상 그룹에 클러스터 이름을 포함하는 `eks:eks-cluster-name` 태그를 지정하여 컨트롤러에 필요한 IAM 권한을 부여해야 합니다. TargetGroupBinding 리소스 또는 클러스터가 삭제되면 컨트롤러가 대상 그룹을 삭제합니다.
# 스토리지 클래스 생성
Amazon EKS 자동 모드의 `StorageClass`는 애플리케이션이 영구 스토리지를 요청할 때 Amazon EBS 볼륨이 자동으로 프로비저닝되는 방식을 정의합니다. 이 페이지에서는 Amazon EKS 자동 모드와 함께 작동하여 EBS 볼륨을 프로비저닝하는 `StorageClass`를 생성하고 구성하는 방법을 설명합니다.
`StorageClass`를 구성하여 볼륨 유형, 암호화, IOPS 및 기타 스토리지 파라미터를 포함하여 EBS 볼륨에 대한 기본 설정을 지정할 수 있습니다. 암호화 관리에 AWS KMS 키를 사용하도록 `StorageClass`를 구성할 수도 있습니다.
EKS 자동 모드는 `StorageClass`를 생성하지 않습니다. EKS 자동 모드의 스토리지 기능을 사용하려면 `ebs.csi.eks.amazonaws.com`을 참조하는 `StorageClass`를 생성해야 합니다.
첫째, `storage-class.yaml`라는 이름의 파일을 만듭니다.
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
둘째, 클러스터에 스토리지 클래스를 적용합니다.
```
kubectl apply -f storage-class.yaml
```
**핵심 구성 요소:**
+ `provisioner: ebs.csi.eks.amazonaws.com`-EKS Auto Mode를 사용합니다.
+ `allowedTopologies` - `eks.amazonaws.com/compute-type:auto`에서 일치하도록 `matchLabelExpressions`를 지정하면 포드가 자동 모드를 사용하여 볼륨을 자동으로 프로비저닝해야 하는 경우 포드가 자동 모드가 아닌 노드에서 예약되지 않습니다.
+ `volumeBindingMode: WaitForFirstConsumer`-포드에 필요할 때까지 볼륨 생성을 지연합니다.
+ `type: gp3`-EBS 볼륨 유형을 지정합니다.
+ `encrypted: "true"` - EBS는 `StorageClass`를 사용하여 생성된 모든 볼륨을 암호화합니다. EBS는 기본 `aws/ebs` 키 별칭을 사용합니다. 자세한 내용은 Amazon EBS 사용 설명서의 [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)을 참조하세요. 이 값은 선택 사항이지만 권장됩니다.
+ `storageclass.kubernetes.io/is-default-class: "true"`-영구 볼륨 클레임에서 다른 볼륨 클래스를 지정하지 않는 한 Kubernetes는 기본적으로 이 스토리지 클래스를 사용합니다. 이 값은 선택 사항입니다. 다른 스토리지 컨트롤러에서 마이그레이션하는 경우 이 값을 설정할 때 주의하세요.
## 자체 관리형 KMS 키를 사용하여 EBS 볼륨 암호화
자체 관리형 KMS 키를 사용하여 EKS Auto Mode로 자동화된 EBS 볼륨을 암호화하려면 다음을 수행해야 합니다.
1. 자체 관리형 KMS 키를 생성합니다.
+ 자세한 내용은 KMS 사용 설명서의 [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) 또는 [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)을 참조하세요.
1. KMS 키에 대한 액세스를 허용하는 새 정책을 생성합니다.
+ 아래의 샘플 IAM 정책을 사용하여 정책을 생성합니다. 새 자체 관리형 KMS 키의 ARN을 삽입합니다. 자세한 내용은 AWS IAM 사용 설명서의 [Creating roles and attaching policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)을 참조하세요.
1. 정책을 EKS 클러스터 역할에 연결합니다.
+ AWS 콘솔을 사용하여 EKS 클러스터 역할의 ARN을 찾습니다. 역할 정보는 **개요** 섹션에 표시됩니다. 자세한 내용은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) 섹션을 참조하세요.
1. `parameters.kmsKeyId` 필드에서 KMS 키 ID를 참조하도록 `StorageClass`를 업데이트합니다.
### 샘플 자체 관리형 KMS IAM 정책
아래 정책에서 다음 값을 업데이트합니다.
+ `` - AWS 계정 ID(예: `111122223333`)
+ `` - 클러스터의 AWS 리전(예: `us-west-2`)
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### 샘플 자체 관리형 KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` 파라미터 참조
Kubernetes `StorageClass` 리소스에 대한 일반적인 내용은 Kubernetes 설명서의 [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)를 참조하세요.
`StorageClass` 리소스의 `parameters` 섹션은 AWS와 관련이 있습니다. 다음 표를 이용하여 사용 가능한 옵션을 검토하세요.
| Parameters | 값 | 기본값 | 설명 |
| --- | --- | --- | --- |
| "csi.storage.k8s.io/fstype" | xfs, ext2, ext3, ext4 | ext4 | 볼륨 생성 중에 형식을 지정할 파일 시스템 유형입니다. 이 파라미터는 대소문자를 구분합니다. |
| "type" | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | EBS 볼륨 유형. |
| "iopsPerGB" | | | GiB당 초당 I/O 작업. IO1, IO2, GP3 볼륨에 대해 지정할 수 있습니다. |
| "allowAutoIOPSPerGBIncrease" | true, false | false | `"true"`인 경우, CSI 드라이버는 `iopsPerGB * `가 너무 낮아 AWS에서 지원하는 IOPS 범위에 맞지 않는 경우 볼륨에 대해 IOPS를 늘립니다. 이렇게 하면 사용자가 너무 작은 PVC 용량 또는 `iopsPerGB` 값을 지정하는 경우에도 동적 프로비저닝이 항상 성공할 수 있습니다. 반면, 이러한 볼륨은 `iopsPerGB`에서 요청된 것보다 IOPS가 높기 때문에 추가 비용이 발생할 수 있습니다. |
| "iops" | | | 초당 I/O 작업. IO1, IO2, GP3 볼륨에 대해 지정할 수 있습니다. |
| "throughput" | | 125 | 처리량 단위는 MiB/s입니다. gp3 볼륨 유형이 지정된 경우에만 유효합니다. |
| "encrypted" | true, false | false | 볼륨이 암호화되어야 하는지 여부입니다. 유효한 값은 "true" 또는 "false"입니다. |
| "blockExpress" | true, false | false | io2 Block Express 볼륨 생성을 활성화합니다. |
| "kmsKeyId" | | | 볼륨을 암호화할 때 사용할 키의 전체 ARN입니다. 지정하지 않으면 AWS는 볼륨이 있는 리전에 기본 KMS 키를 사용합니다. 변경하지 않으면 `/aws/ebs`라는 자동 생성된 키가 됩니다. |
| "blockSize" | | | 기본 파일 시스템을 포맷할 때 사용할 블록 크기입니다. Linux 노드와 fstype `ext2`, `ext3`, `ext4` 또는 `xfs`에서만 지원됩니다. |
| "inodeSize" | | | 기본 파일 시스템을 포맷할 때 사용할 inode 크기입니다. Linux 노드와 fstype `ext2`, `ext3`, `ext4` 또는 `xfs`에서만 지원됩니다. |
| "bytesPerInode" | | | 기본 파일 시스템을 포맷할 때 사용할 `bytes-per-inode`입니다. linux 노드와 fstype `ext2`, `ext3`, `ext4`에서만 지원됩니다. |
| "numberOfInodes" | | | 기본 파일 시스템을 포맷할 때 사용할 `number-of-inodes`입니다. linux 노드와 fstype `ext2`, `ext3`, `ext4`에서만 지원됩니다. |
| "ext4BigAlloc" | true, false | false | `bigalloc` 형식 지정 옵션을 활성화하여 클러스터링된 블록 할당을 사용하도록 `ext4` 파일 시스템을 변경합니다. 경고: `bigalloc`가 노드의 Linux 커널에서 완전히 지원되지 않을 수 있습니다. |
| "ext4ClusterSize" | | | `bigalloc` 기능이 활성화된 경우 `ext4` 파일 시스템을 포맷할 때 사용할 클러스터 크기입니다. 참고: `ext4BigAlloc` 파라미터를 true로 설정해야 합니다. |
자세한 내용은 GitHub의 [AWS EFS CSI 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)를 참조하세요.
## 고려 사항
**참고**
EKS Auto Mode 노드의 EKS Auto Mode StorageClasses에 따라 워크로드만 배포할 수 있습니다. 노드 유형이 혼합된 클러스터가 있는 경우 EKS Auto Mode 노드에서만 실행되도록 워크로드를 구성해야 합니다. 자세한 내용은 [EKS Auto Mode 노드에 워크로드 배포 여부 제어](associate-workload.md) 섹션을 참조하세요.
EKS Auto Mode의 블록 스토리지 기능은 EBS CSI 드라이버와 다릅니다.
+ 정적 프로비저닝
+ EKS Auto Mode에서 외부에서 생성된 EBS 볼륨을 사용하려면 키 `eks:eks-cluster-name`와 클러스터 이름의 값이 포함된 AWS 태그를 수동으로 추가해야 합니다.
+ 노드 시작 테인트
+ 노드 시작 테인트 기능을 사용하여 스토리지 기능 준비 전에 포드 예약을 방지할 수 없습니다.
+ 동적으로 프로비저닝된 볼륨의 사용자 지정 태그
+ 추가 태그 CLI 플래그를 사용하여 동적으로 프로비저닝된 EBS 볼륨에 사용자 지정 태그를 구성할 수 없습니다.
+ `StorageClass` 태깅을 사용하여 사용자 지정 태그를 추가할 수 있습니다. EKS Auto Mode는 연결된 AWS 리소스에 태그를 추가합니다. 사용자 지정 태그에 대한 클러스터 IAM 역할을 업데이트해야 합니다. 자세한 내용은 [EKS Auto 리소스에 대한 사용자 지정 AWS 태그](auto-learn-iam.md#tag-prop) 섹션을 참조하세요.
+ EBS 세부 성능 지표
+ EBS 세부 성능에 대한 Prometheus 지표에 액세스할 수 없습니다.
## CSI 스냅샷 컨트롤러 추가 기능 설치
EKS Auto Mode는 CSI 스냅샷 컨트롤러 Amazon EKS 추가 기능과 호환됩니다.
AWS에서는 이 추가 기능을 내장 `system` 노드 풀에서 실행하도록 구성할 것을 제안합니다.
자세한 내용은 다음을 참조하세요.
+ [전용 인스턴스에서 핵심 추가 기능 실행](critical-workload.md)
+ [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md)
+ [CSI 볼륨의 스냅샷 기능 활성화](csi-snapshot-controller.md)
### 시스템 노드 풀에 스냅샷 컨트롤러를 설치하려면
1. AWS 콘솔에서 EKS 클러스터 열기
1. **추가 기능** 탭에서 **추가 기능 더 가져오기**를 선택합니다.
1. **CSI 스냅샷 컨트롤러**와 **다음**을 차례로 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 **선택적 구성 설정**을 선택하여 **추가 기능 구성 스키마**를 확인합니다.
1. 스냅샷 컨트롤러를 `system` 노드 풀과 연결하려면 다음 yaml을 삽입합니다. 스냅샷 컨트롤러에는 `CriticalAddonsOnly` 테인트에 대한 허용치가 포함됩니다.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. **다음**을 선택합니다.
1. 추가 기능 구성을 검토한 다음 **생성**을 선택합니다.
# EKS Auto Mode 비활성화
기존 EKS 클러스터에서 EKS Auto Mode를 비활성화할 수 있습니다. 이는 파괴적인 작업입니다.
+ EKS는 EKS Auto Mode에서 운영하는 모든 EC2 인스턴스를 종료합니다.
+ EKS는 EKS Auto Mode에서 운영하는 모든 로드 밸런서를 삭제합니다.
+ EKS는 EKS Auto Mode에서 프로비저닝한 EBS 볼륨을 삭제하지 **않습니다**.
EKS 자율 모드는 생성한 리소스를 완전히 관리하도록 설계되었습니다. 수동 개입으로 인해 EKS 자율 모드가 비활성화되면 해당 리소스를 완전히 정리하지 못할 수 있습니다. 예를 들어 외부 보안 그룹 규칙에서 관리형 보안 그룹을 참조하고 클러스터에 대해 EKS 자율 모드를 비활성화하기 전에 해당 참조를 제거하는 것을 잊어버린 경우 관리형 보안 그룹이 유출됩니다(삭제되지 않음). 아래 단계에서는 누출된 보안 그룹을 제거하는 경우 해당 방법을 설명합니다.
## EKS Auto Mode 비활성화(AWS 콘솔)
1. AWS Management Console에서 클러스터 개요 페이지를 엽니다.
1. **EKS Auto Mode**에서 **관리**를 선택합니다.
1. **EKS Auto Mode**를 `off`로 전환합니다.
이 프로세스가 끝나는 시점에서 관리형 보안 그룹이 삭제되지 않은 경우 [보안 그룹 삭제](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)의 설명을 사용하여 수동으로 삭제할 수 있습니다.
## EKS Auto Mode 비활성화(AWS CLI)
다음 명령을 사용하여 기존 클러스터에서 EKS Auto Mode를 비활성화합니다.
`aws` CLI가 설치되어 있으며 EKS 클러스터를 관리할 수 있는 충분한 권한으로 로그인해야 합니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
**참고**
동일한 요청에서 컴퓨팅, 블록 스토리지, 로드 밸런싱 기능을 모두 활성화 또는 비활성화해야 합니다.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
다음과 같이 EKS 자율 모드를 비활성화한 후 누출된 EKS 자율 모드 보안 그룹을 삭제하지 못했는지 여부를 확인할 수 있습니다.
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
보안 그룹을 삭제하는 방법:
```
aws ec2 delete-security-group --group-name=
```
# EKS Auto Mode 클러스터의 Kubernetes 버전 업데이트
이 주제에서는 Auto Mode 클러스터의 Kubernetes 버전을 업데이트하는 방법을 설명합니다. Auto Mode는 노드 교체와 컨트롤 플레인 업데이트의 조정을 처리하는 동시에 포드 중단 예산을 통해 워크로드 가용성을 유지하여 버전 업데이트 프로세스를 간소화합니다.
Auto Mode 클러스터를 업그레이드할 때 기존에 수동 업데이트가 필요했던 많은 구성 요소가 이제 서비스의 일부로 관리됩니다. 업그레이드 프로세스의 자동화된 측면과 사용자의 책임을 이해하면 클러스터의 원활한 버전 전환을 보장하는 데 도움이 됩니다.
## EKS Auto Mode를 사용한 업데이트 알아보기
컨트롤 플레인 업그레이드가 시작된 후에 EKS 자동 모드가 클러스터의 노드를 업그레이드합니다. 노드가 만료되면 EKS 자동 모드가 해당 노드를 새 노드로 바꿉니다. 새 노드에는 해당하는 새 Kubernetes 버전이 있습니다. EKS Auto Mode는 노드 업그레이드 시 포드 중단 예산을 관찰합니다.
또한 더 이상 다음과 같은 구성 요소를 업데이트할 필요가 없습니다.
+ Amazon VPC CNI
+ AWS 로드 밸런서 컨트롤러
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI 드라이버
EKS Auto Mode는 이러한 구성 요소를 서비스 기능으로 대체합니다.
여전히 다음을 업데이트할 책임이 있습니다.
+ 클러스터에 배포된 앱 및 워크로드
+ 자체 관리형 추가 기능 및 컨트롤러
+ Amazon EKS 추가 기능
+ [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 방법 알아보기
[클러스터 업그레이드 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) 알아보기
## 클러스터 업데이트 시작
클러스터 업데이트를 시작하려면 [기존 클러스터를 새 Kubernetes 버전으로 업데이트](update-cluster.md) 섹션을 참조하세요.
# 내장 NodePools 활성화 또는 비활성화
EKS Auto Mode에는 내장 NodePools 2개가 있습니다. AWS 콘솔, CLI 또는 API를 사용하여 이러한 NodePools를 활성화 또는 비활성화할 수 있습니다.
## 내장 NodePool 참조
+ `system`
+ 이 NodePool에는 `CriticalAddonsOnly` 테인트가 있습니다. CoreDNS와 같은 많은 EKS 추가 기능은 이 테인트를 허용합니다. 이 시스템 노드 풀을 사용하여 클러스터의 핵심 애플리케이션을 분리합니다.
+ `amd64` 및 `arm64` 아키텍처를 모두 지원합니다.
+ `general-purpose`
+ 이 NodePool은 클러스터에서 범용 워크로드를 위한 노드 시작을 지원합니다.
+ `amd64` 아키텍처만 사용합니다.
두 내장 NodePools의 특성은 다음과 같습니다.
+ 기본 EKS NodeClass 사용
+ 온디맨드 EC2 용량만 사용
+ C, M 및 R EC2 인스턴스 패밀리 사용
+ 5세대 이상의 EC2 인스턴스 필요
**참고**
EKS가 ‘기본’ NodeClass를 프로비저닝하려면 하나 이상의 내장 NodePool을 활성화해야 합니다. 모든 내장 NodePool를 비활성화하는 경우 사용자 지정 NodeClass를 생성하고 이를 사용하도록 NodePool을 구성해야 합니다. NodeClasses에 대한 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 절차
### 사전 조건
+ 장치에 최신 버전의 AWS Command Line Interface(AWS CLI)가 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)을 참조하세요.
+ 충분한 IAM 권한을 사용하여 CLI에 로그인하고 IAM 정책, IAM 역할, EKS 클러스터를 포함한 AWS 리소스를 생성합니다.
### AWS CLI로 활성화
다음 명령을 사용하여 두 내장 NodePools를 모두 활성화합니다.
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
명령을 수정하여 NodePools를 선택적으로 활성화할 수 있습니다.
### AWS CLI로 비활성화
다음 명령을 사용하여 두 내장 NodePools를 모두 비활성화합니다.
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# EKS Auto Mode 노드에 워크로드 배포 여부 제어
EKS Auto Mode를 사용하여 EKS 클러스터에서 워크로드를 실행하는 경우 특정 워크로드가 EKS Auto Mode 노드에서 실행되는지 또는 기타 컴퓨팅 유형에서 실행되는지 여부를 제어해야 할 수 있습니다. 이 주제에서는 노드 선택기 및 선호도 규칙을 사용하여 워크로드가 의도한 컴퓨팅 인프라에 예약되게 하는 방법을 설명합니다.
이 주제의 예제에서는 `eks.amazonaws.com/compute-type` 레이블을 사용하여 EKS Auto Mode 노드에서 워크로드 배포를 요구하거나 방지하는 방법을 보여줍니다. 이는 EKS Auto Mode와 자체 관리형 Karpenter 프로비저너 또는 EKS 관리형 노드 그룹과 같은 기타 컴퓨팅 유형을 모두 실행하는 혼합 모드 클러스터에서 특히 유용합니다.
EKS Auto Mode 노드가 `eks.amazonaws.com/compute-type` 레이블 값을 `auto`로 설정했습니다. 이 레이블을 사용하여 EKS Auto Mode에서 관리하는 노드에 워크로드가 배포되는지 여부를 제어할 수 있습니다.
## 워크로드가 EKS Auto Mode 노드에 배포되어야 함
**참고**
이 `nodeSelector` 값은 EKS Auto Mode에 필요하지 않습니다. 이 `nodeSelector` 값은 EKS Auto Mode에서 관리하지 않는 노드 유형인 혼합 모드에서 클러스터를 실행하는 경우에만 관련이 있습니다. 예를 들어 EKS 관리형 노드 그룹을 사용하여 클러스터에 정적 컴퓨팅 용량을 배포하고 EKS Auto Mode에서 동적 컴퓨팅 용량을 관리할 수 있습니다.
이 `nodeSelector`를 배포 또는 기타 워크로드에 추가하여 Kubernetes가 EKS Auto Mode 노드에서 예약하도록 요구할 수 있습니다.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## 워크로드가 EKS Auto Mode 노드에 배포되지 않아야 함
이 `nodeAffinity`를 배포 또는 기타 워크로드에 추가하여 Kubernetes가 EKS Auto Mode 노드에서 예약하지 **않도록** 요구할 수 있습니다.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# 전용 인스턴스에서 핵심 추가 기능 실행
이 주제에서는 EKS Auto Mode가 `system` 노드 풀에 워크로드를 예약하도록 `CriticalAddonsOnly` 허용 오차가 있는 워크로드를 배포하는 방법을 알아봅니다.
EKS Auto Mode의 내장 `system` 노드 풀은 전용 인스턴스에서 핵심 추가 기능을 실행하도록 설계되었습니다. 이러한 분리를 통해 필수 구성 요소에 전용 리소스가 있고 일반 워크로드에서 격리되어 전반적인 클러스터 안정성과 성능이 향상됩니다.
이 가이드는 `CriticalAddonsOnly` 허용 및 적절한 노드 선택기를 활용하여 `system` 노드 풀에 추가 기능을 배포하는 방법을 보여줍니다. 이러한 단계를 따르면 EKS Auto Mode의 특수 노드 풀 구조에서 제공하는 격리 및 리소스 할당 이점을 활용하여 핵심 애플리케이션이 전용 `system` 노드로 예약되게 할 수 있습니다.
EKS Auto Mode에는 `general-purpose` 및 `system`이라는 기본 제공 노드 풀 2개가 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하십시오.
`system` 노드 풀의 목적은 핵심 추가 기능을 서로 다른 노드로 분리하는 것입니다. `system` 노드 풀에서 프로비저닝한 노드에는 `CriticalAddonsOnly` Kubernetes 테인트가 있습니다. Kubernetes는 해당 허용이 있는 경우에만 이러한 노드에 포드를 예약합니다. 자세한 내용은 Kubernetes 설명서의 [테인트와 허용 오차](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)를 참조하세요.
## 사전 조건
+ EKS Auto Mode 클러스터는 내장 `system` 노드 풀이 활성화되어 있습니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하세요.
+ `kubectl`을 설치하고 구성했습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 단원을 참조하십시오.
## 절차
아래 예제 yaml을 검토합니다. 다음 구성에 유의하세요.
+ `nodeSelector`-워크로드를 내장 `system` 노드 풀과 연결합니다. 이 노드 풀은 AWS API로 활성화해야 합니다. 자세한 내용은 [내장 NodePools 활성화 또는 비활성화](set-builtin-node-pools.md) 단원을 참조하십시오.
+ `tolerations`-이 허용 오차는 `system` 노드 풀의 노드에 있는 `CriticalAddonsOnly` 테인트를 극복합니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
`system` 노드 풀에서 실행할 워크로드를 업데이트하려면 다음을 수행해야 합니다.
1. 기존 워크로드를 업데이트하여 위에 설명된 다음 구성을 추가합니다.
+ `nodeSelector`
+ `tolerations`
1. `kubectl apply`를 사용하여 업데이트된 워크로드를 클러스터에 배포합니다.
워크로드를 업데이트하면 전용 노드에서 실행됩니다.
# EKS Auto Mode에서 네트워크 정책 사용
## 개요
고객이 EKS를 사용하여 애플리케이션 환경을 조정할 때 네트워크 트래픽 격리는 클러스터 내부 및 외부의 리소스에 대한 권한 없는 액세스를 방지하는 기본적인 방식으로 더 많이 사용되고 있습니다. 클러스터에서 여러 관련 없는 워크로드가 나란히 실행되는 다중 테넌트 환경에서 특히 중요합니다. Kubernetes 네트워크 정책을 사용하면 Kubernetes 워크로드의 네트워크 보안 태세 및 클러스터 외부 엔드포인트와의 통합을 강화할 수 있습니다. EKS Auto Mode는 다양한 유형의 네트워크 정책을 지원합니다.
### 계층 3 및 4 격리
표준 Kubernetes 네트워크 정책은 OSI 네트워크 모델의 계층 3 및 4에서 작동하며, 이를 통해 Amazon EKS 클러스터 내 IP 주소 또는 포트 수준에서 트래픽 흐름을 제어할 수 있습니다.
#### 사용 사례
+ 워크로드 간에 네트워크 트래픽을 분할하여 관련 애플리케이션만 서로 통신할 수 있도록 보장합니다.
+ 정책을 통해 네임스페이스 수준에서 테넌트를 격리하여 네트워크 분리를 적용합니다.
### DNS 기반 적용
고객은 일반적으로 더 광범위한 분산 환경의 일부인 EKS에 워크로드를 배포합니다. 이 중 일부는 클러스터 외부의 시스템 및 서비스와 통신해야 합니다(노스바운드 트래픽). 이러한 시스템 및 서비스는 AWS 클라우드에 있거나 AWS 외부에 있을 수 있습니다. 도메인 이름 시스템(DNS) 기반 정책을 사용하면 포드에서 클러스터 외부 리소스 또는 엔드포인트로의 권한 없는 액세스를 방지하기 위해 보다 안정적이고 예측 가능한 접근 방식을 채택하여 보안 태세를 강화할 수 있습니다. 이 메커니즘을 사용하면 특정 IP 주소를 수동으로 추적하고 허용 목록에 추가하지 않아도 됩니다. DNS 기반 접근 방식으로 리소스를 보호하면 업스트림 서버 및 호스트에 대한 변경 중 보안 태세를 완화하거나 네트워크 정책을 수정하지 않고도 외부 인프라를 업데이트할 수 있는 유연성도 향상됩니다. 정규화된 도메인 이름(FQDN) 또는 DNS 도메인 이름과 일치하는 패턴을 사용하여 외부 엔드포인트로 송신 트래픽을 필터링할 수 있습니다. 이를 통해 특정 클러스터 외부 엔드포인트와 연결된 여러 하위 도메인으로 액세스를 확장할 수 있는 유연성이 추가됩니다.
#### 사용 사례
+ Kubernetes 환경에서 클러스터 외부 엔드포인트로의 액세스를 필터링하기 위한 DNS 기반 접근 방식을 표준화합니다.
+ 다중 테넌트 환경에서 AWS 서비스에 대한 보안 액세스.
+ 하이브리드 클라우드 환경의 경우 포드에서 온프레미스 워크로드로의 네트워크 액세스를 관리합니다.
### 관리자 또는 클러스터 범위의 규칙
다중 테넌트 시나리오와 같은 일부 경우 고객은 전체 클러스터에 적용되는 네트워크 보안 표준을 적용해야 할 수 있습니다. 각 네임스페이스에 대해 고유한 정책을 반복적으로 정의하고 유지하는 대신 단일 정책을 사용하여 네임스페이스에 관계없이 클러스터의 여러 워크로드에 대한 네트워크 액세스 제어를 중앙에서 관리할 수 있습니다. 이러한 유형의 정책을 사용하면 계층 3 및 계층 4에서와 DNS 규칙을 사용할 때 적용되는 네트워크 필터링 규칙의 적용 범위를 확장할 수 있습니다.
#### 사용 사례
+ EKS 클러스터의 모든 워크로드와 워크로드의 하위 집합에 대한 네트워크 액세스 제어를 중앙에서 관리합니다.
+ 전체 클러스터에서 기본 네트워크 보안 태세를 정의합니다.
+ 보다 운영 효율적인 방식으로 조직 보안 표준을 클러스터 범위로 확장합니다.
## 시작하기
### 사전 조건
+ EKS Auto Mode가 활성화된 Amazon EKS 클러스터
+ 클러스터에 연결하도록 구성된 kubectl
### 1단계: 네트워크 정책 컨트롤러 활성화
EKS Auto Mode로 네트워크 정책을 사용하려면 먼저 클러스터에 ConfigMap을 적용하여 네트워크 정책 컨트롤러를 활성화해야 합니다.
1. 다음 콘텐츠가 포함된 `enable-network-policy.yaml`이라는 파일을 생성합니다.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. 클러스터에 ConfigMap 적용:
```
kubectl apply -f enable-network-policy.yaml
```
### 2단계: 네트워크 정책 생성 및 테스트
이제 Kubernetes 네트워크 정책을 지원하도록 EKS Auto Mode 클러스터가 구성되었습니다. [Amazon EKS 네트워크 정책에 대한 Stars 데모](network-policy-stars-demo.md)를 사용하여 테스트할 수 있습니다.
### 3단계: 노드 클래스에서 네트워크 정책 에이전트 구성 조정(선택 사항)
선택적으로 새 노드 클래스를 생성하여 노드에서 네트워크 정책 에이전트의 기본 동작을 변경하거나 네트워크 정책 이벤트 로깅을 활성화할 수 있습니다. 이렇게 하려면 다음 단계를 따릅니다.
1. 다음 내용을 사용하여 노드 클래스 YAML 파일(예: `nodeclass-network-policy.yaml`)을 생성하거나 편집합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. 클러스터에 노드 클래스 구성을 적용합니다.
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. 노드 클래스가 생성되었는지 확인합니다.
```
kubectl get nodeclass network-policy-config
```
1. 이 노드 클래스를 사용하도록 노드 풀을 업데이트합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 어떻게 작동하나요?
### DNS 기반 네트워크 정책
![\[EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/apply-dns-policy-2.png)
1. 플랫폼 팀은 DNS 기반 정책을 EKS 클러스터에 적용합니다.
1. 네트워크 정책 컨트롤러는 클러스터 내에서 정책 생성을 모니터링한 다음, 정책 엔드포인트를 조정할 책임이 있습니다. 이 사용 사례에서 네트워크 정책 컨트롤러는 생성된 정책의 허용 목록에 있는 도메인을 기반으로 DNS 요청을 필터링하도록 노드 에이전트에 지시합니다. 도메인 이름은 FQDN 또는 Kubernetes 리소스 구성에 정의된 패턴과 일치하는 도메인 이름을 사용하여 허용 목록에 추가됩니다.
1. 워크로드 A는 클러스터 외부 엔드포인트의 IP를 확인하려고 시도합니다. DNS 요청은 먼저 네트워크 정책을 통해 적용된 허용 목록을 기반으로 이러한 요청을 필터링하는 프록시를 거칩니다.
1. DNS 요청이 DNS 필터 허용 목록을 거치면 CoreDNS로 프록시됩니다.
1. 그러면 CoreDNS는 외부 DNS 해석기(Amazon Route 53 Resolver)에 요청을 보내 도메인 이름 뒤의 IP 주소 목록을 가져옵니다.
1. TTL이 있는 확인된 IP는 DNS 요청에 대한 응답으로 반환됩니다. 그런 다음 IP 계층 적용을 위한 다음 단계에서 사용되는 eBPF 맵에 이러한 IP가 기록됩니다.
1. 그런 다음 포드 veth 인터페이스에 연결된 eBPF 프로브는 적용된 규칙에 따라 워크로드 A에서 클러스터 외부 엔드포인트로의 송신 트래픽을 필터링합니다. 이를 통해 포드는 허용 목록에 추가된 도메인의 IP로만 클러스터 외부 트래픽을 전송할 수 있습니다. 이러한 IP의 유효성은 외부 DNS 해석기(Amazon Route 53 Resolver)에서 검색된 TTL에 기반합니다.
#### 애플리케이션 네트워크 정책 사용
`ApplicationNetworkPolicy`는 단일 사용자 지정 리소스 정의(CRD)를 사용하여 표준 Kubernetes 네트워크 정책의 기능을 네임스페이스 수준에서 DNS 기반 필터링과 결합합니다. 따라서 다음 경우에 `ApplicationNetworkPolicy`를 사용할 수 있습니다.
1. IP 블록 및 포트 번호를 사용하여 네트워크 스택의 계층 3 및 4에서 제한 사항 정의.
1. 네트워크 스택의 계층 7에서 작동하는 규칙을 정의하고 FQDN을 기반으로 트래픽을 필터링할 수 있습니다.
**중요**
`ApplicationNetworkPolicy`를 사용하여 정의된 DNS 기반 규칙은 EKS Auto Mode에서 시작한 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. `ApplicationNetworkPolicy`는 송신 규칙에 대한 추가 FQDN 필터와 함께 표준 Kubernetes `NetworkPolicy`의 모든 필드를 지원합니다.
**주의**
동일한 네임스페이스 내에서 `ApplicationNetworkPolicy` 및 `NetworkPolicy`에 동일한 이름을 사용하지 마세요. 이름이 충돌하면 결과 `PolicyEndpoints` 객체에 두 정책이 올바르게 반영되지 않을 수 있습니다. 두 리소스 모두 오류 없이 수락되므로 이 문제를 진단하기가 어렵습니다.
이름 충돌을 해결하려면 네임스페이스 내에서 고유하도록 `ApplicationNetworkPolicy` 또는 `NetworkPolicy`로 이름을 바꾼 후 해당 `PolicyEndpoints` 객체가 올바르게 업데이트되었는지 확인합니다.
#### 예제
EKS Auto Mode 클러스터에는 DNS 이름을 사용하는 로드 밸런서 뒤에 있는 온프레미스 애플리케이션과 통신해야 하는 워크로드가 있습니다. 다음 네트워크 정책을 사용하여 이를 달성할 수 있습니다.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Kubernetes 네트워크 수준에서는 이를 통해 `role: backend` 레이블이 지정된 'galaxy' 네임스페이스의 모든 포드에서 TCP 포트 8080의 도메인 이름 **myapp.mydomain.com**으로의 송신을 허용합니다. 또한 VPC에서 회사 데이터 센터로의 송신 트래픽에 대한 네트워크 연결을 설정해야 합니다.
![\[온프레미스 애플리케이션과 통신하는 EKS Auto의 워크로드에 대한 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 관리자(또는 클러스터) 네트워크 정책
![\[EKS에서 네트워크 정책의 평가 순서에 대한 그림\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/evaluation-order.png)
#### 클러스터 네트워크 정책 사용
`ClusterNetworkPolicy`를 사용하는 경우 관리자 티어 정책이 먼저 평가되며 이는 재정의할 수 없습니다. 관리자 티어 정책이 평가되면 표준 네임스페이스 범위의 정책을 사용하여 적용된 네트워크 분할 규칙을 실행합니다. 이는 `ApplicationNetworkPolicy` 또는 `NetworkPolicy`를 사용하여 수행할 수 있습니다. 마지막으로 클러스터 워크로드에 대한 기본 네트워크 제한 사항을 정의하는 기준 티어 규칙이 적용됩니다. 이러한 기준 티어 규칙은 필요한 경우 네임스페이스 범위의 정책에 의해 재정의 **가능**합니다.
#### 예제
클러스터에 다른 테넌트 워크로드와 격리하려는 애플리케이션이 있습니다. 다른 네임스페이스의 클러스터 트래픽을 명시적으로 차단하여 민감한 워크로드 네임스페이스에 대한 네트워크 액세스를 방지할 수 있습니다.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 고려 사항
### 정책 평가 순서 이해
EKS에서 지원되는 네트워크 정책 기능은 예측 가능한 보안 트래픽 관리를 보장하기 위해 특정 순서로 평가됩니다. 따라서 환경에 대해 효과적인 네트워크 보안 태세를 설계하려면 평가 흐름을 이해하는 것이 중요합니다.
1. **관리자 티어 정책(먼저 평가됨)**: 모든 관리자 티어 ClusterNetworkPolicies는 다른 정책보다 먼저 평가됩니다. 관리자 티어 내에서 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 작업 유형에 따라 다음 상황이 결정됩니다.
+ **거부 작업(가장 높은 우선순위)**: 거부 작업이 있는 관리자 정책이 트래픽과 일치하면 다른 정책에 관계없이 해당 트래픽이 즉시 차단됩니다. 추가 ClusterNetworkPolicy 또는 NetworkPolicy 규칙은 더 이상 처리되지 않습니다. 이를 통해 조직 전체의 보안 제어가 네임스페이스 수준 정책에 의해 재정의되지 않습니다.
+ **허용 작업**: 거부 규칙을 평가한 후 허용 작업이 있는 관리자 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 허용 작업이 일치하면 트래픽이 수락되고 추가 정책 평가가 수행되지 않습니다. 이러한 정책은 레이블 선택기를 기반으로 여러 네임스페이스에 액세스 권한을 부여하여 특정 리소스에 액세스할 수 있는 워크로드를 중앙에서 제어할 수 있습니다.
+ **통과 작업**: 관리자 티어 정책에서 통과 작업은 의사 결정이 하위 티어로 위임합니다. 트래픽이 통과 규칙과 일치하면 평가는 해당 트래픽에 대한 나머지 모든 관리자 티어 규칙을 건너뛰고 NetworkPolicy 티어로 바로 진행합니다. 이를 통해 관리자는 특정 트래픽 패턴에 대한 제어를 애플리케이션 팀에 명시적으로 위임할 수 있습니다. 예를 들어 통과 규칙을 사용하여 외부 액세스에 대한 엄격한 제어를 유지하면서 네임스페이스 내 트래픽 관리를 네임스페이스 관리자에게 위임할 수 있습니다.
1. **네트워크 정책 티어**: 거부 또는 허용과 일치하는 관리자 티어 정책이 없거나 통과 작업이 일치하는 경우 네임스페이스 범위의 ApplicationNetworkPolicy 및 기존의 NetworkPolicy 리소스가 다음에 평가됩니다. 이러한 정책은 개별 네임스페이스 내에서 세분화된 제어를 제공하며 애플리케이션 팀이 관리합니다. 네임스페이스 범위의 정책은 관리자 정책보다 더 제한적일 수 있습니다. 관리자 정책의 거부 결정을 재정의할 수는 없지만 관리자 정책에서 허용하거나 전달하는 트래픽을 추가로 제한할 수 있습니다.
1. **기준 티어 관리자 정책**: 트래픽과 일치하는 관리자 또는 네임스페이스 범위의 정책이 없는 경우 기준 티어 ClusterNetworkPolicies가 평가됩니다. 이는 네임스페이스 범위의 정책으로 재정의할 수 있는 기본 보안 태세를 제공하므로 관리자는 조직 전체의 기본값을 설정하는 동시에 필요에 따라 팀에 사용자 지정할 수 있는 유연성을 제공할 수 있습니다. 기준 정책은 우선순위에 따라(가장 낮은 우선순위 번호 먼저) 평가됩니다.
1. **기본 거부(정책이 일치하지 않는 경우)**:이러한 기본적으로 거부 동작은 명시적으로 허용된 연결만 허용되도록 보장하여 강력한 보안 태세를 유지 관리합니다.
### 최소 권한 원칙 적용
+ **제한적인 정책으로 시작하고 필요에 따라 점진적으로 권한 추가** - 먼저 클러스터 수준에서 기본적으로 거부 정책을 구현한 다음 정상 연결 요구 사항을 검증할 때 허용 규칙을 점진적으로 추가합니다. 이 접근 방식을 사용하면 팀이 각 외부 연결을 명시적으로 정당화하여 보다 안전하고 감사 가능한 환경을 생성할 수 있습니다.
+ **정기적으로 미사용 정책 규칙 감사 및 제거** - 애플리케이션이 진화하면서 시간이 지남에 따라 네트워크 정책이 누적될 수 있으며 공격 표면을 불필요하게 확장하는 더 이상 사용되지 않는 규칙이 남겨질 수 있습니다. 정기적인 검토 프로세스를 구현하여 더 이상 필요하지 않은 정책 규칙을 식별하고 제거하여 엄격하고 관리 가능한 보안 태세를 보장합니다.
+ **가능하면 광범위한 패턴 대신 특정 도메인 이름 사용** - `*.amazonaws.com`과 같은 와일드카드 패턴은 편의를 제공하지만 다양한 서비스에 대한 액세스 권한도 부여합니다. 가능하면 `s3.us-west-2.amazonaws.com`과 같은 정확한 도메인 이름을 지정하여 애플리케이션에 필요한 특정 서비스로만 액세스를 제한함으로써 워크로드가 손상되는 경우 측면 이동의 위험을 줄입니다.
### EKS에서 DNS 기반 정책 사용
+ `ApplicationNetworkPolicy`를 사용하여 정의된 DNS 기반 규칙은 EKS Auto Mode에서 시작된 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. 혼합 모드 클러스터(EKS Auto 및 비EKS Auto 워커 노드로 구성)를 실행하는 경우 DNS 기반 규칙은 EKS Auto 모드 워커 노드(EC2 관리형 인스턴스)에서만 유효합니다.
### DNS 정책 검증
+ **테스트를 위해 프로덕션 네트워크 토폴로지를 미러링하는 스테이징 클러스터 사용** - 스테이징 환경은 정확한 정책 테스트를 보장하기 위해 프로덕션의 네트워크 아키텍처, 외부 종속성 및 연결 패턴을 복제해야 합니다. 여기에는 VPC 구성 일치, DNS 확인 동작, 프로덕션 워크로드에 필요한 것과 동일한 외부 서비스에 대한 액세스가 포함됩니다.
+ **중요한 네트워크 경로에 대한 자동화된 테스트 구현** - CI/CD 파이프라인의 일부로 필수 외부 서비스에 대한 연결을 검증하는 자동화된 테스트를 빌드합니다. 이러한 테스트는 권한 없는 연결이 차단되는 동안 정상 트래픽 흐름이 허용되도록 확인해야 합니다. 이를 통해 인프라가 진화함에 따라 네트워크 정책이 올바른 보안 태세를 유지 관리하는 지속적 검증을 제공합니다.
+ **정책 변경 후 애플리케이션 동작 모니터링** - 새 네트워크 정책 또는 수정된 네트워크 정책을 프로덕션에 배포한 후 애플리케이션 로그, 오류 발생률 및 성능 지표를 면밀히 모니터링하여 연결 문제를 신속하게 식별합니다. 예기치 않은 애플리케이션 동작 또는 서비스 중단이 발생하는 경우 정책 변경 사항을 신속하게 되돌릴 수 있도록 명확한 롤백 절차를 설정합니다.
### Amazon Route 53 DNS 방화벽과의 상호 작용
EKS 관리자 및 네트워크 정책은 트래픽이 시작될 때 포드 수준에서 먼저 평가됩니다. EKS 네트워크 정책이 특정 도메인으로의 송신을 허용하는 경우 포드는 Route 53 Resolver에 도달하는 DNS 쿼리를 수행합니다. 이때 Route 53 DNS 방화벽 규칙이 평가됩니다. DNS 방화벽이 도메인 쿼리를 차단하면 EKS 네트워크 정책에서 허용했더라도 DNS 확인에 실패하고 연결을 설정할 수 없습니다. 그래서 보완적인 보안 계층을 생성합니다. EKS DNS 기반 네트워크 정책은 애플리케이션 특정 액세스 요구 사항 및 다중 테넌트 보안 경계에 대한 포드 수준의 송신 제어를 제공하는 반면, DNS 방화벽은 알려진 악성 도메인에 대해 VPC 전반의 보호를 제공하고 조직 전체의 차단 목록을 적용합니다.
# EKS 자동 모드의 태그 서브넷
EKS 자동 모드의 로드 밸런싱 기능을 사용하는 경우 VPC 서브넷에 AWS 태그를 추가해야 합니다.
## 배경
이 태그는 클러스터와 연결된 서브넷을 식별하며, 더 중요한 것은 서브넷이 퍼블릭인지 프라이빗인지 식별합니다.
퍼블릭 서브넷은 인터넷 게이트웨이를 통해 인터넷에 직접 액세스할 수 있으며, 로드 밸런서와 같이 공개적으로 액세스해야 하는 리소스에 사용됩니다.
프라이빗 서브넷은 인터넷에 직접 액세스할 수 없고 아웃바운드 트래픽에 NAT 게이트웨이를 사용하며, 퍼블릭 IP가 필요 없는 EKS 노드와 같은 내부 리소스에 사용됩니다.
NAT 게이트웨이 및 인터넷 게이트웨이에 대한 자세한 내용은 Amazon Virtual Private Cloud(VPC) 사용 설명서의 [다른 네트워크에 VPC 연결](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)을 참조하세요.
## 요구 사항
현재 EKS 자동 모드에서 로드 밸런싱에 사용되는 서브넷에는 다음 태그 중 하나가 있어야 합니다.
### 퍼블릭 서브넷
퍼블릭 서브넷은 인터넷에 연결된 로드 밸런서에 사용되며, 다음 태그가 있어야 합니다.
| 키 | 값 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` 또는 `` |
### 프라이빗 서브넷
프라이빗 서브넷은 내부 로드 밸런서에 사용되며, 다음 태그가 있어야 합니다.
| 키 | 값 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` 또는 `` |
## 절차
시작하기 전에 퍼블릭 서브넷(인터넷 게이트웨이 액세스 가능)과 프라이빗 서브넷(NAT 게이트웨이 사용)을 식별합니다. VPC 리소스를 수정하려면 권한이 필요합니다.
### AWS Management Console
1. Amazon VPC 콘솔을 열고 **서브넷**으로 이동하세요.
1. 태그를 지정할 서브넷을 선택하세요.
1. **태그** 탭을 선택하고 **태그 추가**를 선택하세요.
1. 적절한 태그를 추가합니다.
+ 퍼블릭 서브넷의 경우: Key=`kubernetes.io/role/elb`
+ 프라이빗 서브넷의 경우: Key=`kubernetes.io/role/internal-elb`
1. **값**을 `1`로 설정하거나 비워 두세요.
1. 저장하고 나머지 서브넷에 대해 반복하세요.
### AWS CLI
퍼블릭 서브넷의 경우
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
프라이빗 서브넷의 경우
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
`subnet-ID`를 실제 서브넷 ID로 바꿉니다.
# kubectl 디버그를 사용하여 Kubernetes 노드에서 CIS 규정 준수 보고서 생성
이 주제에서는 `kubectl debug` 명령을 사용하여 Amazon EKS 노드에 대한 인터넷 보안 센터(CIS) 규정 준수 보고서를 생성하는 방법을 설명합니다. 이 명령을 사용하면 Kubernetes 노드에 디버깅 컨테이너를 임시로 생성하고 `apiclient` 도구를 사용하여 CIS 규정 준수 검사를 실행할 수 있습니다. `apiclient` 도구는 EKS 자동 모드 노드에서 사용하는 OS인 Bottlerocket OS의 일부입니다.
## 사전 조건
시작하기 전에 다음을 갖추었는지 확인하세요.
+ `kubectl`이 구성된 Amazon EKS 클러스터에 대한 액세스 권한(버전이 v1.32.0 이상이어야 함, 확인하려면 `kubectl version` 입력)
+ 노드를 디버깅할 수 있는 적절한 IAM 권한
+ 디버그 작업을 허용하는 유효한 프로파일(예: `sysadmin`)
`kubectl`을 사용하여 디버깅 프로파일을 사용하는 방법에 대한 자세한 내용은 Kubernetes Documentation의 [Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)을 참조하세요.
## 절차
1. 보고서를 실행할 노드의 AWS 인스턴스 ID를 결정합니다. 다음 명령을 사용하여 클러스터의 노드를 나열합니다. 인스턴스 ID는 이름 열에서 찾을 수 있으며 `i-`로 시작합니다.
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. ``를 쿼리하려는 노드의 인스턴스 ID로 바꿔서 다음 명령을 실행합니다.
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
이 명령의 구성 요소는 다음과 같습니다.
+ `kubectl debug node/` - 지정된 EC2 인스턴스 ID에 디버깅 세션을 생성합니다.
+ `-it` - TTY(명령줄 쉘)를 할당하고 대화형 사용을 위해 stdin을 열어 둡니다.
+ `--profile=sysadmin` - 적절한 권한으로 지정된 `kubectl` 프로파일을 사용합니다.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` - 디버깅을 위한 컨테이너 이미지로 `amazonlinux:2023`을 사용합니다.
+ `bash -c "…"` - bash 쉘에서 다음 명령을 실행합니다.
+ `yum install -q -y util-linux-core` - 필요한 유틸리티 패키지를 자동으로 설치합니다.
+ `nsenter -t 1 -m` - `nsenter`를 실행하여 호스트 프로세스의 네임스페이스(PID 1)로 들어갑니다.
+ `apiclient report cis --level 1 --format text` - 텍스트 출력을 사용하여 레벨 1에서 CIS 규정 준수 보고서를 실행합니다.
1. 보고서 텍스트 출력을 검토합니다.
## 출력 해석
명령은 다양한 CIS 제어의 규정 준수 상태를 보여주는 텍스트 기반 보고서를 생성합니다. 출력에는 다음이 포함됩니다.
+ 개별 CIS 제어 ID
+ 각 제어에 대한 설명
+ 각 검사의 통과, 실패 또는 건너뛰기 상태
+ 규정 준수 문제를 설명하는 세부 정보
다음은 Bottlerocket 인스턴스에서 실행되는 보고서의 출력 예입니다.
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
벤치마크에 대한 자세한 내용은 인터넷 보안 센터(CIS)의 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)를 참조하세요.
## 관련 리소스
+ Bottlerocket OS Documentation의 [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)
+ 쿠버네티스 문서의 [동작 중인 파드 디버그](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)
+ CIS(Center for Internet Security)의 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)
# EKS Auto Mode용 고객 관리형 KMS 키를 사용하여 EBS 볼륨 암호화 활성화
고객 관리형 KMS 키를 사용하여 EKS Auto Mode 인스턴스의 임시 루트 볼륨을 암호화할 수 있습니다.
Amazon EKS Auto Mode는 Kubernetes 클러스터의 암호화된 EBS 볼륨을 관리할 때 서비스 연결 역할을 사용하여 다른 AWS 서비스에 권한을 위임합니다. 이 주제에서는 EKS Auto Mode에서 Amazon EBS 암호화용 고객 관리형 키를 지정할 때 필요한 키 정책을 설정하는 방법에 대해 설명합니다.
고려 사항:
+ EKS Auto Mode는 기본 AWS 관리형 키를 사용하여 계정의 암호화된 볼륨을 보호하는 데 추가 승인이 필요하지 않습니다.
+ 이 주제에서는 EC2 인스턴스의 루트 볼륨인 임시 볼륨의 암호화를 다룹니다. 워크로드에 사용되는 데이터 볼륨 암호화에 대한 자세한 내용은 [스토리지 클래스 생성](create-storage-class.md) 섹션을 참조하세요.
## 개요
다음 AWS KMS 키는 EKS Auto Mode에서 인스턴스를 시작할 때 Amazon EBS 루트 볼륨 암호화에 사용할 수 있습니다.
+ **AWS 관리형 키** - Amazon EBS에서 생성, 소유 및 관리하는 계정의 암호화 키입니다. 이 키는 새 계정을 위한 기본 암호화 키입니다.
+ **고객 관리형 키** - 사용자가 생성, 소유 및 관리하는 사용자 지정 암호화 키입니다.
**참고**
키는 대칭이어야 합니다. Amazon EBS에서는 비대칭 고객 관리형 키를 지원하지 않습니다.
## 1단계: 키 정책 구성
KMS 키에는 EKS Auto Mode가 고객 관리형 키로 암호화된 Amazon EBS 볼륨으로 인스턴스를 시작할 수 있도록 허용하는 키 정책이 있어야 합니다.
다음 구조로 키 정책을 구성합니다.
**참고**
이 정책에는 EKS Auto Mode에 대한 권한만 포함되어 있습니다. 다른 자격 증명이 키를 사용하거나 권한 부여를 관리해야 하는 경우 키 정책에 추가 권한이 필요할 수 있습니다.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
``를 실제 AWS 계정 ID로 바꿔야 합니다.
키 정책을 구성할 때:
+ `ClusterServiceRole`에는 암호화 작업에 KMS 키를 사용하는 데 필요한 IAM 권한이 있어야 합니다.
+ `kms:GrantIsForAWSResource` 조건은 AWS 서비스에 대해서만 권한 부여를 생성할 수 있도록 합니다.
## 2단계: 고객 관리형 키를 사용하여 NodeClass 구성
키 정책을 구성한 후 EKS Auto Mode NodeClass 구성에서 KMS 키를 참조합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
자리 표시자 값을 실제 값으로 바꿉니다.
+ ``을 실제 AWS 리전으로 바꿈
+ ``를 실제 AWS 계정 ID로 바꿈
+ ``를 실제 KMS 키 ID로 바꿈
다음 형식 중 하나를 사용하여 KMS 키를 지정할 수 있습니다.
+ KMS 키 ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS 키 ARN: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ 키 별칭 이름: `alias/eks-auto-mode-key`
+ 키 별칭 ARN: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
kubectl을 사용하여 NodeClass 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
## 관련 리소스
+ [Amazon EKS용 NodeClass 생성](create-node-class.md)
+ AWS Key Management Service 개발자 안내서에서 자세한 내용을 참조하세요.
+ [키 정책의 AWS 서비스에 대한 권한](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [키 정책 변경](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [AWS KMS의 권한 부여](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# EKS 자동 모드에 대한 조직 제어 업데이트
일부 조직 제어로 인해 EKS 자동 모드가 제대로 작동하지 않을 수 있습니다. 이 경우 EKS 자동 모드가 사용자를 대신하여 EC2 인스턴스를 관리하는 데 필요한 권한을 갖도록 해당 제어를 업데이트해야 합니다.
EKS 자동 모드는 서비스 역할을 사용하여 EKS 자동 모드 노드를 지원하는 EC2 인스턴스를 시작합니다. 서비스 역할은 사용자의 계정에서 생성된 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)로, 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임하는 역할입니다. 서비스 역할로 수행되는 작업에는 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)이 항상 적용됩니다. 이를 통해 SCP는 자동 모드의 작동을 억제할 수 있습니다. SCP를 사용하여 시작할 수 있는 Amazon Machine Image(AMI)를 제한하는 경우가 가장 일반적인 예입니다. EKS 자동 모드가 작동하도록 하려면 EKS 자동 모드 계정에서 AMI를 시작할 수 있게 SCP를 수정합니다.
[EC2 허용된 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 기능을 사용하여 다른 계정에 있는 AMI의 가시성을 제한할 수도 있습니다. 이 기능을 사용하는 경우 관심 리전에 EKS 자동 모드 AMI 계정도 포함하도록 이미지 기준을 확장해야 합니다.
## EKS 자동 모드 AMI를 제외한 모든 AMI를 차단하는 SCP 예제
아래 SCP는 AMI가 us-west-2 또는 us-east-1의 EKS 자동 모드 AMI 계정에 속하지 않는 한 `ec2:RunInstances`를 직접적으로 호출하지 못하도록 합니다.
**참고**
`ec2:Owner` 컨텍스트 키를 사용하지 **않는** 것이 중요합니다. Amazon은 EKS 자동 모드 AMI 계정을 소유하며 이 키의 값은 항상 `amazon`입니다. `ec2:Owner`가 `amazon`인 경우 AMI를 시작할 수 있는 SCP를 구성하면 EKS 자동 모드용 AMI뿐만 아니라 Amazon이 소유한 모든 AMI를 시작할 수 있습니다.\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS 자동 모드 AMI 계정
리전별로 다른 AWS 계정이 EKS 자동 모드 퍼블릭 AMI를 호스팅합니다.
| | |
| --- |--- |
| AWS 리전 | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## 퍼블릭 IP 주소 연결
`ec2:RunInstances`가 호출되면 인스턴스 시작의 `AssociatePublicIpAddress` 필드는 인스턴스가 시작되는 서브넷 유형에 따라 자동으로 결정됩니다. SCP를 사용하여 시작되는 서브넷 유형과 무관하게 이 값을 명시적으로 false로 설정할 수 있습니다. 이 경우 SCP의 요구 사항을 충족하기 위해 NodeClass 필드 `spec.advancedNetworking.associatePublicIPAddress`를 false로 설정할 수도 있습니다.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# EKS Auto Mode를 사용하여 용량 예약으로 워크로드 배포 제어
[용량 예약](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)으로 워크로드 배포를 제어할 수 있습니다. EKS Auto Mode는 EC2 온디맨드 용량 예약(ODCR) 및 ML용 EC2 용량 블록을 지원합니다.
**작은 정보**
기본적으로 EKS Auto Mode는 오픈 매치를 통해 오픈 ODCR로 시작할 수 있지만 우선순위는 지정되지 않습니다. 오픈 매치를 통해 시작된 인스턴스에는 `reserved`가 아닌 `karpenter.sh/capacity-type: on-demand` 레이블이 지정됩니다. ODCR 사용량의 우선순위를 지정하고 인스턴스에 `karpenter.sh/capacity-type: reserved` 레이블을 지정하려면 NodeClass 정의에서 `capacityReservationSelectorTerms`를 구성합니다. ML에 대한 용량 블록에는 항상 `capacityReservationSelectorTerms`가 필요하며 이 용량 블록은 자동으로 사용되지 않습니다.
## EC2 온디맨드 용량 예약(ODCR)
EC2 온디맨드 용량 예약(ODCR)을 사용하면 특정 가용 영역의 Amazon EC2 인스턴스에 대해 원하는 기간만큼 컴퓨팅 용량을 예약할 수 있습니다. EKS 자동 모드를 사용하는 경우 사전 구매한 용량의 사용률을 극대화하거나 중요한 워크로드가 보장된 리소스에 액세스할 수 있도록 Kubernetes 워크로드를 이러한 예약 인스턴스에 배포할지 여부를 제어할 수 있습니다.
기본적으로 EKS 자동 모드는 개방형 ODCR로 자동 시작됩니다. 그러나 NodeClass에서 `capacityReservationSelectorTerms`를 구성하여 워크로드에서 사용하는 ODCR을 명시적으로 제어할 수 있습니다. 구성된 ODCR을 사용하여 프로비저닝된 노드는 `karpenter.sh/capacity-type: reserved`를 가지며 온디맨드와 스팟보다 우선순위가 높습니다. 이 기능이 활성화되면 EKS 자동 모드는 더 이상 개방형 ODCR을 자동으로 사용하지 않습니다. NodeClass에서 ODCR을 명시적으로 선택해야 하므로 클러스터 전체에서 용량 예약 사용량을 정확하게 제어할 수 있습니다.
**주의**
클러스터의 NodeClass에서 `capacityReservationSelectorTerms`를 구성하는 경우 EKS 자동 모드는 더 이상 클러스터의 *모든* NodeClass에 대해 개방형 ODCR을 자동으로 사용하지 않습니다.
### NodeClass 예제
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
이 예제 NodeClass는 ODCR을 선택하는 두 가지 접근 방식을 보여줍니다. 첫 번째 방법은 ID(`cr-56fac701cc1951b03`)로 특정 ODCR을 직접 참조합니다. 두 번째 방법은 태그 기반 선택을 사용하여 `Name: "targeted-odcr"` 태그가 있는 ODCR을 대상으로 합니다. 예약을 소유한 AWS 계정으로 필터링할 수도 있는데, 이는 특히 여러 계정이 관련된 시나리오나 공유 용량 예약을 처리할 때 유용합니다.
## ML용 EC2 용량 블록 사용
ML용 용량 블록은 향후 날짜에 GPU 기반 가속 컴퓨팅 인스턴스를 예약하여 단기간의 기계 학습(ML) 워크로드를 지원합니다. 용량 블록 내부에서 실행되는 인스턴스는 지연 시간이 짧은 페타비트 규모의 비차단 네트워킹을 위해 Amazon EC2 UltraClusters 내부에 자동으로 서로 가깝게 배치됩니다.
지원되는 플랫폼 및 인스턴스 유형에 대한 자세한 내용은 EC2 사용 설명서의 [ML용 용량 블록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)을 참조하세요.
ODCR(앞에서 설명)과 마찬가지로 ML용 용량 블록을 사용하는 EKS Auto Mode NodeClass를 생성할 수 있습니다.
다음 샘플 정의에서는 세 가지 리소스를 생성합니다.
1. 용량 블록 예약을 참조하는 NodeClass
1. NodeClass를 사용하고 테인트를 적용하는 NodePool
1. 테인트를 허용하고 GPU 리소스를 요청하는 포드 사양
### NodeClass 예제
이 NodeClass는 예약 ID로 ML용 특정 용량 블록을 참조합니다. EC2 콘솔에서 이 ID를 얻을 수 있습니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
### NodePool 예제
이 NodePool은 `gpu` NodeClass를 참조하고 중요한 구성을 지정합니다.
+ `karpenter.sh/capacity-type: reserved`를 설정하여 예약 용량**만** 사용함
+ ML 워크로드에 적합한 특정 GPU 인스턴스 패밀리를 요청함
+ 이러한 노드에 GPU 워크로드만 예약되도록 `nvidia.com/gpu` 테인트를 적용함
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
### 포드 예제
이 포드 예제는 용량 블록 노드에서 실행하도록 워크로드를 구성하는 방법을 보여줍니다.
+ **nodeSelector**를 사용하여 특정 GPU 유형(이 경우 H200 GPUs)을 대상으로 지정함
+ 여기에는 NodePool에서 적용하는 `nvidia.com/gpu` 테인트에 대한 **허용치**가 포함됨
+ `nvidia.com/gpu` 리소스 유형을 사용하여 명시적으로 **GPU 리소스를 요청**함
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
자세한 내용은 Kubernetes 문서의 [포드](https://kubernetes.io/docs/concepts/workloads/pods/)를 참조하세요.
### 관련 리소스
+ Amazon EC2 사용 설명서의 [ML용 용량 블록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)
+ Amazon EC2 사용 설명서의 [용량 블록 찾기 및 구매](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)
+ [Amazon EKS에서 AI/ML 워크로드의 컴퓨팅 리소스 관리](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ EKS 모범 사례 가이드의 [GPU 리소스 최적화 및 비용 관리](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)
# 로컬 영역에 EKS Auto Mode 노드 배포
EKS Auto Mode는 자동 노드 프로비저닝을 통해 단순화된 클러스터 관리를 제공합니다. AWS 로컬 영역은 AWS 인프라를 최종 사용자에게 더 가까운 지리적 위치로 확장하여 지연 시간에 민감한 애플리케이션의 지연 시간을 줄입니다. 이 가이드에서는 AWS 로컬 영역에 EKS Auto Mode 노드를 배포하는 프로세스를 안내하여 특정 지리적 영역의 사용자가 지연 시간을 줄이면서 컨테이너화된 애플리케이션을 실행할 수 있도록 지원합니다.
또한 이 가이드는 Kubernetes 테인트 및 허용 오차를 사용하여 로컬 영역 노드에서 특정 워크로드만 실행하게 함으로써 비용을 제어하고 리소스 사용을 최적화하는 방법을 보여줍니다.
## 사전 조건
로컬 영역에 EKS Auto Mode 노드 배포를 시작하기 전에 다음 사전 조건이 있는지 확인합니다.
+ [기존 EKS Auto Mode 클러스터](create-auto.md)
+ [AWS 계정에서 로컬 영역에 옵트인됨](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## 1단계: 로컬 영역 서브넷 생성
로컬 영역에 EKS Auto Mode 노드를 배포하는 첫 번째 단계는 해당 로컬 영역에 서브넷을 생성하는 것입니다. 이 서브넷은 노드에 대한 네트워크 인프라를 제공하고 노드가 나머지 VPC와 통신할 수 있게 합니다. [Create a Local Zone subnet](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) 지침(AWS 로컬 영역 사용 설명서)에 따라 선택한 로컬 영역에서 서브넷을 생성합니다.
**작은 정보**
로컬 영역 서브넷의 이름을 기록합니다.
## 2단계: 로컬 영역 서브넷에 대한 NodeClass 생성
로컬 영역 서브넷을 생성한 후 이 서브넷을 참조하는 NodeClass를 정의해야 합니다. NodeClass는 사용할 서브넷, 보안 그룹 및 스토리지 구성을 포함하여 노드의 인프라 속성을 지정하는 Kubernetes 사용자 지정 리소스입니다. 아래 예제에서는 해당 이름을 기반으로 로컬 영역 서브넷을 대상으로 하는 'local-zone'이라는 NodeClass를 생성합니다. 또한 서브넷 ID를 사용할 수도 있습니다. 로컬 영역 서브넷을 대상으로 하도록 이 구성을 조정해야 합니다.
자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## 3단계: NodeClass 및 테인트를 사용하여 NodePool 생성
NodeClass가 구성된 경우 이제 이 NodeClass를 사용하는 NodePool을 생성해야 합니다. NodePool은 인스턴스 유형을 포함하여 노드의 컴퓨팅 특성을 정의합니다. NodePool은 NodeClass를 참조로 사용하여 인스턴스를 시작할 위치를 결정합니다.
아래 예제에서는 'local-zone' NodeClass를 참조하는 NodePool을 생성합니다. 또한 노드에 테인트를 추가하여 이러한 로컬 영역 노드에서 허용 오차가 일치하는 포드만 예약할 수 있도록 합니다. 이는 일반적으로 비용이 더 많이 들고 특별히 지연 시간 단축의 이점을 특별히 활용하는 워크로드에서만 사용해야 하는 로컬 영역 노드에 특히 중요합니다.
자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
키가 `aws.amazon.com/local-zone`이고 효과가 `NoSchedule`인 테인트는 일치하는 허용 오차가 없는 포드가 이러한 노드에서 예약되지 않도록 합니다. 이를 통해 정기적인 워크로드가 로컬 영역에서 실수로 실행되어 예기치 않은 비용이 발생하지 않도록 방지합니다.
## 4단계: 허용 오차 및 노드 선호도를 사용하여 워크로드 배포
로컬 영역 노드에서 워크로드 배치에 대한 최적의 제어를 위해 테인트/허용 오차 및 노드 선호도를 모두 함께 사용합니다. 이러한 결합된 접근 방식에는 다음과 같은 이점이 있습니다.
1. **비용 제어**: 테인트를 사용하면 명시적 허용 오차가 있는 포드만 잠재적으로 비용이 많이 드는 로컬 영역 리소스를 사용할 수 있도록 보장합니다.
1. **보장된 배치**: 노드 선호도는 지연 시간에 민감한 애플리케이션이 일반 클러스터 노드가 아닌 로컬 영역에서만 실행되도록 보장합니다.
다음은 로컬 영역 노드에서 특별히 실행하도록 구성된 배포에 대한 예제입니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
이 배포에는 다음과 같은 두 가지 주요 예약 구성이 있습니다.
1. **허용 오차**를 사용하면 `aws.amazon.com/local-zone` 테인트가 있는 노드에서 포드를 예약할 수 있습니다.
1. **노드 선호도** 요구 사항은 이러한 포드가 레이블 `node-type: local-zone`인 노드에서만 실행되도록 보장합니다.
이렇게 하면 지연 시간에 민감한 애플리케이션이 로컬 영역 노드에서만 실행되고, 일반 애플리케이션은 명시적으로 구성되지 않은 한 로컬 영역 리소스를 사용하지 않도록 보장합니다.
## 5단계: AWS 콘솔로 확인
NodeClass, NodePool 및 배포를 설정한 후 노드가 예상대로 로컬 영역에서 프로비저닝되고 워크로드가 실행 중인지 확인해야 합니다. AWS Management Console을 사용하여 EC2 인스턴스가 올바른 로컬 영역 서브넷에서 시작되고 있는지 확인할 수 있습니다.
또한 `kubectl get nodes -o wide`를 사용하여 Kubernetes 노드 목록을 확인해 노드가 올바른 레이블과 테인트로 클러스터에 조인하고 있는지 확인할 수 있습니다.
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
워크로드 포드가 로컬 영역 노드에서 예약되어 있는지 확인할 수도 있습니다.
```
kubectl get pods -o wide
```
이 접근 방식을 사용하면 로컬 영역 테인트를 특별히 허용하는 워크로드만 이러한 노드에서 예약되므로 비용을 제어하고 로컬 영역 리소스를 가장 효율적으로 사용할 수 있습니다.
# 노드에 대한 고급 보안 설정 구성
이 주제에서는 노드 클래스의 `advancedSecurity` 사양을 사용하여 Amazon EKS Auto Mode 노드에 대한 고급 보안 설정을 구성하는 방법을 설명합니다.
## 사전 조건
시작하기 전에 다음을 갖추었는지 확인하세요.
+ Amazon EKS 자동 모드 클러스터. 자세한 내용은 [Amazon EKS 자율 모드에서 클러스터 생성](create-auto.md) 섹션을 참조하세요.
+ `kubectl`을 설치하고 구성했습니다. 자세한 내용은 [Amazon EKS를 사용하도록 설정](setting-up.md) 섹션을 참조하세요.
+ 노드 클래스 구성에 대한 이해. 자세한 내용은 [Amazon EKS용 노드 클래스 생성](create-node-class.md) 섹션을 참조하세요.
## 고급 보안 설정 구성
노드에 대한 고급 보안 설정을 구성하려면 노드 클래스 사양에서 `advancedSecurity` 필드를 설정합니다.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
이 구성을 적용합니다.
```
kubectl apply -f nodeclass.yaml
```
노드 풀 구성에서 이 노드 클래스를 참조합니다. 자세한 내용은 [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) 섹션을 참조하세요.
## 필드 설명
+ `fips`(부울, 선택 사항): `true`로 설정하면 FIPS 140-2 검증 암호화 모듈와 함께 AMI를 사용하여 노드를 프로비저닝합니다. 이 설정에서는 FIPS 준수 AMI를 선택하며, 고객은 규정 준수 요구 사항을 관리할 책임이 있습니다. 자세한 내용은 [AWS FIPS compliance](https://aws.amazon.com/compliance/fips/)를 참조하세요. 기본값: `false`.
+ `kernelLockdown`(문자열, 선택 사항): 커널 잠금 보안 모듈 모드를 제어합니다. 허용되는 값:
+ `integrity`: 커널 메모리를 덮어쓰거나 커널 코드를 수정하기 위해 메서드를 차단합니다. 서명되지 않은 커널 모듈을 로드하지 않도록 합니다.
+ `none`: 커널 잠금 보호를 비활성화합니다.
자세한 내용은 [Linux 커널 잠금 설명서](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)를 참조하세요.
## 고려 사항
+ FIPS 준수 AMI는 AWS 미국 동부/서부, AWS GovCloud(미국) 및 AWS 캐나다(중부/서부) 리전에서 사용할 수 있습니다. 자세한 내용은 [AWS FIPS compliance](https://aws.amazon.com/compliance/fips/)를 참조하세요.
+ `kernelLockdown: "integrity"`를 사용하는 경우 워크로드에 서명되지 않은 커널 모듈의 로드나 커널 메모리 수정이 필요하지 않은지 확인합니다.
## 관련 리소스
+ [Amazon EKS용 노드 클래스 생성](create-node-class.md) - 노드 클래스 구성 가이드 작성
+ [EKS Auto Mode용 노드 풀 생성](create-node-pool.md) - 노드 풀 구성