쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

Amazon EKS에서 Amazon 애플리케이션 복구 컨트롤러(ARC)의 구역 이동에 대해 알아보기

포커스 모드
Amazon EKS에서 Amazon 애플리케이션 복구 컨트롤러(ARC)의 구역 이동에 대해 알아보기 - Amazon EKS

Kubernetes에는 가용 영역(AZ)의 상태 저하 또는 손상과 같은 이벤트에 대해 애플리케이션을 보다 탄력적으로 만들 수 있는 기본 기능이 있습니다. Amazon EKS 클러스터에서 워크로드를 실행할 때 Amazon Application Recovery Controller(ARC) 영역 이동 또는 영역 자동 이동을 사용하여 애플리케이션 환경의 내결함성 및 애플리케이션 복구를 더욱 개선할 수 있습니다. ARC 구역 이동은 구역 이동이 만료되거나 취소할 때까지 리소스에 대한 트래픽을 장애가 발생한 AZ에서 멀리 이동할 수 있는 임시 조치로 설계되었습니다. 필요한 경우 구역 이동을 연장할 수 있습니다.

EKS 클러스터에 대한 영역별 전환을 시작하거나 영역 자동 전환을 활성화하여 AWS가 대신 수행할 수 있도록 허용할 수 있습니다. 이 변경은 클러스터의 동서 네트워크 트래픽 흐름을 업데이트하여 정상 AZ의 워커 노드에서 실행 중인 포드에 대한 네트워크 엔드포인트만 고려하도록 합니다. 또한 EKS 클러스터의 애플리케이션에 대한 인그레스 트래픽을 처리하는 모든 ALB 또는 NLB는 트래픽을 정상 AZ의 타깃으로 자동 라우팅합니다. 고가용성 목표를 추구하는 고객의 경우, AZ가 장애가 발생하는 경우 복구될 때까지 모든 트래픽을 장애가 발생한 AZ로부터 멀리 이동시키는 것이 중요할 수 있습니다. 이를 위해 ARC 영역 전환을 사용하여 ALB 또는 NLB를 활성화할 수도 있습니다.

포드 간 동서 네트워크 트래픽 흐름 이해하기

다음 다이어그램은 주문과 제품이라는 두 가지 워크로드 예시를 보여줍니다. 이 예시의 목적은 서로 다른 AZ의 워크로드와 포드가 통신하는 방법을 보여주기 위한 것이다.

네트워크 트래픽 그림
네트워크 트래픽 그림
  1. Orders가 Products과 통신하려면 먼저 대상 서비스의 DNS 이름을 확인해야 합니다. Orders는 CoreDNS와 통신하여 해당 서비스의 가상 IP 주소(클러스터 IP)를 가져옵니다. Orders가 제품 서비스 이름을 확인하면 해당 대상 IP로 트래픽을 전송합니다.

  2. kube-proxy는 클러스터의 모든 노드에서 실행되며 Service용 EndpointSlices를 지속적으로 감시합니다. 서비스가 생성되면 EndpointSlice 컨트롤러가 백그라운드에서 EndpointSlice를 생성하고 관리합니다. 각 EndpointSlice에는 엔드포인트가 실행 중인 노드와 함께 포드 주소의 하위 집합을 포함하는 엔드포인트 목록 또는 테이블이 있습니다. kube-proxy는 노드에서 iptables를 사용하여 이러한 각 Pod 엔드포인트에 대한 라우팅 규칙을 설정합니다. 또한 kube-proxy는 서비스의 클러스터 IP로 향하는 트래픽을 대신 포드의 IP 주소로 직접 전송하도록 리디렉션하여 기본적인 형태의 로드 밸런싱을 담당합니다. kube-proxy는 발신 연결에서 대상 IP를 다시 작성하여 이를 수행합니다.

  3. 그런 다음 네트워크 패킷은 위 다이어그램에 표시된 대로 각 노드의 ENI를 통해 AZ 2의 제품 포드로 전송됩니다.

EKS의 ARC 구역 이동 이해

사용자 환경에 AZ 장애가 있는 경우 EKS 클러스터 환경에 대한 영역 이동을 시작할 수 있습니다. 또는 AWS가 영역 자동 전환을 사용하여 이를 관리하도록 허용할 수 있습니다. 영역 자동 전환을 사용하면 AWS는 클러스터 환경의 손상된 AZ에서 트래픽을 자동으로 전환하여 전체 AZ 상태를 모니터링하고 잠재적인 AZ 장애에 대응합니다.

