**이 페이지 개선에 도움 주기** 

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.

# 로컬 영역에 EKS Auto Mode 노드 배포
<a name="auto-local-zone"></a>

EKS Auto Mode는 자동 노드 프로비저닝을 통해 단순화된 클러스터 관리를 제공합니다. AWS 로컬 영역은 AWS 인프라를 최종 사용자에게 더 가까운 지리적 위치로 확장하여 지연 시간에 민감한 애플리케이션의 지연 시간을 줄입니다. 이 가이드에서는 AWS 로컬 영역에 EKS Auto Mode 노드를 배포하는 프로세스를 안내하여 특정 지리적 영역의 사용자가 지연 시간을 줄이면서 컨테이너화된 애플리케이션을 실행할 수 있도록 지원합니다.

또한 이 가이드는 Kubernetes 테인트 및 허용 오차를 사용하여 로컬 영역 노드에서 특정 워크로드만 실행하게 함으로써 비용을 제어하고 리소스 사용을 최적화하는 방법을 보여줍니다.

## 사전 조건
<a name="_prerequisites"></a>

로컬 영역에 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단계: 로컬 영역 서브넷 생성
<a name="_step_1_create_local_zone_subnet"></a>

로컬 영역에 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 생성
<a name="_step_2_create_nodeclass_for_local_zone_subnet"></a>

로컬 영역 서브넷을 생성한 후 이 서브넷을 참조하는 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: <local-subnet-id>
```

## 3단계: NodeClass 및 테인트를 사용하여 NodePool 생성
<a name="_step_3_create_nodepool_with_nodeclass_and_taint"></a>

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단계: 허용 오차 및 노드 선호도를 사용하여 워크로드 배포
<a name="_step_4_deploy_workloads_with_toleration_and_node_affinity"></a>

로컬 영역 노드에서 워크로드 배치에 대한 최적의 제어를 위해 테인트/허용 오차 및 노드 선호도를 모두 함께 사용합니다. 이러한 결합된 접근 방식에는 다음과 같은 이점이 있습니다.

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 콘솔로 확인
<a name="step_5_verify_with_shared_aws_console"></a>

NodeClass, NodePool 및 배포를 설정한 후 노드가 예상대로 로컬 영역에서 프로비저닝되고 워크로드가 실행 중인지 확인해야 합니다. AWS Management Console을 사용하여 EC2 인스턴스가 올바른 로컬 영역 서브넷에서 시작되고 있는지 확인할 수 있습니다.

또한 `kubectl get nodes -o wide`를 사용하여 Kubernetes 노드 목록을 확인해 노드가 올바른 레이블과 테인트로 클러스터에 조인하고 있는지 확인할 수 있습니다.

```
kubectl get nodes -o wide
kubectl describe node <node-name> | grep -A 5 Taints
```

워크로드 포드가 로컬 영역 노드에서 예약되어 있는지 확인할 수도 있습니다.

```
kubectl get pods -o wide
```

이 접근 방식을 사용하면 로컬 영역 테인트를 특별히 허용하는 워크로드만 이러한 노드에서 예약되므로 비용을 제어하고 로컬 영역 리소스를 가장 효율적으로 사용할 수 있습니다.