이 페이지 개선에 도움 주기

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

로컬 영역에 EKS Auto Mode 노드 배포

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

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

사전 조건

로컬 영역에 EKS Auto Mode 노드 배포를 시작하기 전에 다음 사전 조건이 있는지 확인합니다.

1단계: 로컬 영역 서브넷 생성

로컬 영역에 EKS Auto Mode 노드를 배포하는 첫 번째 단계는 해당 로컬 영역에 서브넷을 생성하는 것입니다. 이 서브넷은 노드에 대한 네트워크 인프라를 제공하고 노드가 나머지 VPC와 통신할 수 있게 합니다. Create a Local Zone subnet 지침(AWS 로컬 영역 사용 설명서)에 따라 선택한 로컬 영역에서 서브넷을 생성합니다.

2단계: 로컬 영역 서브넷에 대한 NodeClass 생성

로컬 영역 서브넷을 생성한 후 이 서브넷을 참조하는 NodeClass를 정의해야 합니다. NodeClass는 사용할 서브넷, 보안 그룹 및 스토리지 구성을 포함하여 노드의 인프라 속성을 지정하는 Kubernetes 사용자 지정 리소스입니다. 아래 예제에서는 해당 이름을 기반으로 로컬 영역 서브넷을 대상으로 하는 'local-zone'이라는 NodeClass를 생성합니다. 또한 서브넷 ID를 사용할 수도 있습니다. 로컬 영역 서브넷을 대상으로 하도록 이 구성을 조정해야 합니다.

자세한 내용은 Amazon EKS용 노드 클래스 생성 섹션을 참조하세요.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: local-zone
spec:
  subnetSelectorTerms:
    - id: <local-subnet-id>

3단계: NodeClass 및 테인트를 사용하여 NodePool 생성

NodeClass가 구성된 경우 이제 이 NodeClass를 사용하는 NodePool을 생성해야 합니다. NodePool은 인스턴스 유형을 포함하여 노드의 컴퓨팅 특성을 정의합니다. NodePool은 NodeClass를 참조로 사용하여 인스턴스를 시작할 위치를 결정합니다.

아래 예제에서는 'local-zone' NodeClass를 참조하는 NodePool을 생성합니다. 또한 노드에 테인트를 추가하여 이러한 로컬 영역 노드에서 허용 오차가 일치하는 포드만 예약할 수 있도록 합니다. 이는 일반적으로 비용이 더 많이 들고 특별히 지연 시간 단축의 이점을 특별히 활용하는 워크로드에서만 사용해야 하는 로컬 영역 노드에 특히 중요합니다.

자세한 내용은 EKS Auto Mode용 노드 풀 생성 섹션을 참조하세요.

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

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

다음은 로컬 영역 노드에서 특별히 실행하도록 구성된 배포에 대한 예제입니다.

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"

이 배포에는 다음과 같은 두 가지 주요 예약 구성이 있습니다.

이렇게 하면 지연 시간에 민감한 애플리케이션이 로컬 영역 노드에서만 실행되고, 일반 애플리케이션은 명시적으로 구성되지 않은 한 로컬 영역 리소스를 사용하지 않도록 보장합니다.

5단계: AWS 콘솔로 확인

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

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