ARC로 EKS 클러스터 구역 이동이 활성화되면 ARC 콘솔, AWS CLI 또는 구역 이동 및 구역 자동 이동 API를 사용하여 구역 이동을 트리거하거나 구역 자동 이동을 활성화할 수 있습니다. EKS 구역 교대 근무 중에는 다음 작업이 자동으로 수행됩니다:

  • 영향을 받는 AZ의 모든 노드가 폐쇄됩니다. 이렇게 하면 Kubernetes 스케줄러가 건강하지 않은 AZ의 노드에 새 포드를 스케줄링하지 못하게 된다.

  • Managed Node Groups를 사용하는 경우 가용 영역 리밸런싱이 일시 중지되고 Auto Scaling Group(ASG)이 업데이트되어 새 EKS Data Plane 노드가 정상 AZs 에서만 시작되도록 합니다.

  • 비정상적인 AZ의 노드는 종료되지 않으며 이러한 노드에서 포드가 퇴출되지 않습니다. 이는 구역 전환 근무가 만료되거나 취소될 때 트래픽이 아직 수용 인원이 남아 있는 AZ로 안전하게 복귀할 수 있도록 하기 위한 것입니다.

  • EndpointSlice 컨트롤러는 손상된 AZ에서 모든 Pod 엔드포인트를 찾아 관련 EndpointSlices 에서 제거합니다. 이렇게 하면 정상 AZ에 있는 포드 엔드포인트만 네트워크 트래픽을 수신하도록 타겟팅됩니다. 영역 이동이 취소되거나 만료되면, EndpointSlice 컨트롤러는 복원된 AZ에 엔드포인트를 포함하도록 EndpointSlices를 업데이트합니다.

아래 다이어그램은 EKS 영역 이동이 클러스터 환경에서 건강한 포드 엔드포인트만 대상으로 삼도록 하는 방법에 대한 높은 수준의 흐름을 보여줍니다.

네트워크 트래픽 그림
네트워크 트래픽 그림

EKS 구역 교대 근무 요건

EKS에서 구역 이동이 성공적으로 작동하려면 AZ 장애에 탄력적으로 대응할 수 있도록 클러스터 환경을 미리 설정해야 합니다. 다음은 따라야 하는 단계의 목록입니다.

  • 여러 AZ에 걸쳐 클러스터의 워커 노드 프로비저닝하기

  • 단일 AZ의 제거를 견딜 수 있도록 충분한 컴퓨팅 용량 프로비저닝

  • 모든 AZ에서 포드(CoreDNS 포함) 사전 스케일링

  • 모든 AZ에 여러 포드 복제본을 분산하여 단일 AZ에서 이동해도 충분한 용량을 확보할 수 있도록 하세요.

  • 동일한 AZ에 상호 의존적이거나 관련된 포드를 공동 배치합니다.

  • 수동으로 구역 이동을 시작하여 클러스터 환경이 더 적은 AZ에서 예상대로 작동하는지 테스트합니다. 또는 구역별 자동 교대 근무를 활성화하고 자동 교대 근무 연습 실행에 응답할 수 있습니다. 영역 교대 근무가 EKS에서 작동하기 위해 반드시 필요한 것은 아니지만 강력히 권장됩니다.

여러 AZ에 걸쳐 EKS 워커 노드 프로비저닝하기

AWS 리전에는 가용성 영역(AZ)이라고 하는 물리적 데이터 센터가 있는 여러 개의 별도 위치가 있습니다. AZ는 리전 전체에 영향을 미칠 수 있는 동시 영향을 피하기 위해 서로 물리적으로 격리되도록 설계되었습니다. EKS 클러스터를 프로비저닝할 때는 리전 내 여러 AZ에 워커 노드를 배포해야 합니다. 이렇게 하면 클러스터 환경이 단일 AZ의 장애에 더 탄력적으로 대응하고 다른 AZ에서 실행 중인 애플리케이션의 고가용성(HA)을 유지할 수 있습니다. 영향을 받는 AZ에서 구역 이동을 시작하면 클러스터의 고가용성 상태를 유지하면서 정상 AZ만 사용하도록 EKS 환경의 클러스터 내 네트워크가 자동으로 업데이트됩니다.

EKS 환경에 이러한 다중 AZ를 설정하면 시스템의 전반적인 안정성을 향상시킬 수 있습니다. 그러나 multi-AZ 환경은 애플리케이션 데이터가 전송되고 처리되는 방식에 중요한 역할을 할 수 있으며, 이는 결국 환경의 네트워크 요금에 영향을 미칠 수 있습니다. 특히 잦은 이그레스 크로스존 트래픽(AZ 간에 분산되는 트래픽)은 네트워크 관련 비용에 큰 영향을 미칠 수 있습니다. 다양한 전략을 적용하여 EKS 클러스터의 포드 간 영역 간 트래픽 양을 제어하고 관련 비용을 절감할 수 있습니다. 고가용성 EKS 환경을 실행할 때 네트워크 비용을 최적화하는 방법에 대한 자세한 내용은 이 모범 사례 가이드를 참조하세요.

아래 다이어그램은 3개의 정상 AZ가 있는 고가용성 EKS 환경을 보여줍니다.

네트워크 그림

아래 다이어그램은 3개의 AZ가 있는 EKS 환경이 AZ 장애에도 복원력이 있고 다른 2개의 정상 AZ로 인해 높은 가용성을 유지하는 방법을 보여 줍니다.

네트워크 그림

단일 AZ 제거를 견딜 수 있는 충분한 컴퓨팅 용량 프로비저닝

EKS 데이터 플레인에서 컴퓨팅 인프라의 리소스 사용률과 비용을 최적화하려면 워크로드 요구 사항에 따라 컴퓨팅 용량을 조정하는 것이 가장 좋습니다. 그러나 모든 워커 노드가 최대 용량에 도달하면 새 포드를 예약하기 전에 새 워커 노드를 EKS 데이터 플레인에 추가해야 합니다. 중요한 워크로드를 실행할 때는 일반적으로 갑작스러운 부하 증가, 노드 상태 문제 등과 같은 비상 상황에 대처하기 위해 항상 온라인에서 여분의 용량을 확보하고 실행하는 것이 좋습니다. 영역 이동을 사용하려는 경우 전체 AZ의 용량을 제거할 계획이므로 AZ가 오프라인 상태에서도 부하를 충분히 처리할 수 있도록 여분의 컴퓨팅 용량을 조정해야 합니다.

컴퓨터를 확장할 시 EKS Data Plane에 새 노드를 추가하는 프로세스에는 시간이 다소 걸리며, 이는 특히 영역 장애가 발생할 경우 애플리케이션의 실시간 성능과 가용성에 영향을 미칠 수 있습니다. 최종 사용자나 클라이언트의 경험 저하를 방지하기 위해 EKS 환경은 AZ 손실로 인한 부하를 흡수할 수 있는 탄력성을 갖춰야 합니다. 즉, 새 포드가 필요한 시점과 워커 노드에서 실제로 예약되는 시점 사이의 지연을 최소화하거나 없애야 합니다.

또한 영역 장애가 발생하는 경우, 잠재적인 컴퓨팅 용량 제약으로 인해 새로 필요한 노드를 정상 AZ의 EKS 데이터 플레인에 추가할 수 없는 위험을 완화해야 합니다.

이를 위해, 특히 사용자 환경에 AZ가 하나 더 적은 경우, 각 AZ의 일부 워커 노드에서 컴퓨팅 용량을 오버프로비저닝하여 쿠버네티스 스케줄러가 새로운 포드 배치를 위해 기존 용량을 사용할 수 있도록 해야 한다.

여러 포드 복제본을 AZ에서 실행 및 확산하기

Kubernetes를 사용하면 단일 애플리케이션의 여러 인스턴스(포드 복제본)를 실행하여 워크로드를 사전 확장할 수 있습니다. 애플리케이션에 대해 여러 포드 복제본을 실행하면 단일 장애 지점을 제거하고 단일 복제본의 리소스 부담을 줄임으로써 전반적인 성능을 향상시킬 수 있습니다. 그러나 애플리케이션의 고가용성과 내결함성을 모두 확보하려면 애플리케이션의 여러 복제본을 여러 장애 도메인(이 경우 토폴로지 도메인이라고도 함)에 걸쳐 실행하고 분산시켜야 합니다(이 경우 AZ). 토폴로지 분산 제약 조건을 사용하면 기존 정적 안정성을 갖도록 애플리케이션을 설정할 수 있으므로 AZ 장애가 발생할 경우 정상 AZs에 추가 트래픽 급증 또는 급증을 즉시 처리할 수 있는 충분한 복제본을 보유할 수 있습니다.

아래 다이어그램은 모든 AZ가 정상일 때 동서 방향 트래픽 흐름이 있는 EKS 환경을 보여줍니다.

네트워크 그림

아래 다이어그램은 단일 AZ에 장애가 발생하여 구역 이동을 시작할 때 동서 방향 트래픽 흐름이 있는 EKS 환경을 보여 줍니다.

네트워크 그림

아래 코드 스니펫은 이 Kubernetes 기능으로 워크로드를 설정하는 방법의 예시입니다.

apiVersion: apps/v1 kind: Deployment metadata: name: orders spec: replicas: 9 selector: matchLabels: app:orders template: metadata: labels: app: orders tier: backend spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: orders

가장 중요한 것은 DNS 서버 소프트웨어(CoreDNS/kube-dns)의 여러 복제본을 실행하고 기본적으로 구성되지 않은 경우 유사한 토폴로지 확산 제약 조건을 적용해야 한다는 것입니다. 이렇게 하면 단일 AZ 장애가 발생하는 경우 클러스터의 다른 통신하는 포드에 대한 서비스 검색 요청을 계속 처리할 수 있도록 정상 AZ에 충분한 DNS 포드가 있는지 확인하는 데 도움이 됩니다. CoreDNS EKS 추가 기능에는 사용 가능한 AZs가 여러 개 있는 경우 클러스터의 가용 영역에 CoreDNS 포드가 분산되도록 하는 기본 설정이 있습니다. 이러한 기본 설정을 사용자 지정 구성으로도 바꿀 수 있습니다.

Helm에 CoreDNS를 설치할 때 value.yaml 파일replicaCount를 업데이트하여 각 AZ에 충분한 수의 복제본이 있는지 확인할 수 있습니다. 또한 이러한 복제본이 클러스터 환경의 여러 AZ에 분산되도록 하려면 동일한 values.yaml 파일에서 topologySpreadConstraints 속성을 업데이트해야 합니다. 아래 코드 스니펫은 이를 위해 CoreDNS를 구성하는 방법을 보여줍니다.

CoreDNS Helm values.yaml

replicaCount: 6 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: k8s-app: kube-dns

AZ 장애가 발생하는 경우, CoreDNS용 자동 확장 시스템을 사용하여 CoreDNS 포드의 증가된 부하를 흡수할 수 있습니다. 필요한 DNS 인스턴스 수는 클러스터에서 실행 중인 워크로드 수에 따라 달라집니다. CoreDNS는 수평 포드 오토스케일러(HPA)를 사용하여 CPU를 기반으로 확장할 수 있는 CPU 바인딩입니다. 아래는 필요에 맞게 수정할 수 있는 예시입니다.

apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: coredns namespace: default spec: maxReplicas: 20 minReplicas: 2 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: coredns targetCPUUtilizationPercentage: 50

또는 EKS는 CoreDNS의 EKS 애드온 버전에서 CoreDNS 배포의 자동 확장을 관리할 수 있습니다. 이 CoreDNS 오토스케일러는 노드 수와 CPU 코어 수를 포함하여 클러스터 상태를 지속적으로 모니터링합니다. 해당 정보를 기반으로 컨트롤러는 EKS 클러스터에서 CoreDNS 배포의 복제본 수를 동적으로 조정합니다.

CoreDNS EKS 추가 기능 에서 자동 크기 조정 구성을 활성화하려면 다음과 같은 선택적 구성 설정을 추가해야 합니다.

{ "autoScaling": { "enabled": true } }

NodeLocal DNS 또는 클러스터 비례 오토 스케일러를 사용하여 CoreDNS 를 조정할 수도 있습니다. 여기에서 CoreDNS 수평 확장에 대한 자세한 내용을 확인할 수 있습니다.

동일한 AZ에 상호 의존적인 포드 배치하기

대부분의 경우 엔드투엔드 프로세스의 성공적인 실행을 위해 서로 통신해야 하는 별개의 워크로드를 실행하고 있을 수 있습니다. 별개의 애플리케이션이 서로 다른 AZ에 분산되어 있지만 동일한 AZ에 배치되어 있지 않은 경우 단일 AZ 장애가 기본 엔드투엔드 프로세스에 영향을 미칠 수 있습니다. 예를 들어 애플리케이션 A가 AZ 1과 AZ 2에 여러 복제본을 가지고 있지만 애플리케이션 B는 모든 복제본을 AZ 3에 가지고 있는 경우, AZ 3의 손실은 이 두 워크로드(애플리케이션 A와 B) 간의 모든 엔드투엔드 프로세스에 영향을 미칩니다. 토폴로지 확산 제약 조건과 포드 선호도를 결합하면 모든 AZ에 포드를 확산하고 특정 포드 간의 관계를 구성하여 함께 코로케이션되도록 함으로써 애플리케이션의 복원력을 향상시킬 수 있습니다.

포드 선호도 규칙을 사용하면 워크로드 간의 관계를 정의하여 Kubernetes 스케줄러의 동작에 영향을 주어 동일한 작업자 노드 또는 동일한 AZ에서 포드를 공동 배치할 수 있습니다. 이러한 예약 제약 조건을 얼마나 엄격하게 설정할지 구성할 수도 있습니다.

apiVersion: apps/v1 kind: Deployment metadata: name: products namespace: ecommerce labels: app.kubernetes.io/version: "0.1.6" spec: serviceAccountName: graphql-service-account affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - orders topologyKey: "kubernetes.io/hostname"

다 다이어그램은 포드 선호도 규칙을 사용하여 동일한 노드에 공동 배치된 포드를 보여줍니다.

네트워크 그림

클러스터 환경이 AZ 손실을 처리할 수 있는지 테스트하기

위의 요구 사항을 완료한 후 다음 중요한 단계는 AZ 손실을 처리할 수 있는 충분한 컴퓨팅 및 워크로드 용량을 보유하고 있는지 테스트하는 것입니다. EKS에서 영역 이동을 수동으로 트리거하여 이 작업을 수행할 수 있습니다. 또는 영역 자동 시프트를 활성화하고 연습 실행을 구성하여 클러스터 환경에서 AZ를 하나 줄인 상태에서 애플리케이션이 예상대로 작동하는지 테스트할 수 있습니다.

FAQ

왜 이 기능을 사용해야 하나요?

EKS 클러스터에서 ARC 구역 이동 또는 구역 자동 이동을 사용하면 클러스터 내 네트워크 트래픽을 손상된 AZ에서 멀리 이동시키는 빠른 복구 프로세스를 자동화하여 Kubernetes 애플리케이션 가용성을 더 잘 유지할 수 있습니다. ARC를 사용하면 장애 발생 시 복구 기간이 길어지는 길고 복잡한 단계를 피할 수 있습니다.

이 기능은 다른 AWS 서비스에서 어떻게 작동하나요?

EKS는 AWS에서 복구 작업을 수행할 수 있는 기본 인터페이스를 제공하는 ARC와 통합됩니다. 클러스터 내 트래픽이 손상된 AZ에서 적절하게 라우팅되도록 하기 위해, Kubernetes 데이터 플레인에서 실행되는 포드의 네트워크 엔드포인트 목록을 수정한다. 외부 트래픽을 클러스터로 라우팅하기 위해 AWS 로드 밸런서를 사용하는 경우, 이미 로드 밸런서를 ARC에 등록하고 영역 이동을 트리거하여 성능 저하 영역으로 트래픽이 유입되는 것을 방지할 수 있습니다. 이 기능은 또한 EKS 관리형 노드 그룹(MNG)에 의해 생성된 Amazon EC2 자동 확장 그룹(ASG)과 상호 작용합니다. 손상된 AZ가 새로운 Kubernetes 포드 또는 노드 실행에 사용되지 않도록 하기 위해, EKS는 손상된 AZ를 ASG에서 제거한다.

이 기능은 기본 Kubernetes 보호와 어떻게 다른가요?

이 기능은 고객이 복원력을 유지하는 데 도움이 되는 여러 가지 Kubernetes 기본 제공 보호 기능과 함께 작동합니다. 포드가 트래픽을 수신해야 하는 시기를 결정하는 포드 준비 상태 및 활성 프로브를 구성할 수 있습니다. 이러한 프로브가 실패하면 쿠버네티스는 이러한 포드를 서비스의 대상으로 제거하고 트래픽은 더 이상 파드로 전송되지 않는다. 이 기능은 유용하지만, 고객이 이러한 상태 검사를 구성하여 영역이 저하될 때 실패하도록 하는 것은 간단하지 않습니다. ARC 구역 이동 기능은 Kubernetes의 기본 보호 기능으로 충분하지 않은 경우 성능 저하된 AZ를 완전히 격리하는 데 도움이 되는 추가적인 안전망을 제공합니다. 또한 아키텍처의 운영 준비 상태와 복원력을 쉽게 테스트할 수 있는 방법을 제공합니다.

AWS가 저를 대신하여 구역 이동을 트리거할 수 있나요?

예, ARC 구역 전환를 완전히 자동화된 방식으로 사용하려면 ARC 구역 자동 전환를 사용하도록 설정할 수 있습니다. 구역별 자동 교대 근무를 사용하면 AWS를 사용하여 EKS 클러스터의 AZ 상태를 모니터링하고 AZ 장애가 감지되면 자동으로 교대 근무를 트리거할 수 있습니다.

이 기능을 사용하는데 워커 노드와 워크로드가 사전 확장되지 않은 경우 어떻게 되나요?

사전 확장하지 않고 영역 이동 중에 추가 노드 또는 포드 프로비저닝에 의존하는 경우 복구가 지연될 위험이 있습니다. Kubernetes Data Plane에 새 노드를 추가하는 프로세스에는 시간이 다소 걸리며, 이는 특히 영역 장애가 발생할 경우 애플리케이션의 실시간 성능과 가용성에 영향을 미칠 수 있습니다. 또한 영역 장애가 발생하면 잠재적인 컴퓨팅 용량 제약이 발생하여 새로 필요한 노드를 정상 AZ에 추가하지 못할 수도 있습니다.

워크로드가 사전 확장되지 않고 클러스터의 모든 AZ에 분산되어 있는 경우, 영역 장애는 영향을 받는 AZ의 워커 노드에서만 실행되는 애플리케이션의 가용성에 영향을 미칠 수 있습니다. 애플리케이션의 완전한 가용성 중단 위험을 완화하기 위해 EKS는 워크로드의 모든 엔드포인트가 비정상적인 AZ에 있는 경우 트래픽이 손상된 영역의 포드 엔드포인트로 전송되지 않도록 하는 장애 세이프 기능을 제공합니다. 그러나 영역별 문제 발생 시 가용성을 유지하기 위해 애플리케이션을 사전 확장하고 모든 AZ에 분산하는 것이 좋습니다.

스테이풀 애플리케이션을 실행하면 어떻게 되나요?

상태 저장 애플리케이션을 실행하는 경우 사용 사례와 아키텍처에 따라 내결함성을 평가해야 합니다. 액티브/대기 아키텍처 또는 패턴이 있는 경우 액티브가 손상된 AZ에 있는 경우가 있을 수 있습니다. 애플리케이션 수준에서 대기 모드가 활성화되어 있지 않으면 애플리케이션에 문제가 발생할 수 있습니다. 정상 AZs에서 새 Kubernetes Pod가 시작되면 손상된 AZ에 한정된 영구 볼륨에 연결할 수 없으므로 문제가 발생할 수도 있습니다.

이 기능은 Karpenter와 함께 작동하나요?

현재 EKS의 ARC 구역 전환 및 영역 자동 전환에서는 Karpenter 지원을 사용할 수 없습니다. AZ가 손상된 경우, 새 워커 노드가 정상 AZ에서만 시작되도록 비정상적인 AZ를 제거하여 관련 Karpenter 노드풀 구성을 조정할 수 있습니다.

이 기능은 EKS Fargate에서 작동하나요?

이 기능은 EKS Fargate에서 작동하지 않습니다. 기본적으로 EKS Fargate가 영역 상태 이벤트를 인식하면 포드는 다른 AZ에서 실행되는 것을 선호합니다.

EKS 관리형 Kubernetes 컨트롤 플레인이 영향을 받나요?

아니요, 기본적으로 Amazon EKS는 고가용성을 보장하기 위해 여러 AZ에서 Kubernetes 컨트롤 플레인을 실행하고 확장합니다. ARC 영역 시프트 및 영역 자동 시프트는 Kubernetes 데이터 플레인에서만 작동합니다.

이 새로운 기능과 관련된 비용이 있습니까?

EKS 클러스터에서 추가 비용 없이 ARC 구역 교대근무 및 구역 자동 교대근무를 사용할 수 있습니다. 그러나 프로비저닝된 인스턴스에 대한 비용은 계속 지불해야 하며, 이 기능을 사용하기 전에 Kubernetes 데이터 플레인을 사전 확장하는 것이 좋습니다. 비용과 애플리케이션 가용성 간의 적절한 균형을 고려해야 합니다.

추가 리소스

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.